Mémoire d'agent IA : j'ai sur-conçu un système, puis tout jeté pour du Markdown

J’ai passé deux mois à construire un système de mémoire long terme pour mes agents IA. Vector store, embeddings, compression pilotée par LLM, décroissance temporelle, exposition via MCP. C’était techniquement terminé, documenté, opérationnel. Je ne l’ai jamais utilisé une seule fois.

Le 2026-05-08, j’ai archivé l’ensemble et je l’ai remplacé par un repo Git de fichiers Markdown. Ce repo est utilisé tous les jours depuis.

Ce que j’ai construit (et jamais utilisé)

ENGRAM v1 était une couche de mémoire pour agents IA : SQLite pour le stockage relationnel, Qdrant pour la recherche vectorielle, FastEmbed pour les embeddings, une passe de compression par LLM sur les anciens fragments, un mécanisme de décroissance temporelle, et une interface MCP pour que n’importe quel agent puisse l’interroger.

Le design venait de trois sources : un livestream de devs compétents construisant une mémoire d’agent sur pgvector, les patterns RAG plus larges que je voulais apprendre, et l’hypothèse qu’une « vraie » mémoire d’agent a besoin de récupération sémantique. Deux mois de travail, une architecture propre, zéro usage.

Pourquoi il est devenu orphelin

Trois semaines après avoir terminé la v1, mes sessions Claude Code tournaient toujours sans lui. Mes projets personnels ne le sollicitaient pas. Je me disais qu’il fallait juste un peu plus de finition, de meilleurs connecteurs, une itération de plus. Le scénario classique d’un projet qui ne résout pas un problème ressenti.

Puis Anthropic a sorti deux choses dans la même semaine, ce qui a cristallisé le problème :

Une fonctionnalité de mémoire persistante pour les Claude Managed Agents, bâtie sur un design filesystem où les souvenirs sont des fichiers que le modèle lit, écrit et grep avec des outils standard.
Auto Dream, un système de consolidation de mémoire dont la structure cible est un index MEMORY.md plus des fichiers Markdown thématiques.

Deux releases, même direction, même semaine. Pendant ce temps, mon vector store restait inactif.

Le pivot vers le Markdown

ENGRAM v2 est un repo Git de fichiers Markdown structurés, plus un petit skill Claude Code. Pas de Qdrant, pas de FastEmbed, pas de compression, pas de décroissance, aucun service à maintenir. Le repo fait son propre travail : lisible par un humain, versionné par Git, et manipulable par n’importe quel LLM via les commandes de fichiers qu’il connaît déjà (read, grep, write).

Ce qui a changé du jour au lendemain : je l’utilise vraiment. Pas par discipline. Parce qu’écrire une note Markdown est plus rapide que de réexpliquer le même contexte à trois sessions différentes.

C’est le vrai test de n’importe quel système personnel. Sans pression extérieure, est-ce que tu y reviens ? Si oui, le design est le bon, quel que soit son degré de sophistication. Si non, le design ne résout pas un vrai problème, quel que soit son degré de sophistication.

« Mais les vector stores, c’est bien, non ? »

Oui. C’est la bonne réponse pour la recherche sémantique sur d’énormes corpus hétérogènes, le RAG sur des millions de pages, la similarité sur des données non textuelles. Mon erreur n’a pas été de choisir un vector store, mais de choisir une complexité qui dépassait mon problème réel. Pour quelques centaines de fichiers Markdown personnels consultés par moi et quelques agents, un grep en texte brut suffit largement.

La porte reste ouverte. Si un jour le volume dépasse la recherche textuelle, ou si j’ai besoin de récupération sémantique sur un corpus que je ne peux pas indexer à la main, j’ajouterai une couche vectorielle, mais en partant d’un besoin réel et observé.

Pourquoi ne pas simplement utiliser la mémoire d’Anthropic ?

Leur design est celui vers lequel j’ai convergé, et il est bon. Mais il est couplé à Claude et hébergé par Anthropic. Je veux que ma propre couche de mémoire reste agnostique au LLM et auto-hébergeable, pour pouvoir changer de modèle librement à l’avenir (d’autres versions de Claude, mais aussi d’autres fournisseurs si le contexte, le coût ou la conformité l’exigent un jour). Un repo Markdown plus un petit skill est le substrat le plus portable que je puisse imaginer. N’importe quel modèle capable de lire et d’écrire du texte peut l’utiliser.

Ce que j’en retire

Trois patterns que je garde :

La R&D personnelle sans dogfooding reste un actif théorique. Si après quelques semaines je ne reviens pas vers la chose que j’ai construite, c’est qu’elle ne résout pas un problème ressenti. Change le design, ou assume honnêtement que c’était un projet d’apprentissage et passe à autre chose.
La simplicité radicale est un test de valeur. Un système à cinq composants a un coût d’adoption élevé. Un système qui tient dans un repo plus un skill entre en usage immédiatement. Pour de l’outillage personnel, le second gagne presque à chaque fois.
La sur-ingénierie vient souvent d’un inconfort technique déguisé en ambition. Quand je me surprends à construire « la solution parfaite » sur une stack que je ne maîtrise pas, je confonds en général la curiosité avec un besoin produit. Les deux sont légitimes, mais pas dans le même projet.

ENGRAM v2 est en service depuis une semaine. Je saurai dans quelques semaines si le pivot a tenu. Si je l’utilise plusieurs fois par semaine avec un ensemble de fichiers en bonne santé, le diagnostic était bon. Sinon, je me dois un autre post-mortem honnête.