Tu installes Claude Code, tu lui demandes de corriger un bug, et il réécrit la moitié du projet. Tu lui répètes la même consigne trois fois par jour. Le problème n'est presque jamais le modèle : c'est qu'il ne sait rien de ton projet ni de ta façon de travailler au moment où tu ouvres le terminal.

Le fichier CLAUDE.md sert exactement à ça. C'est un simple fichier texte que Claude Code lit automatiquement à chaque démarrage de session, avant même ta première question. Tu y écris tes règles, ta stack technique, tes commandes de test, tes interdits. Bien rédigé, il transforme un assistant bavard en collègue qui connaît déjà la maison.

Tu vas voir où le placer, comment le créer (trois méthodes), les sept règles d'écriture qui font qu'une consigne est suivie plutôt qu'ignorée, un exemple complet que tu peux copier, et la façon de vérifier que Claude Code obéit vraiment. Aucune compétence avancée en développement n'est nécessaire : un éditeur de texte suffit.

À quoi sert vraiment le fichier CLAUDE.md

Le fichier CLAUDE.md est un mémo permanent que Claude Code charge dans sa mémoire de travail au début de chaque session, sans que tu aies à le coller toi-même.

La différence avec une consigne tapée dans le chat est simple : ta consigne vaut pour une conversation, le CLAUDE.md vaut pour toutes. Si tu écris « lance toujours les tests avant de dire que c'est terminé » dans le fichier, la règle s'applique lundi comme jeudi, sur une session neuve, sans que tu y penses.

Concrètement, on y met quatre familles d'informations :

• Le contexte du projet : à quoi sert l'application, qui l'utilise, quelle est la stack (langage, framework, base de données).
• Les commandes utiles : comment installer les dépendances, lancer les tests, démarrer le serveur, formater le code. Claude Code perd beaucoup de temps à deviner ces commandes s'il ne les a pas.
• Les conventions : nommage des fichiers, style de commit, structure des dossiers, langue des commentaires.
• Les interdits : ce qu'il ne doit jamais faire (toucher au dossier de production, modifier les fichiers générés automatiquement, installer une nouvelle dépendance sans demander).

Un point que beaucoup découvrent trop tard : chaque ligne de ce fichier est relue à chaque session et consomme une partie du budget de contexte. Un CLAUDE.md de 400 lignes floues est moins efficace qu'un fichier de 80 lignes précises. La concision n'est pas une coquetterie de style, c'est une contrainte technique.

Si tu débutes complètement avec l'outil, commence par le tutoriel Claude Code pour débutants puis reviens ici : le CLAUDE.md prend tout son sens une fois que tu as fait tes premières sessions.

Où placer ton fichier CLAUDE.md (et lequel l'emporte)

Tu peux placer un CLAUDE.md à plusieurs endroits à la fois : ils s'additionnent, et le plus proche du code que tu modifies pèse le plus lourd.

Emplacement	Portée	Quand l'utiliser
~/.claude/CLAUDE.md	Tous tes projets	Tes préférences personnelles de travail (langue, style de réponse, habitudes)
CLAUDE.md à la racine du projet	Toute l'équipe	Stack, commandes, conventions, interdits. Versionné avec Git
CLAUDE.md dans un sous-dossier	Ce dossier	Règles spécifiques à une partie du code (API, front, scripts)

Le fichier à la racine du projet est celui qui compte le plus. Comme il est versionné avec le reste du code, toute l'équipe travaille avec les mêmes règles, et un nouveau venu hérite du contexte en clonant le dépôt.

Deux raccourcis à connaître tout de suite. La commande /memory ouvre tes fichiers de mémoire pour les éditer directement depuis le terminal. Et en commençant un message par le caractère #, tu demandes à Claude Code d'ajouter lui-même la règle au fichier de ton choix : pratique pour capturer une consigne au moment exact où tu la formules. Tu peux aussi importer un autre fichier dans ton CLAUDE.md avec la syntaxe @chemin/vers/fichier.md, utile pour éviter de dupliquer une documentation déjà existante. Les emplacements et la syntaxe complète sont décrits dans la documentation officielle de la mémoire de Claude Code.

En cas de contradiction entre deux fichiers, la règle la plus spécifique gagne en pratique. Évite quand même de te contredire : si ton fichier personnel dit « réponds en anglais » et celui du projet « réponds en français », tu obtiendras des résultats instables d'une session à l'autre.

Trois façons de créer ton fichier CLAUDE.md

Tu peux te former avec un accompagnement structuré, laisser Claude Code générer un premier jet avec sa commande native, ou partir d'une page blanche. Les trois fonctionnent, elles ne demandent simplement ni le même temps ni le même niveau de départ.

Méthode 1 : te former avec Skilzy

C'est la voie la plus rapide si tu pars de zéro et que tu veux un fichier qui tient la route dès la première semaine. Le programme Claude Code et vibe coding de Skilzy te fait construire ton CLAUDE.md sur ton propre projet, étape par étape : installation, premières sessions, rédaction des règles, vérification qu'elles sont bien suivies. Tu ne recopies pas un modèle générique, tu écris le tien.

L'atout concret, c'est le Lab IA intégré : tu utilises les vrais outils d'IA depuis la plateforme, crédits inclus, sans empiler les abonnements pendant l'apprentissage. Skilzy couvre plus de 15 programmes (images, vidéo, musique, automatisation avec n8n, rédaction de prompts, code avec l'IA) et propose deux certifications reconnues par l'État et finançables, la RS7439 en marketing de contenus IA et la RS6792 en IA et vente. L'accès démarre à 29,90 € par mois, sans engagement.

Pour tester avant de payer, la démo découverte donne 7 jours avec 1 image, 1 vidéo, 1 musique et 10 messages, sans carte bancaire. Tu crées un compte, c'est tout.

Méthode 2 : la commande /init de Claude Code

Claude Code sait générer un premier CLAUDE.md tout seul. Tu ouvres le terminal à la racine de ton projet, tu lances Claude Code, tu tapes /init et tu valides. Il parcourt l'arborescence, repère la stack, les scripts disponibles et les conventions apparentes, puis écrit un fichier à la racine.

C'est gratuit, immédiat, et c'est un excellent point de départ. Ses limites sont réelles : le fichier généré décrit ce qu'il voit, pas ce que tu veux. Il ne connaît ni tes interdits, ni les pièges du projet, ni le fait que tel dossier ne doit jamais être touché. Considère /init comme un brouillon à relire ligne par ligne et à compléter à la main. La commande fait partie des 20 commandes Claude Code à connaître si tu veux le reste du panorama.

Méthode 3 : écrire le fichier à la main

Tu crées un fichier nommé CLAUDE.md à la racine de ton projet avec ton éditeur, et tu le remplis. Cette voie demande le plus de recul, mais elle produit le fichier le plus propre, parce que chaque ligne est là pour une raison que tu peux expliquer. C'est aussi la bonne approche pour un projet très particulier, où la structure automatique détectée par /init serait trompeuse.

En pratique, la plupart des gens combinent : /init pour le squelette, puis un nettoyage à la main.

Les sept règles d'écriture qui font la différence

Une instruction est suivie quand elle est courte, impérative et vérifiable ; elle est ignorée quand elle ressemble à une intention générale.

1. Une règle par ligne, à l'impératif. « Lance npm test avant de déclarer une tâche terminée » fonctionne. « Il faudrait idéalement penser à la qualité » ne veut rien dire d'actionnable.
2. Rends chaque règle vérifiable. Mets des noms de fichiers, des chiffres, des commandes exactes. « Garde les composants sous 200 lignes » est mesurable, « fais des composants courts » ne l'est pas.
3. Dis ce qu'il faut faire, pas seulement ce qu'il faut éviter. Remplace « n'utilise pas de requêtes SQL concaténées » par « utilise toujours des requêtes paramétrées ». Une consigne positive donne une direction, une interdiction seule laisse le champ libre.
4. Donne les commandes réelles du projet. Installation, tests, lint, build, démarrage local. C'est la section qui fait gagner le plus de temps, parce qu'elle supprime les tâtonnements en début de session.
5. Mets les interdits absolus en haut, dans une section courte. Trois à cinq lignes maximum, clairement identifiées. Noyés au milieu de quarante recommandations, ils passent à la trappe.
6. Garde le fichier court. Vise 50 à 150 lignes. Au-delà de 250, tu dilues tes propres priorités et tu consommes du contexte pour rien. Si une section devient énorme, sors-la dans un fichier dédié et importe-la avec @.
7. Explique le pourquoi en une demi-ligne quand la règle est contre-intuitive. « Ne modifie jamais schema.generated.ts : il est régénéré à chaque build. » Une raison courte évite que la règle soit contournée par bonne volonté.

Un exemple de CLAUDE.md commenté

Voici une structure complète que tu peux adapter en dix minutes à ton propre projet.

Projet : Boutique en ligne (Next.js + Supabase)

Interdits

• Ne touche jamais au dossier /migrations sans mon accord explicite.
• N'installe aucune nouvelle dépendance sans me demander d'abord.
• Ne commit jamais de clé API : utilise les variables d'environnement.

Commandes

• Installer : pnpm install
• Démarrer en local : pnpm dev (port 3000)
• Tests : pnpm test (Vitest)
• Lint : pnpm lint --fix

Conventions

• Composants React en PascalCase, un composant par fichier.
• Commentaires et messages de commit en français.
• Messages de commit au format type(scope): description.
• Les appels à la base passent par lib/db.ts, jamais directement depuis un composant.

Façon de travailler

• Avant une tâche de plus de trois étapes, propose un plan et attends ma validation.
• Lance pnpm test avant d'annoncer qu'une tâche est terminée. Si un test échoue, dis-le avec la sortie.
• Fais le changement le plus simple qui fonctionne. Pas de refactorisation non demandée.

Quatre sections, une quinzaine de lignes utiles. Tu peux repartir de ce squelette et remplacer chaque ligne par la réalité de ton projet. Résiste à l'envie d'ajouter tout ce qui te passe par la tête : ajoute une règle le jour où tu constates qu'elle manque.

Les erreurs qui font ignorer tes instructions (et comment vérifier)

Les instructions mal suivies viennent presque toujours d'un fichier trop long, trop vague, ou contradictoire avec un autre fichier de mémoire.

Les cas les plus fréquents :

• Le roman-fleuve. Trois cents lignes de bonnes intentions. Claude Code lit tout, mais rien ne ressort comme prioritaire.
• Les consignes non testables. « Écris du code de qualité professionnelle » ne produit aucun comportement observable.
• Le fichier copié d'un autre projet. Il mentionne des commandes qui n'existent pas, ce qui provoque des erreurs en cascade au démarrage.
• Le fichier jamais mis à jour. Tu as changé de gestionnaire de paquets il y a six mois, le CLAUDE.md dit encore npm.
• La contradiction global / projet. Ton fichier personnel et celui de l'équipe se disputent sur la même règle.

Pour vérifier que tout est bien chargé, trois gestes simples. Tape /memory pour voir les fichiers effectivement pris en compte. Ouvre une session neuve et demande : « Résume en cinq points les consignes que tu suis sur ce projet. » Si ton interdit principal n'apparaît pas, il est mal placé ou mal formulé. Enfin, teste une tâche piège : demande quelque chose qui frôle un interdit et regarde s'il s'arrête pour demander confirmation.

Dernier point important : le CLAUDE.md est une consigne, pas une barrière technique. Pour les règles qu'aucun oubli ne doit briser (bloquer une commande dangereuse, formater systématiquement après chaque écriture de fichier), passe par le mécanisme des hooks de Claude Code, qui s'exécutent de façon déterministe, et par les réglages décrits dans la documentation des paramètres et permissions.

Le mot de la fin

Un bon CLAUDE.md se construit par petites touches : tu commences avec quinze lignes, et chaque fois que tu corriges Claude Code deux fois sur la même chose, tu ajoutes la règle manquante. Au bout de deux semaines, tu as un fichier qui reflète vraiment ta façon de travailler, et des sessions où tu répètes trois fois moins.

Commence aujourd'hui : crée le fichier, mets tes trois interdits et tes quatre commandes. Le reste viendra tout seul.