Mémoire des agents d’IA : séparer le contexte, les préférences et les faits persistants, et décider de leur expiration

Se souvenir ne signifie pas conserver l’historique

Un agent qui assiste une même personne ou équipe à plusieurs reprises a besoin de continuité : il peut être raisonnable de retenir une langue préférée, le format habituel d’un livrable ou le nom d’un projet. Toutefois, transformer toutes les conversations, tous les documents récupérés et toutes les inférences du modèle en mémoire réutilisable pose un problème de gouvernance. Le système peut récupérer des informations non pertinentes, obsolètes, erronées, sensibles ou applicables uniquement à une situation antérieure.

La question d’architecture n’est pas de savoir si l’agent possède une mémoire, mais quelle affirmation précise il conserve, qui peut l’utiliser, dans quel but et pendant combien de temps. Une phrase telle que « le client préfère approuver les modifications par e-mail » peut être une préférence déclarée, une observation déduite d’un seul échange ou une règle opérationnelle en vigueur. Ces interprétations n’ont pas la même valeur et ne devraient pas être stockées ni appliquées de la même manière.

La mémoire persistante n’acquiert pas non plus d’autorité parce qu’elle a été stockée. Une instruction figurant dans une conversation passée, un document importé ou un résultat de récupération reste le contenu de la source qui l’a apportée. Elle ne doit pas écarter des instructions d’autorité supérieure ni autoriser des actions que l’agent ne peut pas accomplir dans le contexte actuel. Cette séparation est particulièrement importante lorsque le contenu récupéré n’a pas été validé ou peut avoir été manipulé.

Pour orienter ce guide, il est utile de distinguer les faits de conception des décisions de politique. C’est un fait opérationnel qu’un système peut attribuer à des enregistrements des dates de création, de révision ou d’expiration. En revanche, décider qu’une préférence expire après quatre-vingt-dix jours relève d’une politique de l’organisation : ce choix doit être justifié par le risque, la volatilité de la donnée et l’expérience attendue, et non présenté comme une règle universelle.

Quatre objets à séparer

Le mot « mémoire » mélange souvent des composants dont les cycles de vie sont très différents. Les séparer réduit les récupérations inappropriées et rend le comportement de l’agent plus compréhensible. Le contexte de session contient l’échange immédiat qui permet d’interpréter la demande actuelle. Il devrait être limité à la session et disparaître ou devenir inaccessible lorsqu’elle se termine, sauf si une partie est délibérément promue vers une autre catégorie.

L’état de tâche représente l’avancement d’un travail précis : identifiant d’une demande, éléments déjà traités, brouillon en cours, résultat partiel ou étape en attente. Il peut devoir survivre à une interruption brève, mais il ne devient pas pour autant une préférence ni un fait qui doit être accessible dans des tâches futures. La documentation des outils d’exécution d’agents de Google fournit un exemple d’état de flux de travail lié à une session et de nettoyage explicite ou fondé sur une durée de vie à la fin de la tâche ou de la conversation.

La mémoire déclarée est l’information qu’une personne ou une équipe a fournie pour assurer la continuité, telle qu’une langue préférée, un fuseau horaire ou une convention de nommage. Elle doit conserver la déclaration d’origine, ou une référence vers celle-ci, ainsi que son périmètre. Un paramètre indiqué pour un projet ne doit pas nécessairement s’étendre à tous les projets, et une préférence d’un membre d’équipe ne doit pas être attribuée à toute l’organisation.

La connaissance récupérable rassemble des affirmations obtenues à partir de sources identifiées : une politique interne en vigueur, l’état d’un service ou une liste de responsables. Sa conception ressemble moins à un profil utilisateur qu’à un enregistrement de provenance : source, version ou moment de consultation, responsable, portée et conditions de mise à jour. L’ontologie PROV-O du W3C fournit des concepts pour représenter des entités, des activités et des agents, ainsi que des relations de génération, de dérivation et d’invalidation. Elle n’impose pas l’adoption d’une base de données particulière, mais aide à rendre la traçabilité explicite.

Le registre minimal d’un souvenir gouvernable

Un enregistrement n’a pas besoin de conserver l’intégralité du texte conversationnel pour être utile. Dans de nombreux cas, une affirmation normalisée et des métadonnées suffisent. Par exemple, au lieu de conserver un dialogue entier, un registre peut indiquer qu’une personne a choisi de recevoir des résumés en espagnol pour un espace de travail précis. La réduction du contenu n’élimine pas tous les risques, mais elle limite l’exposition et facilite l’inspection.

Au minimum, chaque élément devrait inclure un identifiant stable ; le contenu ou une référence vers celui-ci ; le propriétaire ou sujet auquel il est attribué ; la finalité autorisée ; le périmètre d’application ; la source et le mode d’obtention ; le niveau de confiance ; la date de création ; la date de dernière vérification ; la règle d’expiration ; et l’état de suppression ou de restriction. S’il dérive d’autres données, il doit aussi conserver ses dépendances. Il devient ainsi possible de localiser les souvenirs à réviser lorsqu’une source change ou qu’une personne demande une rectification.

Il convient de distinguer le niveau de confiance de l’autorisation d’utilisation. Une préférence directement déclarée par la personne peut offrir un niveau élevé de confiance quant à ce qu’elle a exprimé, tout en ayant un périmètre limité. Une donnée extraite automatiquement d’un document peut être potentiellement utile, mais nécessiter une validation humaine ou la consultation de la source primaire avant de déclencher une action. La confiance ne doit pas devenir un score opaque qui remplace la provenance.

Pour les informations personnelles, le Règlement général sur la protection des données de l’Union européenne énonce des principes de limitation des finalités, de minimisation, d’exactitude et de limitation de la durée de conservation, ainsi que des droits relatifs à la rectification, à l’effacement et à la limitation du traitement dans les conditions applicables. Un produit opérant dans ce cadre doit traduire ces principes en processus effectifs ; ajouter un champ nommé « TTL » ne démontre pas, à lui seul, la conformité juridique.

Ce qui peut persister et ce qui devrait disparaître

La persistance doit être décidée selon la nécessité fonctionnelle et le risque, non selon la facilité de stockage. Une préférence explicite et à faible impact peut persister si elle a un titulaire clair, une finalité précise et un moyen accessible d’être modifiée. Un état de tâche est généralement supprimé lorsque le travail s’achève. Un fait externe changeant, tel qu’un tarif, une politique ou la disponibilité d’un service, peut être conservé comme indice de récupération, mais ne devrait pas être traité comme une preuve en vigueur lorsqu’une décision importante doit être prise.

Les inférences méritent une catégorie distincte. Le fait que le modèle ait déduit qu’une personne préfère des communications brèves ne signifie pas que cette personne l’a déclaré. Si le produit choisit de stocker des inférences, il devrait les étiqueter comme telles, réduire leur périmètre, leur attribuer une révision courte et proposer un mécanisme simple pour les confirmer, les corriger ou les écarter. Dans les scénarios à fort impact, il est plus prudent de ne pas transformer des inférences comportementales en mémoire persistante sans décision explicite de produit et sans évaluation des risques.

Les données sensibles exigent une évaluation plus stricte que les paramètres de présentation. Leur sensibilité dépend autant de la nature de la donnée que du contexte, du destinataire, de la finalité et de la juridiction. Ce guide ne remplace pas une analyse juridique ou de sécurité. Comme critère de produit, la présence d’une donnée sensible ne justifie pas sa persistance : l’équipe doit démontrer une finalité précise, des contrôles d’accès, une conservation limitée et un processus effectif pour traiter les changements ou l’effacement lorsque cela est nécessaire.

Il est également important de ne pas masquer cette classification derrière une étiquette unique de « mémoire ». L’interface et les API internes devraient refléter les différences : un utilisateur peut vouloir modifier une préférence, annuler une tâche en pause ou contester l’exactitude d’un fait issu d’une source externe. Il s’agit d’opérations différentes, qui requièrent des traces différentes.

Expiration : échéance, révision et événements

Une date d’expiration répond à la question de savoir quand cesser de récupérer automatiquement une donnée. Une révision obligatoire répond à une autre question : quand faut-il la vérifier à nouveau avant de la considérer comme valide ? Les deux peuvent coexister. Par exemple, une préférence de format peut demeurer disponible jusqu’à ce que la personne la modifie ou la supprime, tandis qu’une politique opérationnelle peut rester indexée mais exiger la consultation de sa source avant d’être utilisée pour approuver une action.

Les règles fondées sur les événements complètent l’horloge. Un changement de projet, de rôle, de fournisseur, de compte ou de version documentaire peut invalider les souvenirs associés. Si une affirmation dépend d’une source précise, la mise à jour ou le retrait de cette source devrait déclencher une révision de ses dérivés. La modélisation des dérivations et des invalidations permet de trouver l’ensemble affecté plutôt que d’attendre que chaque élément expire séparément.

L’expiration ne doit pas être confondue avec une suppression physique immédiate. Pour des raisons opérationnelles ou réglementaires, différents états peuvent exister, tels que « non récupérable », « en attente d’effacement » ou « conservé selon une politique spécifique ». L’essentiel pour le comportement de l’agent est qu’un élément expiré ou restreint ne réintègre pas silencieusement le contexte de réponse. L’implémentation doit documenter qui peut accéder à chaque état et dans quelle finalité.

Les durées précises ne peuvent pas être déduites d’une source technique générale. Elles doivent découler de la finalité, du type de donnée, du risque d’obsolescence, des obligations applicables et des besoins opérationnels. Une équipe peut définir des classes de conservation, mais elle devrait mesurer leurs effets : combien de souvenirs expirent sans usage, combien sont corrigés et combien de récupérations sont bloquées faute de validité.

Conflits : instructions actuelles, préférences et sources

Un conflit fréquent survient lorsqu’une préférence mémorisée contredit la demande présente. La règle opérationnelle la plus simple est que la demande actuelle de la personne, dans les limites d’autorisation et de sécurité du système, prévaut sur une préférence antérieure. Si une personne a auparavant demandé des réponses brèves mais sollicite maintenant une analyse détaillée, l’agent doit satisfaire la demande actuelle et, si nécessaire, proposer la mise à jour de la préférence au lieu de la modifier silencieusement.

La hiérarchie des instructions est indépendante de la mémoire. La spécification des modèles d’OpenAI décrit des niveaux d’autorité pour les instructions et indique qu’un contenu non fiable n’acquiert pas d’autorité parce qu’il apparaît dans des données fournies ou récupérées. Par conséquent, une instruction stockée dans la mémoire déclarée ou intégrée depuis un document ne peut pas annuler des règles d’autorité supérieure. La conception doit conserver l’origine de chaque instruction et éviter que la récupération ne la présente comme un ordre du système.

Lorsque deux sources de connaissance divergent, l’agent ne devrait pas résoudre la divergence en inventant une synthèse. Il doit identifier le conflit, préférer une source primaire ou plus récente conformément à une politique définie, ou demander une intervention humaine si la décision a des conséquences importantes. Le registre de mémoire doit marquer les éléments contestés afin qu’ils ne soient pas réutilisés comme des faits établis.

La correction comporte deux dimensions. Corriger l’enregistrement principal empêche que la donnée continue d’apparaître dans de nouvelles récupérations. Corriger ses dérivés évite qu’elle survive dans des résumés, des index, des caches, des évaluations ou des données d’entraînement de récupération, selon l’architecture. Un processus de rectification ou d’effacement qui ne met à jour qu’une table visible, tout en laissant la donnée dans les index qui alimentent l’agent, n’atteint pas l’objectif opérationnel d’empêcher sa réutilisation.

Revalider avant une action externe

La mémoire peut aider à formuler une réponse, mais elle ne suffit pas toujours pour effectuer une action externe. Si l’agent doit envoyer des informations, modifier un enregistrement, initier une transaction, changer des autorisations ou prendre une décision ayant un impact, il doit évaluer la validité de la donnée qui conditionne cette action. Plus l’impact est élevé et plus la source est changeante, plus l’exigence de consultation ou de confirmation doit être forte.

La preuve de validité n’est pas l’affirmation générale selon laquelle l’enregistrement présente une « confiance élevée ». Il peut s’agir d’une consultation récente de la source primaire autorisée, d’une confirmation explicite de la personne compétente ou d’une donnée signée et encore valide selon les règles du domaine. Le système devrait enregistrer quelle vérification a été réalisée, quand, auprès de quelle source et quelle décision elle a autorisée. S’il ne peut pas vérifier, il doit s’abstenir, réduire le périmètre de l’action ou demander une confirmation.

Le projet OWASP Gen AI Security identifie des risques liés à l’empoisonnement de la mémoire et du contexte dans les applications agentiques. Du point de vue de la conception, cela renforce la nécessité de séparer le contenu récupéré des instructions autorisées, d’enregistrer la provenance et d’observer quels souvenirs ont influencé une action. Un filtre sémantique seul ne garantit ni qu’un souvenir soit fiable, ni qu’il soit approprié à l’objectif actuel.

Dans son cadre de gestion des risques liés à l’IA, le NIST propose des activités de gouvernance, de cartographie, de mesure et de gestion, incluant la surveillance et la documentation en exploitation. Appliqué à la mémoire, cela suggère de traiter les récupérations défaillantes, les souvenirs obsolètes et les corrections répétées comme des signaux de risque mesurables, et non seulement comme des incidents isolés de qualité.

Contrôles de produit et tests opérationnels

Une vue de la mémoire n’est pas simplement une page de configuration. Elle doit permettre de comprendre quelles données l’agent utilise et de distinguer, au minimum, les préférences déclarées, les faits récupérables, les inférences et les états de tâche lorsqu’ils sont visibles par la personne. Pour chaque élément, une présentation utile comprend un contenu compréhensible, la source ou le mode d’obtention, le périmètre, la dernière révision, la date d’expiration et les options de modification, de restriction ou de suppression lorsqu’elles s’appliquent.

Le journal d’utilisation est le complément technique de cette vue. Face à une réponse problématique, l’équipe doit pouvoir reconstruire quels éléments ont été récupérés, lesquels ont été écartés, lesquels ont influencé la décision et si une revalidation a eu lieu. Il n’est pas nécessaire d’exposer toutes les données internes à tous les opérateurs : les journaux eux-mêmes requièrent des contrôles d’accès, une minimisation et des durées de conservation. La traçabilité doit soutenir l’enquête sans devenir une autre mémoire illimitée.

Les tests doivent couvrir davantage que la bonne récupération. Incluez des cas où un ancien souvenir contredit la demande actuelle ; où une source a changé ; où une inférence est erronée ; où une préférence appartient à un autre projet ; et où un élément supprimé apparaît dans un résumé ou un cache. Pour les actions externes, vérifiez que l’absence de preuve valide bloque l’action ou demande une confirmation appropriée.

Mesurez les taux de récupération de souvenirs expirés ou hors périmètre, les conflits détectés et non résolus, les rectifications, les effacements terminés, les blocages dus à l’absence de revalidation et les actions qui ont dépendu de la mémoire. Ces métriques ne démontrent pas à elles seules que le système est sûr ou conforme, mais elles révèlent les situations où la mémoire devient une source de décisions défectueuses.

Checklist de déploiement

Avant d’activer une mémoire persistante, l’équipe devrait pouvoir répondre de manière vérifiable à plusieurs questions : quelles classes de données elle conserve ; qui en est le propriétaire ; quelle finalité justifie chaque classe ; comment la source est identifiée ; quand la donnée expire ; quels événements l’invalident ; qui peut la voir ou la modifier ; et ce qui arrive aux index, caches et résumés lorsqu’elle est corrigée ou supprimée.

L’architecture n’a pas besoin de résoudre tous les risques par l’automatisation. Dans certains domaines, la bonne réponse consiste à limiter la mémoire à des préférences à faible impact, à garder les faits sensibles hors de la persistance de l’agent ou à exiger une revue humaine pour les changements à fort impact. La continuité opérationnelle ne dépend pas du fait de retenir davantage, mais du fait de ne retenir que ce qui peut être gouverné.

Pour élargir le cadre, reliez cette pratique aux contenus Learn sur la conception des agents, à Sécurité pour les risques opérationnels et au Glossaire afin d’harmoniser des termes comme provenance, conservation, périmètre et revalidation. Le maintien d’un vocabulaire commun évite que les équipes produit, ingénierie, données et sécurité utilisent le terme « mémoire » pour désigner des mécanismes incompatibles.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.