🧠Mémoire des agents IA : format commun (2026)
Découvrez pourquoi la mémoire des agents IA est incompatible et comment un format de mémoire IA commun améliore l’interopérabilité. OpenTelemetry, MCP.
Les agents IA ont besoin d'une mémoire qu'ils peuvent partager
Un agent de développement découvre qu'une commande de test nécessite PostgreSQL. La question devient vite très concrète : où cette information doit-elle aller ? Dans un fichier AGENTS.md, dans une règle propre à un éditeur, dans une mémoire gérée par un fournisseur, ou sur un serveur accessible via MCP ? Dans la plupart des équipes, la réponse dépend surtout de l'outil déjà en place. Et le résultat, lui, reste le même : l'agent suivant ne retrouve pas forcément la leçon.
Ce n'est pas qu'un souci de confort. Quand plusieurs agents travaillent sur le même dépôt (en local, en intégration continue, ou pendant une revue), une mémoire isolée finit souvent par provoquer les mêmes erreurs, des consignes contradictoires et du travail en double. Les solutions existent, oui. Mais leurs formats ne se parlent pas. Du coup, le vrai problème n'est pas seulement « choisir un outil plus complet » : il faut pouvoir échanger des informations sans les vider de leur sens ni perdre leur origine.
On a déjà vu un casse-tête assez similaire en observabilité, avant l'arrivée d'OpenTelemetry. Là aussi, il a fallu regarder les formats existants, les initiatives de portabilité, et ce que risquait un standard « commun ». L'objectif : clarifier ce qu'un accord devait couvrir - et ce qu'il devait laisser aux outils.
Pourquoi les mémoires des agents restent-elles cloisonnées ?
Chaque outil fait son travail, mais il stocke ses « souvenirs » à sa façon. Un dépôt peut contenir des fichiers AGENTS.md ou CLAUDE.md, plus des règles propres à un éditeur. Un agent peut écrire dans un répertoire de mémoire. Un assistant peut garder des faits liés à un dépôt directement sur l'infrastructure du fournisseur. Et il existe aussi des serveurs de mémoire qui stockent un graphe de connaissances en JSONL.
Pris séparément, ces choix se défendent. Mis ensemble, ils fabriquent des silos. Une info apprise par l'agent de CI reste dans l'environnement qui l'a produite. L'agent utilisé dans l'éditeur n'y accède pas forcément, et un outil adopté quelques mois plus tard encore moins.
Le problème n'est pas le nombre d'outils
Ce n'est même pas seulement une question de formats. Les mémoires ne partagent pas toujours la même définition. Par exemple : parle-t-on d'un fichier entier, d'un fait atomique, d'un bloc de contexte, ou d'une relation entre entités ? L'information est-elle liée à un utilisateur, à un projet, à un dépôt, à une branche ? Et surtout : une nouvelle écriture remplace-t-elle l'ancienne, ou s'y ajoute-t-elle ?
Ces différences ont des effets très concrets. Si deux agents enregistrent la même consigne mais avec des identifiants et des règles de mise à jour incompatibles, vous vous retrouvez avec des doublons ou des versions qui se contredisent. Et si l'information n'a pas de durée de vie claire, elle peut rester « disponible » longtemps après que le code ou les pratiques ont changé.
La multiplication des outils montre que le besoin est réel. Elle ne prouve pas qu'ils arriveront à collaborer. Ajouter une nouvelle brique sans accord de format peut rendre le choix initial simple... tout en rendant la fragmentation plus tenace.
Une mémoire utile doit être située dans le temps et dans le contexte
Prenez une note du type : « Les tests d'intégration échouent si PostgreSQL n'est pas démarré. » Utile, peut-être. Mais pour quel dépôt, quelle configuration, et dans quel contexte ? Et surtout : jusqu'à quand ?
Une mémoire exploitable devrait répondre, au minimum, à quatre questions : où ça s'applique, comment l'identifier, que ça dit, et quand ça ne vaut plus. Il faut aussi savoir qui l'a créée. Une note écrite par un développeur n'a pas le même niveau de preuve qu'une production par un agent, ni qu'une extraction automatique d'une conversation.
Sans ces éléments, on ne fait que transférer du texte. Avec eux, les outils peuvent interpréter l'info, juger sa pertinence, et décider s'ils doivent vraiment l'utiliser. C'est ce qui sépare une collection de fichiers d'un système d'échange.
Que nous apprend l'exemple d'OpenTelemetry ?
Avant OpenTelemetry, l'écosystème d'observabilité avait souvent son propre univers : ses propres agents, ses bibliothèques d'instrumentation, ses formats. Résultat : changer de fournisseur pouvait obliger à réécrire une partie de l'instrumentation. OpenTracing et OpenCensus ont tenté de régler ça, mais avec des approches différentes.
En 2019, ils ont fusionné pour donner naissance à OpenTelemetry. L'idée clé n'était pas d'imposer un tableau de bord unique ni un seul produit. Le vrai travail, c'était de poser des fondations communes : un modèle de données pour les traces, les métriques et les journaux ; des conventions de nommage ; un protocole de transmission ; et des implémentations compatibles.
Partager les fondations, pas les produits
OpenTelemetry laisse les fournisseurs se différencier sur le stockage, la manière d'interroger, et l'analyse. Les équipes instrumentent leurs applications avec un modèle commun, puis choisissent leurs outils d'exploitation. La compatibilité se joue « à la frontière », au moment où les produits échangent des données.
Pour la mémoire des agents, la logique est la même : un standard n'a pas à imposer quelle base de données utiliser, quel moteur de recherche privilégier, ou quelle interface proposer. Il devrait surtout dire ce qu'est un enregistrement, comment l'adresser, et comment un outil peut le lire ou le modifier sans en trahir le contenu.
En clair : il ne s'agit pas de remplacer tous les outils par une plateforme unique. L'objectif est plutôt de réduire le coût de passage d'un outil à l'autre, et de permettre à plusieurs outils de travailler dans le même espace.
L'analogie a ses limites
On ne confond pas tout. Une trace décrit généralement un événement technique, et c'est assez « neutre » dans la façon dont ça influence le futur. Une mémoire d'agent peut, elle, orienter les décisions d'un agent. Elle peut aussi contenir une information inexacte, sensible, ou simplement devenue obsolète. Dans ce contexte, l'origine et la durée de validité ne sont pas des détails.
Le déploiement compte aussi. Une mémoire partagée par des agents d'une même équipe ne pose pas les mêmes questions qu'une mémoire synchronisée entre entreprises ou fournisseurs. Les exigences de sécurité, de confidentialité et de conformité (avec le RGPD en particulier) doivent être prises en compte dès la conception, pas « ajoutées après ».
Ce qui reste vrai, c'est l'enseignement général : les outils peuvent continuer à se concurrencer, mais ils ont intérêt à s'accorder sur ce qu'ils échangent. Un protocole suffit rarement à lui seul. Il faut aussi un modèle de données clair et stable.
Quels formats et projets existent déjà ?
Aujourd'hui, on trouve plusieurs familles de formats. Il y a des documents d'instructions, comme AGENTS.md ou CLAUDE.md, lisibles par des humains et souvent rattachés à un dépôt ou à un chemin. Il y a des mémoires gérées par des agents, sous forme de fichiers créés et modifiés par ces agents. Et d'autres outils gardent des faits liés à un dépôt, à un utilisateur ou à une application.
On rencontre aussi des blocs de contexte structurés, des magasins de données avec espaces de noms et clés, voire des graphes d'entités, de relations, ou de faits temporels. Tout ça répond à des besoins différents : simplicité, recherche, gestion de l'expiration, ou représentation des liens entre informations.
Des choix pertinents, mais rarement compatibles
Certaines idées reviennent souvent et mériteraient d'être reprises. Par exemple : associer des faits à des références au code rend la vérification plus directe. Un stockage basé sur un espace de noms, une clé et une valeur peut garder le modèle accessible. Et la gestion du temps peut distinguer la période pendant laquelle un fait était vrai de celle où le système l'a appris.
Les fichiers « classiques » ont aussi un côté pratique : c'est facile à ouvrir, comparer, et inspecter directement dans un dépôt. Mais un fichier Markdown n'offre pas automatiquement une identité stable pour chaque élément de mémoire, ni des règles communes pour la mise à jour, la recherche ou l'expiration.
Les propositions de portabilité tentent de résoudre une partie du problème. Certains projets parlent de paquets exportables, de manifestes, de mécanismes de suppression ou de signature. D'autres formats cherchent à importer des mémoires produites par plusieurs plateformes. Ces efforts aident, mais ils répondent souvent à la question : « Comment déplacer des données d'un fournisseur à un autre ? »
Exporter ne suffit pas pour les Ă©quipes d'agents
Pour des outils de développement, une autre question arrive très vite : comment plusieurs agents lisent-ils et écrivent-ils dans le même espace, de façon cohérente ? Un agent « éditeur », un robot de revue, et une tâche de CI peuvent intervenir sur le même dépôt en même temps. Ils doivent comprendre ce que désigne une clé, quelle portée elle implique, et comment fonctionne la mise à jour.
C'est d'autant plus important en entreprise. Un export ponctuel facilite un changement de fournisseur, mais ne garantit pas le partage « en live » entre les outils d'une même équipe. À l'inverse, un magasin accessible à plusieurs agents ne garantit pas forcément qu'on puisse migrer les données si le service disparaît.
Un format de mémoire « complet » devrait donc traiter les deux dimensions : une représentation portable d'un enregistrement, et des règles d'accès permettant à plusieurs outils de travailler dessus. Les propositions actuelles donnent des éléments à évaluer, mais ce n'est pas encore un accord universel.
À quoi ressemblerait un standard de mémoire utile ?
Un enregistrement de mémoire pourrait combiner une enveloppe structurée et un contenu. L'enveloppe préciserait son identité, son adresse, son type, sa provenance et son cycle de vie. Le contenu pourrait rester en Markdown (ou suivre un autre format annoncé). Le but n'est pas d'imposer un schéma unique, mais de clarifier ce qu'un outil doit pouvoir comprendre.
spec: agent-memory/0.1
id: 8f0c2a6e-4b1d-4c7a-9e2f-3a5b6c7d8e9f
address: { level: repo, value: github.com/acme/checkout }
key: tests-need-local-postgres
kind: lesson
written_by: { type: agent, name: agent-de-code }
content_type: text/markdown
lifecycle: { expires_at: null, extended_by: write }
attributes: { vcs.pr: 482, ci.run: "123" }
Dans cet exemple, l'adresse indique où la note s'applique, la clé sert à la retrouver et à décider comment une nouvelle écriture interagit avec l'ancienne, et le cycle de vie décrit quand ça expire. La provenance dit qui l'a créée. Des attributs nommés par domaine peuvent conserver des informations utiles sans obliger tous les outils à les connaître.
Définir les opérations et les conventions
Un standard pourrait ensuite préciser quelques opérations communes : écrire, lire, lister, rechercher, archiver. Les noms ne suffisent pas. Les entrées, les résultats et les erreurs doivent avoir une sémantique partagée. Sinon, deux serveurs peuvent tous les deux proposer une opération « lire », mais appliquer des règles incompatibles.
Des conventions versionnées seraient utiles pour les niveaux d'adresse (global, projet, dépôt, branche) et pour les types de mémoire. Les monorepos montrent pourquoi une hiérarchie trop rigide peut devenir pénible : il faut parfois une portée intermédiaire, liée à un sous-projet. La spécification devrait distinguer ce qui est commun de ce qui reste en extension locale.
Les attributs demandent la même logique. Des espaces de noms comme vcs.*, ci.* ou agent.* permettent à un outil spécialisé d'ajouter des données sans casser la lecture par un autre outil. Et une règle essentielle : préserver les attributs inconnus quand on réécrit un enregistrement. Les ignorer à la lecture, c'est tolérable. Les supprimer silencieusement, beaucoup moins.
Enfin, les tests de conformité seraient plus utiles qu'une « implémentation de référence » unique. Ils vérifieraient qu'un enregistrement peut être converti sans perdre de champs, que les champs inconnus sont préservés, et que l'expiration annoncée est bien appliquée. Les équipes pourraient garder leurs propres stockages, tout en s'assurant qu'ils respectent le contrat.
Rendre visibles l'origine, l'expiration et les risques
Le choix de la personne (ou du système) qui écrit une mémoire relève de la conception. Parfois, c'est un mainteneur qui met à jour un fichier. Parfois, c'est l'agent qui écrit directement. Parfois, un service extrait des faits d'une conversation. Un standard n'a pas besoin d'imposer une seule méthode : il doit juste permettre de l'indiquer.
L'expiration mérite la même clarté. Une consigne sur une procédure de test peut rester pertinente longtemps. Une information liée à une version de dépendance a plus de chances d'être invalide quand le code change. Une politique « d'oubli » par défaut réduit le risque de conserver des données périmées, mais elle peut aussi effacer quelque chose d'encore utile. Le bon compromis dépend du type de mémoire et de son usage.
Et il y a un autre point, moins discuté mais crucial : une mémoire peut influencer le comportement d'un agent. Une info malveillante ou erronée peut devenir une porte d'entrée pour l'injection. La provenance, les signatures éventuelles et les références au code concerné aident à évaluer une note, sans rendre l'empoisonnement impossible. Les droits d'écriture et les règles de contrôle doivent aussi rester explicites.
En revanche, le stockage, le classement, les embeddings et l'interface peuvent rester des zones où les outils se différencient. L'idée n'est pas d'étouffer l'innovation, mais de protéger le contrat commun au moment de l'échange.
Conclusion
Les mémoires des agents IA répondent à des besoins différents, mais la fragmentation rend le passage d'un outil à l'autre plus coûteux, et rend difficile le travail de plusieurs agents sur un même projet. L'exemple d'OpenTelemetry montre qu'on peut viser l'interopérabilité sans uniformiser les produits : on s'accorde sur les données et les conventions, pas sur tout le reste.
Un standard utile devrait préciser l'adresse, l'identité, le contenu, la provenance et le cycle de vie d'une mémoire, puis définir les opérations et les tests de conformité. Et il devrait aussi assumer ses limites : aucun format ne garantit qu'un souvenir est forcément vrai, pertinent ou sûr.
Pour une équipe, le bon critère n'est donc pas « combien de fonctionnalités » l'outil affiche. C'est la capacité à vérifier ce qui est mémorisé, à faire évoluer ces informations proprement, et à les transmettre sans perdre le contexte. C'est à partir de là que les outils peuvent vraiment travailler ensemble.