Mémoire des agents IA : que conserver et où ?

Une équipe autonome a besoin de continuité. Elle doit savoir ce qui a déjà été tenté, retrouver les préférences utiles et reprendre un dossier sans demander au lecteur de tout répéter. La réponse la plus simple consiste à enregistrer davantage de conversations. C'est aussi celle qui crée le plus vite une base parallèle remplie de faits non vérifiés, de données sensibles et de décisions devenues obsolètes.

La bonne question n'est donc pas combien un agent peut mémoriser. Elle est de savoir quelle information mérite de survivre à la tâche, sous quelle autorité et avec quel mécanisme de correction. Un échange récent peut aider à comprendre une demande sans devenir une vérité durable. Une préférence peut être réutilisable sans avoir la force d'un contrat. Une adresse de livraison validée, un statut de facture ou une approbation engageante doit rester dans l'application métier qui en garantit la version et la responsabilité.

Pour Atlensia, ce choix appartient à l'Operating Layer. Le modèle peut extraire ou suggérer un souvenir, mais il ne devrait pas décider seul que ce souvenir devient une donnée permanente. La couche opérationnelle doit séparer contexte de travail, mémoire durable et système de référence, puis appliquer à chacun une identité, une finalité, une durée de vie et une trace.

Trois couches répondent à trois responsabilités différentes

Le contexte de travail rassemble ce dont l'équipe autonome a besoin pour accomplir la tâche actuelle : mandat, messages récents, résultats d'outils, étapes déjà exécutées et contraintes applicables. Sa valeur vient de sa proximité avec l'action. Il peut être résumé ou abandonné lorsque le travail se termine, parce qu'il n'a pas vocation à devenir une connaissance générale sur une personne ou une entreprise.

La mémoire durable contient des éléments susceptibles d'améliorer plusieurs sessions : préférence explicitement exprimée, enseignement validé sur un processus, synthèse d'un dossier récurrent ou règle locale qui n'existe pas encore dans un référentiel structuré. Elle est utile, mais elle reste une représentation dérivée. Elle peut avoir été extraite par un modèle, consolidée à partir de plusieurs échanges ou retrouvée par similarité. Elle doit donc conserver sa provenance, son périmètre et son degré de confiance.

Le système de référence, enfin, détient les faits qui produisent un effet métier ou juridique. Le CRM porte le statut de l'opportunité, l'ERP celui de la commande, le système RH les données contractuelles et l'outil de support l'état officiel du ticket. Copier ces faits dans une mémoire d'agent peut accélérer une réponse, mais cette copie ne doit jamais devenir l'autorité qui décide si le fait est encore vrai.

Cette distinction empêche deux erreurs opposées. Sans mémoire durable, l'équipe recommence inutilement et perd les ajustements utiles. Sans frontière avec le système de référence, elle peut agir sur une synthèse périmée en croyant consulter la vérité opérationnelle.

Le premier schéma montre comment ces trois couches coopèrent sans se confondre.

Schéma Atlensia : le contexte aide à exécuter la tâche, la mémoire durable facilite la continuité et le système métier conserve les faits qui engagent l'entreprise.

La circulation n'est pas symétrique. Le système métier peut fournir un fait vérifié au contexte. Une conversation peut proposer un souvenir durable. En revanche, une proposition issue du modèle ne devrait pas modifier directement le système de référence ni devenir une mémoire partagée sans contrôle de sa portée.

Les produits de mémoire automatisent l'extraction, pas la responsabilité

Les plateformes récentes rendent la mémoire plus facile à intégrer, mais leurs mécanismes confirment justement la nécessité d'une politique explicite. La documentation d'Amazon Bedrock AgentCore Memory distingue une mémoire à court terme, composée d'événements de session, et une mémoire à long terme qui extrait des faits, préférences, résumés ou épisodes selon des stratégies configurables. AWS permet aussi d'organiser les souvenirs avec des espaces de noms liés à un acteur et à une session, puis de restreindre leur accès avec IAM.

La documentation de Google Agent Platform Memory Bank décrit une extraction de souvenirs à partir des conversations, suivie d'une consolidation capable de créer, mettre à jour ou supprimer un souvenir. Les « memory topics » définissent les informations jugées pertinentes. Google précise toutefois que le filtrage des données sensibles ou personnelles n'est pas infaillible. Cette réserve est essentielle : un extracteur de mémoire réduit le travail technique, mais il ne remplace ni la classification des données ni la décision de rétention.

Ces services ne sont pas directement comparables sur un simple tableau de fonctionnalités. AWS expose notamment des stratégies, des espaces de noms, des métadonnées et des opérations de suppression. Google met en avant les sujets d'extraction, les portées et la consolidation des contradictions. Dans les deux cas, la qualité de la mémoire dépend de décisions prises en dehors du modèle : quelles sources sont admissibles, quel acteur possède le souvenir, combien de temps il reste valide et quel événement impose sa révision.

Une organisation devrait donc évaluer un outil de mémoire sur sa capacité à appliquer sa politique, pas sur la seule fluidité d'une démonstration. La continuité conversationnelle est visible immédiatement. Les erreurs de portée, les souvenirs contradictoires et les suppressions incomplètes apparaissent plus tard, souvent lorsque plusieurs rôles ou plusieurs équipes partagent la même infrastructure.

Un fait qui engage l'entreprise reste dans son application propriétaire

Une mémoire d'agent est particulièrement dangereuse lorsqu'elle ressemble assez à une base métier pour être crue, mais ne possède pas les contrôles de cette base. Une synthèse peut indiquer qu'un client accepte une condition commerciale. Si cette condition n'a pas été enregistrée dans le CRM ou dans le contrat validé, elle n'est qu'un élément de contexte. L'utiliser pour générer automatiquement une offre transforme une hypothèse en engagement.

Le critère décisif est l'effet produit lorsque l'information est fausse. Si une erreur peut modifier un paiement, une obligation, un droit d'accès, un statut réglementaire, une relation contractuelle ou une communication externe engageante, la lecture doit revenir au système propriétaire au moment de l'action. La mémoire peut conserver un pointeur, un identifiant et une explication de pertinence. Elle ne doit pas remplacer la lecture du fait actuel.

Cette règle évite aussi les conflits de correction. Lorsqu'une adresse change, une personne doit savoir où la rectifier. Si le CRM, une mémoire vectorielle, un résumé de session et un profil d'agent détiennent chacun une version, la correction devient une chasse aux copies. Une architecture fiable désigne un seul lieu d'autorité et traite le reste comme des représentations temporaires ou dérivées.

Pour un Operating Layer, cette séparation produit une règle simple : la mémoire suggère ce qu'il peut être utile de récupérer, tandis que l'intégration métier confirme ce qui est vrai maintenant. Le modèle peut formuler une requête ou expliquer une divergence. Il ne choisit pas silencieusement la copie qui l'arrange.

La décision de conserver doit précéder l'écriture

Enregistrer d'abord et filtrer plus tard inverse l'ordre de gouvernance. Une donnée sensible peut déjà avoir été indexée, résumée ou propagée vers une mémoire partagée avant qu'une suppression soit demandée. L'OWASP Top 10 for Agentic Applications 2026 décrit l'empoisonnement de mémoire et de contexte comme la corruption d'informations conservées ou retrouvées qui influence ensuite le raisonnement, la planification ou l'utilisation des outils. Le risque persiste entre les sessions et peut se propager entre agents.

Le point d'écriture doit donc répondre à quatre questions. L'information possède-t-elle une finalité future précise ? Sa source est-elle admissible et identifiable ? Sa durée de validité peut-elle être déterminée ? Une personne ou un système dispose-t-il du droit de la corriger, de la révoquer ou de la supprimer ? Si une réponse manque, la conservation durable est prématurée.

L'arbre suivant transforme ces questions en choix d'architecture.

Schéma Atlensia : la nature du fait, sa durée de validité, sa sensibilité et son effet métier déterminent sa destination, pas la seule capacité technique à le mémoriser.

L'arbre ne cherche pas à classer toute information comme utile ou interdite. Il choisit le bon régime. Une étape intermédiaire sans valeur future disparaît avec le contexte. Une préférence stable et consentie peut entrer dans une mémoire durable avec expiration. Un fait engageant est écrit par le workflow autorisé dans le système métier. Une donnée sensible sans finalité admissible n'est pas conservée.

Une mémoire gouvernée possède un cycle de vie observable

La création n'est que le début. Une mémoire durable doit pouvoir être retrouvée avec sa provenance, comparée à une nouvelle information, corrigée et supprimée. AWS documente des opérations distinctes pour supprimer les événements de court terme et les enregistrements de long terme. La documentation prévient que supprimer un événement source ne supprime pas automatiquement l'information structurée qui en a été dérivée. Cette distinction montre pourquoi une procédure d'effacement doit suivre les dérivations, pas seulement le message original.

La réglementation sur les données personnelles renforce ce raisonnement sans définir une architecture d'agent particulière. L'article 5 du RGPD établit notamment les principes de limitation des finalités, minimisation et limitation de la conservation. Dans un système agentique, les appliquer suppose de savoir pourquoi un souvenir existe, quelles actions l'utilisent et quand il doit être réévalué ou supprimé.

Une mesure de pertinence ne suffit pas comme preuve. Un score de similarité indique qu'un souvenir ressemble à la requête, pas qu'il est exact, autorisé ou encore valide. La récupération doit donc être filtrée par l'identité, le rôle, l'organisation, le type de mémoire et la période, avant que le contenu n'entre dans le contexte du modèle.

Le test utile consiste à injecter un mauvais souvenir

Un pilote ne devrait pas seulement vérifier que l'agent se souvient d'une préférence correcte. Il doit aussi observer ce qui se passe lorsqu'une source contredit le souvenir, lorsqu'un autre utilisateur tente de le récupérer, lorsqu'il expire ou lorsqu'un document malveillant cherche à inscrire une instruction durable. C'est à ce moment que l'architecture révèle si la mémoire est un service gouverné ou une simple accumulation de texte.

Prenons un exemple illustratif de support client. Un utilisateur demande que les réponses techniques soient toujours envoyées au format PDF. Cette préférence peut être conservée si elle est attribuée au bon compte, non sensible et facile à révoquer. Le niveau de service contractuel, en revanche, doit être relu dans le CRM ou l'outil de support avant toute promesse. Une phrase trouvée dans une pièce jointe demandant d'ignorer cette règle ne doit entrer ni dans la mémoire durable ni dans le système de référence.

Le test doit couvrir la séparation des acteurs, une contradiction, une expiration, une suppression et une tentative d'empoisonnement. Pour chaque cas, l'équipe conserve la source, la décision de mémoire, les éléments récupérés et l'effet observé. Le NIST AI RMF Generative AI Profile insiste sur la gestion des risques de confidentialité, d'intégrité de l'information et d'intégration des composants. Une mémoire ne peut pas être évaluée indépendamment des outils et décisions qu'elle influence.

Conclusion

Une mémoire plus longue n'est pas automatiquement une meilleure mémoire. Le contexte de travail sert la tâche présente. La mémoire durable apporte de la continuité sous une politique de portée, de durée et de correction. Le système métier conserve les faits officiels qui engagent l'entreprise. Confondre ces responsabilités crée une base parallèle dont les erreurs peuvent survivre à la conversation qui les a produites.

La prochaine étape consiste à choisir un workflow réel et à inventorier dix informations qu'il manipule. Pour chacune, décider si elle doit disparaître après la tâche, rester disponible entre sessions ou être confirmée dans un système de référence. Ajouter ensuite un propriétaire, une durée de vie et un test de correction. Cette matrice fournit une politique de mémoire exploitable avant même de sélectionner un fournisseur.

---

Sources primaires et références

• Amazon Bedrock AgentCore Memory
• AWS, organisation des mémoires et espaces de noms
• AWS, suppression des événements de court terme
• Google Agent Platform, génération et consolidation des mémoires
• OWASP Top 10 for Agentic Applications 2026
• NIST AI 600-1, Generative AI Profile
• Règlement général sur la protection des données, article 5
• Atlensia, plateforme et Operating Layer