Maîtriser Claude Code — De zéro à 10x — 8. CLAUDE.md : la mémoire qui se compose

18 min read min de lecture
Chapitre 08

CLAUDE.md : la mémoire qui se compose

Chapitre 8 sur 10 · 80%

Objectifs de ce chapitre

  • Comprendre le problème de la session vierge
  • Créer un CLAUDE.md qui codifie ton projet
  • Faire évoluer cette mémoire dans le temps

Le problème de la session vierge

À chaque nouvelle session, Claude repart de zéro. Tu réexpliques le projet, les conventions, où sont les fichiers, comment référencer la clé API… C'est une perte de temps répétée, mais c'est pire que ça : c'est une perte de fiabilité. Un jour tu oublies de mentionner une convention, et Claude affiche une clé API en clair dans une commande ou range un fichier au mauvais endroit. La qualité de ton système dépend alors de ta mémoire du moment — exactement ce qu'on cherche à éliminer depuis le début du cours.

La solution s'appelle CLAUDE.md. C'est un fichier à la racine de ton projet que Claude Code lit au démarrage de chaque session, avant même ton premier message. Tout ce que tu y mets devient du contexte persistant : Claude le connaît avant que tu parles. C'est la différence entre un intérimaire qu'on rebriefe chaque matin et un collaborateur qui connaît la maison.

Une mémoire à plusieurs étages

CLAUDE.md n'existe pas qu'à la racine du projet. Claude Code lit en réalité une hiérarchie de fichiers mémoire, du plus général au plus spécifique : ton fichier personnel ~/.claude/CLAUDE.md (tes préférences valables dans tous tes projets — langue, style de réponse, conventions personnelles), le CLAUDE.md du projet (versionné dans Git, partagé avec l'équipe), et d'éventuels CLAUDE.md dans des sous-dossiers pour les règles propres à une partie du projet.

  • ~/.claude/CLAUDE.md — tes préférences personnelles, tous projets confondus.
  • CLAUDE.md à la racine du projet — conventions et contexte du projet, partagés via Git.
  • sous-dossier/CLAUDE.md — règles spécifiques à une zone, chargées quand Claude y travaille.

Cette hiérarchie répond à la question « où mettre quoi ». La règle est la même qu'au chapitre 3 pour les skills : ce qui est personnel va chez toi, ce qui appartient au projet va dans le projet. « Réponds-moi toujours en français » → personnel. « La clé API se référence via le fichier .env, jamais en clair » → projet.

Créer ton CLAUDE.md

Deux chemins possibles. Le premier : la commande /init, qui analyse ton projet et génère un premier CLAUDE.md — c'est le bon réflexe sur un projet existant que Claude ne connaît pas. Le second, plus précis pour notre cas : demander à Claude de codifier ce que vous avez construit ensemble, puisqu'il a tout le contexte. Colle ce prompt :

PROMPT
crée un fichier CLAUDE.md qui codifie tout ce qu'on a construit dans ce projet :
- lien vers la doc de l'API utilisée
- où se trouve la clé API et comment la référencer dans les commandes
- conventions de commandes (toujours inline, etc.)
- lien vers le fichier de voix de marque
- lien vers la config du quality gate
- lien vers le journal des posts
- tout autre pattern qu'on a établi

Claude parcourt le projet, rassemble les patterns récurrents qui ont bien marché, et les codifie. Désormais chaque session démarre avec tout le contexte : la structure du projet de Léa, ses conventions, ses garde-fous. Ouvre le fichier généré et lis-le — c'est la photographie de tout ce que tu as appris dans ce cours.

Ce qui va dans CLAUDE.md (et ce qui n'y va pas)

La tentation, une fois le mécanisme compris, est d'y mettre tout. Erreur : CLAUDE.md est chargé dans le contexte de chaque session, chaque mot a donc un coût permanent. Un fichier de 400 lignes encombre toutes tes conversations avec des détails inutiles 95% du temps — exactement le bruit qu'on combat depuis le chapitre 2. La cible : un fichier court et dense, où chaque ligne mérite d'être lue à chaque session.

Dans CLAUDE.mdLe permanent et transversal : conventions, structure du projet, liens vers les fichiers clés (brand-voice.md, journal), règles de sécurité (.env), commandes fréquentes.
Dans un skillLes procédures détaillées d’une tâche précise (/post, /plan-week) : chargées seulement quand on exécute cette tâche.
Nulle part (ou en référence)Les gros contenus (docs d’API complètes, listes d’échantillons) : on met un lien ou un chemin dans CLAUDE.md, Claude les lira à la demande.
Ne mets jamais de secret (clé API, mot de passe) dans CLAUDE.md — il est versionné dans Git et lu à chaque session. On y écrit est la clé (« dans .env, variable SOCIAL_API_KEY ») et comment la référencer, jamais sa valeur.

Le raccourci # : mémoriser à la volée

Maintenir cette mémoire ne doit pas être une corvée, sinon tu ne le feras pas. Claude Code a un raccourci dédié : commence un message par # et ce que tu écris est proposé à l'ajout dans la mémoire, sans interrompre ton travail. En pleine session, tu remarques que Claude a encore utilisé un format de date qui te déplaît ? Tape # les dates sont toujours au format JJ/MM/AAAA — la règle est capturée, la session continue.

L'autre mécanisme d'entretien, plus structurel : en fin de session de travail riche, demande « relis notre conversation et mets à jour CLAUDE.md avec les patterns qu'on a établis ». Claude extrait les décisions durables de la conversation et les fond dans la mémoire. C'est l'équivalent du compte rendu de réunion — dix secondes à demander, et rien ne se perd.

Le savoir qui se compose

Comme tes skills, ton CLAUDE.md évolue en continu — et c'est cette boucle qui change tout. Chaque session construit sur la précédente au lieu de repartir de zéro : c'est ainsi que ton expertise se compose dans le temps, au sens des intérêts composés. La plupart des gens utilisent l'IA de façon linéaire : 100 sessions, 100 fois le même niveau. Avec une mémoire entretenue, ta session 100 démarre avec le condensé des 99 précédentes.

flowchart LR
  S["Session de travail"] --> U["« mets à jour CLAUDE.md »"]
  U --> M["CLAUDE.md enrichi"]
  M -->|"Lu au démarrage"| N["Nouvelle session"]
  N --> S
La boucle de mémoire : chaque session démarre avec tout le contexte de la précédente.

Et la boucle se referme avec le chapitre 2 : tu peux maintenant faire /clear sans état d'âme. Le bruit conversationnel disparaît, l'essentiel revient par CLAUDE.md. Contexte propre et mémoire durable — les deux exigences qui semblaient contradictoires au début du cours sont réconciliées.

Et maintenant ?

Fais le bilan du système de Léa : un skill /post multi-plateforme avec sa voix de marque, un quality gate qui rend les erreurs publiques impossibles, des subagents qui publient en parallèle, une commande /plan-week qui orchestre la semaine, et une mémoire projet qui fait tenir le tout dans la durée. Léa tape une phrase ; le système fait le reste, sous son contrôle.

Pour aller plus loin, trois directions naturelles : brancher davantage d'outils externes via MCP (CRM, analytics, calendriers — la commande claude mcp add est ton point d'entrée), explorer le mode navigateur pour que Claude teste lui-même ce qu'il publie, et surtout : rejouer la méthode de ce cours sur un autre processus de ta vie professionnelle. La méthode — skill, garde-fou, parallélisation, validation, mémoire — est le vrai livrable de ce cours. Léa n'était que le prétexte.

Félicitations 🎉 — tu sais maintenant bâtir des frameworks réutilisables (skills, hooks, subagents, mémoire), pas juste lancer des prompts isolés. C'est exactement ce qui sépare un utilisateur occasionnel d'un utilisateur 10x.
🛠️ À toi de jouer

Contexte

Le système de Léa est complet et fonctionne — mais tout son savoir-faire vit encore dans la session en cours. Si elle ferme la fenêtre, le système reste, la connaissance s'évapore. Tu veux qu'il survive aux nouvelles sessions, qu'un éventuel collaborateur puisse le reprendre en clonant le repo, et qu'il s'améliore encore avec le temps. C'est le test final : une session vierge doit tout savoir.

Consignes

  1. Crée le CLAUDE.md avec le prompt fourni dans le chapitre.
  2. Ouvre le fichier et relis-le : vérifie qu’il référence la voix de marque, le quality gate et le journal, et qu’aucun secret n’y figure en clair.
  3. Ferme la session, rouvre-en une nouvelle, et demande « que sais-tu de ce projet ? ».
  4. Vérifie qu’il connaît la voix, le quality gate et le journal sans aucune réexplication.
  5. Lance un /post dans cette session vierge et vérifie que toutes les conventions sont respectées du premier coup.
  6. En cours de session, capture une nouvelle règle à la volée avec # (par exemple un format de date).
  7. Termine par « relis notre conversation et mets à jour CLAUDE.md » et observe ce que Claude juge digne d’être mémorisé.
Indice — Crée un raccourci qui recharge CLAUDE.md et résume l'état du projet en début de session : contexte instantané, zéro réexplication.

En résumé

  • CLAUDE.md est lu au démarrage de chaque session : contexte persistant, zéro rebriefing.
  • La mémoire est hiérarchique : ~/.claude/CLAUDE.md (personnel), racine du projet (partagé via Git), sous-dossiers (spécifique).
  • /init génère un premier CLAUDE.md sur un projet existant ; ici on codifie ce qu’on a construit ensemble.
  • Garde-le court et dense : chaque ligne coûte du contexte à chaque session — les gros contenus se référencent, ne se collent pas.
  • Jamais de secrets dedans : on écrit où est la clé et comment la référencer, pas sa valeur.
  • Le raccourci # capture une règle à la volée ; « mets à jour CLAUDE.md » en fin de session fait le compte rendu.
  • Mémoire durable + /clear sans regret : ton expertise se compose au lieu de repartir de zéro.
  • Le vrai livrable du cours : la méthode skill → hook → subagents → validation → mémoire, transposable à tout processus.

Quiz — vérifie ta compréhension

1. À quoi sert CLAUDE.md ?

Claude lit CLAUDE.md au démarrage de chaque session : il connaît ton projet d'emblée.

2. Comment maintenir CLAUDE.md utile dans le temps ?

Comme un skill, CLAUDE.md s'améliore en continu pour composer ton expertise.

3. Où mettre la préférence « réponds-moi toujours en français » ?

Ce qui est personnel et indépendant du projet va dans ta mémoire personnelle ; le CLAUDE.md du projet est partagé avec l'équipe via Git.

4. Pourquoi faut-il garder CLAUDE.md court et dense ?

Un CLAUDE.md obèse encombre toutes tes conversations de bruit. Les gros contenus se référencent par un lien ou un chemin, Claude les lira à la demande.

5. Que fait le raccourci # en début de message ?

Le # capture une règle à la volée (« # les dates au format JJ/MM/AAAA ») : la mémoire s'entretient sans friction.

6. Quelle information ne doit JAMAIS figurer dans CLAUDE.md ?

CLAUDE.md est versionné et lu partout : on y écrit où est la clé (.env) et comment la référencer, jamais sa valeur.

Auteur(s)

R

REHOUMA Haythem

Haythem Rehouma est un ingénieur et architecte IA et cloud, formateur et enseignant technique, avec un profil orienté IA médicale, AWS, MLOps, LLM/RAG et vision par ordinateur.