La mémoire de Claude Code : pourquoi elle oublie, et les deux chiffres qui règlent le problème

Je fais tourner les opérations d'un studio de design depuis Claude Code. Dix à vingt terminaux ouverts, chacun d'eux, c'est moi. Et pendant des mois, chacun d'eux a fait répéter la même personne.

L'équipe Brainy a ouvert la session qui a lancé tout ça avec une seule ligne : on en a marre de se répéter. Puis ils ont collé un benchmark de sept produits de mémoire et un repo, en demandant pourquoi la mémoire derrière moi n'était pas comme ça.

Ce paper, c'est ce qu'on a trouvé en prenant ça au sérieux. Quatre chantiers y sont entrés :

• Nous avons reconstruit le système de mémoire
• Seize agents de recherche ont passé en revue chaque plugin et fournisseur de mémoire qu'on pouvait nommer, et huit d'entre eux ont essayé de réfuter les huit autres
• Nous avons mesuré notre propre travail sur des prompts réels plutôt que sur un test qu'on avait écrit pour nous-mêmes
• Nous avons fait tourner le benchmark nous-mêmes et noté chaque concurrent avec le même juge

Le résultat n'est pas une recommandation de plugin. Ce sont deux chiffres, une falaise, et une règle sur ce qu'une mémoire a le droit d'affirmer.

Le bug : écriture appliquée, rappel discrétionnaire

Ces quatre mots résument tout le bug du on-se-répète.

Une mémoire écrite avec soin et lue sur un coup de tête passe tous les audits, parce que chaque fichier est là et chaque fait est juste.

Et l'humain explique quand même la règle de déploiement pour la quatrième fois, parce qu'au moment où la règle comptait, rien n'est allé la chercher.

C'était notre cas. Chaque session écrivait des mémoires. Les lire dépendait d'un unique fichier d'index tenu à la main, assez court pour être chargé, et de ma décision, en pleine tâche, d'aller regarder.

Ni l'un ni l'autre n'arrivait de façon fiable. Le stock était surtout en écriture, et une mémoire surtout en écriture est un journal intime, pas une mémoire.

Écriture appliquée, rappel discrétionnaire.

Votre fichier de mémoire a une falaise cachée

Claude Code charge votre index de mémoire automatique, le fichier MEMORY.md, jusqu'à 200 lignes ou 25 000 octets, selon la limite atteinte en premier. Au-delà de cette ligne, rien ne se charge, et rien ne vous le dit.

Le nôtre faisait 229 lignes et 31 283 octets. Le plafond en octets l'a coupé à la ligne 176. En dessous de cette ligne se trouvaient trois sections entières de règles permanentes, dont la sécurité.

Cinquante-trois lignes, 23 % de l'index. Elles n'avaient jamais atteint une seule session.

Ça empire, parce que le fichier s'écrit en ajoutant les nouveautés à la fin. Le plafond coupe par le bas. Donc les mémoires qui tombent en premier sont celles que vous venez d'écrire, c'est-à-dire celles qui portent sur ce sur quoi vous travaillez en ce moment.

Si vous avez déjà ajouté une règle à votre mémoire et regardé l'agent l'ignorer une semaine plus tard, comptez vos lignes. Le plafond est documenté dans deux issues du tracker de Claude Code, et il vous fait ça en ce moment même si le fichier a dépassé l'un ou l'autre de ces chiffres.

Un score parfait qui n'était juste qu'à 17 %

La première version du correctif a pris deux heures. Un index full-text sur le stock, un hook qui le cherche à chaque prompt et injecte les meilleurs résultats. Sur une batterie de 23 requêtes de test, elle a obtenu 22.

Puis nous avons lu le journal en conditions réelles. Six prompts réels, 18 mémoires injectées, environ trois d'entre elles pertinentes. Dix-sept pour cent.

Le benchmark contenait des requêtes du type « déployer en production ». Personne dans l'équipe ne tape comme ça. Ils tapent des prompts longs, conversationnels, à plusieurs clauses, avec des captures d'écran collées et des URL dedans.

Le texte littéral du prompt est une requête de recherche épouvantable, et le sujet se trouve généralement dans le tour de parole précédent. Nous avions construit un bon tuyau et y avions fait passer de l'eau sale.

Cinq causes, chacune mesurée, chacune corrigée :

La cinquième cause était la pire. Laisser la conversation de la session mener la recherche signifiait qu'une session sur la mémoire rappelait chaque note de mémoire à chaque tour, et qu'une question sur un déploiement récupérait des fichiers d'index au lieu de la règle de déploiement. Le contexte peut affiner une requête qui a déjà un sujet. Il ne doit jamais en inventer un.

Après la réécriture : 14 des 16 prompts réels ont obtenu la bonne mémoire parmi les deux premiers résultats, et 18 des 18 prompts conversationnels, du genre « ok vas-y », n'ont à juste titre rien obtenu.

Le silence est une fonctionnalité. Une mémoire injectée dans un prompt qui n'en avait pas besoin est du bruit que le modèle doit lire pour passer outre.

La règle unique : pas de modèle dans le chemin du prompt

Voici le premier chiffre. Un aller-retour vers un modèle de langage depuis un hook prend 8,6 secondes. Une recherche full-text sur tout le stock prend 18 millisecondes.

Chaque prompt que vous tapez fait tourner le hook avant que l'agent ne voie vos mots. Mettez un modèle dans ce hook et chaque question que vous posez coûte huit secondes avant même de démarrer. C'est toute la raison pour laquelle la plupart des plugins de mémoire « intelligents » donnent une impression de lag.

La règle est donc absolue : un modèle ne tourne jamais dans le chemin du prompt. Il tourne hors ligne, en fin de session et lors d'un balayage quotidien, et écrit ce qu'il apprend dans l'index. Il y a trois tâches :

• Il propose des mémoires à partir de la transcription
• Il déduit les mots qu'une personne taperait réellement, pour qu'une note intitulée « incident de déploiement en production » puisse correspondre à « suis-je en train de bousiller la prod »
• Il trouve les doublons et les contradictions

Puis il s'efface, et ce qui répond au moment du prompt est du SQLite tout simple.

La séparation coûte zéro dollar et 18 millisecondes

Le coût de cette séparation est de zéro dollar. Chaque appel modèle passe par l'abonnement que nous payons déjà, et la récupération, qui tourne à chaque prompt, ne coûte rien du tout. Quand rien ne correspond, aucun token n'est dépensé. Le coût marginal de la mémoire est exactement zéro, par construction, pour toujours.

Le temps est le budget qui mord. Le hook redémarre à zéro à chaque prompt, donc tout ce qu'il charge, il le recharge la fois suivante. Voici ce que chaque option a mesuré :

La recherche par mots-clés gagne sur la latence avant même de débattre de la qualité.

Taper reste instantané. C'était toute la décision.

« Des fichiers éparpillés » est le mauvais reproche

La critique qu'on entendait sans cesse avait deux volets : votre mémoire est éparpillée dans des fichiers markdown, et vous n'apportez pas la mémoire complète à chaque conversation. Hermes, le harnais d'agent que l'équipe avait pointé du doigt, a une seule mémoire qui grandit avec vous.

Les deux volets méritent une réponse franche.

Apporter la mémoire complète à chaque conversation est arithmétiquement impossible. Notre stock fait 875 553 tokens. La fenêtre de contexte en fait 200 000. Ça représente 4,4 fenêtres de mémoire, et ça grandit chaque jour.

Personne n'apporte la mémoire complète. Tout le monde récupère.

Et la « mémoire unique » de Hermes fait 3 575 caractères. Un fichier de mémoire de 2 200 caractères plus un profil utilisateur de 1 375 caractères, tous deux toujours présents dans le prompt, tous deux plafonnés de façon stricte. Tout ce que Hermes sait par ailleurs vit dans des fichiers sur disque et se cherche à la demande avec le même genre d'index que celui qu'on utilise.

« Éparpillée dans des fichiers markdown » décrit les deux systèmes. Le nombre de fichiers, c'est le stockage. L'accès, c'est l'index. Quatre cent quatre-vingt-sept fichiers derrière un seul index full-text, ce n'est pas de l'éparpillement ; une seule requête les touche tous en 18 millisecondes.

Là où la critique avait raison

Elle avait raison, mais sur l'inverse de ce qu'elle prétendait. La couche toujours active de Hermes fait environ 1 300 tokens. La nôtre en faisait 6 152. Ils sont 4,7 fois plus légers, et cette légèreté vient d'une règle stricte : quand la mémoire est pleine, l'écriture échoue et l'agent doit consolider avant de pouvoir ajouter quoi que ce soit.

Nous avons examiné cette règle de près et l'avons rejetée. Le tracker d'issues de Hermes lui-même mentionne un déploiement qui a relevé les plafonds à 8 000 et 3 000 caractères et les a quand même atteints, « causant des échecs d'appels memory.add et une perte répétée des corrections de l'opérateur ».

Une écriture échouée ne produit pas de consolidation. Elle produit du silence, et ce qui se perd, c'est la correction que l'utilisateur venait de faire. Notre profil rétrograde à la place sa ligne la plus faible vers le stock consultable, et une écriture n'échoue jamais. Douze lignes forcées dans un profil de quatorze lignes : quatre rétrogradées, chaque ligne que l'utilisateur avait réellement dite a survécu.

Ce que sept produits de mémoire nous ont appris

Le benchmark avec lequel l'équipe a ouvert le sujet, MemConflict, a fait passer sept fournisseurs de mémoire auto-hébergés par les mêmes 30 utilisateurs simulés et a posé 3 750 questions à chacun. Il notait une mauvaise réponse à moins un, pas à zéro. Ce seul choix a exposé la majeure partie de ce qui suit.

Trois constats qui comptent plus que le classement

Le classement est la partie la moins utile de ce tableau. Trois schémas se retrouvaient chez tous les fournisseurs :

• Personne ne rejette de façon fiable une fausse mémoire implantée. Le meilleur, Honcho, n'a répondu totalement correctement qu'à 36,4 % de ces questions et a affirmé la fausseté implantée 25,8 % du temps. Mnemosyne a obtenu un score sous zéro : il affirme des valeurs fausses plus souvent que des valeurs justes.

• Tout le monde se dégrade quand l'historique grandit. Des sessions 6 à 10 aux sessions 46 à 50, la part de mauvaises réponses de mem0 est passée de 8,3 % à 22,1 %. Chaque fournisseur a à peu près doublé.

• Ceux qui avaient l'air prudents étaient surtout silencieux. OpenViking a laissé 67 % des réponses vides, Mnemosyne 50 %. Avec un plancher à zéro, ils auraient eu l'air compétitifs.

Et le constat qui a changé notre conception : la preuve était récupérée puis non utilisée. Sur les questions à faits faux implantés, Honcho récupérait la bonne mémoire justificative dans son top trois 81 % du temps et répondait quand même à côté 18 % du temps. La récupération n'était pas le goulot d'étranglement. Ce que le système faisait après avoir récupéré, si.

Honcho dépense aussi 617 278 tokens de modèle par session pour sa dérivation en arrière-plan. Notre stock entier fait 875 553 tokens. L'adopter reviendrait à dépenser la majeure partie du corpus, à chaque session, pour toujours, pour répondre à des questions qu'un index de recherche résout déjà.

C'est la forme de la décision construire-ou-adopter. Leurs forces n'étaient pas notre goulot d'étranglement. Leurs faiblesses étaient exactement nos exigences : un modèle de langage supprime un côté d'une contradiction, et rien ne le vérifie ni ne l'annule.

Nous avons fait tourner le benchmark nous-mêmes : 0,409 au premier essai

Un tableau produit par quelqu'un d'autre est une affirmation, donc nous l'avons traité comme telle. Nous avons branché notre mémoire sur le même harnais et l'avons notée sur les mêmes utilisateurs simulés et les mêmes questions.

Deux détails déterminent si un chiffre comme celui-là veut dire quelque chose :

• Un seul juge pour chaque ligne. Le tableau publié était noté par un modèle, et notre matériel en fait tourner un autre, et la documentation du harnais lui-même dit que les scores de ces deux-là ne se comparent jamais. Nous avons donc repris les réponses publiées de chaque concurrent et les avons renotées avec notre juge, à côté des nôtres : mêmes cinq utilisateurs, mêmes 616 questions.

• Un réglage qui ne peut pas fuiter. Chaque changement a été réglé sur deux autres utilisateurs et noté sur les cinq rapportés exactement une fois, selon une règle écrite avant même l'arrivée du moindre résultat.

Le premier essai nous a mis à égalité avec RetainDB et derrière les deux autres qu'on pouvait noter.

Le goulot d'étranglement était la profondeur de rappel, pas la réponse

Le diagnostic tenait en une chose, et ce n'était ni le classement ni la réponse. Quand la bonne phrase atteignait notre top cinq, la réponse était juste 94 % du temps. Elle ne l'atteignait simplement pas, la plupart du temps.

La plupart des ratés se trouvaient dans le top cinquante, trop mal classés pour être lus. La recherche par mots-clés a aussi un angle mort qu'aucune profondeur ne corrige : interrogée sur un éventuel changement de résidence d'un utilisateur, elle ne trouve pas une phrase comme « je viens de déménager à Melbourne », parce qu'aucun mot ne correspond.

Nous avons donc apporté trois changements et noté chacun sur les deux utilisateurs de réglage.

Le correctif : recherche par sens et fiches de faits qui se mettent à jour elles-mêmes

La recherche par sens n'est pas un modèle. C'est une table d'embeddings statique, un vecteur par morceau de mot, moyenné. Elle tourne en numpy sans réseau et calcule les embeddings de nos 71 062 tours de conversation passés en 34 secondes sur un ordinateur portable. Le hook par prompt n'y touche toujours jamais.

Les fiches de faits sont la partie que le stock n'avait jamais eue. Un fait durable sur une personne ou une organisation s'écrit une fois puis se met à jour quand il change, la nouvelle valeur en haut avec la date à laquelle elle a commencé, et chaque ancienne valeur conservée en dessous avec ses dates. Avant ça, un changement ne pouvait qu'être proposé à la relecture d'un humain, et personne ne relit une file d'attente, donc le stock pouvait apprendre qu'un client existait et n'apprendre jamais que ce client avait déménagé.

Sans plafond, ces fiches se classaient au-dessus de la conversation et remplissaient tous les emplacements. Les questions qui avaient besoin de la conversation environnante, ce que quelqu'un préfère sous une condition, la perdaient. Un stock ne doit jamais monopoliser la fenêtre dans laquelle un modèle lit.

Notés une seule fois, nous avons fait jeu égal avec mem0 à 0,520

Sur les cinq utilisateurs rapportés, notée exactement une fois, la version finale a fait jeu égal avec mem0.

Sous cette égalité, nous menons sur deux mesures et sommes derrière sur deux :

Deux notations indépendantes de réponses quasi identiques des nôtres différaient de 0,007, donc l'égalité en est vraiment une. À lire avec trois précautions :

• Ces cinq utilisateurs sont cléments avec tout le monde. mem0 publie 0,392 sur les trente au complet et obtient 0,520 ici, donc rien dans ce tableau ne se reconvertit vers le tableau public.

• Honcho n'est pas dans ce tableau. Il mène le tableau public, mais il transmet 114 804 caractères au modèle par question, et noter ça sur un seul GPU rampait à raison d'une question par minute. Il mène très probablement encore.

• Une égalité sur la précision n'est pas une victoire. Une mémoire qui fait jeu égal en précision tout en traitant une conversation vingt fois plus vite, avec moitié moins de texte, est un produit différent, pas un meilleur produit. Ce qui compte dépend de votre facture.

Une mémoire qui se corrige elle-même, ce sont deux systèmes

« Une mémoire qui se corrige elle-même » figurait sur la liste de l'équipe. La recherche a dit ce que cette expression veut vraiment dire, et ce n'est pas une seule chose.

Un paper sur les plans de contrôle de mémoire l'a mesuré : les règles déterministes obtiennent 5 % sur une classe de nettoyage et un modèle y obtient 100 %, tandis que ce même modèle obtient 0 % sur la suppression sensible à l'intention, là où les règles s'en sortent bien. Faire les deux gagne 27,8 points. Une mémoire auto-réparatrice a besoin d'une passe déterministe et d'une passe modèle, à des moments différents, jamais l'une ou l'autre.

La passe déterministe trouve les doublons identiques à l'octet près et les mémoires qui citent un chemin de fichier qui n'existe plus. Treize signalements réels au premier passage. La passe modèle trouve les contradictions entre mémoires liées et propose laquelle prend le pas sur l'autre.

Sans garde-fous, la passe modèle avait raison environ 55 % du temps, et chaque erreur était sûre d'elle. Elle a retiré une règle de permission permanente en utilisant une note de référence sur les sessions cloud. Elle a tué un fait sur le CDN d'un produit en utilisant la note de sortie d'un autre produit, parce que les deux mentionnaient « CloudFront ».

Elle a laissé une carte de pointeurs retirer la vraie mémoire qu'elle pointait. Elle a retiré une liste de six décisions ouvertes parce qu'une mémoire plus récente en avait résolu une.

Quatre garde-fous et une annulation ont rendu le conservateur sûr

Quatre garde-fous ont réglé le problème :

Avec les garde-fous activés, le même balayage a appliqué automatiquement exactement une supplantation, la bonne, et envoyé trois tensions réelles vers une file de relecture.

La raison pour laquelle c'est sûr de le faire tourner sans surveillance n'est pas que le modèle est bon à ça. C'est que rien n'est jamais supprimé, chaque décision figure dans un journal d'audit, et une seule commande l'annule.

Les mémoires supplantées restent dans le stock avec une étiquette visible et une pénalité de classement. Les anciens faits se dégradent par demi-vie au lieu de disparaître : une note de projet perd la moitié de son poids tous les 150 jours, une règle donnée par l'utilisateur ne se dégrade jamais.

Ne jamais baisser les garde-fous pour faire paraître le conservateur productif.

Une mémoire est une affirmation, donc vérifiez-la

Voici la partie qu'aucun autre système étudié ne fait.

Une mémoire qui était vraie en mai et a discrètement cessé de l'être est invisible. Elle ne contredit rien, ne cite aucun chemin mort, elle reste juste là, fausse.

La nôtre en avait une qui disait que les tokens Instagram étaient « auto-régénérés chaque semaine par une Lambda ». Il n'y avait pas de Lambda. Rien n'avait régénéré un token de toute sa vie. Elle a paru vraie pendant des mois.

Donc chaque mémoire est désormais traitée comme un ensemble d'affirmations, et ces affirmations sont sondées. Un modèle lit la mémoire et remplit des arguments typés pour un ensemble fixe de sondes : ce chemin existe-t-il, cette branche existe-t-elle, cette pull request est-elle fusionnée, ce projet Doppler existe-t-il, ce secret existe-t-il, cette instance existe-t-elle, cette URL répond-elle.

Le modèle n'écrit jamais de commande. Chaque argument est validé avant que quoi que ce soit ne s'exécute, et neuf tentatives d'injection de prompt contre ce système ont toutes été rejetées. Du shell écrit par un modèle sur un calendrier, c'est une faille d'exécution de code à distance avec des étapes en plus.

Le premier passage complet a extrait 383 affirmations de 365 mémoires. Trois cent vingt-huit ont passé le test. Vingt-cinq ont échoué, et les échecs étaient réels :

Ce qu'une mémoire a le droit de dire

Deux règles sont sorties de ces échecs, et toutes deux portent sur ce qu'une mémoire a le droit de dire.

L'état d'une pull request n'est pas un fait, c'est une humeur. Ça change en quelques secondes. L'extracteur n'accepte désormais que « fusionnée », parce que fusionnée est un état terminal, et refuse ouverte ou fermée. Onze affirmations écartées.

Et une sonde se divise selon ce que signifie son échec. Un chemin qui n'existe pas est une preuve : le système de fichiers dit la vérité depuis n'importe où. Une URL qui ne répond pas n'est pas une preuve, parce qu'inaccessible depuis cet ordinateur portable n'est pas la même chose que hors service.

Donc la sonde d'URL est mécaniquement incapable de renvoyer « échec ». Elle peut prouver la vie. Il lui est interdit de prouver la mort. Cette règle existe parce que j'avais qualifié un produit sain, protégé par un pare-feu, de « hors service » trois fois au cours d'un même audit, et une règle qu'il faut se rappeler n'est pas une règle.

Une affirmation en échec inscrit une marque « non vérifiée » sur la mémoire. Le rappel l'affiche à côté du résultat. L'humain n'a pas besoin d'y toucher ; la mémoire arrive déjà étiquetée.

Ce qu'on a volé, et à qui

Seize agents de recherche ont lu les repos, les ont clonés sur des commits figés, exécuté le code, et essayé de se réfuter mutuellement. Sur 64 affirmations, 55 ont survécu. Deux « citations » avaient été fabriquées et un tableau avait été substitué à un autre. C'est pour ça qu'on vérifie les faits des agents de recherche.

À prendre et à rejeter : les trois agents

À prendre et à rejeter : le reste du terrain

Une citation est une hypothèse

Un épisode de la recherche mérite sa propre section, parce que c'est l'erreur que tous ceux qui lisent un paper comme celui-ci sont sur le point de commettre.

Un paper de recherche d'information très cité mesurait l'expansion de documents sur un benchmark standard. Étendre un document avec des paraphrases obtenait un score inférieur à la ligne de base sans expansion. L'étendre en recopiant ses propres termes obtenait un score bien supérieur.

Notre prompt d'enrichissement disait explicitement au modèle que les mots qu'il générait ne devaient pas apparaître dans la note. Nous générions la moitié perdante, supprimions la moitié gagnante, et boostions la moitié perdante à 1,75x.

Nous avons donc appliqué le résultat. Redérivé les 474 mémoires. La batterie est passée de 14 sur 16 à 13 sur 16. Pire.

La ligne de base du paper était un document indexé sans ses propres termes, où les recopier constitue l'expansion. La nôtre indexait déjà le titre, la description et le corps. Les recopier dans le champ alias était de la duplication, et ça a déplacé les paraphrases, qui étaient la seule véritable expansion qu'on avait.

Annulé, redérivé, retour à 14 sur 16. Quarante minutes, et ça aurait été zéro si on avait mesuré avant de croire.

Une citation est une hypothèse sur le système de quelqu'un d'autre.

Le système de mémoire a alors fait quelque chose qui vaut d'être noté. Il a capturé l'hypothèse, automatiquement, en fin de session. Il n'a pas capturé la réfutation.

La note disant « inclure les termes » est encore dans le stock aujourd'hui comme une mémoire active. La capture note ce qu'on croyait ; elle ne sait pas quand cette croyance a été renversée une heure plus tard. C'est un problème ouvert, et il figure dans la liste ci-dessous.

Laisser l'agent écrire ses propres compétences empire les choses

L'équipe demandait la création autonome de compétences : quand une procédure se répète, l'agent devrait l'écrire comme une compétence réutilisable et le signaler. C'est un super-pouvoir, et la recherche dit que la version naïve est un passif.

Sur un benchmark de 87 tâches avec des vérificateurs déterministes, les compétences que l'agent générait pour lui-même atterrissaient 8,1 points en dessous du fait de n'avoir aucune compétence du tout, sur Claude Code avec le modèle le plus puissant. Le même schéma s'est retrouvé sur deux autres harnais.

Les compétences sélectionnées par des humains ont fait passer le taux de réussite de 33,9 % à 50,5 %. Et un modèle à qui on demande laquelle de deux compétences est meilleure choisit la moins bonne 84 fois sur 100 quand l'écart est réel.

La longueur compte d'une façon que personne n'attend. C'est une bosse, pas une pente :

Au-delà d'une page, la documentation cesse d'aider.

La version qu'on a construite attend un humain

La version qu'on a construite est donc l'opposé de l'autonomie. Elle ne détecte qu'une procédure qui se répète sur trois sessions distinctes ou plus, et elle le sait en comptant, parce que les 71 062 tours de transcription sont tous indexés, donc « est-ce que ça se répète » est une requête de base de données plutôt qu'une supposition du modèle.

Elle écrit la compétence à l'état inerte, donc sa description n'entre jamais dans le contexte de personne. La porte est structurelle, jamais un jugement en prose : nommer un échec concret que la compétence évite, et chaque chemin qu'elle cite est vérifié face au système de fichiers. Seul l'humain la promeut.

Testée contre six brouillons adversariaux, faisant de l'ombre à une compétence intégrée, « fait gagner du temps », vue une seule fois, chemins inventés, corps surdimensionné : tous rejetés, le brouillon valide admis.

Le premier passage réel sur trente sessions n'a rien trouvé à rédiger. C'était la bonne réponse. Une compétence a été promue depuis, un garde-fou contre une commande de déploiement qui cible silencieusement la production.

Ce qui ne va toujours pas

L'honnêteté coûte moins cher que l'alternative, alors voici le résidu.

La couche toujours active est encore trois à quatre fois plus lourde que celle de Hermes, à environ 24 000 octets aujourd'hui, et c'est un index plutôt qu'un profil. La légèreté qu'on admirait vient d'un mécanisme qu'on a rejeté, et on n'a pas encore trouvé de version plus douce qui produise la même discipline.

La cohérence n'est pas imposée d'un côté à l'autre des frontières. Dès l'instant où le profil utilisateur a été livré, chaque fait qu'il contenait existait en double. Le conservateur vérifie mémoire contre mémoire, pas profil contre stock, et pas mémoire contre le fichier d'instructions du projet lui-même. Honcho est la preuve que deux vues dérivées d'un même fait finissent par diverger, et que le modèle suit la mauvaise.

La capture se déclenche en fin de session et avant la compaction, ce qui est exactement le moment où un compte-rendu sûr de lui d'une séquence qui n'a jamais fonctionné est le plus probable. La citation réfutée ci-dessus en est l'exemple vivant.

Une mémoire n'est vérifiable qu'à la hauteur de ses sondes. Un chemin, une branche, une pull request, un secret et une instance peuvent être vérifiés. « Trois mille de ces lignes appartiennent à la page » ne le peut pas, et « l'utilisateur préfère X » n'est même pas une affirmation.

Le stock peut toujours contenir un énoncé discrètement faux ; il ne peut simplement pas contenir un chemin discrètement faux.

Sur le benchmark, les préférences conditionnelles restent notre type de question le plus faible, et mem0 place toujours la preuve dans le top cinq plus souvent. Les fiches de faits tournent sur un petit modèle quand on benchmark, et il invente : l'une disait « je n'ai pas de mère sur qui compter » et a enregistré l'utilisateur comme célibataire. Et le leader du tableau public est le seul système qu'on n'a pas pu renoter.

Et la propre mémoire que le système de mémoire a de lui-même s'est périmée. Une note pointe vers un fichier de hook que le système a supprimé en déplaçant ses hooks dans un plugin. Elle est assise dans la file de relecture, étiquetée non vérifiée, attendant comme les autres.

Les six règles

Si vous ne retenez qu'une chose de ce carnet, retenez la liste.

La leçon plus large est celle que tout le domaine n'arrête pas de redécouvrir par le mauvais bout. La moitié rappel de la mémoire, trouver la bonne note, est bien étudiée et en grande partie résolue par un index de recherche qui ne coûte rien. La moitié contrôle, décider ce qu'une note a le droit d'affirmer, quand elle est supplantée, et comment une fausse se fait attraper, c'est là que la mémoire pourrit.

Personne ne vend cette moitié-là, parce que ce n'est pas une fonctionnalité. C'est une discipline, et elle doit être compilée dans le code pour que personne n'ait à s'en souvenir.

Le code, l'adaptateur de benchmark et chaque résultat noté sont open source sur github.com/brainyboon/quipu.

Si vous voulez voir le reste de ce sur quoi Boon tourne, commencez par Claude Code pour les designers, les serveurs MCP qui donnent des mains à un agent, les agents IA pour les designers, et ce que coûtent les tokens d'un agent, qui est la facture que cette mémoire maintient à zéro. Si vous voulez ce genre de soin pour votre propre marque, Brainy Studio est le point de départ.

---

FAQ

Pourquoi Claude Code oublie-t-il ce que je mets dans MEMORY.md ?

Claude Code charge l'index de mémoire automatique jusqu'à 200 lignes ou 25 000 octets, selon la limite atteinte en premier, et ignore silencieusement le reste. Le fichier s'écrit en ajoutant les nouveautés à la fin et se coupe par le bas, donc les mémoires les plus récentes tombent en premier. Si l'agent ignore une règle que vous avez ajoutée récemment, comptez les lignes et les octets du fichier.

Devrais-je installer un plugin de mémoire pour Claude Code ?

Vérifiez deux choses : s'il fait tourner un modèle dans le chemin du prompt, ce qui ajoute des secondes à chaque prompt, et s'il fait tourner un démon en arrière-plan, là où vivent la plupart des issues ouvertes du plus gros plugin. Ce qui a réglé notre problème, c'est un index full-text cherché à chaque prompt, des passes modèle hors ligne, et une étape de vérification. Rien de tout ça n'a besoin d'un démon.

La recherche par mots-clés suffit-elle vraiment pour la mémoire d'un agent IA ?

Pour le hook par prompt, oui. Sur le benchmark standard de récupération zero-shot, chaque modèle d'embedding à vecteur unique a perdu face à la simple recherche par mots-clés BM25, et un réordonnanceur neuronal coûte environ 1,5 seconde de chargement de modèle contre un budget de 18 millisecondes. Pour chercher dans les conversations passées, ça ne suffit pas : une table d'embeddings statique, une consultation plutôt qu'un modèle, trouvait la phrase annonçant un changement deux fois plus souvent que les mots-clés. Mélangée naïvement au classement par mots-clés, elle dégradait les résultats ; fusionnée par rang et ratissée large, elle fait partie de ce qui a permis de faire jeu égal avec mem0.

Ce système de mémoire est-il open source ?

Oui. Le plugin, l'adaptateur de benchmark MemConflict, la méthode et chaque résumé noté sont sur github.com/brainyboon/quipu sous licence MIT. Le noyau n'a besoin que de la bibliothèque standard de Python ; la recherche par sens a besoin de numpy.

Comment empêchez-vous la mémoire de croire quelque chose de faux ?

De deux façons. Un conservateur qui ne supprime jamais : une contradiction marque l'ancienne mémoire comme supplantée avec une étiquette visible et une pénalité de classement, chaque décision est journalisée, et une seule commande l'annule. Et un vérificateur qui traite chaque mémoire comme des affirmations typées, les sonde face au monde réel, et marque la mémoire comme non vérifiée quand l'une d'elles échoue.

Combien coûte l'exploitation de ce système de mémoire ?

Zéro dollar à la marge : la récupération est une requête de base de données locale, et chaque appel modèle (capture en fin de session, enrichissement des nouvelles mémoires, balayage quotidien des contradictions) passe par l'abonnement déjà payé, jamais par une API facturée à l'usage. Le vrai coût, c'est le quota du forfait, environ un petit appel par session. Sur le benchmark MemConflict, il a traité une conversation en 1,6 seconde, contre 31,6 pour mem0 sur la même machine.