Le système mémoire derrière un Agentic OS

Tu utilises Claude Code tous les jours. Mais à chaque nouveau projet, tu finis par lui ré-expliquer les mêmes choses : les conventions, les commandes, les décisions, les erreurs à ne pas refaire.

Et quand on parle de régler ça, tout le monde cherche "la meilleure mémoire IA". Sauf que c'est la mauvaise question.

En réalité, il n'y a pas UNE mémoire — il y a trois problèmes différents : où stocker la mémoire, comment l'agent retrouve la bonne info, et comment cette mémoire se nettoie avec le temps.

Dans cet article, je décortique les 6 niveaux de mémoire pour Claude Code, et surtout comment les ranger dans 3 catégories pour choisir le bon setup sans empiler des outils au hasard.

Le vrai problème : la dispersion, pas l'oubli

Claude Code a déjà une mémoire basique aujourd'hui :

• CLAUDE.md — un fichier statique qui sert à donner règles et contexte au démarrage
• Auto Memory — le système où Claude écrit ses propres notes dans un dossier /memory

Donc oui, Claude commence à se souvenir. Mais dès que ton setup devient sérieux, le problème change. Le vrai souci, ce n'est plus "est-ce que Claude oublie ?" — c'est la dispersion.

Tu as :

• Des règles dans CLAUDE.md
• Des notes auto dans /memory
• Des décisions dans Obsidian
• De l'historique dans les conversations
• Du contexte dans le repo

…et parfois tout ça ne raconte pas exactement la même histoire.

C'est exactement le problème que j'ai sur mon propre setup : Claude Code, OpenClaw, Obsidian, scripts YouTube, veille, décisions business. Si je ne structure pas la mémoire, l'agent peut retrouver des bouts d'information, mais pas forcément la bonne source de vérité.

Les 3 couches d'une mémoire agentique

Une bonne mémoire agentique ne se résume pas à un seul outil. Elle répond à trois questions distinctes :

Couche	Question	Niveaux
Storage	Où vit la mémoire ?	0, 1, 2
Retrieval	Comment l'agent retrouve la bonne info ?	3, 4
Consolidation	Comment la mémoire se nettoie / mûrit ?	5

C'est ça le pitch : tu choisis d'abord la catégorie dont tu as besoin, puis le niveau adapté. Pas l'inverse.

STORAGE — Où vit la mémoire ?

Niveau 0 — CLAUDE.md, la mémoire statique

Le baseline. Un fichier Markdown chargé à chaque démarrage de Claude Code, qui contient les conventions, commandes, architecture, règles de projet.

• Robuste parce que c'est simple
• Mais statique : si personne ne l'édite, il ne s'améliore pas
• Quand ça suffit : projet solo court, 1 repo, 1 contexte

Pour beaucoup de projets, c'est déjà suffisant. Je pense même que 60% des devs devraient commencer là, pas avec une base vectorielle ou un outil de mémoire compliqué.

Niveau 1 — Auto Memory : Claude prend ses propres notes

Le système natif Claude Code (depuis v2.1.59+). Claude écrit lui-même dans ~/.claude/projects/<project>/memory/ :

• MEMORY.md comme index
• Fichiers typés (user.md, feedback.md, project.md, reference.md)
• Topic files lus à la demande

Limites importantes :

• Seules les 200 premières lignes de MEMORY.md ou 25 KB sont chargées au démarrage
• Auto Memory est locale à la machine — pas de sync cross-device
• Tous les worktrees du même repo partagent le même dossier

C'est un vrai pas en avant : Claude apprend de tes corrections. Mais ça reste une mémoire locale, simple, fichier.

Niveau 2 — Obsidian (ou vault externe) : ton vrai cerveau long-terme

⭐ C'est mon pattern signature. Si tu as déjà un cerveau externe (Obsidian, Notion, un vault), pourquoi en créer un deuxième ?

Pattern : Claude Code lit/écrit directement dans ~/repo/obsidian-mikecodeur/.

Avantages clés :

• Visible par humain ET IA (graph view, backlinks)
• Versionné avec Git
• Cross-machine automatiquement
• Partageable avec d'autres
• Source de vérité unique pour contenu, décisions, veille

C'est exactement ce que je fais sur ce blog, mes vidéos, ma veille. Claude écrit ses brouillons, met à jour ses notes, référence avec [[backlinks]].

RETRIEVAL — Comment retrouver la bonne info ?

Niveau 3 — RAG (retrieval sur codebase + docs)

Indexer ton code, tes docs, tes notes en embeddings + recherche par similarité.

Différence vs mémoire : pas de "fait appris" — c'est un index sur du contenu existant.

Outils concrets :

• claude-context MCP — embeddings + retrieval Claude Code
• repomix + embeddings sur le codebase
• Cursor codebase index — référence du marché
• Cody (Sourcegraph) — RAG enterprise
• aider semantic add

Quand ça vaut le coup : codebase > 100k LOC, ou docs internes massives. Avant ça → over-engineering.

"Trouve-moi le fichier qui gère l'auth" sur un gros monorepo, sans donner le path → c'est exactement le use case du RAG.

Niveau 4 — Mémoire sémantique dédiée

Le retrieval mais pour les faits/préférences, pas pour le contenu source.

Outils :

• claude-mem (github.com/thedotmack/claude-mem) — plugin Claude Code de persistent memory compression
• Memory tool API (Anthropic, sortie avec Sonnet 4.5) — primitive native pour stocker/retrouver via tool calls
• mem0, Letta, Cipher — alternatives open source

Différence vs Niveau 3 : tu retriev des conclusions (faits, feedback), pas du contenu source.

Le RAG retrouve des documents. La mémoire sémantique retrouve des conclusions : ce que l'agent a appris.

claude-mem fonctionne via hooks Claude Code (SessionStart, UserPromptSubmit, PostToolUse, SessionEnd) + un worker local + SQLite/FTS5 + un index vectoriel optionnel. Ce n'est pas juste un MCP server — c'est une vraie pipeline mémoire.

CONSOLIDATION — Comment la mémoire mûrit ?

Niveau 5 — Dream / sleep-time compute

Concept : pendant que tu ne bosses pas, l'agent re-traite sa mémoire. Il relit ses traces, résume, fusionne, supprime le bruit, transforme l'historique en connaissances.

Implémentations :

• OpenClaw dreaming — phases light / deep / REM, transcripts redacted, Memory Palace Diary
• Letta sleep-time agents — agent secondaire qui consolide pendant l'idle
• memory-wiki + Imported Insights (OpenClaw) — ingestion ChatGPT + consolidation

Quand ça vaut le coup : agents long-running qui accumulent du bruit, besoin de "raffiner" la mémoire. Overkill si tu as peu de volume.

À ce niveau, la mémoire n'est plus seulement stockée ou retrouvée. Elle est retravaillée.

Quelle mémoire choisir ?

Le piège, c'est d'empiler tous les outils en pensant que plus = mieux. La bonne stratégie, c'est de choisir le niveau adapté à ton usage.

Profil	Recommandation
Petit projet, dev solo	CLAUDE.md (Niveau 0) suffit largement
Claude Code régulier, multi-projets	Active Auto Memory (Niveau 1)
Créateur / consultant long-terme	Obsidian externe (Niveau 2) ⭐
Gros codebase / monorepo	Ajoute du RAG (Niveau 3)
Agent autonome multi-sessions	Mémoire sémantique (Niveau 4)
Agent long-running 24/7	Consolidation / dreaming (Niveau 5)

Conclusion — La mémoire, c'est l'OS de tes agents

La mémoire, c'est ce qui transforme Claude Code d'un outil en un système qui apprend de toi. Et c'est exactement la fondation d'un Agentic OS personnel : sans mémoire structurée, tu repars de zéro à chaque conversation.

Le but, ce n'est pas d'avoir la stack la plus compliquée. C'est d'avoir une mémoire qui aide vraiment ton agent à travailler mieux sans créer une usine à gaz.

---

🎥 Voir la vidéo complète : Le système mémoire derrière un Agentic OS (16 min)

📥 Lead magnet — Le pack mémoire agentique (gratuit) : mkc.sh/agentic-os-memory — templates, patterns Obsidian, prompts à copier

📬 Newsletter The Agentic Dev : chaque mardi, une stack agentique décortiquée. Inscription