Un second cerveau avec Claude Code : configuration et relecture

Un second cerveau (second brain) Claude Code, c’est votre dossier de notes avec Claude Code qui tourne dedans. Claude Code est l’agent de code d’Anthropic, mais rien chez lui n’est propre au code : il lit des fichiers, en écrit, fouille des dossiers et lance des commandes. Pointez-le sur un coffre Obsidian et il peut trier votre inbox, transformer des comptes rendus de réunion en points d’avancement de projet, répondre à des questions à partir de tout ce que vous avez écrit, et tenir à jour les liens entre les notes.

La différence avec une application de chat, c’est que les notes sont la mémoire. Vous ne collez pas le contexte dans chaque conversation. Claude lit sur le disque ce dont il a besoin, et tout ce qu’il écrit reste dans des fichiers markdown simples qui vous appartiennent. Le wiki LLM d’Andrej Karpathy pousse la même idée plus loin : l’agent entretient tout un wiki à partir de vos sources.

Il y a un piège. Un agent qui peut améliorer chaque note peut aussi modifier en douce une note sur laquelle vous comptez. Ce guide couvre donc l’installation et, tout autant, la façon de voir et d’approuver ce que Claude change : avec git, qui marche dès aujourd’hui, et avec Knowtarium.

Knowtarium est une base de connaissances chiffrée de bout en bout pour des notes que les personnes et les agents écrivent ensemble. Claude Code s’y connecte via MCP, chaque changement que fait Claude est signé, montre qui l’a fait et peut être annulé, et chaque note montre qui l’a écrite (et, dans les dossiers où la relecture est activée, qui l’a vérifiée). Vous pouvez commencer gratuitement. De courtes notes au fil du texte disent comment Knowtarium gère chaque étape.

Il vous faut Claude Code installé (voir la documentation d’Anthropic) et un dossier de notes en markdown. Obsidian est facultatif : Claude n’a besoin que du dossier.

1. Prenez d’abord un instantané

Avant que Claude ne touche à quoi que ce soit, mettez le coffre sous git et faites un commit. C’est votre bouton d’annulation pour tout ce qui suit, et cela prend une minute. Ajoutez un .gitignore pour que les fichiers de disposition d’Obsidian n’encombrent pas chaque diff :

# Obsidian réécrit ces fichiers sans arrêt ; gardez-les hors de vos diffs
.obsidian/workspace.json
.obsidian/workspace-mobile.json
.trash/
CLAUDE.local.md

2. Lancez Claude Code dans le coffre

$ cd ~/Notes                  # votre coffre$ git init && git add -A$ git commit -m "before Claude"$ claude
> /init

/init examine le dossier et rédige un premier CLAUDE.md. Il a été conçu pour du code : prenez ce brouillon comme point de départ et réécrivez-le avec les règles ci-dessous. Lancez /context pour confirmer que le fichier est chargé.

3. Décidez de ce que Claude peut faire sans demander

Claude Code a des modes de permission. En mode Manual, il demande avant chaque modification. Le mode Plan lui fait proposer un plan sans rien modifier, ce qui convient à une première session dans un coffre auquel vous tenez. Vous passez de l’un à l’autre avec Shift+Tab. La page sur les modes de permission indique le mode dans lequel démarre une session, qui dépend de votre version et de votre compte.

Dans Knowtarium

Les modes de permission décident de ce que Claude peut faire pendant une session. Knowtarium couvre le reste : vous connectez Claude à un espace de travail, à certains dossiers seulement si vous voulez, en lecture seule ou en lecture-écriture. Chaque changement qu’il fait est signé et peut être annulé en un clic. Les agents ne peuvent supprimer que si vous leur en avez donné la permission (une note supprimée revient avec Undo tant que votre durée d’historique la conserve), et ils ne peuvent pas marquer une note comme vérifiée par vous. Pour les dossiers que vous voulez approuver d’abord, activez la relecture (« Ask me first ») : les changements de Claude y attendront votre accord.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

CLAUDE.md est un fichier markdown que Claude Code lit au début de chaque session. Pour un coffre, il doit répondre à trois questions : comment le coffre est organisé, comment Claude doit écrire, et ce dont il doit rendre compte. La documentation sur la mémoire d’Anthropic donne les règles qui comptent :

• Restez sous les 200 lignes environ. Les fichiers plus longs consomment plus de contexte et sont suivis moins fidèlement.
• Écrivez des instructions vérifiables (« journal/ est en lecture seule », pas « fais attention à mes notes »).
• Intégrez d’autres fichiers avec des imports @path, comme une note sur vos priorités du moment.
• Un CLAUDE.md placé dans un sous-dossier se charge quand Claude lit des fichiers de ce dossier : un gros projet peut ainsi avoir ses propres règles.
• Mettez dans CLAUDE.local.md les notes personnelles que vous ne voulez pas dans git.

# Ce coffre
 
Notes personnelles, gérées dans Obsidian. Markdown simple, wikilinks.
 
## Organisation
- inbox/ : captures brutes. Traite-les, puis sors-les de là.
- projects/ : un dossier par projet en cours, avec un README.md.
- areas/ : sujets permanents (santé, argent, travail).
- journal/ : mes notes quotidiennes. Lis-les, ne les modifie jamais.
- archive/ : projets terminés. N’y touche pas.
 
## Comment écrire
- Garde ma formulation. Ajoute, ne réécris pas, sauf si je le demande.
- Les nouvelles notes reçoivent un frontmatter : type, created, source.
- Quand tu énonces un fait, lie la note ou l’URL d’où il vient.
- Lie les personnes sous la forme [[Prénom Nom]], les projets sous la forme [[Nom du projet]].
 
## Après chaque tâche
- Liste les fichiers que tu as créés, modifiés ou déplacés.
- Ajoute une ligne à log.md : date, ce que tu as fait, quels fichiers.
 
Priorités du moment : @context/now.md

« Garde ma formulation » et « liste les fichiers que tu as modifiés » sont les deux lignes que l’on regrette le plus souvent de ne pas avoir écrites dès le premier jour. La première empêche Claude de lisser votre voix jusqu’à la faire disparaître de vos notes. La seconde rend la relecture possible.

Faites des règles importantes des règles strictes

La documentation le dit explicitement : CLAUDE.md est du contexte, pas une configuration appliquée de force. Claude essaie de le suivre, sans garantie. Pour les dossiers qui ne doivent jamais changer, ajoutez une règle deny à .claude/settings.json dans le coffre. Les règles Edit couvrent les outils de fichiers de Claude et les commandes shell courantes, mais pas un script qui ouvre lui-même des fichiers : gardez donc git comme filet de sécurité.

{
  "permissions": {
    "deny": ["Edit(/journal/**)", "Edit(/archive/**)"]
  }
}

Claude Code a deux sortes de mémoire, et il est utile de savoir où chacune se trouve.

Quand vous dites à Claude « retiens que je vérifie les factures le vendredi », cela va dans l’auto memory. Quand vous dites « ajoute ça à CLAUDE.md », cela va dans le fichier. /memory liste les deux et les ouvre.

Pour un second cerveau, gardez le contexte qui compte pour vous dans le coffre, là où vous pouvez le lire, où git le suit et où chaque agent peut le voir. Un petit context/now.md avec les priorités de la semaine, importé depuis CLAUDE.md, fait plus qu’un long fichier de mémoire. Mettez-le à jour vous-même le lundi, ou demandez à Claude de rédiger la mise à jour et relisez-la comme n’importe quel autre changement.

L’essentiel de la valeur vient d’une poignée de tâches répétables :

• Tri de l’inbox. Claude propose où va chaque capture, vous approuvez, il déplace les notes et les relie.
• Des comptes rendus de réunion aux points d’avancement. Collez ou déposez une transcription ; Claude écrit un résumé, met à jour le README du projet et liste les actions en suspens.
• Interroger vos notes. « Qu’ai-je décidé pour la page de tarifs, et pourquoi ? » Demandez-lui de répondre avec des liens vers les notes qu’il a utilisées.
• Bilan hebdomadaire. Lire le journal et les notes de projet de la semaine et rédiger une note de bilan, sans modifier les originaux.
• Entretien des liens. Trouver les notes orphelines, les liens cassés et les notes qui devraient pointer l’une vers l’autre, et proposer les corrections sous forme de liste.

Transformez chaque tâche que vous répétez en skill. Un skill est un fichier SKILL.md dans .claude/skills/<name>/ ; vous le lancez en tapant /<name>, et Claude peut aussi s’en servir de lui-même quand votre demande correspond à sa description. Contrairement à CLAUDE.md, un skill ne se charge que quand il sert : des procédures détaillées ne coûtent presque rien le reste du temps.

---
description: Traite l’inbox. À utiliser quand je dis « traite l’inbox » ou « tri ».
---
 
Pour chaque note de inbox/ :
1. Décide où elle va : un projet, un domaine ou la corbeille.
2. Montre-moi le plan sous forme de tableau avant de déplacer quoi que ce soit.
3. Une fois que j’ai approuvé, déplace les notes et ajoute des liens depuis le
   README du projet ou du domaine.
4. Ne supprime jamais une note. Mets les rejets dans archive/inbox-rejects/.
5. Liste tous les fichiers que tu as touchés.

Dans Knowtarium

Quelle que soit la tâche, chaque note que Claude écrit ou modifie est signalée dans la barre latérale jusqu’à ce que vous l’ouvriez, avec ses changements et un Undo à un clic. Pour l’entretien des liens, les liens vers des notes que personne n’a encore écrites apparaissent en fantômes dans le graphe. Quand Claude écrit une note avec des citations en notes de bas de page, survolez-en une dans Knowtarium pour voir la source derrière l’affirmation.

(s’ouvre en grand dans un nouvel onglet) (s’ouvre en grand dans un nouvel onglet)

Les commandes intégrées utiles dans un coffre :

Au bout de quelques semaines, un second cerveau Claude Code contient des notes que vous n’avez pas écrites vous-même, et des notes que vous avez écrites mais que Claude a modifiées depuis. Les deux sont très bien, tant que vous savez lesquelles sont lesquelles. Les problèmes typiques :

• Une passe de rangement réécrit une note dans le style de Claude et fait sauter la seule réserve qui comptait.
• Un résumé avance une date ou un chiffre qui ne figure pas dans la note source.
• Un déplacement casse des liens, parce que Claude a déplacé le fichier avec une commande shell et que rien n’a mis à jour les liens.
• Vous corrigez un fait dans une note, et trois autres portent encore l’ancienne version.
• Une note écrite par Claude il y a des mois paraît aussi sûre d’elle qu’une note que vous avez vérifiée hier.

Le /rewind de Claude Code aide au sein d’une session, avec les limites que détaille la documentation sur les checkpoints : il ne suit pas les fichiers modifiés par des commandes shell (comme mv ou rm), et il « ne remplace pas un système de gestion de versions ». Pour des notes que vous gardez des années, il vous faut une étape de relecture qui ne dépende pas de la session.

Git est la base. C’est gratuit et ça marche dès aujourd’hui : faites un commit avant une session, laissez Claude travailler, puis lisez le diff et ne gardez que ce que vous approuvez.

$ git status --short           # ce qui a changé pendant que Claude travaillait$ git diff --stat$ git diff projects/           # lire les modifications, dossier par dossier$ git add -p                   # garder ce qui est juste, bloc par bloc$ git commit -m "inbox triage, reviewed"$ git restore .                # jeter le reste$ git clean -n                 # voir les nouveaux fichiers que vous n’avez pas gardés

Quelques habitudes rendent cela rapide :

• Une tâche par session, un commit par tâche. Un diff de 4 fichiers se lit facilement ; un diff de 60, non.
• Lisez d’abord la liste des fichiers modifiés. Tout ce qui sort du dossier sur lequel vous avez posé la question mérite un examen plus attentif.
• Vérifiez les nouveaux faits par rapport à la note ou au lien qu’ils citent. Ce sont les faits sans source qu’il faut remettre en question.
• Si quelque chose fait des commits automatiques de votre coffre à intervalles réguliers, ces commits mélangeront vos modifications et celles de Claude. Faites vos commits à la main autour des sessions de Claude, ou relisez ensuite avec git log -p.

Git vous montre un diff quand vous pensez à faire un commit. Knowtarium garde l’historique à côté des notes : c’est l’installation que nous recommandons dès que Claude écrit plus que ce que vous avez envie de lire dans un terminal. Vos notes vivent dans un espace de travail chiffré de bout en bout sous forme de paquet OKF : du markdown simple dont le frontmatter note qui a écrit chaque note, qui l’a vérifiée, d’où viennent ses affirmations et quand elle se périme.

• Chaque changement est signé et annulable. Les changements de Claude sont enregistrés aussitôt et signés avec sa propre clé. Un point dans la barre latérale signale les notes qu’il a modifiées jusqu’à ce que vous les ouvriez, une ligne sous le titre indique quand et renvoie aux changements, et Undo restaure la version précédente. L’historique garde chaque version aussi longtemps que vous le réglez, d’un jour à un an.
• La relecture est là quand vous la voulez. Activez la relecture (« Ask me first ») pour un espace de travail ou un dossier, et les changements de Claude y attendent sous forme de diffs que vous les approuviez ou les rejetiez. Vos propres modifications y attendent que vous demandiez à Claude de les vérifier, par exemple « vérifie les modifications du jour », et Claude les compare à tout ce qui y est lié.
• Qui l’a écrite, sur chaque note. L’auteur d’une note figure en haut de celle-ci. Dans les dossiers où la relecture est activée, elle montre aussi qui l’a vérifiée, le graphe peut colorer les notes par niveau de confiance (unverified, machine-confirmed ou human-reviewed), et une note est entièrement vérifiée une fois que vous et un agent l’avez vérifiée après son dernier changement.
• Rien ne se périme en silence. La page Stale and expiring liste les notes qui ont dépassé stale_after et celles qui arrivent à échéance.
• Claude travaille via MCP. Knowtarium n’appelle aucune IA lui-même. Claude Code se connecte avec npx knowtarium connect et reçoit les conventions avec ses outils. Nous ne pouvons pas lire vos notes ; Claude voit ce qu’il lit.

Knowtarium est gratuit pour commencer, avec 500 Mo de stockage et un espace de travail, et les offres payantes Starter (5,99 $US par mois) et Pro (11,99 $US par mois) ajoutent du stockage et des espaces de travail. Importez un coffre Obsidian dans un espace de travail et il est converti en OKF sans toucher à ce que vous avez écrit, et vous pouvez tout exporter en markdown simple quand vous voulez. Voir le guide de migration, et la page de comparaison pour savoir en quoi les deux applications diffèrent.

Rien ici n’est propre à Claude Code. N’importe quel agent capable de lire et d’écrire des fichiers dans un dossier peut faire tourner votre second cerveau. La principale différence, c’est le nom du fichier d’instructions :

• Codex lit AGENTS.md, depuis ~/.codex et depuis les dossiers situés entre la racine git et l’endroit où vous le lancez, jusqu’à 32 Kio au total par défaut (documentation de Codex).
• Cursor lit aussi AGENTS.md, comme alternative plus simple à ses fichiers .cursor/rules (documentation de Cursor).
• Claude Code lit AGENTS.md quand il n’y a pas de CLAUDE.md, dans ses versions récentes. L’installation portable consiste à garder vos règles dans AGENTS.md et à réduire CLAUDE.md à une seule ligne, @AGENTS.md, plus ce qui est propre à Claude.

Chaque agent suit alors les mêmes règles pour le coffre, et la même relecture les rattrape tous, dans git ou dans l’historique de Knowtarium. Notre guide AGENTS.md pour les bases de connaissances propose un modèle plus complet. Si vous choisissez une application pour lire le résultat, la présentation du second cerveau IA donne une vue d’ensemble, et le fichier d’idée du wiki LLM de Karpathy vaut la lecture pour le modèle plus large.