La mémoire d’un agent IA n’est pas ce que le modèle « sait ». C’est le choix de conserver une information après une interaction pour la réutiliser plus tard. Avant d’activer cette persistance, il faut donc écrire un contrat : ce qui reste dans la tâche en cours, ce qui sera relu dans le système de référence, ce qui peut devenir un souvenir durable et ce qui doit expirer ou ne jamais être écrit.

Ce tri évite un piège fréquent : appeler « mémoire » tout ce qui donne du contexte à l’agent. Une base de connaissances contient des documents que l’agent peut consulter. Le CRM ou l’ERP reste le système de référence pour l’état métier vivant. Le journal d’audit sert à comprendre une exécution. La mémoire durable, elle, réinjecte une information sélectionnée dans une décision future.

Une mémoire utile n’est pas tout l’historique

Garder chaque conversation paraît simple. C’est pourtant une mauvaise politique par défaut. Une remarque ponctuelle peut être prise pour une préférence stable. Un ancien statut peut rivaliser avec le CRM. Une donnée non vérifiée peut survivre à la tâche qui l’a produite.

La note exploratoire publiée par la CNIL et le CIANum en juillet 2026 décrit ce changement d’échelle : la mémoire persistante peut accumuler et enrichir des données personnelles, les disperser entre plusieurs espaces et rendre plus difficile la compréhension de ce qui est gardé, pendant combien de temps et par qui. La note évoque notamment le cloisonnement, la limitation et l’expiration comme pistes de maîtrise. Elle ne crée pas une nouvelle règle autonome et ne remplace pas une analyse juridique adaptée au traitement.[1]

La bonne question n’est donc pas « combien de mémoire peut-on stocker ? », mais « quelle information mérite d’influencer une tâche future, sous quelle autorité, et comment la corriger ou la retirer ? »

Quatre responsabilités à ne pas mélanger

Espace Ce qu’il contient Autorité Sortie normale
État de tâche Les éléments nécessaires à l’action en cours La tâche et sa session Fin de tâche ou expiration de session
Système de référence Le statut métier vivant : dossier, rôle, disponibilité, commande L’application métier propriétaire Mise à jour dans l’application, puis nouvelle lecture
Mémoire durable Une préférence ou décision stable, sourcée et réutilisable Un propriétaire métier nommé Correction, remplacement, expiration ou suppression
Journal d’audit La preuve de ce que l’agent a lu, décidé et tenté La politique d’exploitation et d’audit Rétention et accès séparés de la mémoire de rappel

Microsoft distingue lui aussi historique de conversation, état de session, fournisseurs de contexte et persistance applicative dans sa documentation Agent Framework.[5] Sa documentation de gouvernance traite séparément identité, cycle de vie, observabilité et données, avec des décisions explicites sur l’accès, le stockage et la rétention.[4] Le mot « mémoire » ne suffit donc pas dans un cahier des charges : il faut demander où chaque état vit et quelle source fait foi.

Une trace d’audit ne doit pas devenir automatiquement un souvenir. Elle peut être nécessaire pour analyser une exécution, sans être pertinente ni autorisée pour guider la prochaine réponse. C’est la frontière avec l’observabilité d’un agent IA : les traces expliquent ce qui s’est passé ; la mémoire sélectionne ce qui sera rappelé.

La matrice : éphémère, relire, persister ou oublier

Le tri doit produire une décision, pas une catégorie décorative. Les six cas ci-dessous sont synthétiques et ne contiennent aucune donnée réelle :

Information candidate Décision Pourquoi
Les pièces ouvertes pour préparer une réponse en cours Éphémère Elles servent la tâche présente, pas les suivantes
Le statut actuel d’un dossier Relire à la source Il peut changer hors de l’agent ; l’application métier reste l’autorité
Une préférence de format confirmée par l’utilisateur Persister, avec portée et correction Elle peut éviter une répétition si sa finalité et son propriétaire sont clairs
Une contrainte projet valable jusqu’à une date connue Persister avec expiration Elle reste utile dans ce périmètre, puis doit cesser d’agir
Une procédure versionnée Relire à la source La copie mémorisée deviendrait silencieusement obsolète
Un résumé proposé par l’agent puis refusé Oublier, ne pas écrire Il n’est ni validé ni utile comme autorité future

Cette matrice pousse à mémoriser moins. Le statut d’un dossier, un rôle ou une disponibilité se relisent au moment de l’action. La mémoire peut conserver un pointeur vers la bonne source ou une préférence stable, pas une copie silencieuse d’un état qui continue de bouger.

Le choix d’un LLM local ou d’un hébergement particulier ne tranche pas cette question. Le cycle de vie de l’information reste à définir, quel que soit l’endroit où tourne le modèle.

Le contrat mémoire tient en sept champs

Chaque type d’information autorisé à entrer en mémoire doit avoir une fiche courte :

  1. Finalité : quelle tâche future justifie le rappel ? « Personnaliser » est trop vague.
  2. Source : utilisateur, système de référence, décision validée ou calcul dérivé ?
  3. Propriétaire : qui répond de la définition et peut décider qu’elle n’est plus utile ?
  4. Portée : pour quel utilisateur, projet, équipe ou processus la donnée peut-elle revenir ?
  5. Validité : quel événement ou quelle date force une relecture, une expiration ou une revue ?
  6. Correction : comment remplace-t-on une valeur sans laisser l’ancienne rivaliser avec la nouvelle ?
  7. Suppression et sortie : comment demander le retrait, exporter ce qui est visible et vérifier les magasins concernés ?

Cette fiche ne fixe aucune durée universelle. Une durée pertinente dépend de la finalité, du métier, des obligations applicables et de l’architecture réelle. Elle oblige simplement à faire apparaître la décision au lieu de laisser un composant technique la prendre par défaut.

Les contrôles produit peuvent rendre ce contrat compréhensible. Anthropic documente par exemple une mémoire optionnelle, séparée par projet, visible et éditable, ainsi qu’un mode de conversation qui ne l’alimente pas. C’est un exemple de choix d’interface, pas un benchmark ni une recommandation de fournisseur.[6]

Le contrat mémoire à une page : définir l'information autorisée, son autorité, sa validité, sa correction et sa sortie, puis tester le cycle écrire, rappeler, corriger, expirer et vérifier.

Écrire moins, avec provenance

Une écriture mémoire devrait être un événement contrôlé. Avant d’écrire, l’agent ou le workflow doit pouvoir répondre à trois questions : l’information est-elle vérifiée, sa future utilisation est-elle prévue, et la portée est-elle explicite ?

Il faut aussi distinguer des objets qui se ressemblent dans une conversation :

  • un fait vérifié n’est pas une inférence produite par le modèle ;
  • une préférence confirmée n’est pas une remarque faite une fois ;
  • une consigne adressée à la tâche n’est pas une donnée sur la personne ;
  • une ancienne valeur remplacée n’est pas un second avis à conserver « au cas où ».

Quand une information change, l’ancienne version doit être remplacée ou invalidée avec une date d’effet. Empiler « préfère les synthèses courtes » puis « demande maintenant le détail » sans règle de priorité crée deux souvenirs plausibles. Le problème ressortira plus tard, au moment le moins visible.

Une entrée hostile ne doit pas devenir un souvenir de confiance

L’OWASP classe le memory poisoning parmi les risques propres aux agents : une donnée malveillante ou trompeuse peut être persistée puis influencer de futures sessions ou d’autres utilisateurs. Son aide-mémoire recommande notamment de valider les écritures, d’isoler les mémoires entre utilisateurs ou sessions, de limiter leur taille, de prévoir une expiration et d’auditer les contenus sensibles avant persistance.[2]

Un article OWASP du 13 mai 2026 insiste sur le saut de confiance : une entrée hostile ponctuelle devient plus dangereuse quand elle atteint un espace persistant que le système consulte encore après la session initiale.[3] Le contenu rappelé doit donc rester traité comme une donnée, avec sa provenance et sa portée, pas comme une nouvelle instruction de confiance.

Le détail des droits d’outils et des contenus externes appartient au chantier sur l’injection de prompt indirecte. Ici, le contrôle spécifique est plus étroit : aucune entrée non fiable ne passe en mémoire durable sans validation d’écriture.

Tester tout le cycle, pas seulement le rappel

Un test qui demande « l’agent se souvient-il ? » ne couvre que le chemin heureux. Le protocole doit exercer le cycle complet :

  1. écrire une préférence synthétique autorisée et vérifier sa provenance ;
  2. la rappeler dans la bonne portée ;
  3. vérifier qu’elle ne revient pas pour un autre utilisateur ou projet ;
  4. modifier la source et confirmer que la règle d’autorité gagne ;
  5. corriger la préférence sans obtenir deux valeurs concurrentes ;
  6. atteindre l’expiration prévue et vérifier l’absence de rappel ;
  7. demander la suppression, puis vérifier que le comportement futur change ;
  8. tenter de faire persister une instruction issue d’un document non fiable et confirmer le refus.

Ces scénarios complètent une évaluation d’agent avant production. Ils ne remplacent pas les tests de permissions, de qualité générale ou de réponse à incident. Si une mauvaise mémoire a déjà provoqué une action, le traitement relève du plan de réponse à incident ; le contrat sert à rendre la correction, l’invalidation et la suppression possibles avant ce moment.

Attention au mot « suppression ». La disparition dans une interface ne prouve pas à elle seule l’effacement de chaque copie, index, sauvegarde ou journal dérivé. Le test doit nommer les magasins couverts et les limites connues, sans promettre un effacement absolu que l’architecture ne démontre pas.

Checklist d’achat ou de cadrage

Avant d’accepter une option « mémoire persistante », demandez :

  • où vivent l’historique, l’état de session, la mémoire durable et les traces ;
  • qui peut écrire sans validation, et à partir de quelles sources ;
  • quelle identité et quelle portée accompagnent chaque écriture ;
  • quelle source gagne en cas de contradiction ;
  • qui peut voir, corriger, invalider et supprimer un souvenir ;
  • comment une expiration est appliquée et vérifiée ;
  • ce qui est exportable à la fin du service ;
  • quels magasins dérivés subsistent après une suppression visible ;
  • comment les tests prouvent l’isolation, la correction et l’oubli.

Une réponse comme « le vector store garde le contexte » n’est pas suffisante. Elle décrit un composant, pas le contrat de réutilisation.

Votre agent doit garder le fil entre deux tâches, sans garder tout le reste ? Last Word peut cartographier l’état de tâche, les systèmes de référence, les écritures mémoire, les règles de rappel et les chemins de correction avant le prototype. Consultez le service agent IA support, voyez comment cadrer l’automatisation du processus ou décrivez votre besoin.

Questions fréquentes

Que doit mémoriser un agent IA ?

Seulement une information utile à une tâche future, issue d’une source identifiée, possédée par un responsable, limitée à une portée claire, assortie d’une règle de validité, de correction et de suppression. L’état métier qui change doit généralement être relu dans le système de référence plutôt que copié en mémoire.

Quelle différence entre mémoire d’agent et base de connaissances ?

La base de connaissances rassemble les documents que l’agent peut consulter. La mémoire durable contient des informations sélectionnées après une interaction pour les réutiliser plus tard. Le CRM reste l’autorité pour l’état métier vivant et le journal d’audit conserve la preuve d’exécution. Ces quatre rôles ne devraient pas partager une politique implicite unique.[4][5]

Faut-il conserver tout l’historique des conversations ?

Non. L’historique peut contenir des remarques ponctuelles, des états dépassés, des données inutiles ou des inférences non validées. La persistance doit répondre à une finalité explicite ; le reste reste éphémère, est relu à la source ou n’est pas écrit.[1]

Comment éviter qu’une mémoire d’agent devienne obsolète ?

Donnez à chaque type de souvenir une source, une date ou un événement de validité et une règle de remplacement. Pour un statut vivant, ne mémorisez pas la valeur : relisez l’application métier. Lors d’une correction, invalidez l’ancienne valeur au lieu d’empiler deux versions concurrentes.

Comment tester l’oubli d’un agent IA ?

Demandez la suppression dans le périmètre prévu, relancez une tâche qui aurait rappelé l’information et vérifiez que le comportement a changé. Contrôlez séparément les magasins couverts par la suppression. Une valeur disparue de l’interface ne prouve pas automatiquement l’effacement de toutes les copies dérivées.

Sources

[1] https://www.cnil.fr/sites/default/files/2026-07/ia-cianum-cnil.pdf, CNIL / CIANum, « IA agentique et protection des données personnelles : équation à inconnues multiples pour les utilisateurs », note exploratoire de juillet 2026, consultée le 4 septembre 2026.

[2] https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html, OWASP Cheat Sheet Series, « AI Agent Security Cheat Sheet », date de mise à jour non affichée, consulté le 4 septembre 2026.

[3] https://genai.owasp.org/2026/05/13/memory-is-a-feature-it-is-also-an-attack-surface, OWASP GenAI Security Project, « Memory Is a Feature. It Is Also an Attack Surface », 13 mai 2026, consulté le 4 septembre 2026.

[4] https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ai-agents/governance-security-across-organization, Microsoft Learn, « Govern and secure AI agents across the organization », date de mise à jour non affichée, consulté le 4 septembre 2026.

[5] https://learn.microsoft.com/en-us/agent-framework/get-started/memory, Microsoft Learn, « Memory and persistence », mise à jour le 25 août 2026, consulté le 4 septembre 2026.

[6] https://www.anthropic.com/news/memory, Anthropic, « Bringing memory to Claude », publié le 11 septembre 2025 et mis à jour le 23 octobre 2025, consulté le 4 septembre 2026.