Publié le 20 octobre 2026
« Donner une mémoire à l’agent » fait partie de ces exigences qui paraissent simples jusqu’au moment de les implémenter. En pratique, la mémoire n’est pas une seule fonctionnalité — c’est un ensemble de mécanismes différents qui résolvent des problèmes différents, et les confondre est l’une des raisons les plus courantes pour lesquelles les agents AI en production oublient des choses qu’ils ne devraient pas, ou retiennent des éléments qui les rendent plus lents, plus coûteux et parfois erronés.
Avant d’ajouter de la mémoire à un agent, il vaut la peine d’être précis sur le type de mémoire réellement nécessaire à une tâche donnée, car la mémoire à court terme et la mémoire à long terme dans les systèmes d’agents ne sont pas simplement « la même chose à des échelles de temps différentes » — ce sont des problèmes architecturaux différents.
Mémoire à court terme : gérer la fenêtre de contexte
La mémoire à court terme d’un agent, en pratique, c’est la gestion de la fenêtre de contexte : ce qui est inclus dans le prompt pour la tâche en cours afin que le modèle dispose de ce qu’il lui faut pour agir. Cela comprend les derniers échanges de la conversation, les résultats des appels d’outils effectués plus tôt dans la même session, ainsi que tout raisonnement intermédiaire que l’agent doit garder en mémoire pendant l’exécution d’une tâche en plusieurs étapes.
Le défi ici n’est pas le stockage — c’est la pertinence et le coût. Chaque token dans la fenêtre de contexte coûte de l’argent et mobilise de l’attention ; déverser tout l’historique de la conversation et chaque résultat d’outil dans chaque appel suivant dégrade les performances et fait grimper la latence comme les dépenses. Les systèmes d’agents en production ont généralement besoin d’une stratégie claire pour décider ce qui reste dans le contexte actif : résumer les anciens échanges, supprimer les sorties d’outils une fois leur résultat intégré à la décision, et ne récupérer les détails à nouveau que lorsqu’ils sont réellement nécessaires, plutôt que de les conserver en mémoire « au cas où ».
Mémoire à long terme : ce qui doit persister d’une session à l’autre
La mémoire à long terme est un problème entièrement différent : que doit encore savoir l’agent la prochaine fois qu’il est sollicité, potentiellement des jours ou des semaines plus tard, dans une autre session, éventuellement pour un autre utilisateur ou une autre tâche ? C’est là que se prennent la plupart des décisions architecturales, parce que la mémoire à long terme doit répondre à des questions comme :
- S’agit-il d’un fait propre à un utilisateur ou à un client précis (préférences, historique, décisions passées) qui doit être récupéré à la demande, et non chargé en bloc à chaque fois ?
- S’agit-il d’un fait lié à l’entreprise ou au domaine (politiques, catalogue de produits, résultats passés) qui doit vivre dans un dépôt de connaissance partagé plutôt que d’être rattaché à une seule conversation ?
- S’agit-il d’un état opérationnel — l’endroit où un workflow en plusieurs étapes s’est interrompu — qui doit survivre à un redémarrage ou à un transfert vers une autre instance d’agent ?
Chacun de ces cas tend à correspondre à un pattern de stockage différent : un vector store ou une base de données structurée pour la mémoire fondée sur la récupération (la mécanique est la même que celle de retrieval-augmented generation), un enregistrement relationnel pour le workflow et l’état opérationnel, et parfois un simple magasin clé-valeur pour des faits petits et fréquemment consultés qui n’ont pas besoin de recherche sémantique du tout.
Pourquoi « tout stocker et tout récupérer » ne fonctionne pas bien
Une erreur fréquente au début consiste à traiter la mémoire à long terme comme un réservoir indifférencié : chaque interaction est vectorisée et stockée, puis chaque nouvelle tâche récupère des mémoires « pertinentes » par recherche de similarité. Cela a tendance à se dégrader d’une manière précise et prévisible à mesure que le magasin de mémoire grandit — la récupération commence à faire remonter des faits plausibles mais obsolètes ou contradictoires, et le comportement de l’agent devient plus difficile à interpréter parce que personne ne peut dire avec certitude ce qu’il « sait » à un instant donné.
Les systèmes de mémoire en production ont besoin de la même rigueur que n’importe quel autre magasin de données : les faits doivent avoir une source claire, un moyen d’être mis à jour ou invalidés lorsqu’ils changent, et idéalement un périmètre qui limite ce qui est injecté dans une tâche donnée. Un agent qui gère le support client n’a pas besoin d’un accès sans restriction à chaque mémoire jamais stockée sur chaque client — il a besoin des bonnes mémoires, limitées au client et à la tâche en cours, récupérées de manière ciblée plutôt que déversées en bloc.
Les garde-fous comptent plus pour la mémoire que pour la plupart des autres composants d’agent
La mémoire est aussi l’endroit où une grande partie des questions les plus difficiles de garde-fous en conception d’agents apparaissent réellement. Si un agent peut écrire dans sa propre mémoire à long terme, qu’est-ce qui l’empêche d’y stocker une information incorrecte puis d’agir à plusieurs reprises sur cette fausse donnée lors de sessions futures ? Si la mémoire persiste d’un utilisateur ou d’un tenant à l’autre, qu’est-ce qui empêche les données d’un utilisateur de fuir dans le contexte d’un autre via un magasin de récupération partagé ? Ce ne sont pas des cas marginaux — ce sont des questions standards dans toute conception de mémoire en production, et elles doivent recevoir une réponse avant qu’un agent ne soit mis en ligne avec un accès d’écriture à sa propre mémoire, et non après un incident.
Un cadre pratique pour décider ce qu’un agent doit retenir
Plutôt que de partir du principe qu’il faut « tout stocker », il est plus utile de classer ce qu’un agent donné doit retenir en trois catégories et de concevoir le stockage en conséquence pour chacune :
- Mémoire limitée à la tâche — n’existe que pendant la durée d’une tâche ou d’une session, puis est supprimée. Aucune infrastructure particulière n’est nécessaire au-delà d’une gestion rigoureuse du contexte.
- Mémoire limitée à l’entité — des faits liés à un client, un dossier ou un enregistrement précis, récupérés chaque fois que cette entité réapparaît. C’est la forme la plus courante de mémoire long terme « utile » dans les agents métier.
- Mémoire limitée au domaine — des connaissances partagées qui s’appliquent à toutes les tâches et à tous les utilisateurs, généralement mieux prises en charge par une base de connaissances dédiée ou un système RAG que par le mécanisme de mémoire propre à l’agent.
La plus grande part de la valeur de la mémoire des agents vient d’une mémoire limitée à l’entité bien conçue — fiable, avec des règles claires de mise à jour et d’invalidation — plutôt que d’une architecture de mémoire généraliste de plus en plus sophistiquée qui tente de traiter les trois cas de façon identique.
Par où commencer
Si vous construisez ou évaluez un système d’agents et que la mémoire revient sans cesse comme une exigence floue, l’exercice utile consiste à passer en revue les tâches réelles que l’agent doit accomplir et à se demander, pour chacune, ce qu’il doit réellement retenir et à partir de quelle source. Le plus souvent, cet exercice révèle que l’agent a bien moins besoin de « mémoire » au sens générique et beaucoup plus besoin d’une récupération précise depuis un petit nombre de sources bien définies — ce qui est un système bien plus simple et plus fiable à construire et à maintenir. Nous aidons les équipes à concevoir des architectures d’agents, y compris les couches de mémoire et de récupération, capables de tenir sous une vraie charge de production ; contactez-nous si vous travaillez sur votre propre projet d’agent.
Lié