Meilleures pratiques CLAUDE.md : 9 règles pour que Claude vous écoute vraiment (2026)

Meilleures pratiques CLAUDE.md : 9 règles pour que Claude vous écoute vraiment (2026)

La plupart des articles sur les meilleures pratiques CLAUDE.md vous donnent un modèle et s'arrêtent là — mais le fichier que vous avez écrit la semaine dernière est probablement déjà ignoré, et vous ne savez pas pourquoi. La solution, c'est rarement « ajouter plus de règles ». C'est souvent le contraire. Nous avons déployé Claude Code sur tous nos projets clients récents, et ces 9 règles sont celles qui changent vraiment la donne : une hiérarchie qui correspond à la façon dont Claude charge les fichiers, un budget d'instructions que vous ne pouvez pas dépasser, la décision AGENTS.md, et les six raisons pour lesquelles Claude abandonne silencieusement votre fichier en cours de session.

Points clés à retenir

• CLAUDE.md est la mémoire du projet chargée dans le contexte de Claude Code — gardez-le sous 200 lignes, sinon les règles commencent à disparaître.
• Les fichiers sont chargés de haut en bas : global, racine du projet, sous-répertoire (chargement différé), et CLAUDE.local.md (personnel, ignoré par git).
• Utilisez AGENTS.md si vous travaillez aussi avec Cursor ou Copilot ; créez un lien symbolique de CLAUDE.md vers AGENTS.md pour cibler les deux.
• Si Claude ignore votre fichier, dans 90 % des cas c'est une question de longueur, de formulation vague, ou d'une justification manquante.

Ce que CLAUDE.md fait réellement (et pourquoi ça compte)

En bref : CLAUDE.md est un fichier markdown que Claude Code lit comme mémoire du projet au début de chaque session. Ce n'est pas un prompt système, un hook ou une compétence — c'est du contexte consultatif qui oriente Claude vers les conventions de votre équipe. Pensez-y moins comme de la documentation et plus comme un fichier de configuration que votre pair programmeur IA lit vraiment.

Beaucoup d'équipes écrivent CLAUDE.md comme un README. C'est la première erreur. Un README explique le projet à des humains qui peuvent parcourir et ignorer des sections. CLAUDE.md est consommé en entier par Claude Code au démarrage de chaque session — chaque ligne coûte des tokens et de l'adhérence. C'est beaucoup plus proche d'un fichier de configuration ou d'un ensemble de fixtures de test que de la documentation.

Ce n'est pas non plus le seul moyen d'orienter Claude. Les hooks déclenchent des actions déterministes (formatage, blocage de commits). Les compétences regroupent des flux de travail réutilisables. CLAUDE.md se situe entre les deux en tant que contexte consultatif — Claude l'évalue, parfois l'ignore, et oublie certainement des parties si vous en écrivez trop. Cette distinction est le fondement de tout ce qui suit, et c'est pourquoi CLAUDE.md n'est qu'un outil dans la pratique plus large du context engineering, pas une solution miracle.

Règle n° 1 : Traitez-le comme du code, pas comme de la documentation. Versionnez-le. Passez-le en revue dans les pull requests. Élaguez-le comme vous refactoriseriez un module gonflé. D'après le guide CLAUDE.md d'Anthropic, le fichier est chargé avec la même priorité que n'importe quelle instruction système — ce qui signifie qu'une règle périmée d'il y a six mois continue d'influencer activement chaque réponse aujourd'hui.

Comment CLAUDE.md se charge : la hiérarchie à 4 niveaux

En bref : Claude Code charge CLAUDE.md depuis quatre niveaux : global (~/.claude/CLAUDE.md), racine du projet, CLAUDE.local.md pour les remplacements personnels, et les fichiers de sous-répertoires qui se chargent en différé uniquement quand Claude lit des fichiers dans ce répertoire. Les sous-répertoires adjacents ne voient jamais le CLAUDE.md des autres, ce qui garde la mémoire de Claude Code bien délimitée.

La hiérarchie est la partie la plus mal comprise de CLAUDE.md, et c'est là où aucun des cinq premiers résultats de recherche ne va en profondeur. Voici ce qui se passe réellement sous le capot :

Deux termes à bien mémoriser : chargement différé et isolation des voisins.

Le chargement différé signifie qu'un CLAUDE.md de sous-répertoire n'entre pas dans le contexte de Claude tant que Claude n'ouvre pas réellement un fichier dans ce répertoire. Si vous demandez « corrige le bug de connexion » et que Claude ne touche que backend/, votre frontend/CLAUDE.md ne se charge jamais. C'est bien — ça garde la fenêtre de contexte propre — mais ça piège les équipes qui placent des règles critiques dans des sous-répertoires en s'attendant à ce qu'elles s'appliquent toujours.

L'isolation des voisins en est le corollaire : frontend/CLAUDE.md et backend/CLAUDE.md ne se voient jamais. Ils partagent uniquement ce qui figure dans le fichier racine du projet. Donc si vos règles frontend contredisent vos règles backend, aucun problème. Si elles doivent partager une convention, remontez-la dans le fichier racine.

CLAUDE.local.md est la trappe de secours. Il est chargé mais pas versionné, parfait pour les remplacements du style « je préfère pnpm mais l'équipe s'est standardisée sur npm ». Le problème : il n'est pas automatiquement ignoré par git. Vous devez l'ajouter vous-même. Oubliez-le et vous commiterez vos règles personnelles dans le dépôt de l'équipe.

Règle n° 4 : Faites correspondre les instructions à l'endroit où Claude les lit vraiment. Les règles de style pour les composants React appartiennent à frontend/CLAUDE.md, pas à la racine. Les règles de migration de base de données appartiennent à backend/. La documentation sur la mémoire d'Anthropic (mise à jour en novembre 2025) le confirme — le comportement de chargement différé est intentionnel et structurellement important.

Quoi mettre dans CLAUDE.md (et quoi laisser dehors)

En bref : Dans CLAUDE.md, mettez tout ce que Claude ne peut pas déduire de votre code : les commandes de build, les conventions de nommage, les anti-patterns qui ont coûté cher à votre équipe, et le pourquoi derrière chaque règle. Dehors : tout ce qui est dans le README, tout ce qui figure dans package.json, et toute règle qui change chaque semaine. Les instructions Claude Code doivent être testables et précises.

Voici un CLAUDE.md minimal qui fait réellement son travail :

# Project: techsy-app

## Commands
- Build: `pnpm build` (Turbopack — Webpack flags don't apply)
- Test: `pnpm test --run` (we use Vitest, not Jest)
- Lint: `pnpm lint` (will fail CI on warnings, not just errors)

## Conventions
- Server components by default. Add `'use client'` only when truly needed.
  Why: we hit 8s LCP last quarter from over-clienting.
- Database access only via `lib/db/` helpers — never raw SQL in routes.
  Why: row-level security policies live in those helpers.
- Tests colocate as `*.test.ts` next to the file under test.

## Don'ts
- Don't add a new dependency without opening a PR comment first.
- Don't use `any` — use `unknown` and narrow.

## Where to look
- Schema: `db/schema.ts`
- Auth flow: `lib/auth/README.md`

Comparez maintenant avec la version anti-pattern que la plupart des équipes livrent :

# Project Rules

- Write clean, maintainable code.
- Follow best practices.
- Use TypeScript properly.
- Make sure tests pass.
- Be consistent with existing patterns.
- Document complex logic.

Le second fichier n'est pas faux. Il est juste inutile. Claude veut déjà écrire du code propre. « Sois cohérent » ne dit pas à Claude avec quel pattern être cohérent. Les exemples publics de Boris Cherny, ingénieur chez Anthropic, penchent fortement vers le premier style — des commandes concrètes, des outils nommés, et le pourquoi derrière les décisions qui ne sont pas évidentes à partir de la base de code seule.

Règle n° 2 : Soyez précis, pas aspirationnel. « Écrire du code propre » est aspirationnel. « Composants serveur par défaut ; n'ajoutez 'use client' que lorsque c'est vraiment nécessaire » est testable. La même discipline sous-tend un bon prompt engineering : des instructions précises et testables l'emportent sur les vagues aspirations, qu'elles vivent dans un prompt ou dans un CLAUDE.md.

Règle n° 3 : Expliquez pourquoi chaque règle est importante. Le « pourquoi » n'est pas du rembourrage — c'est ce qui permet à Claude de trancher les cas limites. Une règle avec une raison (« on a eu un LCP de 8s à cause de trop de composants client ») se généralise à des situations similaires. Une règle sans raison est ignorée dès que le contexte change. Ce schéma est également documenté dans le guide CLAUDE.md de Builder.io.

Pourquoi Claude ignore votre CLAUDE.md ? Le budget d'instructions

En bref : Claude n'est pas malveillant — il manque d'attention. Passé environ 80 lignes, vous constaterez des règles qui disparaissent ; passé 200 lignes, des blocs entiers sont ignorés ; passé 500 mots de règles denses, l'adhérence s'effondre. La solution est un budget d'instructions. Traitez chaque ligne comme un coût sur la mémoire de Claude Code et l'adhérence par règle.

Des recherches récentes confirment ce que les utilisateurs en production ne cessent de constater : le suivi des instructions se dégrade de façon non linéaire avec le nombre de règles. L'article arxiv 2507.11538 sur la capacité de suivi d'instructions montre que l'adhérence par règle diminue à mesure qu'on en empile davantage — et l'analyse de HumanLayer des CLAUDE.md en production aboutit au même constat.

En d'autres termes : chaque règle que vous ajoutez rend chaque autre règle légèrement moins susceptible d'être suivie. Un CLAUDE.md de 400 lignes n'est donc pas 4 fois plus efficace qu'un de 100 lignes. Il est souvent moins efficace, parce que les règles qui comptent vraiment se noient dans celles que vous avez écrites un vendredi il y a trois mois et que vous n'avez jamais supprimées.

Dans nos fichiers CLAUDE.md, tout ce qui dépasse la ligne 150 commence à perdre visiblement en adhérence. À la ligne 250, on a vu Claude sauter des sections entières. Donc on plafonne.

wc -l CLAUDE.md

C'est tout. Exécutez-le. Si vous êtes au-dessus de 200, vous avez dépassé votre budget. La règle stricte qu'on applique chez nos clients :

Traitez CLAUDE.md comme un budget de 200 lignes. Chaque ligne coûte de l'adhérence. Dépensez-la là où ça compte.

Règle n° 1 renforcée : Faites court. Sous 200 lignes. Sous 500 mots de règles denses. Si vous avez envie d'ajouter des règles d'automatisation (« toujours exécuter prettier après les modifications »), elles appartiennent probablement aux hooks Claude Code — les hooks sont déterministes et ne coûtent pas de tokens de budget d'instructions.

CLAUDE.md, AGENTS.md, .cursorrules ou copilot-instructions : que choisir ?

En bref : Si vous n'utilisez que Claude Code, CLAUDE.md suffit. Si vous utilisez deux ou plusieurs CLIs d'agents (Codex, Cursor, Copilot, Sourcegraph), passez à AGENTS.md et créez un lien symbolique de CLAUDE.md vers AGENTS.md. AGENTS.md est apparu fin 2025 comme standard inter-outils — la plupart des agents modernes reviennent dessus en dernier recours, donc un seul fichier alimente tous les écosystèmes.

C'est la question à laquelle aucun des cinq premiers résultats ne répond vraiment. Voici la matrice :

L'astuce du double ciblage tient en une ligne :

ln -s AGENTS.md CLAUDE.md

C'est tout. Désormais Claude Code, Codex et tout outil compatible AGENTS.md lisent le même fichier. Mettez-le à jour une seule fois, tous les agents en bénéficient. La spécification AGENTS.md est ouverte et intentionnellement minimale — c'est juste du markdown avec des sections conventionnelles.

Deux subtilités du monde réel. Premièrement : si votre équipe a un utilisateur avancé de Cursor, le .cursorrules de Cursor adopte une approche différente — fichier unique, pas de hiérarchie, format plus rigide. Certaines équipes gardent les deux : AGENTS.md pour les règles partagées, .cursorrules pour les spécificités Cursor. Deuxièmement : le .github/copilot-instructions.md de Copilot ne replie pas vers AGENTS.md, donc les équipes très orientées Copilot ont besoin d'un fichier séparé.

Si vous choisissez un stack d'agents de zéro, notre comparaison Claude Code vs Cursor vs Copilot couvre les compromis au niveau du harness. En résumé : la hiérarchie de Claude Code est la plus puissante pour les monodépôts, l'UX de Cursor gagne pour le travail solo, l'intégration IDE de Copilot reste la plus fluide pour une adoption progressive.

Règle n° 9 : Utilisez AGENTS.md si vous faites tourner plus d'un CLI d'agents. N'entretenez pas deux fichiers qui disent la même chose. Choisissez le fichier que la majorité de votre stack lit, et créez des liens symboliques pour les autres.

CLAUDE.md vs hooks vs compétences : le triangle de décision

En bref : CLAUDE.md = contexte consultatif. Hooks = actions déterministes. Compétences = capacités regroupées. Choisir le mauvais outil et vous brûlerez du budget d'instructions sur quelque chose qu'un hook devrait gérer, ou vous écrirez une règle CLAUDE.md pour quelque chose que seule une compétence peut accomplir. Ce triangle est le moyen le moins coûteux de garder CLAUDE.md léger.

Trois outils, trois rôles. L'erreur la plus fréquente : mettre « toujours exécuter prettier après avoir édité » dans CLAUDE.md. Claude le lit. Claude exécute parfois prettier. Vous êtes frustré. La solution est de déplacer cette ligne de CLAUDE.md vers un hook — parce que les hooks se déclenchent de façon déterministe à chaque fois, sans marge de manœuvre consultative.

Si une règle doit toujours se déclencher, elle appartient à un hook. Si c'est une préférence de style que Claude peut évaluer selon le contexte, elle appartient à CLAUDE.md. Si c'est un flux de travail multi-étapes avec des assets regroupés (modèles, scripts, prompts), elle appartient à une compétence.

Règle n° 8 : Choisissez correctement entre CLAUDE.md, hooks et compétences — mettre un hook dans CLAUDE.md est le gaspillage de budget d'instructions le plus courant. Configurez les actions déterministes avec les hooks Claude Code et empaquetez les flux de travail réutilisables comme des compétences Claude. Votre CLAUDE.md raccourcit, vos garde-fous se renforcent, et Claude arrête d'« oublier » les règles qui comptent.

Schémas pour monodépôts : CLAUDE.md imbriqué, @imports et .claude/rules/

En bref : Dans un monodépôt, gardez le CLAUDE.md racine minuscule — uniquement des pointeurs et des conventions partagées. Poussez les spécificités dans apps/*/CLAUDE.md pour que chaque sous-arbre ait des règles délimitées. Utilisez les @imports pour partager des fichiers de règles modulaires via .claude/rules/. C'est la divulgation progressive — Claude ne tire chaque partie que lorsque c'est pertinent.

Une arborescence CLAUDE.md typique pour un monodépôt :

.
├── CLAUDE.md                        # 30 lignes — pointe vers les sous-répertoires et les règles partagées
├── .claude/
│   └── rules/
│       ├── style.md
│       ├── testing.md
│       └── security.md
├── apps/
│   ├── web/
│   │   └── CLAUDE.md                # Règles spécifiques à Next.js
│   └── api/
│       └── CLAUDE.md                # Règles spécifiques à Fastify
└── packages/
    └── shared/
        └── CLAUDE.md                # Règles pour les auteurs de bibliothèques

La syntaxe @import permet au fichier racine d'intégrer des morceaux de règles partagées sans les répéter :

# Root CLAUDE.md

This is a Turborepo. See subdir CLAUDE.md for app-specific rules.

@import .claude/rules/style.md
@import .claude/rules/testing.md
@import .claude/rules/security.md

## Top-level commands
- `pnpm dev` runs all apps in parallel
- `pnpm test` runs every workspace's test script

C'est la divulgation progressive en pratique. Le fichier racine fait 30 lignes et sert de pointeur. Chaque CLAUDE.md de sous-répertoire ajoute 50 à 80 lignes de règles ciblées. Les fichiers .claude/rules/ contiennent des morceaux de conventions que plusieurs sous-répertoires peuvent importer. Rien n'est dupliqué, rien n'est oublié, et aucun fichier unique ne dépasse le budget d'instructions.

La règle de chargement différé mentionnée plus tôt est encore plus pertinente ici : quand Claude travaille sur apps/web/Button.tsx, il voit le fichier racine plus apps/web/CLAUDE.md plus les fichiers de règles importés via @import. Il ne voit pas apps/api/CLAUDE.md. C'est tout l'intérêt — les conventions backend ne polluent pas le contexte frontend, et votre fenêtre de contexte reste utilisable.

Règle n° 6 : Utilisez les @imports pour garder le fichier racine sous 200 lignes. Le guide Anthropic Best Practices for Claude Code traite cela comme le schéma standard pour les monodépôts. Les sous-agents héritent aussi du contexte CLAUDE.md parent, ce qui vaut la peine de savoir si vous imbriquez des flux de travail — consultez le context engineering pour voir comment cela interagit avec la conception des sous-agents.

6 raisons pour lesquelles Claude ignore votre fichier (et comment y remédier)

En bref : Quand Claude ignore CLAUDE.md, c'est presque toujours l'une de ces six causes : fichier trop long, formulation vague, justification manquante, compaction du contexte, fichier parent conflictuel, ou mauvais nom de fichier. Chacune a un remède en 60 secondes. Testez dans une session fraîche après chaque modification — c'est la règle n° 7.

1. Fichier trop long (>200 lignes / >500 mots)

Exécutez wc -l CLAUDE.md. Si c'est au-dessus de 200, élaguez sans pitié. Déplacez les règles d'automatisation vers des hooks. Déplacez les flux de travail vers des compétences. Découpez les morceaux partagés en .claude/rules/ et intégrez-les avec @import. La raison la plus fréquente pour laquelle Claude « a arrêté de suivre » vos règles est que le fichier est devenu trop long au fil du temps et que l'adhérence s'est effondrée silencieusement.

2. Formulation vague (« écrire du code propre »)

Remplacez chaque règle aspirationnelle par une règle précise et testable. « Sois cohérent » est invisible pour Claude. « Utilise les composants serveur par défaut ; n'ajoute 'use client' que pour les formulaires ou les interfaces interactives » est quelque chose que Claude peut réellement appliquer.

3. Justification manquante

Les règles sans raison ne se généralisent pas. Claude ne peut pas déduire quand assouplir la règle parce qu'il ne sait pas ce qu'elle protège. Chaque règle non évidente mérite une ligne : « on utilise unknown et non any parce qu'on a eu trois crashs en production à cause de réponses API typées en any le trimestre dernier. »

4. La compaction du contexte l'a éliminé

Les sessions longues déclenchent la compaction — Claude résume le contexte antérieur pour tenir dans la fenêtre, et le contenu CLAUDE.md est parfois résumé jusqu'à disparaître. Le remède : /clear après les grosses consommations de contexte, ou redémarrez la session complètement. C'est exactement ce que le ticket GitHub n° 17530 met en évidence régulièrement.

5. Conflit avec un CLAUDE.md parent

Le global dit « utilise 4 espaces ». La racine du projet dit « utilise 2 espaces ». Le sous-répertoire ne dit rien. Claude en choisit un — parfois le mauvais. Auditez ~/.claude/CLAUDE.md et la racine du projet pour détecter les contradictions. Le plus spécifique devrait l'emporter, mais seulement si vous le rendez explicite.

6. Mauvais emplacement ou casse du nom de fichier

Claude.md et CLAUDE.md sont des fichiers différents sur Linux et macOS. Idem pour claude.md et CLAUDE.md. Confirmez que le chemin est exactement ./CLAUDE.md (tout en majuscules), et que Claude Code est lancé depuis le répertoire qui le contient. Le ticket GitHub n° 668 regorge de cas où le fichier existait mais Claude ne le voyait pas à cause du chemin.

Règle n° 7 : Testez dans une session fraîche. Après toute modification de CLAUDE.md, ouvrez une nouvelle session et demandez à Claude de « résumer les règles dans CLAUDE.md ». Si le résumé rate quelque chose, le fichier ne fait pas son travail.

Votre premier CLAUDE.md en 10 minutes : la recette en 5 étapes

En bref : Exécutez /init pour générer une ébauche, élaghez-la pour garder 6 à 10 vraies règles avec leurs justifications, ajoutez 3 commandes que Claude devrait connaître, ajoutez 2 anti-patterns que votre équipe a déjà rencontrés, puis testez dans une session fraîche en demandant à Claude de résumer le fichier. Temps total : environ 10 minutes. Cette recette en 5 étapes est ce qu'on utilise le jour 1 de chaque nouveau dépôt.

1. Exécutez /init pour générer une ébauche. La commande /init de Claude Code scanne votre dépôt et écrit un CLAUDE.md de démarrage. Ne livrez pas ce qu'elle produit. La sortie de /init est un point de départ, pas un fichier fini — et franchement, la plupart de ce qu'elle génère peut être supprimé.

2. Élaguez jusqu'à 6–10 lignes de vraies règles avec justifications. Supprimez tout ce qui est générique. Supprimez tout ce qui est dans le README. Gardez uniquement les règles que Claude ne peut pas déduire du code lui-même.

3. Ajoutez 3 commandes que Claude devrait connaître. Build, test, lint. Incluez la commande exacte et tous les flags non évidents. Si vous utilisez Vitest et non Jest, dites-le.

4. Ajoutez 2 anti-patterns que cette équipe a rencontrés. Des vrais. « N'utilise pas any parce qu'on a eu trois crashs en production » l'emporte sur « utilise TypeScript correctement » à chaque fois.

5. Ouvrez une session fraîche et vérifiez. Demandez à Claude de « résumer les règles dans CLAUDE.md ». Si quelque chose manque, le fichier est trop long, trop vague, ou il manque un « pourquoi ». Corrigez et recommencez.

Règle n° 5 : Ne vous contentez pas du résultat de /init. /init est un point de départ, pas un fichier fini. Les 8 minutes que vous passez à le tailler et à ajouter des lignes « pourquoi » sont là où le fichier devient réellement utile.

FAQ

Qu'est-ce qu'un fichier CLAUDE.md ?

Un fichier CLAUDE.md est un fichier markdown que Claude Code lit comme mémoire du projet au début de chaque session. Il indique à Claude vos conventions, vos commandes et vos anti-patterns, pour qu'il n'ait pas à les deviner. Il fonctionne à quatre niveaux : global, racine du projet, sous-répertoire (chargé en différé), et un CLAUDE.local.md personnel que vous gardez ignoré par git.

Quelle doit être la longueur d'un fichier CLAUDE.md ?

Moins de 200 lignes et moins de 500 mots de règles denses. Au-delà de ces seuils, le suivi des instructions de Claude se dégrade — chaque règle que vous ajoutez rend chaque autre règle légèrement moins susceptible d'être suivie. Traitez-le comme un budget fixe. Si vous avez besoin de plus, découpez-le en fichiers CLAUDE.md de sous-répertoires et utilisez @import pour les morceaux partagés.

Où dois-je mettre CLAUDE.md ?

Le principal va à la racine de votre projet (./CLAUDE.md) et est versionné. Ajoutez des fichiers CLAUDE.md de sous-répertoires pour les règles spécifiques à chaque application dans les monodépôts. Mettez les préférences inter-projets dans ~/.claude/CLAUDE.md. Utilisez CLAUDE.local.md pour les remplacements personnels que vous ne voulez pas versionner — mais pensez à l'ignorer manuellement dans gitignore.

Pourquoi Claude ignore-t-il mon CLAUDE.md ?

Dans 90 % des cas, c'est l'une de ces trois choses : le fichier est trop long (plus de 200 lignes), les règles sont vagues (« écrire du code propre »), ou des règles manquent d'un « pourquoi » que Claude peut utiliser pour les appliquer. Exécutez wc -l CLAUDE.md, puis vérifiez la précision. Testez les modifications dans une session fraîche en demandant à Claude de résumer le fichier.

Faut-il utiliser CLAUDE.md ou AGENTS.md ?

Si votre équipe n'utilise que Claude Code, restez sur CLAUDE.md. Si vous utilisez deux CLIs d'agents ou plus (Codex, Cursor, Sourcegraph), passez à AGENTS.md et créez un lien symbolique de CLAUDE.md vers lui : ln -s AGENTS.md CLAUDE.md. La plupart des CLIs d'agents modernes reviennent à AGENTS.md en dernier recours, donc un seul fichier alimente tous les outils.

Faut-il exécuter /init pour générer CLAUDE.md ?

Oui — comme ébauche. Non — comme fichier fini. /init scanne votre dépôt et produit un point de départ, mais il est verbeux et générique. Anthropic et HumanLayer recommandent tous les deux d'élaguer agressivement après avoir exécuté /init. Les 8 minutes que vous passez à couper et à ajouter des lignes « pourquoi » font la vraie valeur du fichier.

Comment fonctionnent les fichiers CLAUDE.md dans un monodépôt ?

Le CLAUDE.md racine reste minuscule — uniquement des pointeurs et des règles partagées. Chaque application obtient son propre apps/*/CLAUDE.md avec des conventions délimitées. Les fichiers de sous-répertoires se chargent en différé uniquement quand Claude lit des fichiers dans ce sous-arbre, donc les voisins restent isolés. Utilisez @import .claude/rules/style.md pour partager des morceaux de règles modulaires sans les dupliquer entre les applications.

Quelle est la différence entre CLAUDE.md, les hooks et les compétences ?

CLAUDE.md est du contexte consultatif — Claude le lit et le suit généralement. Les hooks sont des actions déterministes qui se déclenchent toujours (formatage, blocage de commits). Les compétences sont des capacités regroupées pour des flux de travail réutilisables avec des assets. Utilisez CLAUDE.md pour la guidance de style, les hooks pour les règles strictes, et les compétences pour les tâches multi-étapes que vous répéterez sur plusieurs projets.

Comment Techsy aborde cela

Chez Techsy, chaque projet Claude Code que nous livrons a un CLAUDE.md sous 150 lignes et un lien symbolique vers AGENTS.md. Nous traitons le fichier comme du code — on le versionne, on passe les modifications en revue dans les pull requests, et on reteste dans des sessions fraîches avant le merge. Besoin d'aide pour intégrer des agents IA dans votre workflow de développement ? Obtenez une consultation gratuite.