CLAUDE.md et le Plan Mode

Nous voici arrivés aux vrais trésors ! Ces deux fonctionnalités séparent le simple bavardage avec une IA du vibecoding professionnel avec Claude Code.

CLAUDE.md - le coeur du projet

Le fichier le plus important dans ton travail avec Claude Code s'appelle CLAUDE.md : un fichier markdown de mémoire du projet, posé dans le dossier racine, que Claude charge automatiquement au début de chaque session. C'est ta carte, remise au navigateur avant même qu'il pose le pied sur le pont - il connaît le cap avant la première manoeuvre.

Ne te trompe pas sur sa nature : ce n'est pas un fichier de config npm qui remplacerait package.json, ce n'est pas un journal des erreurs du compilateur TypeScript, et encore moins un fichier binaire contenant le modèle Claude. C'est de la mémoire, écrite en markdown, lisible par toi comme par l'IA.

Que mettre dans CLAUDE.md ?

• Les conventions - comment nommer les fichiers, quel style de code, comment formater
• L'architecture - la structure des dossiers, les modules clés
• Les commandes - comment lancer le projet, les tests, le linter, le build

Comment le générer ?

Le plus simple, c'est de laisser Claude le faire pour toi. Tape dans une session :

1# Dans une session claude
2/init

Quatre étapes s'enchaînent alors, toujours dans le même ordre : tu tapes la commande /init dans une session, Claude analyse la structure du projet, un fichier CLAUDE.md prêt à l'emploi est créé dans le dossier racine, et Claude le charge automatiquement à chaque session suivante. Tu peux ensuite le retoucher à la main, ou depuis la session avec la commande /memory - c'est bien /memory qui édite la mémoire du projet, et non /save ou /file, qui n'existent pas dans Claude Code, ni /context, qui montre seulement le contexte occupé.

La hiérarchie des fichiers CLAUDE.md

Claude ne lit pas un seul fichier mais toute une hiérarchie, du plus global au plus spécifique :

• ~/.claude/CLAUDE.md - global, il agit dans tous les projets
• CLAUDE.md - dans le dossier racine du projet
• CLAUDE.md dans un sous-dossier du projet - pour une partie précise du code

Plus un fichier est proche du code concerné, plus ses règles sont précises. Claude ne choisit pas un seul fichier : il les ajoute tous au contexte, du plus général au plus proche, et ne charge celui d'un sous-dossier que lorsqu'il lit des fichiers de ce sous-dossier. Si deux fichiers se contredisent, Claude peut suivre l'un ou l'autre, alors veille à ce que les niveaux restent cohérents. Voici à quoi ressemble un CLAUDE.md de projet : le titre ouvre le fichier, puis viennent la stack, les commandes et enfin les conventions.

1# My Project - Online Store
2
3## Stack
4- Next.js + TypeScript
5- Tailwind CSS
6- Prisma + PostgreSQL
7
8## Commands
9- npm run dev - dev server
10- npm test - tests
11- npm run lint - linter
12
13## Conventions
14- Components: PascalCase in src/components/
15- Always add TypeScript types
16- Tests next to files, in __tests__/

Quatre sections, dans cet ordre : le titre du projet, ## Stack qui dit avec quoi il est construit, ## Commands qui donne les commandes à lancer, ## Conventions qui fixe les règles d'écriture. Rien d'exotique - c'est du markdown que tu relirais toi-même avec plaisir six mois plus tard.

Le Plan Mode - la puissance la plus récente

C'est l'une des fonctionnalités les plus récentes et les plus importantes de Claude Code. En Plan Mode, Claude explore d'abord le projet et présente un plan, et ne modifie les fichiers qu'après ton approbation.

Idéal pour les changements gros et risqués : tu vois ce que Claude compte faire AVANT qu'il ne touche à une seule ligne. Il ne supprime rien pour repartir de zéro, ce n'est pas un mode hors ligne qui tournerait sans modèle, et ce n'est évidemment pas un raccourci pour ouvrir un calendrier.

Comment activer le Plan Mode ?

Trois chemins mènent au même endroit :

1. La touche Shift+Tab - elle fait défiler les modes de permission dans la session, et l'un d'eux est justement le Plan Mode
2. La commande /plan tapée devant ta demande, par exemple /plan rebuild the auth system
3. Un flag au démarrage :

1claude --permission-mode plan "Rebuild the auth system to use JWT"

Retiens l'ordre exact des éléments : d'abord claude, puis --permission-mode, puis plan, et enfin le prompt entre guillemets. Le flag s'appelle bien --permission-mode plan - ni --temperature plan, ni --glob plan, ni --output plan, qui n'existent tout simplement pas.

Les modes de permission

Claude Code possède plusieurs modes qui décident de son autonomie. Voici les quatre modes de base, classés du plus prudent au plus autonome :

• plan - il explore et planifie, sans modifier ton code tant que tu n'as pas validé le plan
• default (affiché comme Manual) - il lit sans demander, mais demande ton accord avant les modifications et les commandes
• acceptEdits - il accepte automatiquement les modifications de fichiers
• bypassPermissions - il ignore les demandes de permission (seulement dans un conteneur ou une machine virtuelle !)

Deux autres modes complètent la liste : auto, où un second modèle (un classificateur) évalue les actions à ta place, et c'est dans ce mode que les versions récentes démarrent une session dans le terminal ; et dontAsk, qui refuse tout ce qui demanderait normalement ton accord (pratique en CI). Tu passes de l'un à l'autre à la volée avec Shift+Tab, ou dès le lancement avec le flag --permission-mode.

Le workflow du Plan Mode

En pratique, une grosse fonctionnalité se déroule toujours en quatre temps :

1# 1. Active le Plan Mode
2claude --permission-mode plan "Add a shopping cart to the store"
3
4# 2. Claude explore le projet et presente un PLAN :
5#    - quels fichiers il va creer
6#    - quels fichiers il va modifier
7#    - dans quel ordre
8
9# 3. Tu lis le plan et tu le valides
10
11# 4. Alors seulement, Claude modifie le code

Cet ordre ne change jamais : activer le Plan Mode, laisser Claude explorer et présenter son plan de changements, lire et approuver, puis laisser le code bouger. L'étape de lecture est ton meilleur filet : une erreur repérée dans un plan te coûte trente secondes, la même erreur repérée dans quinze fichiers déjà modifiés te coûte la soirée.

Réglages et permissions (settings.json)

Le comportement de Claude Code se pilote par des fichiers de réglages :

• .claude/settings.json - les réglages du projet (commités dans le repo)
• .claude/settings.local.json - tes réglages privés pour ce projet (hors de Git)
• ~/.claude/settings.json - les réglages globaux

C'est dans .claude/settings.json que tu définis les règles de permission du projet, sous forme de motifs allow/deny. Il n'existe ni .claude/temperature.json ni claude.config.js, et tsconfig.json reste le fichier de TypeScript : il ne sait rien de Claude. Voici le contenu du fichier .claude/settings.json (c'est du JSON strict, donc pas de commentaires dedans) :

1{
2  "permissions": {
3    "allow": [
4      "Bash(git *)",
5      "Bash(npm run test)"
6    ],
7    "deny": [
8      "Bash(rm -rf *)"
9    ]
10  }
11}

Lis un motif comme Bash(git *) de gauche à droite : le nom de l'outil Bash, une parenthèse ouvrante, le motif git *, une parenthèse fermante. L'espace avant l'étoile compte : git * correspond à git status et à git log, mais pas à gitk. Résultat : les commandes git s'exécutent sans que Claude demande quoi que ce soit, tandis que la règle deny bloque rm -rf dans tous les modes - retiens seulement qu'elle compare le texte à la lettre, donc rm -fr est pour elle une autre commande. Dans ces mêmes réglages tu peux aussi définir des variables d'environnement, le modèle par défaut et des hooks - on en reparle dans le prochain exercice.

Travailler avec de nombreux fichiers

Une carte au trésor ne se lit pas page par page au hasard. Quand tu veux passer en revue tout un dossier, deux approches marchent : une boucle for en bash qui appelle claude -p pour chaque fichier, ou plusieurs fichiers passés via @ dans un seul prompt.

1# Fichier par fichier, en boucle bash
2for file in src/*.ts; do
3  claude -p "Review $file"
4done
5
6# Ou plusieurs fichiers dans un seul prompt, avec @
7claude -p "Compare @src/old-api.ts and @src/new-api.ts"

La boucle donne une réponse séparée par fichier, le prompt unique donne une vision d'ensemble - à toi de choisir selon la question posée. Méfie-toi en revanche des vieux tutoriels : il n'existe aucun flag --glob qui traiterait tous les fichiers d'un coup, et le traitement en lot fonctionne parfaitement dès que tu passes par la boucle ou par @. La même astuce - claude -p branché dans un script - se cache derrière les exercices pratiques qui t'attendent : un générateur de messages de commit, une fabrique de composants et une recherche de code qui comprend des phrases ordinaires au lieu d'expressions régulières.

Deux de ces scripts reçoivent des arguments depuis la ligne de commande. Quand tu lances ./generate-component.sh Button, le mot Button arrive dans la variable $1, et tous les mots tapés après le nom du script arrivent ensemble dans "$*". Il te suffit de placer une telle variable dans la consigne pour Claude :

1NAME=$1
2claude -p "Create the React component $NAME in TypeScript and save it in src/components/$NAME.tsx,
3  tests in src/components/$NAME.test.tsx and stories in src/components/$NAME.stories.tsx" \
4  --permission-mode acceptEdits

Un fichier .stories.tsx décrit les variantes d'un composant pour Storybook, un outil qui affiche les composants de façon isolée. La recherche se construit de la même manière : claude -p "Find the code in this project that deals with: $*" transmet à Claude toute la phrase tapée après le nom du script, et Claude parcourt lui-même les fichiers, puisqu'en mode -p il peut lire sans demander.

Gérer le contexte dans les longues sessions

Plus la conversation s'allonge, plus tu consommes de contexte. Deux commandes t'évitent de saturer la cale :

1# Efface le contexte et repart de zero
2/clear
3
4# Resume la conversation et poursuit la session
5/compact

/clear réinitialise le contexte et te rend une page blanche ; /compact résume la conversation et poursuit la session, en gardant l'essentiel tout en économisant des tokens. En plus, /context te montre la place que la conversation occupe dans le contexte, sans rien effacer (/context show et /context clear n'existent pas). Le contexte se gère donc très bien, et redémarrer le terminal ne sert à rien.

Pour savoir ce que tout cela te coûte, une seule commande :

1# Cout de la session et limites du forfait
2/usage

/usage (ou /cost, qui en est aujourd'hui un alias) affiche le coût de la session en cours et, sur les forfaits Pro, Max, Team et Enterprise, les limites d'utilisation de ton forfait. Ni /save ni /file ne te montreront la note (ces commandes n'existent pas), pas plus que /context, qui compte seulement le contexte occupé. Prends l'habitude de lancer /usage avant de quitter le bord : c'est le journal qui t'apprend quelles habitudes coûtent cher.

Récapitulatif

CLAUDE.md - la mémoire du projet, chargée automatiquement ; génère-la avec /init, édite-la avec /memory La hiérarchie - global ~/.claude/CLAUDE.md, puis racine du projet, puis sous-dossiers Plan Mode - Claude planifie avant de modifier ; Shift+Tab, /plan ou --permission-mode plan Les modes de permission - plan / default / acceptEdits / auto / dontAsk / bypassPermissions settings.json - les règles allow/deny (par exemple Bash(git *)), les variables d'environnement, le modèle Plusieurs fichiers - boucle for avec claude -p, ou références @ dans un seul prompt Le contexte - /clear, /compact, un coup d'oeil avec /context, et le coût avec /usage

Dans les deux derniers exercices, tu découvriras les subagents, les skills, MCP et les hooks - c'est-à-dire ce qui est vraiment nouveau dans Claude Code !

À très vite !

1#!/bin/bash
2# CLAUDE.md - la mémoire du projet dans Claude Code
3
4# Le plus simple : laisse Claude générer CLAUDE.md pour toi.
5# Dans une session 'claude', tape la commande :
6#   /init
7
8# Claude analyse le projet et crée un CLAUDE.md prêt à l'emploi.
9# Tu peux ensuite le modifier à la main, ou avec la commande /memory.
10
11# La hiérarchie des fichiers CLAUDE.md (du plus général) :
12#   ~/.claude/CLAUDE.md         - global, pour tous les projets
13#   CLAUDE.md                   - dans le dossier racine du projet
14#   src/.../CLAUDE.md           - imbriqué, pour une partie du projet
15
16# Claude charge CLAUDE.md AUTOMATIQUEMENT au début de chaque session,
17# donc il connaît tout de suite tes conventions, ton architecture et tes commandes.
18# Les fichiers ne se remplacent pas : tous arrivent dans le contexte, et celui
19# d'un sous-dossier se charge quand Claude travaille dans ce sous-dossier.
20
21echo "Tape /init dans une session claude pour générer CLAUDE.md"