Claude Code fonctionne bien dès le départ, mais devient noticeablement plus efficace une fois qu'il connaît les conventions de votre projet et que vous adoptez quelques habitudes de rédaction d'invites. Ce guide couvre les deux.
Partie 1 — CLAUDE.md : la mémoire de votre projet
Qu'est-ce que c'est
CLAUDE.md est un fichier markdown simple que Claude lit automatiquement au début de chaque session dans ce répertoire. Pensez-y comme au briefing que vous donneriez à un nouveau coéquipier compétent le premier matin : comment l'équipe fonctionne, ce qu'il faut éviter, et où se trouvent les éléments importants.
Vous n'avez pas besoin de le référencer dans les invites ou de l'attacher manuellement. Si le fichier existe, Claude l'a déjà lu.
Où il se trouve
Claude cherche à plusieurs endroits et fusionne ce qu'il trouve, du plus large au plus spécifique :
Emplacement | Portée | Bon pour |
| Chaque projet sur votre machine | Préférences personnelles (par exemple, « j'utilise pnpm, pas npm » ou « toujours suggérer des tests »). |
| Ce projet | Architecture, conventions et commandes. C'est le principal. |
| Ce sous-répertoire | Règles spécifiques au module (par exemple, conventions différentes dans |
La plupart des équipes n'ont besoin que du fichier à la racine du projet. Validez-le dans git pour que toute l'équipe en bénéficie.
Comment il est chargé (et quel est son coût)
CLAUDE.md est lu une fois, au démarrage de la session, et placé verbatim dans l'invite système de Claude. Il n'y a pas de résumé ou de troncature, et il n'est pas relu depuis le disque à chaque tour ; le même contenu reste en contexte pour toute la conversation. Si vous modifiez le fichier en cours de session, la modification ne prend effet que lorsque vous démarrez une nouvelle session.
Pour les clients Claude for Enterprise, le tableau des coûts est meilleur que ce que « chargé à chaque requête » pourrait suggérer. Claude Code applique la mise en cache des invites d'Anthropic à l'invite système, qui inclut CLAUDE.md. La première requête d'une session paie le prix complet des jetons d'entrée pour le fichier ; les requêtes suivantes dans environ cinq minutes l'une de l'autre accèdent au cache et sont facturées au taux beaucoup plus bas de lecture du cache. Le cache est adressé par contenu, donc toute modification de CLAUDE.md l'invalide et la requête suivante paie le prix complet à nouveau.
En pratique, cela signifie qu'un CLAUDE.md de taille considérable coûte des jetons complets une fois par session, plus une fois après tout écart d'inactivité suffisamment long pour que le cache expire, plutôt qu'une fois par message. Il est toujours judicieux de garder le fichier léger pour l'espace de la fenêtre de contexte et le rapport signal/bruit, mais vous n'avez pas besoin de rationner les lignes uniquement pour contrôler les dépenses par message. Dans le tableau de bord d'utilisation Enterprise, l'empreinte du fichier s'affichera presque entièrement comme des jetons de lecture du cache plutôt que des jetons d'entrée standard.
Commencer : exécutez /init
Dans n'importe quel projet, tapez /init. Claude explorera la base de code et rédigera un CLAUDE.md pour vous, couvrant les commandes de construction, les commandes de test, un aperçu de la structure et toutes les conventions qu'il détecte. Examinez le brouillon, supprimez tout ce qui est inexact et validez-le. Cela prend environ cinq minutes et s'avère rentable de façon permanente.
Ce qui y appartient vraiment
Visez un fichier court et dense en signal — quelques centaines de lignes au maximum. Chaque ligne est chargée en contexte à chaque requête, donc chacune devrait valoir son coût.
Vaut la peine d'inclure :
Commandes — comment construire, tester, linter et exécuter localement. Claude les exécutera, donc la précision compte.
Conventions — nommage, gestion des erreurs, disposition des fichiers et décisions « nous utilisons X, pas Y ».
Architecture en trois phrases — quels sont les éléments majeurs et comment ils communiquent.
Contraintes strictes — par exemple, « ne jamais écrire dans la base de données de production à partir des tests », « toutes les routes API ont besoin d'un middleware d'authentification » ou « ne pas modifier
generated/».Pièges connus — les problèmes sur lesquels chaque nouvel ingénieur trébuche.
Ne vaut pas la peine d'inclure :
Documentation API complète (Claude peut lire le code directement).
Journaux des modifications ou historique.
Tout ce qui est déjà évident à partir de l'arborescence des fichiers.
Règles aspirationnelles que l'équipe ne suit pas réellement.
À quelle fréquence le mettre à jour
Traitez-le comme un document d'intégration vivant, pas comme une spécification.
Après
/init— examinez une fois pour nettoyer le brouillon généré.Quand Claude se trompe deux fois — c'est le signal qu'une règle manque. Ajoutez une ligne pour l'adresser.
Quand les conventions changent — par exemple, un nouveau framework, un nouveau test runner ou un nouvel ensemble de règles de linting.
Examen trimestriel — supprimez tout ce qui est obsolète, car les instructions obsolètes sont pires que rien.
Vous pouvez également l'ajouter en cours de session : tapez # suivi d'une instruction (par exemple # toujours utiliser async/await, jamais .then()) et Claude vous proposera de l'ajouter au bon CLAUDE.md pour vous.
Partie 2 — Habitudes de rédaction d'invites qui portent leurs fruits dans Claude Code
Ce ne sont pas des conseils génériques d'ingénierie d'invites ; ce sont les habitudes qui comptent le plus spécifiquement quand Claude lit et modifie une véritable base de code.
1. Énoncez le résultat, pas les étapes
Claude peut explorer la base de code lui-même. Dites-lui ce que vous voulez et pourquoi, et laissez-le déterminer où.
❌ « Ouvrez userService.ts, trouvez la fonction validate, ajoutez une vérification null à la ligne 42. »
✅ « Les utilisateurs sans email plantent l'étape de validation. Faites-la gérer cela gracieusement et ajoutez un test. »
2. Donnez-lui l'erreur, verbatim
Collez la trace de pile complète plutôt que de la résumer. Le nom de fichier exact, le numéro de ligne et le message sont ce qui permet à Claude de trouver le bon emplacement rapidement.
3. Délimitez les grandes tâches avec le mode Plan d'abord
Pour tout ce qui touche plus de quelques fichiers, appuyez sur Maj+Tab pour entrer en mode Plan et demandez :
« Planifiez comment vous ajouteriez une limitation de débit à l'API publique. Ne changez rien pour l'instant. »
Examinez le plan, ajustez-le dans la conversation, puis changez de mode et dites « faites l'étape 1 ». Cela détecte les malentendus avant qu'ils ne se transforment en un diff de douze fichiers.
4. Pointez vers les fichiers quand vous les connaissez déjà
Claude peut rechercher la base de code par lui-même, mais si vous connaissez déjà le fichier pertinent, dites-le — c'est plus rapide et utilise moins de jetons. Utilisez @ pour référencer les chemins, par exemple @src/auth/login.ts.
5. Dites à quoi ressemble « terminé »
Les exemples incluent « les tests passent », « correspond au style des autres gestionnaires » ou « aucune nouvelle dépendance ». Énoncer les critères d'acceptation à l'avance est plus efficace que plusieurs tours de révision.
6. Une tâche par conversation ; /clear entre elles
Les longues sessions accumulent du bruit. Quand vous passez de « corriger le bug de connexion » à « refactoriser le module de facturation », exécutez /clear et recommencez. Votre CLAUDE.md porte le contexte durable vers l'avant, donc l'historique du chat n'a pas besoin de le faire.
7. Corrigez-le comme un collègue, pas un moteur de recherche
Si la première réponse est incorrecte, vous n'avez pas besoin de reformuler toute la demande. Dites simplement ce qui ne va pas — par exemple, « Cela change l'API publique ; gardez la signature identique. » Claude gardera tout le reste et n'ajustera que ce point.
Référence rapide
Vous voulez… | Faites ceci |
Générer un |
|
Voir quelle mémoire Claude utilise |
|
Ajouter une règle en cours de session | Tapez |
Recommencer à zéro mais garder la mémoire du projet |
|
Référencer un fichier spécifique dans une invite |
|