Au bout de quelques semaines d'utilisation intensive de Claude Code, la facture grimpe. Pas parce que les tâches sont plus complexes — parce que les sessions deviennent de plus en plus grasses. Claude charge tout le contexte disponible, relit les mêmes fichiers à chaque échange, et le CLAUDE.md s'allonge à chaque nouvelle règle ajoutée. Résultat : on paye des tokens pour du contexte inutile, pas pour du travail réel.
Voici les leviers qui ont eu le plus d'impact sur mon projet, un portfolio PHP avec un système de veille automatisée en Node.js. Pas de recettes magiques — des ajustements concrets avec leur effet réel.
Le .claudeignore : ce que Claude ne devrait jamais lire
Par défaut, Claude Code peut indexer n'importe quel fichier du répertoire de travail.
Sur mon projet, ça incluait uploads/ (des centaines de JSON de données
runtime), .playwright-mcp/, des plans de session temporaires, et tous les
assets binaires. Aucun de ces fichiers n'a d'intérêt quand on débogue un script Node.js.
La solution est un .claudeignore à la racine, avec la même syntaxe que
.gitignore :
# Données runtime — inutiles pour coder
uploads/
scripts/.retro-state.json
scripts/.veille.lock
# Playwright
.playwright-mcp/
# Plans/specs générés
docs/superpowers/
# Assets binaires
assets/images/
assets/plugins/
# Commentaires blog
blog/comments/
L'effet est immédiat : Claude ne charge plus ces fichiers lors de l'exploration auto du
projet. Sur mon dossier uploads/ qui dépasse 2 Mo de JSON, c'est le gain
le plus significatif.
Découper CLAUDE.md par domaine
Le CLAUDE.md est injecté dans chaque session. S'il fait 300 lignes, elles
sont toutes là dès le premier échange — même quand on travaille sur le CSS du blog et
qu'on n'a aucune raison de connaître les subtilités du daemon de veille.
Claude Code supporte la syntaxe @chemin pour importer d'autres fichiers.
Mais l'import est automatique — il charge toujours le fichier référencé. Ce n'est pas
vraiment du chargement conditionnel.
La vraie solution : séparer les fichiers et ne pas les importer automatiquement. J'ai découpé mon CLAUDE.md en deux :
CLAUDE.md— stack, déploiement, bot LinkedIn. 24 lignes.CLAUDE.veille.md— tout le système de veille. Chargé manuellement quand nécessaire.
Dans CLAUDE.md, juste une note :
> Système de veille : voir `CLAUDE.veille.md`Quand je travaille sur la veille, je dis explicitement à Claude "lis CLAUDE.veille.md". Le reste du temps, le fichier n'existe pas dans le contexte. Le CLAUDE.md principal est passé de 260 à 24 lignes.
La partie difficile n'est pas le découpage — c'est de savoir quoi couper. Un audit ligne par ligne aide : classer chaque règle comme essentielle, déductible du code, obsolète, ou hors scope. Tout ce qui est déductible ou obsolète part directement. Les prompts pour faire cet audit sont dans le contexte associé ci-dessous.
L'autre face du problème : ce qui mérite d'être ajouté. Quand une session révèle un
gotcha réel — une contrainte métier invisible dans le code, un comportement
contre-intuitif, une règle qui surprend — l'encoder immédiatement dans le bon
CLAUDE.md plutôt que de le réexpliquer à la prochaine session. Mais avec
un filtre strict : si c'est déductible des fichiers existants, ou si c'est un cas
limite qui ne se reproduira pas, ça n'a pas sa place. Le CLAUDE.md ne grossit
pas parce qu'on y ajoute des choses — il grossit parce qu'on n'applique pas de
critère.
/clear entre chaque tâche distincte
C'est le levier le plus sous-estimé. Une session Claude Code accumule tout : les fichiers lus, les échanges précédents, les tentatives échouées. Si on enchaîne "ajoute un champ dans le formulaire" → "corrige ce bug dans le daemon" → "rédige cet article", le contexte de la session contient tout ça en même temps.
Chaque échange est facturé sur la totalité du contexte accumulé. Une session de 2h peut coûter 3x plus qu'une série de sessions courtes qui font le même travail.
Règle pratique : /clear dès qu'on change de tâche. /compact
si on veut garder un résumé de ce qui a été fait avant de continuer sur le même sujet.
Des questions ciblées, pas des explorations
"Comment fonctionne le système de veille ?" — Claude va lire 8 fichiers, retracer l'architecture, et produire une explication de 500 tokens. Si on voulait juste savoir comment la déduplication fonctionne, on a payé pour beaucoup de contexte inutile.
La version efficace : "dans scripts/run-veille.js, comment fonctionne la
dédup SHA256 ?" Claude lit un seul fichier, va directement à la fonction, répond en
50 tokens.
Même logique pour les modifications. Plutôt que "je veux modifier le comportement de
la boucle FTP", donner le fichier et la ligne : "dans scripts/run-veille.js
ligne 180, je veux que la condition ignore aussi les fichiers .html". Claude
fait un diff minimal sans relire tout le fichier.
Haiku pour les tâches simples — avec réserves
Claude Haiku coûte environ 20 fois moins cher que Sonnet à volume équivalent. Pour les tâches mécaniques — renommage de variable, ajout de cas dans un switch, correction d'une faute de typo dans un commentaire — il fait le travail.
Mais le coût des allers-retours annule souvent le gain. Sur un projet avec du couplage implicite (registry JSON qui pilote un daemon qui syncronise via FTP), Haiku va régulièrement manquer une contrainte et proposer un fix superficiel. On passe alors 3 échanges à corriger ce qu'un seul échange Sonnet aurait réglé.
Le bon usage : /model haiku pour les questions factuelles ("où est définie
la fonction X ?", "quel est le schéma de ce JSON ?") et les modifications d'une ligne
dans un contexte isolé. Rester sur Sonnet dès que la tâche implique plusieurs fichiers
ou des règles métier non triviales.
Ouvrir Claude depuis un sous-dossier
Claude Code indexe le répertoire depuis lequel il est lancé. Si on lance depuis la racine
du projet, tout est disponible. Si on lance depuis veille/, seul ce dossier
est dans le périmètre d'exploration auto.
Pour du travail focalisé sur un module — admin de la veille, scripts Node.js, blog — ouvrir Claude depuis le bon sous-dossier réduit mécaniquement ce qu'il peut charger par inadvertance.
Conclusion
Aucune de ces optimisations n'est spectaculaire prise isolément. L'effet vient de leur combinaison : un CLAUDE.md court, un .claudeignore qui exclut les données runtime, des sessions courtes et ciblées, des questions précises avec fichier et ligne.
Ce qui reste le plus contre-intuitif : les sessions longues semblent productives parce
qu'on fait beaucoup de choses. En pratique, une session de 20 minutes avec /clear
entre chaque tâche coûte moins et produit un travail aussi propre qu'une session de 2h
sans interruption — souvent meilleur, parce que Claude n'a pas à gérer un contexte
devenu incohérent.