Mémoire d’un agent IA : architecture, rétention et contrôle

La mémoire d’un agent IA n’est pas une propriété magique du modèle. C’est un système applicatif qui décide quoi conserver, sous quelle forme, pour qui, pendant combien de temps et à quel moment une information peut revenir dans le contexte. Si cette couche enregistre tout par défaut, elle accumule des erreurs, des données sensibles et des instructions hostiles. Si elle ne conserve rien, l’utilisateur répète son contexte et les tâches longues deviennent difficiles à reprendre.

La bonne architecture ne commence donc pas par une base vectorielle. Elle commence par quatre objets séparés : la conversation récente, l’état d’une tâche, les préférences durables d’une personne et les connaissances validées de l’organisation. Chacun possède sa propre source de vérité, son périmètre d’accès, sa durée et sa procédure de correction.

Réponse en bref

Pour concevoir la mémoire d’un agent IA :

1. nommez la décision que chaque mémoire doit améliorer ;
2. séparez historique de conversation, état d’exécution, préférences et connaissances ;
3. définissez un contrat contenant finalité, portée, provenance, sensibilité, durée, version et propriétaire ;
4. contrôlez l’écriture avant la persistance, au lieu d’enregistrer automatiquement toute phrase ;
5. contrôlez aussi le rappel : identité, autorisation, pertinence, fraîcheur et compatibilité avec la tâche ;
6. traitez une mémoire rappelée comme une donnée candidate, jamais comme une instruction prioritaire ;
7. isolez les enregistrements par organisation, personne, agent et tâche avec des contrôles techniques ;
8. rendez possibles la consultation, la correction, l’expiration et l’effacement ;
9. testez les erreurs persistantes : empoisonnement, information obsolète, fuite entre utilisateurs et suppression incomplète ;
10. mesurez ce que la mémoire améliore et ce qu’elle coûte en erreurs, délai, stockage et revue.

La prochaine action utile consiste à prendre un seul scénario et à remplir le contrat de mémoire présenté plus bas. Si l’équipe ne peut pas justifier pourquoi une information doit survivre à la session, elle ne doit pas encore la rendre durable.

Le modèle ne porte pas la mémoire de l’application

Une requête isolée à un modèle ne connaît pas automatiquement les échanges précédents. L’application peut renvoyer l’historique, chaîner des réponses, utiliser un objet de conversation ou reconstruire un contexte. La documentation officielle OpenAI présente précisément plusieurs manières de gérer cet état. Cette continuité technique ne décide toutefois pas quelles informations méritent de devenir des souvenirs durables.

Il faut distinguer trois opérations :

• conserver : stocker un événement ou un état hors du contexte immédiat ;
• sélectionner : choisir ce qui peut être pertinent pour une nouvelle tâche ;
• injecter : présenter cette information au modèle pendant l’exécution.

Une base pleine ne signifie pas que l’agent se souvient correctement. Un rappel fiable dépend de la portée, de la fraîcheur, de l’autorisation et de la capacité à reconnaître une contradiction. La mémoire devient donc une chaîne de décisions, pas un simple disque attaché au modèle.

Cette frontière est importante pour la responsabilité. La note exploratoire publiée en juillet 2026 par la CNIL et le CIANum cite la mémoire persistante parmi les caractéristiques qui compliquent la maîtrise des systèmes agentiques, avec l’autonomie, l’interaction entre services et l’action au nom de l’utilisateur. Une donnée conservée aujourd’hui peut influencer une action bien plus tard, dans un contexte que la personne n’avait pas anticipé.

Séparer quatre objets avant de choisir le stockage

1. La conversation récente

Elle contient les tours nécessaires pour comprendre la demande actuelle : questions, réponses, résultats d’outils et décisions intermédiaires. Sa portée naturelle est une session ou un fil. Elle peut être limitée aux derniers éléments, résumée ou supprimée à la clôture.

La conversation ne doit pas devenir automatiquement le profil de l’utilisateur. Une phrase comme « je voyage à Lyon demain » peut être utile pendant l’échange et inutile ensuite. La conserver comme préférence durable créerait une information vite obsolète.

2. L’état de la tâche

L’état décrit ce que le système est en train de faire : étape atteinte, entrée validée, approbation reçue, opération en attente, version du workflow et identifiants des effets. Il sert à reprendre après une interruption sans répéter une action.

Cet objet doit rester structuré. Un résumé libre de conversation ne remplace pas un statut waiting_for_approval ou une clé d’idempotence. L’article sur la file d’erreurs d’un workflow IA détaille les états de reprise ; la mémoire conversationnelle n’est pas la source de vérité de cette machine.

3. Les préférences et décisions durables

Cette mémoire peut contenir un format de réponse demandé, une langue, une préférence explicite, une correction confirmée ou une décision réutilisable. Sa portée est souvent une personne ou une équipe. Elle exige une provenance et un moyen de correction, car une préférence peut changer.

Évitez d’inférer des attributs sensibles ou des traits personnels à partir d’une conversation. Microsoft recommande, dans son guide de sécurité de la mémoire agentique, de contrôler l’intention et la provenance des écritures et de bloquer notamment les secrets, identifiants sensibles et contenus malveillants. Une préférence utile doit être distinguée d’une supposition du modèle.

4. Les connaissances validées

Les procédures, tarifs, règles, catalogues et documents de référence appartiennent à une base de connaissances avec propriétaire, version et date de validité. Ils ne doivent pas être mélangés aux souvenirs personnels. Une conversation ne peut pas modifier silencieusement une règle organisationnelle.

Le protocole pour versionner une base de connaissances IA décrit comment tester et publier ces changements. Dans l’architecture présente, cette base est consultée par l’agent, mais son cycle d’approbation reste indépendant de la mémoire utilisateur.

Écrire le contrat de mémoire à onze champs

Chaque type de mémoire doit tenir dans un contrat lisible avant l’implémentation.

Champ	Question de contrôle
type	conversation, état, préférence ou connaissance ?
finalité	quelle décision future justifie la conservation ?
sujet	à quelle personne, équipe, tâche ou ressource l’entrée se rapporte-t-elle ?
portée	session, utilisateur, organisation, agent ou workflow ?
provenance	qui ou quel système a fourni l’information ?
mode de validation	explicite, règle déterministe ou revue humaine ?
sensibilité	publique, interne, personnelle, confidentielle ou interdite ?
durée	quand l’entrée expire-t-elle ou doit-elle être revue ?
version	quel schéma, modèle et processus ont produit l’entrée ?
droits	qui peut lire, corriger, supprimer ou partager ?
propriétaire	qui tranche une contradiction et répond de la purge ?

Exemple : « réponses en français » peut être une préférence durable si la personne l’a explicitement demandée, qu’elle peut la modifier et que sa portée reste son propre profil. « Ce client accepte toujours les retards » ne doit pas être inféré puis conservé. La phrase est ambiguë, concerne potentiellement un tiers et pourrait modifier une décision future sans base fiable.

Le contrat empêche aussi le stockage réflexe de transcriptions complètes. Si la finalité est de retenir un format, stockez le format confirmé, pas les cinquante messages qui ont mené à cette décision.

Contrôler l’écriture avant la persistance

Le pipeline d’écriture reçoit une information candidate, puis applique plusieurs contrôles avant de créer une mémoire.

1. Identifier la source : utilisateur, outil, document, autre agent ou inférence.
2. Déterminer la finalité : quel usage futur est prévu ?
3. Classer la sensibilité : l’entrée contient-elle un secret, une donnée personnelle ou une information interdite ?
4. Vérifier l’autorité : la source peut-elle modifier cette portée ?
5. Choisir le type : conversation, état, préférence ou connaissance.
6. Fixer la durée : expiration, date de revue ou conservation liée à la tâche.
7. Demander confirmation lorsque l’information engage durablement la personne.
8. Journaliser la décision sans recopier le contenu sensible dans le journal.

Une mémoire doit pouvoir être rejetée avec une raison : secret_detected, scope_not_allowed, unconfirmed_preference, knowledge_owner_missing ou duplicate. Le rejet reste observable afin que l’équipe comprenne pourquoi le système oublie une information.

Voici un enregistrement volontairement sobre :

{
  "memory_id": "mem_opaque_42",
  "kind": "preference",
  "subject_id": "user_opaque_7",
  "scope": "user",
  "claim": "response_language=fr",
  "source": "explicit_user_request",
  "validated_at": "2026-08-11T08:15:00Z",
  "review_after": "2027-08-11",
  "schema_version": "memory.v1",
  "status": "active"
}

L’identifiant est opaque, le contenu est limité à la préférence nécessaire et la date de revue est explicite. Le journal d’audit peut référencer memory_id sans dupliquer claim.

Filtrer le rappel comme une nouvelle décision

Une entrée correctement écrite peut devenir inadaptée. Le pipeline de rappel doit donc contrôler :

• l’identité de la personne ou du service qui demande le contexte ;
• l’autorisation de lire la portée ;
• la correspondance avec la tâche et l’agent actifs ;
• la date d’expiration et la fraîcheur ;
• la provenance et le niveau de validation ;
• l’existence d’une correction ou d’une révocation plus récente ;
• la sensibilité autorisée dans le modèle et l’outil utilisés ;
• la présence de contenu qui cherche à modifier les instructions du système.

Une mémoire rappelée doit être présentée comme donnée, avec une étiquette de provenance, pas concaténée dans le bloc d’instructions. « Préférence déclarée le 11 août » et « règle système » n’ont pas la même autorité. Microsoft décrit ce risque de manière nette : une mémoire persistante peut devenir une couche de configuration et influencer plus tard le choix d’un outil ou un comportement de refus. Elle doit donc être contrôlée au rappel, pas seulement au moment de l’écriture.

Définissez un budget de contexte. Rappeler cent souvenirs supposés proches peut masquer la demande actuelle et augmenter le coût. Sélectionnez peu d’entrées, gardez leur score ou leur règle de sélection dans la trace, puis mesurez si elles ont réellement aidé.

Isoler organisation, personne, agent et tâche

L’isolement ne doit pas dépendre d’une consigne disant au modèle « ne lis pas les données des autres ». Utilisez des clés de partition, des ACL, des jetons limités, un chiffrement adapté et des requêtes filtrées avant que le contenu atteigne le modèle.

Les frontières habituelles sont :

• organisation : aucune mémoire d’un tenant ne doit traverser vers un autre ;
• personne : une préférence personnelle n’est pas automatiquement partagée avec l’équipe ;
• agent : un agent de rédaction n’a pas besoin de la mémoire opérationnelle d’un agent de facturation ;
• tâche : un état intermédiaire n’est accessible qu’au workflow et à la reprise concernés ;
• environnement : les données de test et de production restent séparées.

Dans un système multi-agents, partager la même mémoire par commodité agrandit la surface de fuite et de contamination. Le guide sur l’architecture d’un système multi-agents aide à limiter les délégations ; le même principe s’applique au contexte durable : chaque rôle reçoit seulement ce dont il a besoin.

Résumer sans transformer une hypothèse en fait

Les longues conversations sont souvent compactées ou résumées. Cette opération économise du contexte, mais elle perd de l’information et peut durcir une nuance. « L’utilisateur envisage l’option A » peut devenir « l’utilisateur préfère A ». Une question peut devenir une décision. Une contradiction peut disparaître.

Conservez donc :

• le lien vers les éléments sources lorsque leur conservation est justifiée ;
• la date et la version du résumé ;
• les décisions explicites séparées des hypothèses ;
• les points non résolus ;
• un mécanisme de remplacement, pas seulement d’ajout.

Testez les résumés sur des conversations comportant correction, négation, changement d’avis et plusieurs personnes. La compaction doit être évaluée comme une transformation de données. Elle ne mérite pas une confiance supérieure au texte qu’elle résume.

Programmer expiration, correction et effacement

La CNIL rappelle que les données doivent être adéquates, pertinentes et limitées à la finalité, avec des durées de conservation justifiées et des mécanismes de purge. Cela concerne aussi les journaux. Une mémoire durable sans règle d’expiration devient une base oubliée dont personne ne sait expliquer l’usage.

Associez une politique à chaque type :

Type	Déclencheur de fin possible	Action
conversation	clôture du fil ou délai court	suppression ou résumé minimal
état de tâche	tâche terminée et délai de recours écoulé	archivage limité puis purge
préférence	retrait, correction ou revue périodique	nouvelle version et invalidation de l’ancienne
connaissance	publication d’une version remplaçante	désactivation puis purge selon la politique documentaire

L’effacement doit couvrir la mémoire principale, les index, les caches, les copies de recherche et les files de traitement. Conservez une preuve de l’opération sans remettre la donnée supprimée dans le journal. Si une entrée a influencé une action passée, la suppression ne réécrit pas l’histoire ; elle empêche les usages futurs et permet d’expliquer la période d’influence avec des références opaques.

Tester les défaillances propres à la mémoire

Un test de réponse unique ne révèle pas les risques persistants. Ajoutez au moins douze scénarios :

1. une préférence explicite est rappelée au bon utilisateur ;
2. la même préférence n’apparaît pas chez un autre utilisateur ;
3. une donnée d’un autre tenant est refusée avant le modèle ;
4. un secret proposé à l’écriture est rejeté ;
5. une instruction hostile contenue dans un résultat d’outil ne devient pas une mémoire ;
6. une mémoire expirée n’est plus injectée ;
7. une correction remplace l’ancienne valeur ;
8. une suppression retire aussi l’entrée de l’index de recherche ;
9. un résumé conserve une négation et un changement d’avis ;
10. deux écritures concurrentes ne créent pas deux vérités actives ;
11. une base de connaissances obsolète ne l’emporte pas sur sa nouvelle version ;
12. une reprise après panne conserve l’état de tâche sans répéter l’effet externe.

Ajoutez des tests différés. Une charge hostile peut être enregistrée aujourd’hui et ne s’activer qu’après plusieurs tours ou lorsqu’un outil précis devient disponible. La sécurité de la mémoire doit donc couvrir plusieurs sessions et plusieurs contextes.

Mesurer l’utilité sans récompenser la rétention

Le nombre de souvenirs stockés n’est pas un indicateur de qualité. Mesurez plutôt :

• taux de rappel réellement utile à la tâche ;
• taux de mémoire corrigée ou contestée ;
• entrées expirées encore retrouvées ;
• refus d’écriture par motif ;
• incidents d’isolement ;
• délai ajouté par la sélection et les contrôles ;
• coût de stockage, d’indexation et de revue ;
• part des opérations de création, lecture, correction et suppression tracées.

Comparez aussi un lot avec et sans mémoire. Si la qualité ne progresse pas, ou si l’utilisateur corrige davantage le système, la persistance n’est pas justifiée. Réduire la mémoire peut améliorer la précision en retirant du contexte ancien.

Une revue mensuelle doit examiner quelques rappels utiles, tous les incidents et un échantillon de mémoires jamais utilisées. Les entrées inutiles indiquent souvent une finalité trop vague ou un pipeline d’écriture trop permissif.

Limites

La mémoire est une notion large et les frameworks n’utilisent pas tous les mêmes termes. Une session, un état de workflow, un cache, un historique et une mémoire sémantique ne possèdent pas les mêmes garanties. Les exemples OpenAI et Microsoft cités décrivent leurs mécanismes actuels ; il faut vérifier la version réellement déployée avant d’en déduire un comportement.

La note CNIL-CIANum de juillet 2026 est exploratoire et ne remplace pas une analyse RGPD, sectorielle ou contractuelle. Une architecture de purge ne prouve pas à elle seule que la collecte était licite. Enfin, la recherche vectorielle peut retrouver une information proche sans établir qu’elle est vraie, actuelle ou autorisée. La mémoire améliore la continuité uniquement si l’application garde le contrôle de l’écriture, du rappel et de l’effacement.

Articles liés

• Versionner une base de connaissances IA
• Déléguer une identité et des autorisations à un agent
• Journaliser un agent IA sans conserver les prompts