Le moment où j'ai compris
J'ai atteint le rate limit en 45 minutes. Pas sur une tâche complexe — sur du CSS. Claude avait chargé 2 Mo de JSON de données runtime, le CLAUDE.md de 300 lignes, et l'historique d'un refactoring qui n'avait rien à voir. Je payais des tokens pour du contexte que personne n'avait demandé.
Mon projet — un portfolio PHP avec un système de veille automatisée en Node.js — n'est pas gros. Quelques dizaines de fichiers de code. Mais le répertoire de travail contenait aussi des centaines de JSON uploadés, des screenshots Playwright, des plans de session temporaires, des assets binaires. Claude Code ne fait pas la différence entre un fichier source et un artefact runtime. Il indexe tout, et il charge ce qui lui semble pertinent. Souvent, il se trompe.
Ce jour-là, j'ai décidé de comprendre où partaient les tokens. Pas en lisant la documentation d'abord — en observant ce que Claude faisait réellement dans mes sessions. Voici ce que j'ai trouvé, dans l'ordre où je l'ai découvert.
Première découverte : le .claudeignore
En regardant les logs d'une session, j'ai vu Claude explorer uploads/ —
un dossier de données runtime, des centaines de fichiers JSON. Il cherchait du contexte
pour comprendre la structure du projet. Sauf que ces fichiers ne décrivent pas la
structure du projet. Ce sont des données. Il n'y a rien à en tirer pour écrire du code.
La solution existe et elle est triviale : un .claudeignore à la racine,
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/
Avant : Claude chargeait régulièrement des fichiers de
uploads/ en début de session, surtout quand la question était vague.
Plus de 2 Mo de JSON inutile dans le contexte.
Après : ces fichiers n'existent plus pour Claude. L'exploration auto du projet se limite aux fichiers source. C'est le levier qui a eu le plus gros impact à lui seul — et le plus simple à mettre en place.
Deuxième découverte : le CLAUDE.md qui grossit sans contrôle
Le .claudeignore avait réglé le problème des données runtime. Mais les
sessions restaient chères. En examinant ce qui était injecté au démarrage, j'ai réalisé
que mon CLAUDE.md faisait 260 lignes. Toutes injectées dans chaque session,
dès le premier échange.
260 lignes, c'est l'accumulation de semaines de travail. Chaque fois que Claude faisait une erreur récurrente, j'ajoutais une règle. "Ne touche pas à ce fichier." "Ce service tourne sur le port 3001." "Le format de date est ISO." Des règles utiles au moment où je les ai écrites — mais la moitié concernait le système de veille Node.js. Quand je travaillais sur le CSS du blog, tout ce contexte veille était du bruit pur.
Claude Code supporte la syntaxe @chemin pour importer d'autres fichiers
Markdown. Mais l'import est automatique — le fichier référencé est toujours chargé.
Ce n'est pas du chargement conditionnel.
La vraie solution : séparer et ne pas importer. J'ai découpé en deux fichiers :
CLAUDE.md— stack, déploiement, bot LinkedIn. 24 lignes.CLAUDE.veille.md— tout le système de veille. Chargé manuellement quand nécessaire.
Dans le CLAUDE.md principal, juste une note :
> Système de veille : voir `CLAUDE.veille.md`Quand je travaille sur la veille, je dis à Claude "lis CLAUDE.veille.md". Le reste du temps, ces 240 lignes n'existent pas dans le contexte.
La partie difficile n'est pas le découpage — c'est de savoir quoi garder. J'ai fait un audit ligne par ligne : chaque règle classée comme essentielle, déductible du code, obsolète, ou hors scope. Tout ce qui est déductible ou obsolète part directement. Le résultat : un CLAUDE.md de 24 lignes qui suffit pour 80% des sessions.
L'autre leçon, moins évidente : quand une session révèle un vrai gotcha — une contrainte métier invisible dans le code, un comportement contre-intuitif — l'encoder immédiatement dans le bon fichier. 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.
Troisième découverte : les sessions longues coûtent cher pour rien
À ce stade, j'avais réduit ce que Claude chargeait au démarrage. Mais je continuais à avoir des sessions de 2 heures où j'enchaînais des tâches sans rapport : un champ dans un formulaire, un bug dans le daemon, la rédaction d'un article. Le contexte accumulait tout.
Le problème est arithmétique. Chaque échange est facturé sur la totalité du contexte accumulé. Au dixième échange d'une session longue, le contexte contient les fichiers lus pour les neuf échanges précédents — même s'ils n'ont aucun rapport avec la question en cours.
La commande /clear remet le contexte à zéro. Pas la session, juste le
contexte. Le CLAUDE.md est réinjecté, mais tout le reste disparaît.
Avant : une session de 2h, 15 échanges, facturée sur un contexte qui ne faisait que grossir.
Après : /clear dès que je change de tâche. Cinq sessions
de 20 minutes au lieu d'une session de 2h. Le même travail, pour une fraction du coût.
Et quand je veux garder un résumé de ce qui a été fait avant de continuer sur le même
sujet : /compact. Claude compresse le contexte en gardant l'essentiel.
Moins radical que /clear, mais efficace pour les tâches longues qui ont
une continuité réelle.
Quatrième découverte : la formulation des questions change tout
Même avec un contexte propre, certaines questions coûtent 10x plus cher que d'autres pour le même résultat. J'ai mis du temps à le comprendre parce que le réflexe naturel est de poser des questions larges.
"Comment fonctionne le système de veille ?" — Claude va lire 8 fichiers, retracer l'architecture, et produire une explication de 500 tokens. Si je voulais juste savoir comment la déduplication fonctionne, j'ai payé pour 7 fichiers inutiles.
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.
C'est un changement d'habitude. On passe de "Claude, comprends mon projet" à "Claude, modifie cette ligne dans ce fichier". Moins conversationnel, mais radicalement moins cher.
Bonus : Haiku pour le mécanique, Sonnet pour le reste
Une fois ces habitudes en place, j'ai testé un dernier levier : changer de modèle selon la tâche. Claude Haiku coûte environ 20 fois moins que Sonnet à volume équivalent. Pour les tâches mécaniques — renommage de variable, ajout de cas dans un switch, correction d'une typo — il fait le travail.
Mais j'ai appris à mes dépens que le gain s'annule vite. Sur un projet avec du couplage implicite (registry JSON qui pilote un daemon qui synchronise via FTP), Haiku manque régulièrement une contrainte et propose un fix superficiel. Trois échanges Haiku pour corriger ce qu'un seul échange Sonnet aurait réglé — le coût total est identique, le temps perdu ne l'est pas.
Mon usage actuel : /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é. Sonnet pour tout le reste.
Et lancer Claude depuis le bon dossier
Un dernier détail que j'ai mis du temps à intérioriser. Claude Code indexe le
répertoire depuis lequel il est lancé. Depuis la racine du projet, tout est disponible.
Depuis veille/, seul ce dossier est dans le périmètre d'exploration.
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. C'est complémentaire du .claudeignore, pas un
remplacement.
Ce que ça a changé
Aucune de ces optimisations n'est spectaculaire prise isolément. L'effet vient de leur
combinaison : un CLAUDE.md de 24 lignes au lieu de 260, un .claudeignore
qui exclut 2 Mo de données runtime, des sessions de 20 minutes avec /clear
entre chaque tâche, des questions qui pointent vers un fichier et une ligne au lieu de
demander une explication globale.
Le plus contre-intuitif : les sessions longues semblent productives parce qu'on fait beaucoup de choses. En pratique, cinq sessions courtes coûtent moins et produisent un travail aussi propre — souvent meilleur, parce que Claude n'a pas à gérer un contexte devenu incohérent au fil des changements de sujet.
Je n'ai plus atteint le rate limit sur du CSS.