Mémoire partagée entre agents IA : la fragmentation est un choix

J’ouvre Claude Code à dix heures pour écrire un petit module. À quatorze heures, je reviens à mon assistant personnel pour rédiger un mail sur le même sujet, et je dois lui réexpliquer ce que Claude Code vient de faire, pourquoi, et quelles options j’ai écartées. La mémoire ne traverse pas la frontière entre les agents. Chacun vit dans son propre crâne, et la taxe de la fragmentation finit par dépasser le bénéfice de la spécialisation.

Pejman Pour-Moezzi a résumé ça d’une formule juste : stop giving every agent its own skull. Le diagnostic est exact. La direction qu’il pointe, une couche de mémoire commune en dessous de tous les agents que j’utilise, est aussi la bonne. Mais sur ce qu’il faut faire concrètement en 2026, son fil reste à l’altitude du manifeste. Ce post est ma version au ras du sol.

La fragmentation a un coût mesurable

Trois coûts, pas un.

Le premier est temporel : chaque agent réexplique. À la fin de la semaine, j’ai passé une heure cumulée à recoller des morceaux que l’agent d’à côté connaissait déjà.

Le deuxième est plus pernicieux, c’est la dérive. Quand je décris la même décision à trois agents, je la décris trois fois différemment. Codex finit par compiler une version, mon assistant personnel une autre, Claude Code une troisième. Le projet acquiert plusieurs vérités parallèles, et c’est en relisant un mail trois semaines plus tard que je découvre qu’elles ne disent pas la même chose.

Le troisième est la non-propagation des décisions. J’écarte une approche à 11h dans Claude Code, je rouvre l’assistant perso à 16h, il me la repropose tranquillement. Aucun signal n’est passé. Multiplié par quelques agents et quelques jours, c’est l’arbre d’idées qui retombe en feuilles mortes.

La mémoire utile n’est pas la transcription

L’instinct est de tout déverser dans un store partagé : transcriptions de session, contenu des onglets, fichiers ouverts. C’est la mauvaise unité.

La plupart d’une session est du bruit. Le morceau qui mérite d’être gardé est court, une décision, une contrainte, une préférence, une option qu’on a écartée et pourquoi.

C’est précisément la partie que les transcriptions noient et que les markdown bien écrits capturent. La discipline est ennuyeuse : à la fin d’une session non triviale, j’écris trois à cinq lignes dans le fichier mémoire du projet. Pas un résumé exhaustif, la liste courte des choses qu’un autre agent (ou moi dans deux semaines) doit savoir avant de toucher au sujet.

C’est la même logique que pour un cerveau de travail à court terme : ce qui sert n’est pas le journal, c’est l’index.

Trois couches qui marchent aujourd’hui

Pas besoin d’attendre la mémoire universelle. Ce qui existe déjà, posé proprement, couvre 80 % du problème.

Les fichiers versionnés (CLAUDE.md, AGENTS.md, .claude/memory/, ~/.codex/instructions.md) sont la couche zéro. Tout agent qui ouvre le repo les lit. C’est synchrone, auditable, diffable. Le coût d’entrée est nul ; le gain est immédiat. C’est aussi ce qu’on perd à coller du contexte à la main dans chaque IDE.

MCP (Model Context Protocol) est la couche un. Un serveur que tous mes agents peuvent interroger, pour des notes, des tickets, une base de docs, devient la couche transversale que les fichiers ne fournissent pas. Un seul endroit où une décision s’écrit, plusieurs agents qui la lisent. Le protocole est jeune mais déjà suffisant pour des cas concrets : memory MCP, GitHub MCP, Notion MCP.

Les conventions humaines sont la couche deux, et la plus importante. Quand je passe d’un agent à l’autre, j’écris une ligne. Pas un résumé. Une ligne qui dit ce qui a été décidé et ce qui reste ouvert. Aucun protocole ne remplace ça, c’est l’interface entre moi et les agents, pas entre les agents entre eux.

Une mémoire partagée est une surface partagée

C’est l’angle que Pejman survole et qui me préoccupe le plus.

Si tous mes agents lisent le même store, alors une note injectée dans ce store atteint tous mes agents. La prompt injection indirecte que j’évite péniblement dans Claude Code se propage gratuitement à Codex et à l’assistant perso. Le rayon d’action d’un seul document piégé passe de un agent à tout le cerveau distribué.

Trois mesures qui rendent cela tenable :

Scoper le store. Une mémoire par projet, pas une mémoire globale. La couche commune doit avoir des cloisons, sinon le fil de mes finances personnelles arrive dans la session où je code pour un client.
Étiqueter la provenance. Chaque entrée porte d’où elle vient : écrite par moi, écrite par Claude Code après tel run, importée d’un PDF. Les agents traitent ces classes différemment ; sans étiquette, ils ne peuvent pas.
Traiter la mémoire comme une entrée. Une note lue depuis le store est une entrée externe, pas une instruction de confiance. C’est le même réflexe que le moindre privilège pour un modèle de langage, appliqué à sa mémoire.

La version réaliste, pas le hive mind

Le hive mind est une bonne image pour vendre la direction. Il n’est pas le but. Ce que je vise est plus humble : trois ou quatre agents spécialisés, une couche commune de fichiers et de MCP que je curate, et l’habitude d’écrire ce qui mérite d’être su plutôt que de le réexpliquer.

Le rendu, vu depuis mon clavier, est exactement celui que Pejman décrit : un système qui se comporte moins comme un trousseau d’assistants amnésiques, et plus comme un esprit distribué avec des mains différentes. Mais le chemin pour y arriver n’est pas un projet de mémoire universelle, c’est une série de petites disciplines, posées sur les couches qui existent déjà.

Moins de magie. Plus de conventions.

Si cela vous a parlé, vous aimerez Fichiers mémoire : donner à ton agent un cerveau de travail à court terme et Arrêtez de coller du contexte : un meilleur workflow dans l’IDE. Abonnez-vous ci-dessous pour recevoir le billet de vendredi prochain.