Les 3 niveaux de CLAUDE.md

La différence entre les niveaux, c'est juste leur portée

Pourquoi c’est plus important qu’une session réussie. Les modèles passent : tu les loues. Ces fichiers, eux, sont à toi. Ce que le modèle le plus intelligent y écrit aujourd’hui, chaque session future le suivra, quel que soit le modèle qui tourne.

Chargé au début de chaque session, dans tous tes projets

# Ma façon de travailler
- Explique-moi en clair ce que tu vas faire avant de le faire.
- Si ma demande est ambiguë, énonce tes hypothèses et pose-moi la question avant d'écrire du code.
- Contredis-moi quand j'ai tort. Ne sois jamais d'accord juste pour être agréable.

# Mes réglages par défaut
- Gestionnaire de paquets : [pnpm / npm / yarn, choisis le tien]
- [Préférences de langage, ex. « TypeScript plutôt que JavaScript, toujours »]
- Lis le code existant avant de le modifier.
- Si tu n'es pas sûr qu'une chose existe (un package, une API, un réglage), vérifie ou dis-le. Ne comble jamais le vide avec un truc qui a l'air correct.
- Remonte les erreurs explicitement. Ne les avale jamais, n'ajoute pas de fallback que je n'ai pas demandé.
- Changements minimaux : rien que je n'ai pas demandé, pas d'« améliorations » au passage.

# Avant de dire « c'est fait »
- Lance les tests ou le build du projet s'il en a.
- Ne me dis jamais qu'un truc marche sans l'avoir vraiment exécuté. « Ça devrait marcher » n'est pas « ça marche ».
- Dis-moi ce que tu as changé, et ce dont tu n'es pas sûr.

Chargé à chaque session dans ce projet, partagé avec l'équipe via git

# Ce qu'est ce projet
[Une ou deux phrases : ce qu'il fait, pour qui.]

# Stack
- [Framework, langage, base de données, hébergement. Ex : Next.js, TypeScript, Supabase, Vercel]

# Commandes
- Lancer en local : [npm run dev]
- Tester : [npm test]
- Builder : [npm run build]

# Règles de ce repo
- [Où vivent les choses : « les routes API dans app/api/ », « les composants dans components/ »]
- [Conventions : nommage, système de styles, gestion des erreurs]
- [Les interdits : « ne jamais commiter .env.local », « ne pas toucher au dossier generated/ »]
- Les secrets restent dans les variables d'environnement. Jamais une vraie clé dans un fichier.

# Pièges
- [Tout ce que Claude n'arrête pas de rater, ou ne peut vraiment pas deviner depuis le code]

Chargé seulement quand Claude touche à des fichiers de ce dossier

# Ce dossier
[Ce qui vit ici et à quoi ça sert.]

# Règles qui ne s'appliquent qu'ici
- [Ex : « tout ce dossier est du texte destiné aux clients : français simple, zéro jargon »]
- [Ex : « ces fichiers sont générés : modifie les templates dans /templates à la place »]

Organiser ses CLAUDE.md, c’est une brique d’un système complet pour déléguer à l’IA sans la surveiller. C’est tout l’objet de la formation Agentic eSchool.

Fais-les écrire par le modèle le plus puissant auquel tu as accès

Je veux que tu écrives mes fichiers CLAUDE.md : les instructions permanentes que chaque future session suivra.

1. Explore d'abord ce projet : le code, la structure, le README, et les CLAUDE.md existants s'il y en a.
2. Interviewe-moi ensuite : jusqu'à 8 questions, une à la fois, sur ma façon de travailler, ce qui va souvent de travers, mon niveau technique, et tout ce que tu ne peux pas déduire du code.
3. Écris ensuite trois fichiers :
   - ~/.claude/CLAUDE.md (niveau ordinateur) : uniquement ce qui est vrai pour tous mes projets.
   - CLAUDE.md à la racine de ce projet : uniquement ce qui est propre à ce projet. Ce que c'est, la stack, les commandes, la structure, les conventions, les pièges.
   - Si un sous-dossier a vraiment des règles différentes, un court CLAUDE.md pour ce dossier.

Règles d'écriture : sois précis, jamais vague (« indentation 2 espaces », pas « formate le code proprement »). Chaque fichier bien en dessous de 200 lignes, plus court c'est mieux. N'inclus que ce que je devrais sinon répéter à chaque session, rien que tu peux déduire du code lui-même. Ne répète jamais une règle sur deux niveaux. Quand une règle n'est pas évidente, ajoute sa raison en une ligne. Chaque ligne doit mériter sa place.

Montre-moi chaque fichier avant de l'enregistrer, et dis-moi ce que tu as volontairement laissé de côté et pourquoi.

4 règles, toutes tirées de la doc officielle de Claude Code

Le précis est suivi, le vague est ignoré

« Indentation 2 espaces » est appliqué. « Formate le code proprement » est ignoré. « Lance npm test avant de commiter » est appliqué. « Teste tes changements » est ignoré. Ce sont les exemples mêmes de la doc officielle. Si une règle peut vouloir dire deux choses, ce n'est pas encore une règle. Et quand une règle n'est pas évidente, ajoute son pourquoi en une ligne : une règle motivée s'applique aux situations que tu n'avais pas prévues.

Les fichiers courts sont obéis, les longs sont survolés

Chaque ligne est relue à chaque session, donc chaque ligne coûte du contexte. La cible officielle : moins de 200 lignes par fichier. Au-delà, la doc est claire : plus de contexte consommé, moins de règles suivies. Le test pour chaque ligne : sans elle, Claude se tromperait-il ? Sinon, supprime-la.

Les niveaux s'additionnent, ils ne s'écrasent pas

Les trois fichiers se chargent dans la même session, concaténés. Si deux règles se contredisent, la doc officielle prévient : Claude peut en choisir une arbitrairement. Donc ne répète jamais une règle sur deux niveaux. Chaque règle vit à une seule altitude : la plus haute où elle reste vraie.

Un jardin, pas un monument

Quand Claude refait la même erreur une deuxième fois, ajoute une règle (c'est le critère officiel). Quand tu remarques qu'il fait déjà un truc sans qu'on lui dise, supprime la ligne. La commande /memory te liste à tout moment les fichiers chargés dans ta session. Ces fichiers rapportent session après session, mais seulement si tu les tailles.

Le bémol honnête. Écrire la façon de penser d’un grand modèle dans ces fichiers ne transforme pas un modèle moins cher en ce grand modèle : le raisonnement en direct ne se met pas en fichier. Ce que tu gardes, c’est le jugement : les standards, la structure, la façon de découper les problèmes. En pratique, c’est une part surprenante de ce qui rendait le grand modèle « intelligent ». Et souviens-toi que CLAUDE.md reste du contexte, pas une loi : pour interdire vraiment une action, la doc renvoie vers les hooks.

Savoir quoi mettre dans ces fichiers vient avec la pratique du pilotage d’IA : cadrer, déléguer, vérifier. C’est exactement ce qu’on installe, pas à pas, dans la formation Agentic eSchool.

À retenir