Mémoire | Antoine Weill--Duflos

Le moteur de mémoire : chaleur, déclin et rêves

Fri, 05 Jun 2026 00:00:00 +0000

Dans la première partie j’ai décrit deux problèmes qui revenaient sans cesse me mordre quand je travaillais avec des agents IA. Le premier, c’est qu’ils oublient tout entre les sessions. Le second, c’est qu’ils brûlent des tokens à relire du code qu’ils ont déjà vu. Ce billet porte sur le premier problème, et sur la partie de cortexmd à laquelle je tiens le plus : le moteur de mémoire. L’approche d’ensemble est inspirée de mempalace, un projet de palais de mémoire pour agents IA ; ce qui suit, c’est la façon dont cortexmd en construit sa propre version.

La solution naïve à l’oubli, c’est de tout déverser dans le contexte. Garder un gros fichier de notes, le coller au début de chaque session et espérer que l’agent le lise. J’ai essayé des variantes de ça, et ça s’effondre vite. Le fichier grossit sans limite. Des faits anciens et périmés voisinent avec la seule chose qui compte vraiment aujourd’hui, sur un pied d’égalité. Vous payez pour toute la pile à chaque tour, et le signal qui vous intéresse se retrouve enseveli sous du bruit dont vous avez cessé de vous soucier depuis longtemps. Une mémoire humaine ne fonctionne pas comme ça, et elle ne le devrait pas. L’objectif de conception était donc simple à énoncer mais plus difficile à construire : l’agent devrait se souvenir comme le fait une personne, où ce que vous utilisez reste vif et ce que vous cessez de toucher s’estompe.

Huit sortes de mémoire

Quand un agent stocke quelque chose, cortexmd ne le traite pas comme un bloc de texte indifférencié. Chaque souvenir est auto-catégorisé dans l’une de huit sortes : observation, décision, idée, conversation, fait, préférence, plan et réflexion. La distinction compte parce que ces choses se comportent différemment dans le temps et veulent être retrouvées différemment. Une préférence (je veux toujours l’orthographe britannique, je déteste les tirets cadratins) est un fait durable sur ma façon de travailler, et elle devrait continuer à remonter. Un fragment de conversation est contextuel et surtout utile peu après qu’il s’est produit. Une décision est quelque chose que vous voulez pouvoir retrouver des mois plus tard quand vous vous demandez pourquoi diable vous avez fait ça. Étiqueter la sorte dès le départ donne au reste du système quelque chose à partir de quoi raisonner, au lieu de forcer chaque étape ultérieure à deviner à partir du texte brut.

Chaleur : chaud, tiède, froid

L’idée centrale est que chaque souvenir a une température, et que la température décline. Un souvenir frais ou récemment utilisé est chaud. Laissez-le intact et il refroidit vers tiède, puis après environ un mois d’inactivité il dérive vers froid, et les souvenirs plus froids finissent par être archivés plutôt que gardés au premier plan de l’esprit de l’agent.

Le détail crucial, c’est la promotion à l’accès : lire un souvenir le réchauffe. C’est toute l’astuce. Vous n’avez pas à curer manuellement ce qui est important. L’importance se révèle par l’usage. Les souvenirs vers lesquels vous et l’agent revenez sans cesse restent chauds précisément parce que vous revenez sans cesse vers eux, et ceux que vous ne touchez jamais coulent d’eux-mêmes. C’est le même instinct qu’un cache de type least-recently-used, sauf que ce qui est mis en cache, c’est le sens qu’a l’agent de ce qui compte en ce moment, et l’éviction est gracieuse : froid puis archivé, pas supprimé.

Pourquoi se donner tout ce mal au lieu d’un seul stock plat ? Parce que la température donne au rappel un a priori. Quand l’agent part chercher quelque chose, il ne fait pas face à une mer plate de notes également plausibles. Il a un sens intégré de ce qui a été actif récemment, et ce signal ne coûte rien de plus à maintenir parce qu’il découle de l’usage normal.

Consolidation : ranger le tiroir des froids

Laisser les souvenirs refroidir n’est que la moitié de l’histoire. Si vous laissez simplement les souvenirs froids s’empiler, vous vous retrouvez avec un tiroir plein de bouts quasi dupliqués : cinq notes légèrement différentes sur la même tâche terminée depuis longtemps, chacune un peu périmée, aucune ne valant la peine d’être lue seule. Alors cortexmd consolide. Les souvenirs froids apparentés sont repliés ensemble en résumés, de sorte que l’essentiel survive en un endroit cohérent tandis que les fragments redondants cessent d’encombrer. Le détail n’est pas jeté à la légère, il est compressé en quelque chose que vous voudriez réellement lire plus tard. Le refroidissement décide de ce qui n’est plus urgent ; la consolidation décide quoi en faire.

Rappel hybride

Bien stocker la mémoire ne sert à rien si vous ne pouvez pas la récupérer. Le rappel dans cortexmd est hybride. Il lance une recherche lexicale en texte intégral (la correspondance par mots-clés, bonne pour les termes et noms exacts) et la fusionne avec une recherche sémantique sur des embeddings (la correspondance par le sens, bonne quand vous vous souvenez de l’idée mais pas des mots). Le lexical seul rate tout ce qui est formulé autrement que votre requête. Le sémantique seul peut dériver vers des choses vaguement dans le sujet mais pas ce que vous vouliez dire. Fusionner les deux compense les faiblesses de chacun.

Par-dessus le score fusionné, le classement est rehaussé par trois choses : la température (les souvenirs plus chauds remontent, parce que la récence d’usage est un signal), l’importance (certains souvenirs sont simplement plus lourds) et les liens (un souvenir connecté à d’autres souvenirs pertinents est plus susceptible d’être celui que vous voulez). Le résultat est un classement qui reflète non seulement la similarité textuelle mais aussi à quel point un souvenir est actif et connecté. C’est bien plus proche de la façon dont vous vous rappelez réellement les choses qu’un simple score de similarité.

Le réveil

Tout cela se rejoint au début d’une session dans ce que j’appelle le réveil. Au lieu de commencer chaque conversation comme une page blanche, l’agent effectue un réveil de la mémoire qui fait remonter les souvenirs les plus chauds et les plus pertinents. C’est la différence entre un collègue qui entre en sachant déjà où vous en êtes restés hier et un que vous devez briefer de zéro chaque matin. Le réveil s’appuie sur tout ce qui précède : le modèle de chaleur décide ce qui est actif en ce moment, le rappel hybride décide ce qui est pertinent, et l’agent commence la session déjà orienté. C’est le moment où tout le moteur justifie son existence, parce que c’est le moment où vous sentez l’agent se souvenir de vous.

La phase smarter-brain : liens et rêves

Les pièces ci-dessus formaient le cœur du système de mémoire v2.0. Une phase ultérieure, que je vois comme le travail smarter-brain, a ajouté quelques choses qui font que le cerveau ressemble moins à une base de données et davantage à quelque chose qui réfléchit pendant que vous êtes absent.

L’onglet Intelligence du tableau de bord : santé du coffre, insights de rêve, grappes thématiques, et compteurs d’entités et du graphe de connaissances. Données de démonstration issues du coffre d’exemple seedé du projet.

La première, ce sont les liens automatiques du graphe de connaissances. À mesure que les données sont stockées, cortexmd trace de lui-même des liens entre les notes apparentées, au lieu d’attendre que je les câble à la main. Le lien manuel est exactement le genre de tâche administrative qui semble sympa et n’arrive jamais vraiment, donc avoir les connexions qui se forment automatiquement comme effet secondaire du stockage signifie que le signal de liens dans le rappel ne cesse de s’enrichir sans aucun effort de ma part.

La deuxième, c’est le rêve. cortexmd lance une passe de consolidation planifiée, sur un calendrier calme, que j’ai nommée le rêve à cause de ce qu’elle fait et du moment où elle le fait. Elle réconcilie les notes similaires, avec une attention particulière aux plus anciennes, celles qui ont refroidi, et les replie dans des notes de projet. C’est le jardinier d’arrière-plan du cerveau : pendant qu’il ne se passe rien, il parcourt les coins refroidis, remarque que ces trois pensées à moitié finies ne sont en réalité qu’une seule chose, et les range en une note de projet cohérente. Vous réveillez l’agent le lendemain et le cerveau est un peu mieux organisé que vous ne l’aviez laissé, sans que vous n’ayez rien fait.

La troisième, c’est quelque chose que j’ai emprunté tel quel à Obsidian : une vue graphe du coffre, rendue sur un canvas dans le tableau de bord web. Parce que le graphe de connaissances est réel, vous pouvez le regarder. Voir le cerveau comme une constellation de notes liées, avec les grappes denses et les orphelins solitaires étalés devant vous, rend le tout concret d’une manière qu’une liste de lignes ne fait jamais.

La vue graphe du coffre dans le tableau de bord. Chaque point est une note, chaque trait un lien. C’est le coffre de démonstration autonome du projet : les noms de notes sont des données d’exemple seedées, pas mes propres notes.

Cliquez sur un nœud et la note s’ouvre dans le panneau latéral avec ses liens. Mêmes données de démonstration seedées.

Pourquoi un modèle de chaleur l’emporte

Pour rassembler le tout : la raison pour laquelle un modèle de chaleur bat le fait de tout déverser dans le contexte, c’est que l’attention est la ressource rare, pour un agent exactement comme pour une personne. Un stock plat traite une note d’il y a huit mois et une décision de ce matin comme des égaux, vous fait payer pour les deux à chaque tour, et force l’agent à redécouvrir ce qui compte à chaque fois. Le modèle de chaleur encode ce qui compte comme une propriété des données elles-mêmes, le tient à jour gratuitement par l’usage ordinaire, compresse ce qui a refroidi au lieu de l’accumuler, et fait remonter la tranche active et pertinente au réveil. L’agent porte moins, et ce qu’il porte, c’est ce qu’il faut.

Voilà pour l’oubli. L’autre moitié du problème d’origine, l’agent qui brûle des tokens à relire du code qu’il a déjà vu, demande un mécanisme complètement différent. C’est un indexeur Rust et une base de données de symboles, et c’est le sujet de la troisième partie : le tueur de tokens.

cortexmd est en pré-alpha et sous licence MIT. Le code, y compris le moteur de mémoire décrit ici, vit sur la page du projet et sur GitHub à github.com/Leicas/cortexmd. Les noms et la configuration sont encore mouvants, alors traitez les détails comme un instantané plutôt que comme un contrat.

Série

Ceci est la deuxième partie d’une série de quatre billets sur cortexmd :

Donner un second cerveau à un agent IA
Le moteur de mémoire : chaleur, déclin et rêves (vous êtes ici)
Le tueur de tokens : naviguer dans le code sans le lire
Ouvrir le cerveau : le modèle brain-vault

Donner un second cerveau à un agent IA

Thu, 04 Jun 2026 00:00:00 +0000

Je travaille avec un agent de programmation presque tous les jours maintenant. Il est vraiment bon. Il lit mon code, raisonne dessus, propose des changements, lance les tests, répare ce qu’il a cassé. Et chaque fois que j’ouvre une nouvelle session, il a la mémoire d’un poisson rouge.

Il ne se souvient pas de la décision que nous avons prise la semaine dernière sur la raison pour laquelle un module est structuré comme il l’est. Il ne se souvient pas que je préfère les virgules aux tirets, ni qu’un coin du code est porteur et fragile. Il ne se souvient pas de la conversation où nous avions écarté une approche pour de bonnes raisons. Tout ce contexte vivait dans la session précédente, et la session précédente n’existe plus. Alors je réexplique. Puis je réexplique encore le lendemain.

Voilà le premier problème. L’agent oublie.

Et il n’y a pas que le code. Dès que je lui demande de l’aide pour quoi que ce soit d’humain, le même trou s’ouvre. Demandez-lui de rédiger un e-mail et il n’a aucune idée de qui est le destinataire pour moi, s’il s’agit d’un ami proche, d’un collègue ou d’un partenaire avec qui je dois faire attention, et donc il ne sait pas quel ton adopter, parce que ce ton vivait dans des conversations passées qu’il ne peut plus voir. Il fait un mauvais travail pour relier une session à la suivante, si bien que chaque fil repart à froid. Et la façon dont je cloisonne ma vie aggrave les choses : le personnel dans un compte, le professionnel dans un autre, comme la plupart des gens. Dès que je passe de l’un à l’autre, tout ce que l’agent avait appris sur moi a tout simplement disparu. Pouf. Plus de mémoire.

Deux problèmes, pas un seul

Le second problème est plus discret, mais il apparaît sur chaque facture. Pour faire quoi que ce soit d’utile, l’agent doit comprendre le code, et la façon dont il comprend le code, c’est en le lisant. Donc il lit des fichiers. Des fichiers entiers. Pour répondre à une petite question sur une fonction, il va charger un module entier dans son contexte, et souvent les modules qui appellent ce module aussi. Multipliez cela sur une session de travail et vous payez, en tokens, pour charger le même code source encore et encore, dont la majeure partie n’a rien à voir avec la question posée.

Les deux problèmes viennent du même endroit : l’agent n’a aucun stockage persistant de ce qu’il a appris, et aucun moyen bon marché de consulter les choses. Il n’a que la fenêtre de contexte devant lui, et cette fenêtre est à la fois oublieuse et coûteuse à remplir.

J’ai décidé de m’attaquer aux deux. Pas parce que j’avais une idée de produit, mais parce que ça m’agaçait au quotidien et que j’avais un homelab qui ne demandait qu’à être utile.

Il y avait aussi une raison personnelle qui rendait la forme de la solution évidente. Il y a quelque temps, après avoir lu le long récit d’un ami sur son propre parcours de gestion de connaissances personnelles, je me suis mis à prendre des notes dans Obsidian. Construire ce second cerveau pour moi-même a changé ma façon de voir le problème. Si un coffre de notes liées fonctionne comme mémoire externe pour moi, il devrait fonctionner comme mémoire externe pour l’agent aussi. Je pouvais le laisser lire le mien pour démarrer, en lecture seule, puis le laisser construire le sien, un cerveau que je pourrais réellement ouvrir, parcourir et comprendre. Pas une boîte noire d’embeddings quelque part, mais des notes, dans un coffre, qui m’appartiennent.

L’origine sur le homelab

Depuis un moment, je fais tourner un petit serveur MCP sur mon homelab. MCP, le Model Context Protocol, est la manière standard de donner à un client IA des outils et des données qu’il peut aller chercher. Le serveur que j’avais construit s’appelait obsidian-mcp, et son premier rôle était simple : donner à Claude la capacité de lire, de chercher et d’écrire des notes dans mon coffre Obsidian.

Il tournait dans un conteneur Docker derrière un reverse proxy, mes notes étaient déjà là, et tout à coup l’agent pouvait y accéder. Cela seul était déjà utile. Mais cela transformait aussi le coffre en un endroit naturel où placer les réponses à mes deux problèmes, parce qu’un coffre n’est que du texte structuré qu’un agent peut lire et écrire, et c’est exactement ce sur quoi une mémoire et un index de code doivent reposer.

Le serveur a donc fait pousser deux nouvelles capacités, une pour chaque problème.

La première capacité est un système de mémoire, inspiré de mempalace, un projet de palais de mémoire pour agents IA. Au lieu de laisser tout s’évaporer à la fin d’une session, l’agent peut stocker ce qu’il apprend : une observation, une décision, une intuition, une préférence que j’ai exprimée à voix haute. Ces mémoires ne s’empilent pas simplement à l’infini dans une liste plate. Elles ont un cycle de vie. Celles qui servent restent chaudes et faciles à faire remonter, celles que personne ne touche refroidissent et finissent par être pliées dans des résumés, et au début d’une nouvelle session l’agent fait un réveil qui ramène à la surface les mémoires les plus chaudes et les plus pertinentes. L’objectif, c’est la continuité. L’agent reprend à peu près là où il s’était arrêté plutôt qu’à partir de zéro. C’est le sujet de la deuxième partie.

La seconde capacité est un index de code. Plutôt que de lire des fichiers entiers pour comprendre un dépôt, l’agent interroge un index de celui-ci. Un indexeur en Rust parcourt le dépôt, l’analyse et enregistre les choses que l’on veut réellement consulter : quels symboles existent, leurs signatures, où ils vivent, et surtout qui appelle qui. Ensuite l’agent pose des questions ciblées. À quoi ressemble cette fonction ? Qui l’appelle ? Qu’est-ce qui casse si je la modifie ? Chaque réponse est petite et bon marché, de l’ordre d’une consultation plutôt que d’une lecture complète, au lieu de traîner le fichier entier dans le contexte. L’objectif de conception est franc : une consultation de navigation de code devrait coûter environ soixante tokens par résultat et être bien moins chère que la lecture du fichier dont elle provient. C’est le sujet de la troisième partie.

D’un outil privé à cortexmd

Pendant des mois, ce fut une affaire personnelle. Ça tournait sur mon matériel, sur mon propre coffre Obsidian privé, celui qui contient à la fois des notes personnelles et professionnelles. Je n’en citerai rien ici, et l’outil lui-même est délibérément construit pour que les données restent les miennes. Mais le constat tient : c’était un outil que j’avais fait pour moi, et je l’utilisais tous les jours.

Puis je me suis heurté à un autre genre de mur, qui venait précisément de la façon dont il marchait bien pour moi. Je le raconterai correctement dans la quatrième partie, mais en résumé : tout était réglé sur ma propre installation, mon coffre, monté et synchronisé à ma façon, ce qui en faisait un excellent outil personnel et le rendait impossible à faire tourner pour quiconque d’autre. Le rendre partageable impliquait une refonte, et c’est cette refonte qui en a finalement fait quelque chose que d’autres pouvaient utiliser.

Cette refonte est devenue cortexmd. C’est open source, sous licence MIT, et public sur github.com/Leicas/cortexmd. C’est honnêtement en pré-alpha. Les API et les noms de configuration sont encore en mouvement, et je ne miserais pas un workflow de production dessus pour l’instant. Le cadrage honnête est le bon : j’ai construit ça pour moi, puis je l’ai nettoyé pour le partager. Le nettoyage est un vrai travail et il constitue l’essentiel de la quatrième partie.

Ce que c’est devenu : le panneau de contrôle de cortexmd. Cette capture provient de la démonstration autonome du projet, donc les données sont des exemples seedés, pas mon propre coffre.

Voilà donc la forme de la série. Il y avait deux problèmes, un agent qui oublie et un agent qui brûle des tokens à relire du code. Il y a deux réponses, un système de mémoire et un index de code, tous deux nés à l’intérieur d’un serveur MCP sur un homelab. Et il y a la refonte qui a transformé un outil privé en quelque chose que vous pouvez faire tourner vous-même.

Ce qui arrive

Partie 2, le moteur de mémoire. Chaleur, déclin et rêves. Les huit catégories dans lesquelles une mémoire peut tomber, le cycle de vie chaud vers tiède vers froid, la promotion à l’accès, la consolidation, le rappel hybride qui fusionne recherche plein texte et recherche sémantique, le réveil de session, et le graphe de liaison automatique qui relie les notes entre elles au fur et à mesure qu’elles sont stockées.
Partie 3, le tueur de tokens. L’indexeur en Rust et tree-sitter, la base de données de symboles SQLite, les outils de navigation de code, l’idée des environ soixante tokens par résultat, le hook shell optionnel qui réécrit des commandes comme grep et cat sur un dépôt indexé en leur équivalent bon marché, et ce que ça a donné de l’utiliser sur le propre code source du projet.
Partie 4, l’ouverture du cerveau en open source. Pourquoi un outil qui ne marchait que pour moi a dû être repensé pour être partagé, le modèle du brain-vault qui le généralise, les deux modes de déploiement, le monorepo polyglotte tenu ensemble par un contrat partagé, le renommage, et pourquoi je tiens à posséder mes propres données.

Si vous voulez sauter directement au code, la page du projet est par ici et le dépôt est sur GitHub. Sinon, la deuxième partie est l’endroit où l’agent commence à se souvenir.

Série

Ceci est la Partie 1 : Donner un second cerveau à un agent IA (vous êtes ici).

Partie 1 : Donner un second cerveau à un agent IA (ce billet)
Partie 2 : Le moteur de mémoire : chaleur, déclin et rêves
Partie 3 : Le tueur de tokens : naviguer dans le code sans le lire
Partie 4 : Ouvrir le cerveau en open source : le modèle brain-vault

Page du projet : cortexmd. Source : github.com/Leicas/cortexmd.