Claude Code oublie tout entre deux sessions — sauf ce que vous écrivez dans CLAUDE.md. C'est le fichier qu'il lit au démarrage : vos conventions, vos commandes de build, vos garde-fous. La mémoire persistante d'un agent, c'est d'abord ça.
La hiérarchie
Plusieurs CLAUDE.md se cumulent, du plus général au plus spécifique. Une politique managée d'organisation d'abord, puis vos règles perso, puis le projet, puis vos overrides locaux. Le plus spécifique précise sans écraser le reste.
- ~/.claude/CLAUDE.md — vos règles perso, valables sur tous les projets.
- ./CLAUDE.md ou ./.claude/CLAUDE.md — les instructions du projet, versionnées et partagées.
- ./CLAUDE.local.md — vos overrides personnels sur ce projet, à mettre dans le .gitignore.
Découper avec des rules
Un CLAUDE.md qui dépasse 200 lignes est moins bien suivi : trop long, jamais complet. Cassez-le en fichiers .claude/rules/*.md. Mieux : une règle path-scoped ne se charge que quand Claude touche les fichiers concernés, ce qui évite le bruit.
---
paths:
- "src/api/**/*.ts"
- "**/*.test.ts"
---
# Règles API
- Toute route valide ses entrées avec un schéma strict.
- Format d'erreur standardisé sur toutes les réponses.
- Pas de secret en dur, jamais.Auto memory
En complément, Claude note lui-même des apprentissages entre sessions — commandes de build, pièges de debug, préférences — sans que vous les écriviez. C'est actif par défaut. Un bon réflexe en début de session : « consulte ta mémoire pour les patterns pertinents ».
Écrire des règles qui tiennent
- Courtes et impératives : une convention par ligne, pas un paragraphe.
- Path-scoped quand c'est local : une règle d'API ne devrait charger que dans src/api.
- CLAUDE.md sous 200 lignes : le reste part dans .claude/rules/.
- Jamais de secret : ces fichiers sont lus à chaque session et souvent versionnés.
Un bon CLAUDE.md ne raconte pas votre projet, il cadre l'agent. Chaque ligne doit changer ce que Claude fait — sinon c'est du contexte gaspillé.