Aller au contenu principal

CLAUDE.md & fichiers de mémoire

Débutant

Si vous faites une chose pour rendre Claude Code meilleur, faites ceci. CLAUDE.md est un fichier en texte brut que Claude lit au début de chaque session — le briefing permanent de votre projet.

What you'll learn
  • Pourquoi CLAUDE.md est le réglage de Claude Code au plus fort impact
  • Comment la hiérarchie de mémoire fusionne du global au spécifique au projet
  • Comment générer un fichier de départ avec /init et l'élaguer
  • Ce qui a sa place dans CLAUDE.md — et ce qu'il faut en écarter
  • Comment les @imports vous permettent de référencer des docs sans les dupliquer

Pourquoi c'est le réglage au plus fort impact

Sans lui, vous réexpliquez votre projet à chaque session (« on utilise pnpm, les tests sont dans __tests__, ne touche pas à /generated… »). Avec lui, Claude sait déjà. De bonnes instructions ici améliorent toutes les interactions futures d'un coup.

La hiérarchie de mémoire

Claude Code lit la mémoire depuis plusieurs endroits et les fusionne, grosso modo du plus global au plus spécifique :

  • Mémoire utilisateur — vos préférences personnelles à travers tous les projets.
  • Mémoire de projet (./CLAUDE.md, versionnée) — comment fonctionne ce dépôt. Partagée avec votre équipe.
  • Imbriquée — déposez un CLAUDE.md dans un sous-dossier pour des règles qui ne s'appliquent qu'à cet endroit.
Connaissez vos couches de mémoire
Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 4

Générer un point de départ

Guided walkthrough1 of 3
  1. Claude inspecte le code et vous rédige automatiquement un CLAUDE.md.

Générer un brouillon de CLAUDE.md

/init

Récupérez un modèle prêt à l'emploi depuis Modèles de CLAUDE.md.

Ce qu'il faut y mettre

  • Ce qu'est le projet, en deux phrases.
  • La stack technique et comment lancer / tester / linter.
  • Les conventions que Claude ne peut pas déduire (nommage, structure, style de commit).
  • Garde-fous : « lancer les tests avant de déclarer terminé », « ne jamais modifier /vendor », « ne jamais commiter de secrets ».

Ce qu'il ne faut PAS y mettre

Watch out
  • Claude suit CLAUDE.md à la lettre — des instructions périmées, vagues ou irréalistes nuisent activement.
  • Décrivez comment le projet fonctionne réellement aujourd'hui ; court et vrai vaut mieux que long et aspirationnel.
  • Évitez les docs entiers collés (utilisez les @imports à la place), les secrets et les règles que vous ne suivez pas réellement.
  • Relisez-le périodiquement pour qu'il reste exact à mesure que le projet évolue.

Imports

Intégrez des docs existants au lieu de les dupliquer — par ex. référencez votre guide de style avec un import @path/to/file pour qu'il n'y ait qu'une seule source de vérité. Voir la documentation officielle de la mémoire pour la syntaxe exacte.

Pro tip
  • Une seule source de vérité : référencez un fichier avec les @imports plutôt que de coller son contenu dans CLAUDE.md.
  • Si un doc existe déjà, liez-le — ne le copiez pas. Les copies finissent périmées.

Vérifiez vos acquis

Vérifiez vos acquis

0/3
  1. Quel fichier Claude Code lit-il au début de chaque session comme briefing permanent de votre projet ?
  2. Que fait l'exécution de /init dans un projet ?
  3. Quelle est la façon recommandée d'inclure un gros doc existant comme un guide de style ?
Key takeaways
  • CLAUDE.md est le réglage au plus fort impact : il améliore toutes les sessions futures d'un coup.
  • La mémoire fusionne du global au spécifique : politique d'entreprise, puis fichiers CLAUDE.md utilisateur, de projet et imbriqués.
  • Commencez avec /init, puis élaguez le brouillon jusqu'à ce qui est réellement vrai.
  • Incluez le résumé du projet, les commandes lancer/tester/linter, les conventions et les garde-fous.
  • Gardez-le court et vrai — utilisez les @imports pour les gros docs, et ne commitez jamais de secrets.

Suite