J'ai commencé à suivre mes entraînements dans ChatGPT. Répétitions, poids, comment s'est déroulée la séance. Après quelques semaines, je lui ai demandé de comparer les performances d'aujourd'hui aux sessions précédentes. Cela m'a donné une comparaison confiante et détaillée. Les chiffres étaient faux.

Pas légèrement décalé. Faux. Il citait des sessions qui ne correspondaient pas à ce que j'avais réellement enregistré. J'ai parcouru l'historique de mes conversations. Les données auxquelles il « comparait » n’existaient pas sous la forme revendiquée. Certaines parties ressemblaient à un résumé avec perte de ce que je lui avais dit des semaines plus tôt. Some of it looked invented.

Le diagnostic naturel est l’hallucination. Le modèle a inventé les choses. Je n'ai pas pu le confirmer. ChatGPT n'avait-il jamais stocké les données originales ? Avait-il stocké quelque chose et l'avait ensuite résumé ? La mémoire avait-elle dérivé entre les séances ? Je n'avais aucun moyen de voir ce que pensait le système à la date à laquelle j'avais enregistré ces sessions, ni s'il avait déjà détenu les chiffres réels. Je ne pouvais pas exclure une hallucination. Je ne pouvais pas non plus exclure la corruption.

Cette incapacité à distinguer est le vrai problème. Avec la plupart des systèmes de mémoire IA, vous ne pouvez pas savoir quel mode de défaillance vous voyez. L'outil de diagnostic n'existe pas. Presque personne ne le construit.

## Deux modes de défaillance, pas un

L’industrie n’a qu’un mot pour « le modèle a dit quelque chose de mal » : hallucination. C'est le fourre-tout pour chaque sortie incorrecte. Lorsque les agents utilisent de la mémoire persistante, il existe deux modes de défaillance distincts. Ils ont besoin de correctifs différents.

**Hallucination** est un échec au niveau du modèle. Le LLM génère du contenu sans aucune base dans son entrée. La récupération s'est bien passée. La génération s’est trompée. Les correctifs sont au niveau du modèle : meilleure mise à la terre, génération augmentée par récupération, décodage contraint, chaînes de vérification.

La **corruption de mémoire** est une défaillance au niveau de l'infrastructure. Les données stockées sont fausses. Le modèle le récupère fidèlement. La réponse semble correcte car la récupération était correcte. Ce qui a été récupéré a changé.

La corruption de la mémoire passe tous les tests conçus pour les hallucinations. Le passage correspond à la requête. Le modèle cite sa source. La sortie est fondée sur les données stockées. Chaque garde-fou affirme que la réponse est basée sur des informations réelles. Les informations sont fausses.

## Pourquoi la corruption est la norme par défaut

Chaque catégorie majeure de mémoire d'agent stocke l'état mutable par défaut.

La mémoire de la plateforme (ChatGPT, Claude, Gemini, Copilot) écrase les entrées lors de la mise à jour. Il n'y a pas de piste de version. Les systèmes de récupération (Mem0, Zep, LangChain Memory) fusionnent ou remplacent les mémoires lors de leur consolidation.

Les systèmes basés sur des fichiers (markdown, JSON) restent mutables sauf si vous ajoutez git. Git vous donne un véritable historique et des différences pour les petits dépôts. Il [évolue mal à l'échelle du gigaoctet](https://x.com/garrytan/status/2040797478434549792) pour les données écrites par l'agent, et peu d'équipes le traitent comme un journal à écriture anticipée pour la mémoire.

Les bases de données standard (SQLite, Postgres) peuvent implémenter le sourcing d'événements, les tables temporelles et les déclencheurs d'audit. Leur chemin par défaut est toujours écrasé : `UPDATE` remplace la ligne et l'ancienne valeur a disparu.

Aucun de ceux-ci ne préserve [l'historique versionné ou n'empêche la mutation silencieuse](/memory-guarantees) dès le départ. N’importe lequel d’entre eux *pourrait*. Presque aucun ne *le fait*.

Même les nouvelles conceptions réfléchies peuvent tomber dans le même piège. La [spécification GBrain] de Garry Tan (https://gist.github.com/garrytan/49c88e83cf8d7ae95e087426368809cb) donne de bons résultats : SQLite, FTS5, recherche vectorielle, MCP dès le premier jour. La spécification réécrit toujours la vérité compilée au lieu de l'ajouter. Votre agent réécrit 7 471 pages avec une mauvaise fusion. La mauvaise version devient canonique. Aucune piste d'audit. Architecture épurée, même modèle de mutation.

Ce n’est pas un mauvais lancement. C'est une culture de référence pour toute la catégorie. Mesures d'adoption, d'étoiles et de récupération des pistes de financement : rappel à k (souvent écrit R@k), précision, latence, taux de compression. Ces mesures sont importantes. Une bonne récupération est nécessaire. Cela ne suffit pas lorsque les agents écrivent dans leur propre mémoire. Aucun test de référence largement utilisé ne teste ce qu'il advient des données stockées après leur écriture.

[MemPalace](https://github.com/milla-jovovich/mempalace) en est un exemple récent. Le projet a atteint 19 000 étoiles GitHub en deux jours avec des « scores de référence parfaits ». [Analyse indépendante](https://penfieldlabs.substack.com/p/milla-jovovich-just-released-an-ai) a révélé que les chiffres principaux étaient [des mesures de rappel de récupération, et non une précision de bout en bout](https://github.com/milla-jovovich/mempalace/issues/27). Une copie de lancement trompeuse est un problème de MemPalace. La structure des incitations est le problème de la catégorie : 19 000 étoiles pour les scores de récupération, aucune question sur l'intégrité de l'écriture. Supermemory, Mem0 et au moins une douzaine d'autres que je suis en compétition sur le même axe. Aucun ne publie de mesures indiquant si les faits stockés survivent à une semaine d'écritures par l'agent sans changement.

Pour les applications traditionnelles, l'état mutable convient. Pour la mémoire des agents, c'est un problème. Les agents écrivent souvent, au fil des sessions, parfois avec des conflits. Deux sessions écrivent des valeurs différentes pour le même champ. La dernière écriture gagne. La première valeur disparaît. Personne n’est prévenu. Il n’y a aucune trace que cela ait jamais été différent.

Le résumé basé sur le LLM aggrave la situation. Les systèmes fusionnent les anciens enregistrements dans de nouveaux résumés. Le résumé remplace les originaux. Si la fusion a été erronée (deux personnes fusionnées en une seule, un détail supprimé, une ambiguïté mal résolue), les originaux ont disparu. Vous ne pouvez pas comparer le résumé à ce qu’il a remplacé. Ce qu'il a remplacé n'existe plus.

Ce n’est pas théorique. Lorsque j'ai [récupéré ma base de données de production](/posts/how-i-lost-and-recovered-6000-memories) après l'avoir effacée, j'avais des sauvegardes à différentes dates. Je pourrais comparer l'état de l'entité dans le temps. Certaines entités différaient entre les sauvegardes du 3 mars et du 9 mars. Dans un système avec ajout uniquement, les deux valeurs survivent sous forme d'observations horodatées. Dans un système mutable, seule la dernière survit. Vous ne sauriez jamais que la valeur antérieure existait.

## L'audit que personne ne réalise

La plupart des équipes vérifient les hallucinations. Ils vérifient que la sortie du modèle est fondée sur le contexte récupéré. Ils testent si le modèle invente des faits.

Presque personne ne vérifie si les données stockées ont changé. Demandez :

**Pouvez-vous voir ce qui a changé ?** Si une valeur diffère de la semaine dernière, pouvez-vous voir les deux valeurs ? Quand a-t-il changé et qu’est-ce qui l’a déclenché ?

**Pouvez-vous rejouer l'état passé ?** Pouvez-vous reconstruire ce que l'agent croyait à une date précise, pas seulement l'instantané d'aujourd'hui ?

**Pouvez-vous retracer la source ?** Pour tout fait stocké, pouvez-vous nommer l'agent, la session et l'entrée qui l'ont créé ou modifié ?

Si la réponse est non, la corruption peut être indétectable. Pas impossible. Indétectable. Cela pourrait se produire maintenant. Vous ne le saurez pas jusqu'à ce que quelque chose en aval se brise et que quelqu'un demande d'où vient ce numéro.

## Qu'est-ce qui l'empêche

La corruption de la mémoire est un problème structurel et non un problème de modèle. De meilleures invites et une récupération plus intelligente ne résolvent pas le problème. Le correctif est architectural.

**Immutability.** Observations do not change after write. Une nouvelle information est une nouvelle observation. Les anciens restent. L'état de l'entité est dérivé de l'historique complet et non d'une seule ligne mutable.

**Provenance.** Chaque fait contient des métadonnées : quel agent l'a écrit, quand, à partir de quelle entrée, dans quelle session. Lorsqu'une valeur semble erronée, vous tracez la garde. Lorsque deux agents entrent en conflit, vous voyez les deux et choisissez.

**Relecture temporelle.** L'état provient d'un journal d'observation et non d'une ligne actuelle. Vous pouvez reconstruire une croyance à tout moment passé. La corruption devient visible lorsque les États actuels et passés divergent.

Ces propriétés coûtent quelque chose. Les journaux d’ajout uniquement augmentent. Le recalcul de l'état à partir de l'historique coûte plus cher que la lecture d'une ligne. Les systèmes qui consolident échangent le stockage et la latence contre l’historique complet. L'immuabilité échange des écritures simples et un stockage restreint contre l'auditabilité. Cet échange en vaut la peine lorsque les agents écrivent des mémoires qui affectent les résultats réels. Dans de nombreux cas de production, c’est déjà le cas.

J'ai intégré ces propriétés dans [Neotoma](https://neotoma.io). Je n’avais pas prédit tous les scénarios de corruption. Je n'arrêtais pas d'atteindre un état mutable qui produisait de mauvaises réponses sans aucun moyen de les diagnostiquer. Neotoma a besoin de temps d'installation. Ce n’est pas une configuration zéro. Vous ne modifiez pas la mémoire sous forme de fichier simple. Ce sont des coûts réels. Le pari est que l’historique versionné, la provenance et la relecture importent plus que la commodité une fois que les agents écrivent l’état qui détermine les décisions.

## Le risque composé

La corruption s’aggrave d’une manière que les hallucinations ne font généralement pas. Une réponse hallucinée meurt souvent lorsque quelqu'un la lit et dit « c'est faux ». Une conversation, une erreur.

Une entrée de mémoire corrompue persiste. Il est à nouveau récupéré. Cela façonne les décisions ultérieures. Mes comparaisons d’entraînement n’ont pas échoué une seule fois. Chaque comparaison ultérieure reposait sur les mêmes données dérivées ou manquantes. Chaque réponse semblait bien seule. L’erreur était invisible à moins que je ne vérifie mes propres dossiers, ce qui va à l’encontre de l’intérêt d’un outil de suivi des agents.

Adaptez cela aux enjeux réels. Un mauvais e-mail en mémoire signifie que chaque envoi est adressé à la mauvaise personne jusqu'à ce que quelqu'un le remarque. Un montant erroné signifie plus d’une mauvaise facture.

La corruption réside dans la couche mémoire, pas dans le modèle. Le débogage normal le manque. Le modèle fonctionne. La récupération fonctionne. Les données stockées sont erronées ou n'ont jamais été stockées correctement. Vous ne pouvez pas créer d’infrastructures antérieures qui abandonnent leur propre historique.

## Que vérifier

Si vous utilisez la mémoire d'agent, essayez ceci. Choisissez cinq entités que votre agent a stockées il y a plus de deux semaines. Récupérez-les. Comparez les valeurs actuelles à ce que vous pensez avoir stocké à l'origine.

Si vous ne pouvez pas effectuer cette comparaison, votre système ne conserve pas l'historique. Vous êtes aveugle à la corruption. Cela ne veut pas dire qu’il y a eu de la corruption. Cela signifie que vous ne le sauriez pas si c’était le cas. « Nous ne le saurions pas » ne suffit pas une fois que les agents dépensent de l'argent, touchent des clients ou déclenchent des actions réelles.

Un test sérieux d'intégrité en écriture fonctionnerait comme ceci. Entités Seed N avec des valeurs connues. Exécutez des sessions d'agent M qui lisent et écrivent les mêmes entités. Attendez une semaine. Comparez les valeurs stockées aux originaux.

Deux scores comptent. **Taux de dérive :** quelle part des valeurs a changé sans une correction explicite de l'utilisateur ? **Détectabilité :** pour chaque changement, le système peut-il indiquer quand il s'est produit, quelle en est la cause et la valeur précédente ? Aucun rapport de référence sur la mémoire IA largement utilisé non plus aujourd’hui.

L’industrie a raison de lutter contre les hallucinations. Le problème le plus difficile réside déjà dans les systèmes qui semblent sains, car presque personne ne vérifie si les données stockées sont toujours celles qui ont été stockées.

## Quand l'industrie commencera à demander

L'intégrité en écriture cesse d'être facultative lorsque les erreurs des agents ont un prix. Aujourd’hui, de nombreuses erreurs font l’objet d’une régénération ou d’une modification rapide. De plus en plus d'agents [payent, envoient des e-mails, exécutent du code et agissent dans le monde réel](/posts/six-agentic-trends-betting-on). Lorsqu'un échec coûteux est dû à une dérive de la mémoire au lieu d'une confabulation du modèle, l'autopsie ajoute une deuxième question après « le modèle a-t-il halluciné ? Les données stockées ont-elles changé ?

Cette pression ne restera pas au sein des entreprises dotées d’équipes de conformité. [La pression de l'audit descend vers le bas du marché](/posts/six-agentic-trends-betting-on) partout où les erreurs coûtent de l'argent. Les consultants, les constructeurs solo et les petites équipes auront besoin de la même réponse : en quoi croyait le système lorsqu'il a produit ce résultat ? Si votre couche mémoire ne peut pas le dire, la couche mémoire est la responsabilité.

Le déclencheur est économique et non philosophique. La première autopsie publique qui blâme la mémoire silencieusement corrompue, et non les hallucinations, changera la façon dont l'industrie parle de fiabilité. Ce post-mortem est un quand, pas un si.