Marie Kondo, si vous n'avez pas la ref, c'est une Japonaise spécialisée dans le rangement. Rapport avec le développement, wait for it !
Mi avril, j'ai commencé à compter. En trois semaines, quinze projets distincts ont atterri sur GitHub avec à peu près le même pitch : de la mémoire persistante pour les agents IA. Certains en SQLite, d'autres en ChromaDB ou LanceDB, un en Go, un avec un graphe de connaissances, un autre avec un système bayésien qui pondère la confiance de chaque souvenir. Quinze.
Dans le même temps, trois outils viraux promettaient de réduire la consommation de tokens de 60, 90, et 98 pourcent.
Ce que j'ai trouvé frappant, c'est pas le volume (l'écosystème agent est en pleine effervescence depuis le début de l'année, ça on le sait). C'est que deux familles de solutions aussi différentes répondent au même signal d'alarme, simultanément. La mémoire externe et la compression de contexte, ce sont deux bouts opposés d'un problème qu'on n'a pas encore bien formulé.
La compression, c'est le cas le plus facile à disséquer.
rtk est un proxy CLI en Rust qui intercepte les appels API et compresse le contexte avant envoi. Il annonce entre 60 et 90% de réduction. context-mode revendique 98% sur quatorze plateformes. claude-mem capture ce que Claude fait en session, compresse, réinjecte à la prochaine.
Ces chiffres viennent de benchmarks maison sur des workloads choisis pour la démonstration. Le problème fondamental de la compression pour un LLM, c'est qu'on n'est pas en train de compresser du code source ou un fichier binaire : on compresse du contexte. Et le modèle n'a pas de décompresseur. Ce que vous perdez dans la compression, vous le perdez définitivement. rtk peut faire moins 90% sur un prompt système massif et répétitif ? Probable. Sur une session de debugging avec des traces d'erreur précises, des états intermédiaires, des tentatives ratées qui comptent pour la suite ? Beaucoup moins. Et si l'agent avait besoin exactement de ces 10% pour raisonner correctement sur l'étape suivante, personne ne vous préviendra.
Je ne dis pas que ces outils ne servent à rien. Sur un cas bien défini (pipeline à prompt stable et volumineux, documentation statique injectée en masse), la compression a du sens. Mais la promesse "moins 90% sans coût de qualité" est fausse. Il y a toujours un coût. La question c'est qui le paie et à quel moment on s'en aperçoit.
Côté mémoire, c'est plus intéressant parce que les approches divergent vraiment.
Il y a les projets purement vectoriels, les hybrides FTS5 + vectoriel, le bayésien (aelfrice pondère la confiance de chaque souvenir selon les retours reçus (approche assez originale)), les graphes de décisions qui capturent les preuves depuis GitHub ou Jira pour tracer le "pourquoi" de chaque choix, les git-natifs qui stockent le raisonnement derrière les commits plutôt que les diffs.
J'en ai analysé une bonne partie en détail parce que j'ai construit un truc dans cette catégorie : un serveur MCP local, SQLite avec recherche vectorielle, Ollama pour les embeddings, zéro cloud, zéro service externe. Je ne prétends pas que mon implémentation est meilleure. Mais ça m'a donné une vision assez claire de ce que ces projets résolvent et de ce qu'ils n'abordent pas.
La grande majorité résolvent le problème du stockage (vous ne la voyez pas encore arriver, Kondo sensei ?). Très peu résolvent le problème du rappel.
Stocker, c'est une après-midi de travail. Le vrai problème c'est : quand l'agent a besoin d'information, laquelle ? Comment décide-t-on que ce souvenir est pertinent pour cette tâche, dans ce contexte, maintenant ? C'est un problème de retrieval, pas de storage. Et c'est le problème que la plupart de ces projets esquivent.
Un des plus sérieux que j'ai regardés combine recherche plein texte, similarité sémantique, et un mécanisme d'oubli progressif basé sur l'âge des souvenirs. Je vous épargne les acronymes, vu les mécanismes que j'ai cités plus haut, c'est la même technophilie nucléaire. L'idée derrière est plus simple : chercher par mots, chercher par sens, oublier ce qui vieillit. Mais même ce projet suppose que vous avez déjà décidé quoi capturer. La couche de sélection à l'entrée, ce que le système juge digne d'être mémorisé versus ce qu'il ignore, c'est encore un problème ouvert dans presque tous ces projets.
C'est là que les deux familles se rejoignent dans leur angle mort commun.
Compresser ou externaliser, ce sont deux façons différentes de gérer un flux d'information qu'on n'a pas appris à filtrer à la source. Le problème réel c'est pas "comment faire tenir plus" ou "comment stocker davantage". C'est "qu'est-ce que cet agent a besoin de savoir, à quel moment, et comment on désapprend ce qui est devenu faux ou périmé".
L'analogie qui me vient : le développeur qui règle un problème de performance en ajoutant de la RAM. Parfois c'est la bonne réponse. Souvent, c'est de la RAM pour compenser du code qui n'aurait pas dû allouer autant.
Ou la requête SQL qui fait un SELECT * sur dix millions de lignes parce que "on ne sait jamais, peut-être qu'on aura besoin de tous les champs". Ou la boucle avec un curseur qui traite les résultats un par un là où un GROUP BY aurait tout réglé en une passe. Le problème n'est pas la base de données. C'est qu'on n'a pas réfléchi à ce dont on avait vraiment besoin avant d'écrire la requête. Injecter toute une base de souvenirs dans le contexte d'un agent sans filtrer en amont, c'est exactement ce SELECT *.
Ce qui fonctionne (dans les projets sérieux et dans ma propre impl), c'est de commencer par la question inverse. Pas "qu'est-ce que je stocke", mais "qu'est-ce que je peux me permettre d'oublier". L'oubli actif change complètement l'équation : decay temporel, pruning, remplacement d'un souvenir obsolète sans le garder en double. YourMemory*, un des projets que j'ai regardés, a publié des chiffres là-dessus : 84% de réduction des tokens non pas par compression du contexte, mais par oubli délibéré en amont. Le mécanisme s'appuie sur la courbe d'oubli d'Ebbinghaus, la même qui modélise comment le cerveau humain efface l'information avec le temps. La différence est importante. Dans un cas on dégrade l'information existante. Dans l'autre on choisit ce qui mérite de rester.
Et c'est là que Marie Kondo intervient. Son credo, c'est de jeter. Pour elle, le stockage n'est pas du rangement. Quand un objet n'a pas d'utilité, on le donne, on le vend, on le jette en dernier recours et on lui dit "merci beaucoup". C'est que chaque information a peut-être une leçon, et si ce n'est pas le cas, c'est ok, et que la meilleure façon de vider aussi, c'est de, parfois, prendre tout le placard, le vider en entier, et trier. Pour les éléments en mémoire sur les outils IA, c'est pareil, parfois il faut s'auto-auditer, trier, ne garder que ce qui est utile et si possible en tirer une leçon, un apprentissage.
Quinze projets de mémoire en trois semaines et trois outils de compression viraux, ça raconte une histoire. Pas une convergence vers une solution. Une communauté encore en train de chercher le bon cadrage du problème.
Ça rappelle les années 2015-2017 et l'explosion des state managers JavaScript. Redux est sorti, puis Vuex, puis MobX, puis cinquante autres. On a mis trois ou quatre ans à s'entendre sur ce que "gérer de l'état" voulait dire en pratique. La mémoire des agents en est probablement au même stade.
Si vous cherchez quoi adopter aujourd'hui : ne choisissez pas un outil en premier. Définissez d'abord ce que votre agent doit retenir, ce qu'il peut oublier, et à quelle fréquence ce jugement change. Une fois que vous avez ça, le choix de l'outil devient beaucoup plus évident, et probablement plus simple que ce que le marché vous vend en ce moment.
L'idée à la con que j'ai eue en écrivant cet article
En rédigeant la partie sur la compression, j'ai eu une idée. Si le problème c'est les tokens, et que la mémoire d'un agent c'est du texte que le développeur ne lit de toute façon jamais directement… pourquoi ne pas la stocker en chinois ? Les idéogrammes sont denses. Un poignée de caractères peut exprimer ce qu'une phrase entière dit en français. Et le modèle s'en fiche de la langue, non ?
J'ai posé la question à Claude Code et voilà la réponse : l'idée pointe dans la bonne direction, mais le vecteur est mauvais.
Les tokenizers modernes découpent le texte en morceaux avant de le passer au modèle, c'est le mécanisme qui transforme vos phrases en tokens. Pour les idéogrammes chinois courants, ils assignent généralement un token par caractère. Un seul. Ce qui est effectivement plus dense qu'une lettre latine, mais pas plus qu'un mot anglais fréquent, qui lui aussi tient souvent en un token. "Information" : un token. "情報" : deux tokens pour deux caractères. Le gain vient pas de l'idéogramme en lui-même : il vient de la syntaxe du mandarin. Pas de "the", pas de "that", les auxiliaires disparaissent, les phrases sont structurellement plus courtes. Sur du texte long et bavard, on peut gratter 10 à 20%.
Ce qui n'est pas rien. Mais c'est pas le game changer qu'on espérait.
Et les effets de bord sont réels. Le modèle raisonne dans un espace vectoriel interne qui n'est "dans" aucune langue, mais ses performances sur un domaine donné restent corrélées à la distribution de sa langue d'entraînement. Forcer du chinois dans un contexte où le modèle attend du français ou de l'anglais technique peut dégrader légèrement la qualité du raisonnement. Pas catastrophique. Mesurable quand même. Et les idéogrammes rares, ou les termes techniques retranscrits en sinogrammes, tokenisent parfois très mal : jusqu'à trois ou quatre tokens pour un seul caractère, ce qui efface tout le gain.
Sans parler du debug. Le développeur "ne lit pas la mémoire"… jusqu'au jour où l'agent fait n'importe quoi et qu'il faut comprendre pourquoi. Bonne chance pour relire des logs en mandarin à deux heures du matin.
Ce qui marche vraiment dans cette direction, c'est pas changer de langue. C'est changer de format.
Stocker user:dark_mode=true plutôt que "l'utilisateur m'a indiqué qu'il préférait le mode sombre". Des faits atomiques plutôt que des résumés de conversation. Des clés courtes. C'est ce que font les outils de compression sérieux : ils suppriment les tokens qui ne portent pas de sens (déterminants, connecteurs, reformulations redondantes) plutôt que de traduire. Résultat : 50 à 80% de compression, avec une perte de qualité très faible sur les tâches de rappel.
L'idée à la con pointait dans la bonne direction. Le bon levier, c'est la densité sémantique par token, pas la langue dans laquelle on l'exprime.
* YourMemory — mémoire agent avec décroissance Ebbinghaus, 84% de réduction de tokens, +16pp de recall vs Mem0 sur LoCoMo.