Tutos & Guides · 10 min de lecture · Par Mathieu Dugue
Claude Code : la nouvelle méthode pour écrire ton CLAUDE.md (Anthropic a supprimé 80 % du sien)
Anthropic a supprimé plus de 80 % du prompt système de Claude Code sans perdre en performance. Voici les 6 règles à appliquer à ton CLAUDE.md, tes skills et tes agents — avec la commande /doctor pour auditer ton setup.

Un ingénieur de l’équipe Claude Code vient de publier les nouvelles règles du « context engineering ». Le chiffre qui fait mal : Anthropic a supprimé plus de 80 % du prompt système de Claude Code pour les modèles de génération Claude 5, sans perte mesurable sur ses évaluations de code.
Traduction : si tu empiles les règles dans ton CLAUDE.md depuis un an, tu paies des tokens pour un travail que le modèle fait déjà tout seul. Et tu le ralentis.
L’essentiel :
- Le contexte de Claude, ce n’est pas ton prompt — c’est prompt système + skills +
CLAUDE.md+ mémoire + fichiers référencés. Tout ça se charge à chaque session, et tu le paies à chaque fois. - Les modèles Claude 5 (Opus 5, Sonnet 5, Fable 5) ont assez de jugement pour se passer des garde-fous écrits pour leurs prédécesseurs. Ces garde-fous sont devenus du bruit — parfois contradictoire.
- Six bascules concrètes à appliquer : donner un objectif plutôt que des règles, concevoir des interfaces plutôt que des exemples, charger le contexte au bon moment, ne rien répéter, laisser la mémoire automatique faire son travail, référencer du code plutôt que des descriptions.
- La commande
/doctor(déjà présente dans Claude Code) audite ton installation et te propose de dégraisser. Testée pour cet article sur la version 2.1.220.
1. « Context engineering » : de quoi on parle exactement
Quand tu envoies un message à Claude, ton prompt ne représente qu’une petite partie de ce que le modèle reçoit. Le reste est assemblé automatiquement :
- le prompt système du produit (celui de Claude Code, que tu ne modifies pas) ;
- tes skills — les procédures que tu as écrites pour des tâches récurrentes ;
- tes fichiers
CLAUDE.md, au niveau global (~/.claude/CLAUDE.md) et au niveau projet ; - la mémoire que Claude a sauvegardée au fil des sessions ;
- les fichiers référencés avec
@(specs, maquettes, bouts de code).
Le context engineering, c’est l’art d’assembler tout ça. Et la différence avec un prompt classique est fondamentale : un prompt est écrit pour une demande précise, alors que ce contexte-là s’applique à toutes tes demandes. Tu écris des instructions générales sans savoir ce que tu vas demander demain.
C’est exactement là que les vieux réflexes coûtent cher.
2. Pourquoi Anthropic a coupé 80 % de son prompt système
Le constat de l’équipe est simple : ils sur-contraignaient Claude Code. Prompt système, skills et CLAUDE.md se contredisaient régulièrement.
L’exemple donné dans l’article est parlant. Dans les transcripts de leurs propres sessions, ils voyaient cohabiter deux instructions incompatibles : d’un côté « laisse la documentation quand c’est pertinent », de l’autre un « N’AJOUTE PAS de commentaires » en majuscules. Claude finit par retomber sur ses pattes — mais il doit d’abord dépenser du raisonnement à arbitrer entre des ordres contradictoires. Du raisonnement que tu paies, et qui rallonge la réponse.
Ces garde-fous avaient une raison d’être. À la sortie de Claude Code, il fallait éviter les scénarios catastrophe : suppressions de fichiers, commentaires n’importe où. L’équipe assumait une règle parfois fausse plutôt qu’un risque de dérapage.
Les modèles récents n’ont plus besoin de cette béquille. Et ils ont surtout des outils que le CLAUDE.md remplaçait faute de mieux : la mémoire automatique, les artifacts, les skills.
À retenir : si ton
CLAUDE.mddate d’il y a six mois, il contient probablement des règles écrites contre un modèle qui n’existe plus.
3. Les six bascules « avant → maintenant »
Voilà le cœur de la méthode. Pour chaque ligne de ton CLAUDE.md ou de tes skills, demande-toi laquelle de ces bascules s’applique.
Bascule 1 — Des règles → du jugement
Avant, on écrivait des interdits explicites. Le prompt système de Claude Code disait en substance : par défaut n’écris aucun commentaire, jamais de docstring sur plusieurs paragraphes, une ligne courte maximum.
Maintenant, une seule phrase remplace tout ça : écris du code qui ressemble au code environnant — même densité de commentaires, mêmes conventions de nommage, mêmes idiomes.
La règle vaut pour tout. Décris l’objectif et le résultat attendu, laisse le modèle choisir le chemin.
Bascule 2 — Des exemples → des interfaces bien conçues
La règle numéro un de l’usage des outils, c’était : donne des exemples d’appel. Sur les modèles récents, ces exemples enferment le modèle dans un espace d’exploration réduit.
Mieux vaut soigner la conception de l’outil lui-même. Anthropic cite son outil de todo-list : le simple fait que le champ status soit une énumération pending / in_progress / completed suffit à expliquer comment l’utiliser. L’interface porte l’instruction, plus besoin d’un paragraphe d’exemples.
Applique ça à tes scripts et à tes noms de fichiers : des paramètres expressifs valent mieux qu’une doc verbeuse.
Bascule 3 — Tout charger d’avance → le chargement progressif
C’est la bascule la plus rentable en tokens.
Le prompt système de Claude Code embarquait des procédures détaillées de revue de code et de vérification. Utiles quand elles servaient — mais elles ne servaient pas toujours, et elles étaient chargées à chaque session. Anthropic les a déplacées dans des skills que Claude appelle uniquement quand il en a besoin.
Le même principe s’applique aux outils : certains sont en « chargement différé » (defer_loading). L’agent doit d’abord les chercher via un outil de recherche avant d’obtenir leur définition complète. Résultat : tu peux exposer beaucoup plus d’outils sans qu’ils occupent le contexte tant qu’ils ne servent pas.
Et c’est valable pour tes propres fichiers. Le mythe à abandonner : « mon CLAUDE.md doit tout contenir, sinon Claude ne trouvera pas ». Faux. Construis une arborescence de fichiers chargés au bon moment.
Bascule 4 — Se répéter → une seule description
Les anciens modèles avaient parfois besoin qu’on répète une instruction, et écoutaient mieux ce qui se trouvait à la fin de leur fenêtre de contexte. D’où des consignes dupliquées : une fois dans le prompt système, une fois dans la description de l’outil.
Anthropic a supprimé les doublons. Les instructions d’usage d’un outil vivent dans la description de l’outil, nulle part ailleurs.
Bascule 5 — Mémoire manuelle → mémoire automatique
L’ancien réflexe : le raccourci # pour écrire dans ton CLAUDE.md à la volée. Aujourd’hui, Claude sauvegarde tout seul les éléments pertinents pour ton travail et pour toi. Arrête de nourrir manuellement un fichier qui grossit à chaque session.
Bascule 6 — Des specs simples → des références riches
En mode plan, Claude Code s’appuyait beaucoup sur des fichiers markdown. C’était la bonne pratique : stocker les specs dans le dépôt pour que Claude s’y réfère sur les projets longs.
Le modèle gère aujourd’hui des références bien plus riches. Une spec peut être une suite de tests. Une maquette peut être un artifact HTML plutôt qu’une description. Une fonction d’un autre projet peut servir de référence à porter. Et une grille d’évaluation (rubric) permet à Claude de vérifier son travail contre ton propre standard — par exemple « à quoi ressemble une bonne API chez nous ».
Règle simple : préfère toujours le code à la description. Une maquette HTML donnera de meilleurs résultats qu’un paragraphe ou même qu’une capture d’écran.
4. Le pas-à-pas : auditer ton setup avec /doctor
Bonne nouvelle : tu n’as pas à faire cet audit à la main. Anthropic a intégré ces bonnes pratiques dans une commande.
Dans une session Claude Code, tape :
/doctor
(En dehors d’une session, claude doctor en ligne de commande fait une vérification d’installation plus limitée. La commande est disponible dans le terminal ; elle n’apparaît pas dans l’application de bureau.)
Le fonctionnement est en deux temps, et c’est important : la commande scanne d’abord en lecture seule, te présente un rapport, puis te demande ton accord avant de modifier quoi que ce soit. Tu gardes la main sur ce que tu supprimes.
Ce qu’elle examine :
| # | Vérification | Ce que ça détecte |
|---|---|---|
| 1 | Santé de l’installation | version, installations en double ou résiduelles |
| 2 | Fichiers de configuration | settings cassés, définitions d’agents en collision |
| 3 | Poids mort | skills, serveurs MCP et plugins que tu n’utilises jamais |
| 4 | Redondances | règles répétées ailleurs dans ton système |
| 5 | Dégraissage du CLAUDE.md |
contexte que la session peut déduire toute seule |
| 6 | Chargement paresseux | consignes toujours chargées qui feraient mieux d’être un skill |
| 7 | Scripts bloquants | hooks qui s’exécutent à chaque appel d’outil |
| 8 | Poids du contexte | ce qui consomme ton budget avant même que tu tapes quoi que ce soit |
| 9 | Permissions | mode auto par défaut, pour éviter les validations à répétition |
Le point 3 est celui qui surprend le plus de monde. Dans la démonstration de Duncan Rogoff (Learn Claude Code), le rapport annonce 113 skills personnels, soit environ 10 000 tokens de contexte consommés à chaque session — uniquement pour les lister. Sur ces 113, 25 n’avaient jamais servi une seule fois. La commande s’appuie sur les compteurs d’usage et les transcripts des 50 dernières sessions pour le déterminer : ce n’est pas une estimation.
10 000 tokens par session, c’est le budget parti avant ton premier mot.
5. Réécrire ton CLAUDE.md : avant / après
Le principe directeur : ton CLAUDE.md se charge à chaque session. Plus il est mince, mieux c’est. Pense-le comme un sommaire ou un index, pas comme une encyclopédie.
Ce qui doit sortir — tout ce que Claude peut déduire en regardant ton dépôt :
- l’arborescence de tes dossiers ;
- ta stack technique (il lit ton
package.json) ; - les commandes de build standards ;
- les conventions évidentes de ton langage.
Ce qui doit rester — et où tu dois dépenser tes tokens : les pièges de ta base de code. Les choses qu’on ne devine pas.
Exemple typique : « tous les types vivent dans un fichier monolithique unique, nulle part ailleurs ». Ça, aucune inspection de dossier ne le révèle. C’est exactement le genre d’information qui mérite sa place.
À la place, une arborescence
Plutôt qu’un fichier de 400 lignes :
CLAUDE.md ← 30 lignes : à quoi sert le dépôt + les pièges
├─ skills/verification/SKILL.md ← comment on vérifie une PR ici
├─ skills/deploy/SKILL.md ← la procédure de déploiement
└─ skills/api-design/SKILL.md ← nos conventions d'API
Le CLAUDE.md dit simplement : voilà les skills disponibles, voilà ce que fait chacun. Claude va chercher le détail quand il en a besoin. Le reste du temps, ça ne coûte rien.
Même logique à l’intérieur d’un skill trop long : découpe-le en plusieurs fichiers plutôt que d’entasser.
Pour tes skills
Trois règles :
- Pense « guide », pas « règlement ». Un skill sert à ce que Claude trouve l’information quand il en a besoin. Évite de sur-contraindre, sauf dans les zones vraiment critiques.
- Encode ce qui est spécifique à toi. Un skill a de la valeur quand il contient tes opinions, ton savoir-faire, les pratiques de ton équipe ou de ton produit. Pas quand il réexplique ce que le modèle sait déjà.
- Supprime ceux que tu n’utilises pas. Chaque skill non utilisé te coûte du contexte à chaque session, uniquement pour figurer dans la liste.
6. Ce qu’il faut retenir avant de te lancer
Le message tient en une phrase : simplifie.
Trois réflexes à changer dès aujourd’hui :
- Arrête d’empiler. Chaque règle ajoutée est un token payé à chaque session, et un risque de contradiction avec une autre règle. La question n’est plus « qu’est-ce que je peux ajouter » mais « qu’est-ce que je peux enlever ».
- Décris l’objectif, pas la procédure. Dis à Claude ce que tu veux accomplir et laisse-le trouver le meilleur chemin.
- Charge au bon moment. Un sommaire léger qui pointe vers des fichiers spécialisés bat systématiquement un fichier unique qui contient tout.
Et si tu ne devais faire qu’une chose : lance /doctor, lis le rapport, et regarde combien de tokens partent en fumée avant ta première question.
Sources :
- The new rules of context engineering for Claude 5 generation models — Thariq Shihipar, membre de l’équipe technique Anthropic, 24 juillet 2026
- Anthropic Engineers Just Fixed Claude Code and Nobody’s Talking About it! — Duncan Rogoff, Learn Claude Code, 28 juillet 2026
- Commandes
/doctoretclaude doctorvérifiées sur Claude Code 2.1.220 (macOS)