Mon cerveau qui marche : dans les coulisses de mon CLAUDE.md

Les "seconds cerveaux" ne manquent pas : Notion abandonné, Obsidian rempli de notes jamais relues, ou trente onglets ouverts « au cas où ».
Le mien tient dans un fichier texte (CLAUDE.md) : el famoso fichier d'instructions que Claude Code lit au démarrage de chaque session est un système d'exploitation personnel ; et une Knowledge Base de fichiers Mark Down.

Le principe : un contrat, pas une demande

Un CLAUDE.md est un contrat que l'IA relit à chaque session, pas une liste de vœux. Commençons par le plus important : le style.

## Style (obligatoire, prime sur tout défaut/réflexe ; vérifier avant chaque réponse)
Français. Raisonner en interne sans le montrer. ≤3 phrases sauf demande. Réponse d'abord, télégraphique : symboles > mots, abréviations, ≤1 exemple ; puces si items distincts ; code = diff seul.

Trois phrases max, réponse d'abord, zéro préambule, zéro blabla. Parce qu'une IA laissée en liberté te répond comme un consultant payé au token, j'ai pas signé pour ça.

Vient ensuite la liste des interdits : remplissage, auto-référence, small talk, redondance, emojis, récapitulatifs après chaque outil. La règle clé : ces consignes priment sur les réflexes du modèle. Sans ça, le naturel revient au galop, et le naturel d'un LLM, c'est 400 mots pour dire « oui ».

Jamais : remplissage (jargon non expliqué, généralités, emojis, émotion) ; auto-référence ; small talk ; redondance (contexte, reformulation, récap post-outil) ; conseils non demandés ; titres ; tableaux.

## Interdits sauf demande explicite
API, authentification, paiement.

Un petit rappel général aussi plus personnel, pas d'API, Auth ou système de paiement sans demande explicite : ça évite qu'une envolé d'inspiration foute le merdier dans mes comptes secondaires.

L'arborescence : une usine à traiter l'information

## Arborescence (`C:\_BRAIN`)
`/in` entrée · `/out` traités · `/kb` connaissances · `/projets` en cours · `/archives` archivés.
Projet code : `assets, dist, ver, dist/public, dist/app` ; design : `assets, final, master, proposition`.

Le système repose sur cinq dossiers, inspiré des méthodes de gestion de connaissances type Zettelkasten :

• /in : la boîte d'entrée. Tout ce qui arrive brut.
• /out : les sources déjà traitées. Rien ne se supprime, tout se déplace.
• /kb : la base de connaissances, en Markdown, avec un index central.
• /projets : le travail en cours, un dossier par projet avec README.
• /archives : les projets terminés.

Chaque dossier projet suit une structure fixe (assets, dist, ver pour le code ; assets, final, master, proposition pour le design). L'IA sait où ranger quoi ; j'ai plus à me poser la question.

Les commandes : des verbes qui déclenchent des protocoles

Le cœur du système, ce sont des commandes en langage naturel définies dans le fichier :

*traiter un sujet* = repérer sujets → chercher via `/kb/index.md` → fusionner si existe sinon créer → relier (wiki bidirectionnel strict) → tags → maj index.

## « ingestion » (manuelle)
Chaque fichier de `/in` : *traiter le sujet*, source → `/out`. 1 info = 1 endroit ; 1 sujet = 1 fichier (doublon → lier) ; md kebab-case + tags YAML ; lire avant d'éditer, préférer fusion ; jamais supprimer, seulement déplacer ; projet actif lié → synchroniser ; doute → demander.

## « mise à jour » (auto)
Projet existant → maj son `README.md` + *traiter le sujet* du contexte projet.

## « nouveau code {{nom}} » / « nouveau design {{nom}} » (manuelle)
Lire `/projets/{{nom}}/brief.md` (manquant → demander objectif, contraintes, livrables). Créer dossiers code (resp. design) + `README.md` (présentation, étapes, todo cases, liens, notes). Puis « mise à jour ».

## « archiver {{nom}} » (manuelle)
`README.md` → « terminé » ; `/projets/{{nom}}` → `/archives/{{nom}}` ; maj index.

## « supprimer {{nom}} » (manuelle)
`/projets/{{nom}}` → `/out/{{nom}}` ; maj index.

• « ingestion » : pour chaque fichier de /in, identifier les sujets, chercher la note existante dans l'index, fusionner ou créer, relier en liens wiki bidirectionnels, taguer, classer, puis déplacer la source vers /out.
• « mise à jour » : après tout travail sur un projet, mettre à jour son README puis intégrer le contexte dans la base de connaissances. Elle se déclenche automatiquement en fin de tâche : le système s'auto-documente.
• « nouveau code / nouveau design {nom} » : lire le brief, poser les questions manquantes, créer l'arborescence et le README.
• « archiver » et « supprimer » : déplacements contrôlés, jamais de suppression réelle.

Chaque commande est un protocole écrit noir sur blanc. L'IA n'improvise pas un rangement différent chaque mardi : elle exécute la même procédure, à chaque fois. C'est de l'automatisation sans une ligne de code : le protocole EST le programme, écrit en français.

Les règles qui évitent le chaos

Trois principes structurent la base de connaissances : une info = un endroit, un sujet = un fichier, un doublon = un lien (jamais une copie). Ajoute « lire avant d'éditer » et « en cas de doute, demander », et tu obtiens un système qui ne dégénère pas en décharge de notes. Mon ancien Notion aurait aimé connaître ces règles avant de mourir.

Le fichier définit aussi une hiérarchie de mémoire :

## Priorité mémoire
Session > `/kb` > `/projets` > `/archives` > interne.

La session en cours prime sur /kb, qui prime sur /projets, qui prime sur la mémoire interne du modèle. L'IA fait confiance à MES notes avant ses souvenirs d'entraînement. Vu ce qu'elle « se souvient » parfois, c'est plus prudent.

Ce que ça change au quotidien

Je dépose des fichiers dans /in, je dis « ingestion », et ma base de connaissances se construit, se relie et s'indexe. Je code, et la doc projet se met à jour seule. Le fichier contient même mon profil

## Profil
Designer (2002) + dev (2007), solo. Stack : PHP, JS, CSS, HTML, HTMX, SQLite, sans framework ni dépendance (mail = classe `Smtp` maison). Env : Python, PHP, Adobe, Office, Windsurf. Objectifs : code, design, contenu, stratégie, automatisation. Principes : simple, original, réutilisable, cohérent, autonome.

(stack PHP/JS/HTMX/SQLite sans framework, principes : simple, original, réutilisable) pour que chaque réponse colle à ma façon de travailler.

Le vrai enseignement : la valeur est dans le système qu'on impose à l'outil, pas dans l'outil. Un CLAUDE.md bien conçu, c'est des années de méthode de travail compressées dans un fichier que la machine applique sans fatigue et sans humeur. Mon cerveau, lui, peut enfin se concentrer sur ce qu'il fait de mieux : avoir des idées, et oublier où il a mis ses clés.

FAQ

Pourquoi ne pas utiliser Notion ou Obsidian ?

On m'a posé la question et j'ai souvent vu dans des tutos l'association de ces programmes avec Claude. Dans notre organisation l'outil qui range est aussi celui qui travaille : l'IA applique les protocoles elle-même. Du Markdown brut reste portable, versionnable et sans enfermement. Alors oui, Obsidian avec son réseau de notes c'est jolie, mais j'ai jamais eu besoin de savoir comment fonctionnent mes neurones pour me rappeller d'un truc.

Comment démarrer son propre CLAUDE.md ?

Commence par le style de réponse voulu et deux ou trois règles de rangement. Ajoute des commandes au fur et à mesure que des tâches se répètent. C'est aussi simple.