Un cerveau central pour tous mes agents : Obsidian + Graphify

J'ai divisé par 70 la consommation de tokens de mes agents IA. Pas en changeant de modèle. En changeant leur mémoire.

Mais l'économie de tokens n'est que la conséquence. Le vrai sujet est ailleurs, et il est plus important.

Le problème : cinq employés brillants et amnésiques

J'utilise cinq outils IA différents. Claude Code dans le repo, Claude Desktop pour le chat quotidien, OpenClaw comme majordome multi-canal, Hermes comme agent 24/7 sur mon VPS, et mon propre OS agentique pour l'orchestration.

Chacun a sa mémoire. Enfermée chez lui.

Claude Code a son CLAUDE.md. Claude Desktop a ses conversations. OpenClaw a sa mémoire. Hermes a la sienne. Aucun ne sait ce que les autres ont appris.

Résultat, deux problèmes qui se cumulent :

1. Ton contexte est fragmenté et prisonnier. Tu changes d'outil, tu repars de zéro. L'outil disparaît ou se fait couper, ton cerveau part avec lui.
2. Chaque agent relit tout, à chaque session. Il n'a pas de carte, alors il ouvre les fichiers un par un pour comprendre où il est.

Le premier problème est stratégique. Le second est financier. Ils ont la même cause.

La thèse : ton cerveau ne doit vivre dans aucun outil

C'est le principe File over App de Steph Ango, le CEO d'Obsidian, poussé à l'ère des agents.

Ta mémoire doit vivre dans des fichiers ouverts que tu possèdes. Les outils viennent s'y brancher. Aucun ne la possède.

Ce n'est pas une position idéologique, c'est du calcul de risque. Un outil IA peut disparaître, changer de prix, se faire bannir, ou simplement cesser de te convenir. Si ton contexte vit dedans, tu es otage. S'il vit dans du markdown que tu possèdes, tu changes d'outil un mardi après-midi et tu ne perds rien.

Un fichier markdown se lit dans dix ans, par n'importe quel agent. Pas de format propriétaire, pas de lock-in.

L'architecture : deux couches, N surfaces

              ┌──────────────────────────────┐
              │      CERVEAU CENTRAL         │
              │   Obsidian (markdown)        │  ← décisions, contexte, contenu
              │             +                │
              │   Graphify (graph.json)      │  ← la carte du code, requêtable
              │   → format ouvert, à toi     │
              └──────────────────────────────┘
                 ▲       ▲       ▲       ▲
        ┌────────┘       │       │       └────────┐
      mon OS      Claude Code  OpenClaw        Hermes
    (pilotage)   (dans le repo) (majordome)  (agent 24/7)

   Chaque surface LIT et ÉCRIT le même cerveau. Aucune ne le possède.

Couche 1 : Obsidian, la mémoire humaine

Le vault contient mes décisions, mon contexte et mon contenu. En markdown pur.

Le principe d'organisation, toujours Steph Ango : les dossiers indiquent le type, le frontmatter porte les métadonnées. Un fichier ne bouge jamais de place. Pour changer le statut d'une note, tu modifies une propriété, tu ne la déplaces pas.

C'est la couche que moi je lis et j'édite. Et que les agents comprennent nativement, parce que c'est du texte.

Couche 2 : Graphify, la carte

C'est la partie neuve, et celle qui règle le problème de coût.

Sans carte, un agent qui arrive sur ton repo n'a qu'une option : ouvrir les fichiers. Un par un. À chaque session. C'est là que partent les tokens.

Graphify transforme ton repo (code, docs, markdown) en un graphe requêtable, un graph.json, construit avec tree-sitter. Le point important : la construction du graphe passe par l'AST, pas par un modèle. Elle coûte zéro token.

Ensuite, l'agent interroge le graphe au lieu de tout relire.

Les chiffres — ce sont les mesures publiées par le projet claude-code-memory-setup, sur leur propre benchmark. Je les cite comme telles, pas comme une vérité universelle :

Soit une réduction annoncée allant jusqu'à 71,5× par session, et environ 499× par requête sur leur test de 126 fichiers TypeScript.

Sur mon usage, l'ordre de grandeur se tient. C'est de là que vient le "divisé par 70".

Comment ça se branche concrètement

Graphify produit un graph.json, un GRAPH_REPORT.md, et des notes Obsidian (une par fonction ou module). Ce sont des fichiers, dans le repo, que l'agent lit. Pas de magie.

La règle que je donne à mes agents tient en trois couches, dans cet ordre :

1. Interroger le graphe pour savoir où sont les choses et comment elles se relient.
2. Interroger le vault Obsidian pour les décisions et le contexte.
3. Ne lire le code brut que si c'est nécessaire.

L'essentiel est dans le "que si nécessaire". La plupart des questions n'exigent pas de lire le code. Elles exigent de savoir où il est et pourquoi il est comme ça.

Le vrai bénéfice : les outils deviennent interchangeables

Le cerveau est central. Les outils sont des satellites.

Je peux ajouter un outil ou en retirer un sans rien perdre. Le cerveau reste. Quand un nouvel agent sort, je le branche sur le vault et il arrive avec dix-huit mois de contexte, sans que j'aie rien à réexpliquer.

C'est ça, le vrai gain. Le 70× est agréable, mais c'est la conséquence d'une bonne architecture, pas l'objectif.

Ce que tu peux en tirer

Tu n'as pas besoin de mon setup exact. Tu as besoin de la règle :

• Ta mémoire vit dans des fichiers ouverts que tu possèdes, pas dans un outil.
• Tes agents ont besoin d'une carte avant d'avoir besoin du territoire. Une carte se construit une fois et se requête mille fois.
• Le markdown est un format d'archive. Il te survivra à tous tes outils.

La méthode complète, avec la démo et le setup, est en vidéo : Un cerveau central pour tous mes agents

Et si tu veux ce genre de méthode chaque semaine, c'est dans The Agentic Dev.