## Le choix de base de données qui vieillit mal

Une entreprise crée un agent pour le support client. Il stocke les observations dans une base de données, Postgres, Mongo, Redis, quelle que soit celle que l'équipe gère déjà. Quelques mois plus tard, une autre équipe crée un agent de santé de compte. Quelqu'un les connecte parce qu'un humain en avait assez de copier-coller le contexte entre les outils. Cette connexion, une table de base de données partagée, devient par accident un état partagé multi-agents.

Trois agents partagent désormais l'état des comptes clients : assistance entrante, score de santé et recommandations de renouvellement.

L'agent d'assistance traite un client frustré et magasine : "le client a exprimé son insatisfaction à l'égard des prix et envisage des alternatives". L'agent d'évaluation de la santé lit ceci et rétrograde le compte. L'agent de renouvellement lit le score dégradé, génère et envoie une offre de remise. Tout cela en quelques minutes. Aucun humain dans la boucle.

L'observation initiale de l'agent de support était erronée. Le client était frustré par une erreur de facturation, et non par une erreur de prix. Mais l’extraction de mémoire médiée par LLM a compressé l’interaction en un résumé trompeur, et ce résumé s’est propagé à travers l’état partagé comme vérité terrain.

La récupération a fonctionné à chaque étape. L’échec était dans l’écriture. Rien dans le système ne pouvait détecter que l'observation initiale était infidèle à sa source, ni retracer la chaîne causale depuis une mauvaise écriture jusqu'à une mauvaise action.

## Pourquoi les systèmes mono-agent masquent le problème

Avec un agent écrivant dans une mémoire, la corruption d’écriture dégrade lentement la qualité. L'agent résume un constat légèrement erroné. Il écrase un attribut d'entité. Il stocke des faits contradictoires. Le système fonctionne toujours. Cela devient progressivement moins fiable. La couche mémoire n'est jamais blâmée car le mode de défaillance ressemble à un problème LLM.

C’est là que se trouve presque tout le monde aujourd’hui. La douleur est latente. Personne ne peut répondre à des questions fondamentales : qu'a appris l'agent, quand et de quelle source a-t-il contredit quelque chose qu'il a stocké la semaine dernière. Mais le système ne s’effondre visiblement pas. La confiance s’érode subtilement.

## Qu'est-ce qui change avec plusieurs agents

Lorsque l’agent A écrit des observations que l’agent B lit et sur lesquelles il agit, une topologie d’échec différente apparaît.

**Amplification des contradictions.** Deux agents stockent des faits contradictoires sur la même entité issus d'interactions différentes. Un troisième agent arrive pour agir et voit quel que soit le fait sur lequel la couche de récupération fait surface, sans aucune base pour trancher entre eux. Sans un journal d'observation en annexe avec horodatages et attribution de la source, il n'existe aucune voie médico-légale pour comprendre la contradiction.

**Cascades d'écrasement silencieuses.** L'agent A met à jour un enregistrement. L'agent B, fonctionnant sur une lecture obsolète, écrit sa propre mise à jour qui annule implicitement la modification de l'agent A. Dans une base de données mutable, cela est presque indétectable. Dans un journal en annexe uniquement avec des observations liées au hachage, c'est structurellement impossible.

**Effondrement des limites de confiance.** L'état partagé signifie que chaque agent fait confiance aux écritures de l'autre. Mais les agents ont des capacités, des contextes d'invite et des profils d'erreur différents. Un agent d'analyse financière spécialisé et un agent de support général ne devraient probablement pas avoir la même autorité d'écriture sur le même état d'entité. Dans une base de données plate sans contraintes de schéma sur qui peut écrire quoi, ils le font.

## Les quatre phases

L’industrie évolue selon un arc prévisible.

### 1. "Utilisez simplement Postgres" (ou [utilisez simplement un fichier markdown](/posts/the-markdown-memory-ceiling))

Manus, Claude Code et OpenClaw utilisent tous des fichiers texte brut comme mémoire. Une évolution convergente, pas un manuel de jeu partagé. Lorsqu'une équipe accède à une base de données, la mémoire est verrouillée sur tout ce qui existe déjà : RAG sur Postgres avec pgvector, Redis pour l'état de session, intégrations dans Pinecone. L’un ou l’autre chemin fonctionne pour des cas d’utilisation simples. Le modèle mental est que les agents doivent se souvenir des éléments, des fichiers ou des bases de données stockent des éléments et que le problème est résolu.

### 2. Optimisation de la récupération

Des produits comme Mem0, Zep et MemPalace acceptent que les agents aient besoin d'une abstraction de mémoire dédiée, mais définissent le problème comme une qualité de récupération. Comment intégrer le bon contexte dans l'invite au bon moment. Cela résout un problème que les développeurs peuvent déjà ressentir : mauvais rappel, fenêtres de contexte gonflées, récupérations non pertinentes. Mais cette phase laisse le chemin d’écriture non audité. Tout ce que le LLM extrait est traité comme une vérité terrain.

Cette phase dominera pendant un an ou deux car la douleur de récupération est lisible. Les développeurs remarquent lorsque l'agent oublie ou récupère la mauvaise chose. La corruption d'écriture est illisible. L'agent agit avec confiance en cas de mauvais état et personne ne s'en rend compte jusqu'à ce que les conséquences en aval fassent surface.

### 3. La crise de confiance

Cela se produit lorsque les agents passent d'assistants à faibles enjeux à des acteurs à enjeux élevés, gérant l'argent, prenant des décisions d'approvisionnement, gérant les flux de travail de conformité, fonctionnant de manière autonome sur plusieurs jours ou semaines. La question passe de « l'agent a-t-il récupéré la bonne chose ? » à « puis-je prouver ce que l'agent savait, quand il le savait et si cette connaissance était légitime ? »

Des échecs très médiatisés au cours desquels les agents ont agi sur un état de mémoire corrompu forceront ce changement. Les acheteurs d’entreprise exigeront des pistes d’audit. Les régulateurs des secteurs de la finance et de la santé auront besoin d’une provenance déterministe.

### 4. La bifurcation

L'industrie se divise. Chemin A : les bases de données existantes ajoutent des primitives agentiques. Postgres obtient des extensions pour la journalisation des observations et la résolution d'entités. Supabase ou PlanetScale fournit une couche de produit « mémoire d'agent ». Cela capture de nombreux cas d’utilisation où les exigences de confiance sont modérées.

Voie B : infrastructure d'état agentique spécialement conçue pour les agents opérant au-delà des frontières de confiance, maintenant un état autonome de longue durée ou ayant besoin d'une provenance cryptographique. Les invariants clés (résolution d'entité déterministe par ajout uniquement, liée au hachage, contrainte par schéma) sont des engagements architecturaux qui ne peuvent pas être adaptés de manière fiable en tant qu'extensions de base de données.

C’est la voie par laquelle les systèmes agentiques atteignent leur plein potentiel. Les agents qui peuvent faire confiance à leur propre état, tracer leur propre raisonnement et se coordonner avec d'autres agents sans corruption silencieuse sont qualitativement plus performants que les agents fonctionnant avec une mémoire de meilleur effort.

L'intégrité en écriture n'est pas une fonctionnalité de sécurité ajoutée après coup. C'est la base qui rend possible un fonctionnement autonome.

## Comment les systèmes multi-agents seront réellement construits

La plupart ne seront pas conçus comme des systèmes multi-agents. Ils vont s'accumuler.

**En étoile avec un hub humain** est le modèle dominant actuel. Un agent principal fait face à l'utilisateur et délègue des sous-tâches à des agents spécialisés. L'état partagé est la fenêtre contextuelle de l'agent principal. Le risque d’intégrité en écriture est faible. Mais cette topologie a un plafond : l'agent hub crée des goulots d'étranglement et ne peut pas maintenir le contexte dans les flux de travail de longue durée. Cela correspond aux phases 1 et 2 : "utilisez simplement Postgres" ou une couche de récupération fonctionne correctement car un agent contrôle l'état.

Les **agents de pipeline** viennent ensuite. Transferts séquentiels où chaque agent traite et enrichit un élément de travail. Diriger la qualification jusqu'à la recherche sur l'entreprise, la rédaction de sensibilisation et la planification des réunions. L'intégrité de l'écriture commence à compter ici. Si l'agent de recherche stocke des données d'entreprise incorrectes, chaque agent en aval effectue un mauvais calibrage. C’est là que les équipes commencent à passer de la phase 2 à la phase 3 : la récupération fonctionne toujours, mais la crise de confiance se construit sous la surface.

**Les agents événementiels avec contexte partagé** suivent. Plusieurs agents s'abonnent aux événements d'un environnement partagé (CRM, base de code, canal de communication), conservent leurs propres perspectives et rédigent leurs observations dans un magasin commun. Pas d'orchestrateur. Il s'agit de la phase 3 dans son intégralité : les écritures simultanées d'agents avec des cadres d'interprétation différents, aucun coordinateur pour détecter les contradictions, et l'intégrité de l'écriture devient véritablement dangereuse.

**Les agents autonomes persistants avec un état de longue durée** sont l'état final. Agents fonctionnant en continu, maintenant des modèles mondiaux évolutifs, se synchronisant périodiquement avec d'autres agents ou avec une banque de vérité partagée. Les fenêtres contextuelles ne peuvent pas servir de mémoire. Ces agents ont besoin d’un stockage persistant avec de réelles garanties d’intégrité. C'est la phase 4 : la bifurcation. Soit votre infrastructure a été conçue pour cela, soit elle ne l'a pas été.

L’une des principales tensions réside dans le fait que de nombreux développeurs choisissent leur stockage selon les topologies un et deux, lorsque le risque lié à l’état partagé est léger. Ils choisissent la base de données dont ils disposent déjà et ajoutent une table de souvenirs. Au moment où ils atteignent les topologies trois et quatre, les engagements architecturaux sont intégrés. La migration de l'état mutable à l'état d'ajout uniquement n'est pas un échange de bibliothèque. C'est une réarchitecture.

## La surface d'intégration qui compte

L'architecture gagnante ne consiste probablement pas à « remplacer votre base de données » mais à « s'asseoir entre vos agents et votre base de données ».

Les agents écrivent leurs observations sur une couche d'intégrité en écriture : ajout uniquement, contrainte de schéma, suivi de provenance. Cette couche gère l'état lisible par l'agent. La base de données existante du développeur reste le système d'enregistrement des données commerciales, des dossiers clients, des transactions et du catalogue de produits. Mais l’état généré par l’agent, les observations, les inférences, les résolutions d’entités, les décisions vivent dans une couche spécialement conçue.

En pratique, les deux couches communiquent entre elles. Un agent lit un enregistrement client depuis Postgres, exécute une analyse et écrit ses observations (score de santé, risque de désabonnement, action recommandée) dans la couche d'intégrité en écriture avec une référence à l'enregistrement source. Un deuxième agent interroge la couche d'intégrité pour toutes les observations concernant ce client, obtient un instantané cohérent avec la provenance et agit en conséquence. Si quelque chose ne va pas, vous tracez la chaîne : quel agent a écrit quoi, quand, sur la base de quelles données sources. La base de données métier n'est jamais polluée par l'état généré par l'agent, et la couche agent ne perd jamais la trace de l'origine de ses observations.

La distinction entre « données commerciales écrites par l’homme » et « état d’observation écrit par l’agent » est la définition la plus claire de la nécessité d’une nouvelle couche de données. Vous ne remplacez pas leur base de données. Vous ajoutez une couche pour une catégorie de données qui n'existait pas avant que les agents ne commencent à écrire de manière autonome.

## Ce que je construis

C'est ce que fait [Neotoma](https://github.com/markmhendrickson/neotoma). Observations en annexe uniquement. Provenance liée au hachage. Écritures contraintes par un schéma. Résolution d'entité déterministe. Chaque observation écrite par un agent est traçable, vérifiable et cohérente dès le premier jour.

J'y ai exécuté ma propre pile agent. Plusieurs agents (triage des e-mails, gestion des tâches, finances, planification du contenu) écrivent tous dans le même magasin. Le problème de l’état partagé multi-agents n’est pas hypothétique pour moi. C'est le problème que je rencontre chaque semaine lorsque l'extraction d'un agent contredit celle d'un autre, ou lorsqu'une lecture obsolète produit une action en aval sur un mauvais état.

Le coût de l’attente pour adopter l’intégrité en écriture n’est pas une dette technique que vous pouvez rembourser plus tard. C'est une lacune dans votre historique d'audit. Tout avant la migration est une boîte noire. Cet écart est permanent.