Le second cerveau

Mémoire fichier : ne plus jamais rien perdre

Un LLM est amnésique entre les sessions (leçon 1.1). Le remède industriel : une mémoire fichier persistante que Claude relit et met à jour. Le système de Pierre en est l'exemple de référence.

Principe : un dossier memory/ dans lequel chaque fait durable est un fichier markdown avec frontmatter (name, description, type : user / feedback / project / reference). Un fichier MEMORY.md joue le rôle d'index : une ligne par mémoire, chargé à chaque session.

Trois catégories qui structurent tout :

• feedback : comment Claude doit travailler (corrections, préférences). Avec le pourquoi.
• project : l'état d'un travail, les décisions, les contraintes non déductibles du code.
• reference : pointeurs vers des ressources externes.

Une discipline cruciale, codifiée par Pierre : mettre à jour la mémoire après chaque lot livré, pas seulement en fin de session. Ainsi on ne perd ni détail ni contexte. Et on ne stocke que ce qui n'est pas déjà dans le code (git et le CLAUDE.md le disent déjà) : on garde le non-évident.

Obsidian : le second cerveau navigable

Pierre monte sa mémoire de fichiers comme un vault Obsidian : la même source unique, mais navigable visuellement. Les techniques qui font la différence :

• Wikilinks [[nom-de-la-note]] : chaque note pointe vers des notes connexes. On tisse un réseau, pas une pile de fichiers. Un lien vers une note pas encore écrite est valide : il marque un vide à combler.
• MOC (Map of Content) : des notes-carrefours (_MOC_feedbacks, _MOC_projects, _absolute_rules) qui rassemblent les liens par thème. Un point d'entrée thématique.
• Notes atomiques : un fait par note, densément liées. Plus facile à retrouver et à recombiner.
• Vue graphe : la carte visuelle du vault, pour voir les clusters et les lacunes.

Le protocole "sync memory" de Pierre formalise la maintenance : créer ou mettre à jour la note, tisser ses wikilinks vers les notes connexes, l'ajouter au bon MOC et à l'index. Pas seulement réconcilier l'index : tisser le réseau. Un second cerveau vaut par ses liens, pas par ses fichiers isolés.

Graphify : interroger une base de code au lieu de la relire

Graphify (l'un des skills de Pierre) transforme n'importe quel dossier (code, docs, articles, video) en un graphe de connaissance persistant et interrogeable. Pipeline : détecter les fichiers -> extraire l'AST (code) et le sens (docs) en parallèle -> détecter les communautés (clustering) -> exporter vers HTML/Obsidian/Neo4j.

Le gain est énorme et contre-intuitif : au lieu de relire 30 fichiers pour répondre à "qui appelle cette fonction ?", vous interrogez le graphe (/graphify query, /graphify path, /graphify explain). D'après les mesures de Pierre, jusqu'à ~71x moins de tokens qu'une relecture. C'est l'optimisation de contexte (module 7) appliquée à la connaissance du code.

Sa règle est de brancher Graphify sur chaque projet, nouveau comme existant, en mode AST local (gratuit), via un helper graphify-init.ps1, et d'injecter le graphe dans le vault Obsidian (_graphify\<projet>). Des hooks git rafraîchissent les graphes à chaque commit. Résultat : il dispose de 8 repos et d'un brain-graph de plusieurs centaines de noeuds, tous interrogeables sans rien relire.

Leçon générale : pour les grandes bases de connaissance, indexer une fois, interroger souvent l'emporte sur relire à chaque question. Valable pour le code comme pour votre mémoire.

Dream : consolidation nocturne automatique

Le skill dream de Pierre applique le concept de consolidation mémoire (inspiré du sommeil) à son vault. Une tâche planifiée le lance chaque nuit. En quatre phases :

1. S'orienter : prendre ses repères dans la mémoire existante.
2. Collecter le signal : relire les conversations récentes et la mémoire.
3. Consolider : extraire les faits durables, fusionner les doublons, archiver (ne jamais supprimer) les contradictions, tisser les liens.
4. Vérifier : maintenir MEMORY.md comme index propre.

L'ensemble respecte ses règles absolues : ne jamais supprimer (archiver dans un dossier daté), pas d'emoji, pas de tiret cadratin, l'index reste un index. Une sauvegarde précède chaque passe, et tout s'exécute en mode headless.

C'est l'aboutissement du second cerveau : un système qui se nettoie et se renforce pendant que Pierre dort. La pratique quotidienne (mémoire mise à jour après chaque lot) fournit la matière brute ; Dream la digère, déduplique et lie. Sans cette digestion, une mémoire grossit jusqu'à devenir illisible. Avec elle, elle reste vivante.

Mise à jour du 11 juillet 2026 : sur le dispositif de l'auteur, le rêve nocturne a gagné deux compagnons. Depuis le 9 juillet, un idle-sync : un hook Stop enregistre chaque tour terminé, et une tâche planifiée toutes les 15 minutes synchronise la mémoire de toute session restée inactive 30 minutes en la reprenant en headless. Depuis le 10 juillet, le wrapper de sync committe et pousse aussi le vault vers un dépôt git privé, ce qui garde un clone du cerveau sur le téléphone à jour. Répartition des rôles : l'idle-sync est le fil de l'eau, le rêve reste le grand ménage nocturne. La leçon hooks du module d'installation rapide donne les garde-fous anti-boucle que cela exige.

Apprentissage continu : apprendre de sa propre pratique

Le dernier étage du système : le skill continuous-learning. Il analyse l'historique git des repos sur 90 jours, repère les patterns récurrents (commandes répétées, mêmes correctifs, deployments tapés, avec un seuil d'occurrence) et propose de les transformer en nouveaux skills ou règles à ajouter au CLAUDE.md.

L'idée est profonde : votre pratique quotidienne contient déjà les automatisations dont vous avez besoin, sous forme de répétitions. Plutôt que de les deviner, vous les extrayez des données (l'historique git) et vous les codifiez.

La boucle complète du second cerveau de Pierre :

• Il travaille (sessions Claude Code sur ses projets).
• Il consolide après chaque lot (mémoire) ; Dream digère la nuit.
• Graphify indexe le code en graphes interrogeables.
• Continuous-learning extrait les patterns répétés en nouveaux skills et règles.

Résultat : un système qui s'améliore à chaque session sans effort dédié. C'est le niveau expert de l'utilisation de Claude : non pas se contenter de l'outil, mais bâtir autour de lui une machine qui apprend.

Notes atomiques

Une note atomique contient exactement une idée, un fait ou une décision. Le mot "atomique" signifie indivisible : vous ne pouvez pas fractionner la note davantage sans en perdre le sens. Dans un second cerveau (un système de connaissance personnelle qui stocke et connecte des informations hors de votre mémoire), les notes atomiques sont la plus petite unité utile.

Les notes volumineuses couvrant plusieurs sujets posent un problème de classement : on ne sait jamais quelle catégorie les possède, et retrouver un seul fait oblige à relire tout le reste. Les petites notes ont un seul emplacement et un seul rôle. Elles se recombinent aussi librement, car chacune se suffit à elle-même.

La puissance des notes atomiques vient de la liaison. Quand chaque fichier ne contient qu'une seule idée, les connexions entre fichiers deviennent significatives. Une note sur "les limites de la fenêtre de contexte" peut pointer vers "stratégie de découpage", "comptage de tokens" et "mise en cache des prompts" sans dupliquer le contenu. Claude Code et des outils comme Graphify (un injecteur de graphe de code utilisé par Pierre) peuvent parcourir ces liens et faire remonter les notes pertinentes sans relire des milliers de lignes.

• Une idée par fichier : si vous utilisez "et" dans le titre, scindez la note.
• Titre descriptif : le titre doit rendre le contenu prévisible depuis un résultat de recherche.
• Pas d'orphelins : chaque nouvelle note obtient au moins un lien vers une note existante.
• Privilégier les noms : nommez le concept, pas le projet ("budget de tokens", pas "le problème de tokens de lundi").

Wikilinks et cartes de contenu

Un wikilink est une référence en double crochets comme [[note-title]] qui crée une connexion cliquable entre deux notes. Dans Obsidian (l'application de prise de notes utilisée comme second cerveau), chaque wikilink que vous écrivez devient une arête visible dans la vue graphique. Quand Claude lit votre vault, ces liens sont aussi des métadonnées lisibles : ils lui indiquent quels concepts sont liés sans que vous ayez à répéter l'explication.

Une carte de contenu (MOC, de l'anglais map of content) est une note dont le seul rôle est de lister et de relier d'autres notes sur un sujet. Considérez-la comme un index constitué à la main. Contrairement à un dossier, une MOC peut apparaître dans plusieurs contextes et créer des liens entre différents sujets. Conventions de nommage courantes : _MOC_projects, _MOC_skills, _MOC_reference.

Ensemble, les wikilinks et les MOC offrent à votre vault deux modes de navigation :

• Retrolinks : chaque note affiche quelles autres notes pointent vers elle, ce qui permet de retracer où une idée est utilisée.
• Parcours de hub : vous ouvrez une MOC et naviguez vers n'importe quel sous-sujet en quelques secondes, sans recherche nécessaire.

Lorsque vous demandez à Claude Code de mettre à jour la mémoire, lui demander d'ajouter un [[wikilink]] à la MOC pertinente et à MEMORY.md signifie que la nouvelle note est immédiatement accessible depuis deux points d'entrée. Le graphe reste cohérent sans maintenance manuelle.

Types de mémoire

Claude Code organise la connaissance persistante en quatre types de mémoire, chacun stocké dans un fichier différent et chargé à un moment différent. Comprendre lequel utiliser évite l'encombrement et garantit que le bon contexte arrive au bon moment.

• Mémoire utilisateur : préférences et règles globales qui s'appliquent à tous les projets. Stockée dans ~/.claude/CLAUDE.md. Exemples : votre nom, la langue préférée, la règle sans emoji, le style de commit.
• Mémoire de projet : informations spécifiques à une base de code. Stockée dans .claude/CLAUDE.md à la racine du dépôt. Exemples : la pile technologique, les conventions de dossiers, les noms de variables d'environnement, la stratégie de branches.
• Notes de retour d'expérience : leçons tirées d'erreurs ou de corrections. Nommées feedback_*.md dans votre vault. Exemples : "ne jamais supprimer, toujours archiver", "pas de jq sur Windows, utiliser node". Elles sont référencées depuis MEMORY.md afin que Claude les charge à la demande.
• Notes de référence : documents factuels stables que Claude peut avoir besoin de consulter. Nommées reference_*.md. Exemples : workflow API, limites de quota, versions d'outils. Ce ne sont pas des règles mais des tables de consultation.

La séparation est importante car la mémoire utilisateur est chargée inconditionnellement à chaque session, elle doit donc rester courte et universelle. La mémoire de projet n'est chargée que lorsque Claude démarre dans ce dépôt. Les notes de retour d'expérience et de référence sont chargées à la demande via des liens dans MEMORY.md, ce qui maintient la fenêtre de contexte active (la mémoire de travail que Claude conserve pendant une conversation) légère.

Une erreur courante consiste à écrire des règles spécifiques à un projet dans la mémoire utilisateur, ou à entasser tous les faits dans un seul fichier énorme. Gardez chaque note atomique (un sujet par fichier), liez-la depuis le bon index, et Claude récupérera exactement ce dont il a besoin sans gaspiller de tokens (l'unité qui mesure la quantité de texte que Claude peut traiter en une fois).

Rappel plutôt que relecture

Chaque fois que vous demandez à Claude de relire un fichier source uniquement pour répondre à une question, vous dépensez des tokens (les unités de texte traitées par le modèle) sur un contenu que vos notes résumaient déjà. Au niveau Expert, l'habitude à cultiver est la suivante : interrogez vos notes en premier, ouvrez le fichier brut uniquement si la note est insuffisante.

Un second cerveau bien entretenu (votre vault Obsidian ou tout autre système de notes liées) stocke le sens distillé de chaque fichier : décisions clés, points d'entrée, pièges à éviter et liens croisés. Demander à Claude d'interroger ce graphe coûte une fraction de ce que coûterait la lecture de dizaines de fichiers sources depuis le début. Avec un outil comme Graphify (un constructeur de graphes de code qui cartographie votre dépôt en noeuds et arêtes), une seule requête sur le graphe peut remplacer la lecture de tout un arbre de modules.

Le flux de travail comporte trois niveaux :

• Niveau 1 - rappel : demandez à Claude d'interroger vos notes ou le graphe pour obtenir la réponse.
• Niveau 2 - lecture ciblée : si la note pointe vers un fichier et une plage de lignes spécifiques, lisez uniquement cette portion.
• Niveau 3 - lecture complète : à utiliser uniquement lorsque la note est obsolète ou que la question est structurelle et vraiment nouvelle.

Cette approche par niveaux correspond à la façon dont un ingénieur senior travaille avec une grande base de code : le modèle mental d'abord, le fichier source en dernier recours seulement. Vos notes sont votre modèle mental sur disque.

Injecter les conversations dans le cerveau

Chaque session Claude Code que vous avez lancée est un enregistrement riche : prompts, chaînes de raisonnement, modifications de code et résultats. Par défaut, ces sessions sont stockées dans un répertoire de journaux local et ne sont jamais relues. Injecter les conversations dans le graphe de connaissance signifie exporter ces journaux, les analyser et les injecter dans votre vault Obsidian (votre second cerveau) afin que Claude puisse les retrouver lors de sessions futures, sans relire les textes bruts.

L'étape d'export utilise claude-extract, un petit utilitaire Node qui lit les fichiers de session Claude Code (stockés sous ~/.claude/projects/ en tant que fichiers JSONL, où JSONL signifie un objet JSON par ligne). Sous Windows, définissez PYTHONUTF8=1 avant d'exécuter toute variante Python afin d'éviter les erreurs d'encodage avec les caractères accentués.

Une fois exportées, les transcriptions atterrissent dans un dossier (conventionnellement _conversations/ dans votre vault). Graphify les ingère ensuite : il construit un graphe de type AST (AST signifie Abstract Syntax Tree, une carte structurée des relations) qui relie les nœuds de session aux nœuds de projet, aux nœuds de skills et aux notes mémoire. Le graphe résultant peut atteindre des milliers de nœuds et permet à Claude de répondre à des questions comme "qu'avons-nous décidé sur la géométrie des portes dans Plan2Tour ?" en parcourant les arêtes du graphe plutôt qu'en relisant des centaines de fichiers.

• Emplacement des fichiers de session : ~/.claude/projects/<chemin-encodé>/, un JSONL par session.
• Commande d'export : claude-extract (lancer avec PYTHONUTF8=1 sous Windows).
• Destination : dossier _conversations/ dans votre vault Obsidian.
• Actualisation du graphe : exécuter graphify update <repo> ou déclencher la tâche planifiée qui s'exécute chaque nuit.
• Gain des requêtes : le parcours du graphe coûte bien moins de tokens que la lecture des transcriptions brutes, jusqu'à 71 fois moins dans les grands vaults.

Rafraîchissement nocturne

Un second cerveau (votre vault Obsidian connecté à Claude Code) n'a de valeur que si ses données sont récentes. Le code évolue chaque jour, de nouvelles notes s'accumulent, et le graphe de connaissance (la carte des connexions entre fichiers, fonctions et notes) se désynchronise au fil de la nuit. La consolidation planifiée consiste à lancer des tâches automatisées à heure fixe chaque soir pour tout remettre en phase avant la prochaine session de travail.

Deux tâches complémentaires couvrent ce besoin : un rafraîchissement du graphe (réanalyse de tous les dépôts avec Graphify pour mettre à jour les noeuds et les arêtes AST) et un passage de rêve (un agent de consolidation qui lit les notes récentes, intègre les informations importantes dans la mémoire permanente et tisse de nouveaux wikilinks). Les exécuter dans l'ordre, graphe d'abord puis rêve, garantit que l'agent de rêve raisonne toujours sur le graphe le plus récent.

Sous Windows, le Planificateur de tâches gère les deux. Chaque tâche appelle un script PowerShell qui se place dans le bon répertoire, invoque claude en mode non interactif avec une invite préparée, et consigne le résultat. Les options clés sont :

• --print : exécute un seul tour de façon non interactive, affiche la réponse puis quitte.
• --model claude-opus-4-8 : utilise Opus pour le passage de rêve (raisonnement intensif) ; utilisez claude-sonnet-4-6 pour le résumé de métadonnées de graphe moins coûteux.
• --output-format text : écrit une sortie en texte brut que le script peut ajouter à un fichier journal.
• --max-tokens 2048 : limite la sortie pour éviter des coûts excessifs sur une tâche sans surveillance.

Le résultat : chaque matin votre index de vault est à jour, vos notes de mémoire portent les informations de la nuit, et Claude Code charge un graphe qui reflète ce qui existe vraiment plutôt qu'un instantané périmé.

Un cerveau de poche : Claude Code sur Android, synchronisé par git

L'aboutissement logique d'un second cerveau versionné par git : la même mémoire, sur votre téléphone, pilotée par un Claude Code natif. Pas l'option de télécommande officielle (piloter votre PC depuis le téléphone), mais Claude qui tourne sur l'appareil Android lui-même, inspectant et agissant sur le téléphone, et lisant le même coffre que votre poste de bureau. L'auteur a déployé exactement cela en juillet 2026 ; voici le mode opératoire, pièges déjà désamorcés.

La plateforme, c'est Termux, un environnement terminal Linux pour Android, installé depuis F-Droid, jamais le Play Store (la fiche Play Store est un build mort depuis des années ; un fork plus récent y existe mais restreint l'exécution de binaires). Ajoutez l'appli compagnon Termux:API (même source, même signature) pour les intégrations téléphone : notifications, presse-papiers, capteurs, voix. Claude Code lui-même s'installe via un installeur communautaire qui télécharge le binaire officiel linux-arm64 d'Anthropic et vérifie son SHA256 (les versions récentes nécessitent un correctif de compatibilité glibc sur la libc Bionic d'Android, que l'installeur gère). Auditez tout script communautaire de ce type avant de l'exécuter, comme l'enseigne le module sécurité : le lire, confirmer qu'il récupère depuis des domaines officiels, vérifier ce qu'il touche d'autre.

L'authentification cache un piège et une règle. Le piège : l'OAuth par navigateur depuis Termux boucle souvent sur lui-même. La voie fiable consiste à générer un jeton longue durée sur votre poste de bureau avec claude setup-token et à le placer dans l'environnement du téléphone (CLAUDE_CODE_OAUTH_TOKEN) : l'usage reste couvert par votre abonnement. La règle : ne jamais brancher une clé API Console facturée au jeton sur un appareil qui fait tourner des sessions agentiques dans votre poche. Le second piège se déguise : le premier lancement peut échouer avec une erreur de permission sur la lecture de / (Claude Code ignorant le répertoire temporaire du bac à sable). Le correctif consiste à le lancer via proot avec le répertoire temporaire lié, enveloppé dans un alias shell ; à partir de là, connexion et sessions se comportent normalement.

Le lien cerveau, c'est ce qui paie. Clonez votre dépôt coffre dans Termux, puis créez un lien symbolique entre le chemin de mémoire de session du téléphone (~/.claude/projects/<home-slug>/memory) et le clone. Le poste de bureau et le téléphone lisent et écrivent désormais dans le même cerveau. Automatisez la synchronisation avec les hooks que vous connaissez déjà : un hook SessionStart fait un pull (fast-forward seulement, avec délai, sans jamais bloquer), un hook SessionEnd fait un commit et un push. Ajoutez la synchronisation d'inactivité du poste de bureau en face, et les deux appareils convergent en quelques minutes après tout changement, sans étape manuelle. Un second petit dépôt peut porter votre configuration (CLAUDE.md pour le téléphone, un sous-ensemble de skills sélectionné) avec un script de démarrage idempotent, si bien que reflasher le téléphone reconstruit tout en une seule commande.

Kit de survie propre à Android, chaque élément gagné à la dure :

• Le tueur de processus fantômes d'Android tue silencieusement les tâches longues : désactivez les restrictions sur les processus enfants dans les options de développeur, et prenez un verrou de réveil pour les exécutions longues (intégrez termux-wake-lock dans l'alias de lancement pour que ce soit automatique).
• Le ripgrep fourni est cassé sur ARM64 : installez celui du système et pointez Claude vers lui (USE_BUILTIN_RIPGREP=0).
• RAM limitée : plafonnez le tas de Node (NODE_OPTIONS=--max-old-space-size=512).
• Les claviers mobiles corrompent les chaînes && collées : lancez les commandes sur des lignes séparées, et activez la saisie caractère par caractère dans les propriétés Termux.
• L'accès au stockage nécessite un termux-setup-storage ponctuel.

Que faire concrètement avec un Claude de poche ? La voix est l'interface qui change tout : un petit script en boucle enchaîne speech-to-text, claude -p (avec -c pour continuer la conversation), et text-to-speech, lancé depuis un widget d'écran d'accueil. Vous dictez une idée en sortant d'une réunion ; le téléphone l'écrit dans le cerveau ; le poste de bureau la récupère avant votre prochaine session. Cadrez honnêtement la portée : sans root, Claude peut travailler sur les fichiers, les notifications, le presse-papiers, les capteurs et les scripts, mais ne peut pas toucher aux données privées des autres applications ni aux réglages système. C'est un terminal cerveau, pas un administrateur de téléphone, et c'est exactement le bon périmètre.