Qu’appelle-t-on la mémoire d’un agent IA ?
La mémoire d’un agent est l’ensemble des informations qu’il conserve au-delà de la tâche en cours et qu’il pourra réintroduire dans son contexte plus tard. Ce n’est pas un espace de stockage passif : ce qui y entre peut orienter une réponse, un choix d’outil ou une action, des semaines après y avoir été inscrit.
Le mot recouvre en réalité quatre mécanismes qu’on gagne à ne pas confondre, parce qu’ils n’ont ni la même durée de vie ni le même niveau de fiabilité.
| Type de mémoire | Ce qu’elle contient | Horizon |
|---|---|---|
| Contexte immédiat | Conversation en cours, instructions, documents récupérés, résultats d’outils | La tâche |
| Mémoire utilisateur | Préférences, habitudes, paramètres, décisions antérieures | Plusieurs sessions |
| Mémoire de travail | État d’une tâche longue : étapes faites, erreurs rencontrées, reste à faire | La durée de la tâche |
| Mémoire organisationnelle | Connaissances tirées de l’activité des agents, réutilisables par d’autres | Indéterminé |
Le contexte immédiat relève du Context Engineering, c’est-à-dire de la sélection de ce que le modèle voit réellement. Les trois autres posent une question différente : non plus ce qu’on montre à l’agent maintenant, mais ce qu’on l’autorise à garder.
Le vrai risque : une erreur ponctuelle devient un état permanent
Prenons un agent qui assiste une équipe commerciale. À la suite d’un échange ambigu, il retient qu’un client refuse systématiquement les remises. La conversation se termine, l’incident est clos.
Trois semaines plus tard, un commercial lui demande de préparer une proposition pour ce même client. L’information mémorisée revient dans le contexte et pèse sur la proposition. Le modèle n’a rien halluciné cette fois-ci : il exploite correctement une information fausse enregistrée plus tôt.
Sans mémoire, une mauvaise information disparaît avec la conversation. Avec une mémoire persistante, elle devient une instruction implicite pour toutes les conversations suivantes.
L’enjeu change encore de nature quand l’agent peut agir. Une mémoire erronée n’influence plus seulement une réponse : elle peut orienter le choix d’un outil, d’un destinataire ou d’une procédure.
Microsoft traite désormais l’empoisonnement de mémoire comme une technique d’attaque à part entière des systèmes agentiques. Le principe en est simple et c’est ce qui le rend redoutable : un contenu malveillant n’a pas besoin de réussir toute l’attaque dans une seule interaction. Il lui suffit d’obtenir l’inscription d’une information persistante, qui produira son effet plus tard, dans une session où plus personne ne fera le lien avec le document d’origine. C’est le prolongement direct des questions traitées dans la sécurité des agents IA en entreprise, avec une différence : le contenu malveillant ne fait pas que passer, il laisse une trace.
Une mémoire sans provenance ne se gouverne pas
Une information mémorisée ne devrait jamais être traitée comme une vérité brute. Elle devrait porter avec elle de quoi décider s’il faut encore lui faire confiance.
Concrètement, six attributs suffisent à rendre une mémoire interrogeable.
| Attribut | La question à laquelle il répond |
|---|---|
| Source | D’où vient cette information ? |
| Date | Quand a-t-elle été enregistrée ? |
| Auteur | Utilisateur, système, document ou agent ? |
| Niveau de confiance | Confirmée explicitement, ou seulement déduite ? |
| Durée de vie | Doit-elle encore servir dans six mois ? |
| Périmètre | Pour quelles tâches peut-elle être mobilisée ? |
La distinction entre une information confirmée et une information déduite mérite qu’on s’y arrête. « Le client a demandé à être contacté par courriel » et « le client semble préférer le courriel » ne se valent pas, et pourtant rien ne les distingue une fois qu’elles sont écrites dans la même table sous la même forme. Un agent qui ne conserve pas cette nuance finira par présenter une inférence comme un fait.
Qui écrit dans la mémoire, et avec quelle autorité ?
C’est la question qui sépare une mémoire d’un index documentaire. Un index est constitué par des humains qui ont choisi d’y verser des documents. Une mémoire est écrite par le système lui-même, souvent par l’agent, parfois à partir d’un contenu qu’il vient de lire.
Trois chemins d’écriture coexistent dans la plupart des implémentations, et ils n’ont pas le même degré de fiabilité.
| Chemin d’écriture | Ce qui est inscrit | Fiabilité |
|---|---|---|
| Déclaration explicite | L’utilisateur énonce une préférence ou une règle | Élevée, la source est identifiée |
| Déduction du système | Une régularité observée dans les usages | Moyenne, c’est une hypothèse |
| Conclusion tirée d’un contenu | Une information extraite d’un document ou d’un message | Faible, la source n’est pas toujours de confiance |
La conséquence pratique tient en une règle d’architecture : un agent qui vient de lire un contenu externe ne devrait pas pouvoir écrire dans la mémoire persistante au cours du même tour. Séparer la lecture de l’écriture supprime le chemin le plus court entre un document piégé et une instruction durable. C’est contraignant, et c’est nettement moins coûteux que de devoir un jour auditer une mémoire pour retrouver laquelle de ses entrées y a été introduite par un tiers.
Un bon système de mémoire décide aussi ce qu’il oublie
L’intuition première consiste à tout garder, au cas où. C’est exactement l’inverse de ce qu’il faut faire, pour une raison qui n’est pas seulement réglementaire : plus la mémoire grossit, plus elle contient d’informations obsolètes qui continuent pourtant de peser sur les décisions.
Une préférence utilisateur reste souvent valable plusieurs mois. Le résultat intermédiaire d’une tâche n’a de valeur que quelques heures. Une donnée sensible n’a parfois aucune raison d’entrer dans une mémoire persistante, et la question rejoint alors celle de ce que vos données deviennent quand elles entrent dans un LLM. Une information déduite par le modèle gagne à être confirmée avant d’être inscrite.
La question n’est donc pas « comment donner une mémoire à notre agent ? » mais « qu’a-t-il le droit de retenir, sur quelle base, et pendant combien de temps ? ».
Une mémoire doit pouvoir être contredite
Un utilisateur qui constate que l’agent se trompe à son sujet a besoin d’un endroit où corriger l’information. Le contredire dans une conversation ne suffit pas : la conversation se termine, la mémoire reste. Sans écran de consultation et de correction, la seule façon de réparer une mémoire fausse consiste à ouvrir un ticket, ce qui n’arrive jamais.
Il y a aussi une raison réglementaire de prévoir ces écrans dès la conception. Le RGPD ne connaît pas la notion de mémoire d’agent. Il connaît celle de donnée à caractère personnel, et ses articles 15 à 17 ouvrent des droits d’accès, de rectification et d’effacement qui s’exercent sur elle où qu’elle réside. Notre lecture est que cela englobe les représentations qu’un système en conserve, base vectorielle ou résumé produit par un modèle, même si le texte ne les nomme pas. Une architecture qui ne sait pas énumérer ce qu’elle a retenu d’une personne ne saura pas non plus l’effacer sur demande.
Trois erreurs qui reviennent souvent : cache, conclusions, absence de date
Confondre mémoire et cache. Un cache accélère un calcul dont le résultat serait identique sans lui. Une mémoire modifie le résultat. Les deux se stockent de la même façon et ne relèvent pas du tout de la même gouvernance.
Mémoriser des conclusions plutôt que des faits. « Ce client est difficile » est une conclusion, et elle survivra longtemps à la situation qui l’a produite. « Ce client a refusé la proposition du 12 mars » est un fait, daté, que la suite pourra contredire. La première forme est plus commode à réutiliser, la seconde est la seule qui reste vraie.
Ne pas horodater. Une mémoire sans date ne vieillit pas, ce qui veut dire qu’elle ne peut jamais être écartée pour obsolescence. Elle pèsera sur les décisions avec le même poids dans deux ans qu’aujourd’hui.
Les cinq questions à trancher avant d’activer une mémoire persistante
La troisième question est celle qu’on oublie le plus souvent, et c’est aussi celle qui rend la mémoire auditable : ce qu’aucun écran ne permet de consulter, personne ne pourra le vérifier, ce qui ramène aux exigences de traçabilité décrites dans rendre chaque action d’un agent reconstituable.
La cinquième est celle qui engage. Si la réponse est oui, la mémoire a cessé d’être une commodité de confort : elle est devenue un maillon de la chaîne de décision, et elle relève dès lors de qui répond des décisions prises par le système.
Sans ces cinq réponses, la mémoire devient un problème de gouvernance
Une mémoire activée sans ces cinq réponses n’est plus un problème d’architecture. C’est un problème de gouvernance qu’on a résolu techniquement sans l’avoir posé.
Notre position est simple : une mémoire persistante ne s’active pas parce qu’elle est disponible dans l’outillage, elle s’active parce qu’une tâche précise en a besoin. Commencer sans mémoire, constater ce que l’agent redemande à chaque session, puis n’ouvrir que ce périmètre coûte moins cher que de tout mémoriser et de devoir ensuite décider quoi effacer.
À retenir
La mémoire est ce qui rend un agent utile sur des tâches longues et répétées. Elle modifie aussi son modèle de risque en profondeur, parce qu’elle transforme des événements ponctuels en état durable du système.
La vraie question n’est pas de savoir si les agents auront une mémoire, mais qui décide de ce qu’ils ont le droit de retenir, et de ce qu’ils doivent oublier.
