La mémoire des agents IA doit entrer dans la cartographie des données

Rédigé le 02/11/2026
Joël Parfait Kuate

Un agent résume une note juridique, en extrait trois règles puis les conserve dans une mémoire utilisée la semaine suivante. Entre-temps, la note a changé. L’agent peut désormais produire une réponse cohérente à partir d’une information périmée. Le problème n’est ni un simple défaut de recherche documentaire ni une hallucination isolée : c’est une rupture de traçabilité entre la source, les transformations et l’usage du souvenir.

De l’inventaire des documents à la chaîne de dérivation

Une cartographie classique répond à des questions utiles : où réside une donnée, quel système y accède, combien de temps la conserve-t-on ? Un agent introduit plusieurs copies sémantiques : extrait récupéré par RAG, résumé de conversation, état de planification, mémoire persistante, message adressé à un autre agent. Le flux devient un graphe de dépendances. Une suppression dans le référentiel d’origine ne retire pas automatiquement les formulations dérivées. La catégorie ASI06 « Memory & Context Poisoning » du référentiel OWASP Agentic 2026 rend visible ce risque ; elle n’en mesure pas la fréquence chez les entreprises.

Je propose de traiter chaque mémoire comme un enregistrement gouverné, et non comme une commodité cachée de l’orchestrateur. Un enregistrement devrait porter au minimum : un identifiant immuable ; la référence à la source et à sa version ; l’horodatage d’extraction ; l’identité du créateur et du propriétaire ; la finalité ; le périmètre d’habilitation ; une date d’expiration ; le statut de confiance ; les identifiants des états dérivés. Un vecteur seul ne remplace pas cette fiche d’identité. L’embedding facilite la recherche par similarité, mais ne prouve ni la validité ni l’autorisation de réutilisation.

Un calcul illustratif, pas un taux observé

Considérons un système fictif traitant 10 000 documents par mois. Supposons, pour illustrer une analyse de sensibilité, que 8 % soient modifiés dans le mois et que 25 % des documents modifiés aient donné lieu à une mémoire conservée. On obtient 10 000 × 0,08 × 0,25 = 200 mémoires candidates à la réévaluation par mois. Ce nombre est une conséquence des hypothèses, pas une statistique sectorielle. Si le taux de modification est compris entre 4 % et 12 %, l’ordre de grandeur varie de 100 à 300. La métrique opérationnelle utile serait la part des mémoires dépendant d’une version invalidée, puis le délai médian et au 95e percentile de propagation d’une correction.

Corriger la source ne suffit pas

L’architecture doit conserver des liens de dérivation : document D version v3 → résumé S42 → mémoire M18 → réponse R7. Une nouvelle version v4 déclenche l’invalidation de S42 et M18, puis une nouvelle extraction si la finalité demeure légitime. La politique peut choisir une suppression, une quarantaine ou une révision, mais doit inscrire l’action dans un journal auditable. Une mémoire utilisée pour une décision antérieure ne peut pas faire disparaître cette décision : il faut prévoir un processus de rectification métier distinct de la purge technique.

L’habilitation doit être réévaluée à la lecture, pas seulement au moment de l’ingestion. Si un collaborateur perd l’accès à une catégorie de contrats, l’agent ne doit pas contourner cette révocation en utilisant une mémoire résumée alors qu’il ne peut plus lire les documents initiaux. C’est une application de la logique du moindre privilège et de la vérification continue décrite par le NIST SP 800-207, transposée ici à des états sémantiques dérivés.

Quatre tests pour sortir des promesses

Premier test : modifier une source et vérifier que toutes les mémoires dépendantes changent de statut dans un délai mesuré. Deuxième test : retirer un droit et tenter une réponse à partir d’une mémoire préexistante. Troisième test : injecter un extrait contradictoire ou hostile dans une source de test afin d’observer si une instruction externe est promue en règle permanente. Quatrième test : demander la provenance d’une assertion et vérifier si l’agent peut revenir à une version précise plutôt qu’à une référence vague.

Chaque test doit produire des preuves : jeu de données synthétique, liste des dépendances attendues, traces avant/après et critères d’acceptation. On peut, par exemple, fixer contractuellement un objectif de 99 % d’invalidations propagées en moins de cinq minutes ; ce seuil est un choix de service à valider, non une performance démontrée. Le NIST AI 600-1 encourage une approche de gestion des risques sur le cycle de vie ; il ne certifie pas une implémentation particulière.

La vraie question de gouvernance

Une mémoire utile accroît la continuité d’un assistant. Une mémoire sans origine, sans durée et sans mécanisme de rectification accroît sa dette informationnelle. Cartographier les agents consiste donc à représenter non seulement leurs connexions, mais aussi les conséquences des transformations de données. À défaut, une organisation saura où se trouve le document exact tout en ignorant où survit son ancienne signification.

Références techniques (sources consultables)
• OWASP, Top 10 for Agentic Applications (2026) — https://genai.owasp.org/2025/12/09/owasp-genai-security-project-releases-top-10-risks-and-mitigations-for-agentic-ai-security/
• OWASP, LLM06 Excessive Agency (2025) — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
• NIST, AI 600-1 Generative AI Profile (2024) — https://doi.org/10.6028/NIST.AI.600-1
• NIST, SP 800-207 Zero Trust Architecture (2020) — https://doi.org/10.6028/NIST.SP.800-207

A propos de l'auteur

Joël Parfait Kuate est architecte des systèmes d’information, ingénieur spécialisé en IA générative et Big Data, fondateur de Digital House Company. Il accompagne les organisations sur les architectures RAG, les agents IA, l’automatisation et la gouvernance des données. Auteur de « L’Afrique et l’Intelligence Artificielle », il travaille sur la mémoire persistante et l’évaluation des systèmes multiagents.