AlexWrites
← Retour aux articles
Dev, IA

Comment j'ai divisé par 2 ma consommation de tokens sur Claude Code

Alexandre
Alexandre
··
Durée de lecture : 9 min
Illustration économie de tokens Claude Code — CLAUDE.md, hooks, règles proactives

Cliquer pour agrandir

En janvier, j'ai comparé deux semaines de sessions Claude Code sur le même projet Livate, même complexité de tâches. La seule différence : la deuxième semaine, j'avais mis en place 5 règles avant d'ouvrir ma première session.
Résultat : -52 % de tokens consommés.
Pas grâce à /compact. Grâce à ce que j'avais configuré avant même d'écrire mon premier prompt.

Mesurer avant d'optimiser : la commande /cost

Avant de toucher quoi que ce soit, il faut savoir où tu en es. Claude Code intègre une commande /cost qui affiche la consommation en temps réel de la session en cours :
Total cost:            $0.87
Total duration (API):  8m 42.3s
D'après la documentation officielle Anthropic, la moyenne constatée est de 6 $/dev/jour, avec 90 % des utilisateurs sous les 12 $/jour. Si tu es systématiquement au-dessus, les sections suivantes sont pour toi.

Pourquoi Claude Code consomme-t-il autant de tokens ?

Sans règles, Claude Code est un stagiaire curieux avec une carte de crédit illimitée. Il va ouvrir node_modules/ pour comprendre une lib. Lire package-lock.json (300 000 lignes) pour vérifier une version. Explorer .next/ parce qu'il cherche un fichier de config. Scanner dist/ pour comprendre la sortie du build.
Chaque fichier inutile lu = des tokens brûlés. Sur une session intense de 2-3 heures sur Livate, j'ai mesuré des écarts de 40 à 60% de consommation entre une session "à l'arrache" et une session cadrée. La différence, c'est pas le code produit. C'est la quantité de contexte inutile que Claude s'est mis dans la tête avant de coder.

La solution : une couche de règles proactives

Depuis que j'ai mis en place ce setup, ma consommation moyenne par session a baissé de moitié. Pas de magie. Juste 5 éléments qui empêchent le contexte de gonfler dès le départ.

1. Le CLAUDE.md : ta mémoire projet

Le CLAUDE.md est un fichier Markdown placé à la racine du projet que Claude Code charge automatiquement au démarrage de chaque session. Il joue le rôle de mémoire persistante : conventions de code, architecture, commandes, fichiers à ignorer.
Le fichier CLAUDE.md à la racine du projet, c'est le truc le plus sous-estimé de Claude Code. Il est chargé automatiquement à chaque session. Le mien fait une centaine de lignes et contient tout ce que Claude a besoin de savoir sur le projet : la stack, les conventions de code, les commandes Docker, l'architecture des dossiers.
## Conventions de code
- Backend : snake_case fichiers, camelCase variables, PascalCase classes
- Frontend : PascalCase composants, camelCase fonctions
- Indentation : 4 espaces (2 pour JSON)
- Commits : feat:, fix:, refactor:, test:, docs:
Sans ça, Claude te pose des questions de contexte à chaque session. "Quelle convention de nommage ?", "Où est la config ?", "Quel ORM tu utilises ?". Chaque question = des tokens pour la poser ET pour lire les fichiers qui répondent. Avec un CLAUDE.md solide, tu coupes 20-30% de tokens de contexte pur.
J'en ai parlé en détail dans mon article précédent, mais le point clé ici c'est l'impact sur la consommation, pas juste la qualité du code.

2. Le fichier de règles token-economy.md

Dans .claude/rules/, tu peux poser des fichiers Markdown chargés automatiquement dans toute session et tout agent. Contrairement au CLAUDE.md qui décrit le projet, ces fichiers imposent des comportements — des règles que Claude doit respecter en permanence, quoi qu'il arrive.
Dans .claude/rules/, tu peux poser des fichiers Markdown qui sont chargés automatiquement dans toute session et tout agent. Mon token-economy.md contient les règles d'économie de tokens que Claude doit respecter en permanence :
# Économie de tokens — règles obligatoires

## Exploration de fichiers
- Grep/Glob avant Read : toujours cibler avant d'ouvrir un fichier.
- Ne jamais lire : node_modules/, .next/, dist/, *.lock, DerivedData/
- Stopper l'exploration dès qu'on a trouvé ce qu'on cherche.

## Contexte et réponses
- Réponses courtes. Pas de récapitulatif de ce qui vient d'être fait.
- Ne pas relire un fichier déjà lu dans la même session.
- Pas de prose introductive ("Je vais maintenant...", "Bien sûr !").
La règle "Grep/Glob avant Read" à elle seule change tout. Au lieu d'ouvrir 15 fichiers pour trouver une fonction, Claude fait un Grep ciblé, trouve le fichier en une requête, et lit uniquement celui-là. La règle "pas de récapitulatif" coupe aussi pas mal : par défaut, Claude adore résumer tout ce qu'il vient de faire avant de passer à la suite. C'est rassurant, mais ça coûte des tokens pour rien.

3. Les hooks : des garde-fous automatiques

Un hook PreToolUse est un script (bash ou JSON) que Claude Code exécute automatiquement avant chaque appel d'outil. Il peut bloquer l'action, la modifier ou la laisser passer — sans que tu aies besoin d'intervenir.
Les hooks, c'est des scripts qui s'exécutent automatiquement à des points précis du cycle de vie de Claude Code. Tu peux t'en servir comme garde-fous pour bloquer les comportements gourmands.
Exemple concret : un hook PreToolUse qui bloque toute lecture dans les dossiers de build :
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read",
        "hooks": [
          {
            "type": "command",
            "if": "Read(node_modules/*)",
            "command": "echo 'Lecture node_modules bloquée' >&2 && exit 2"
          }
        ]
      }
    ]
  }
}
Claude essaie de lire un fichier dans node_modules/ ? Bloqué. Il ne perd pas 2000 tokens à lire le code source de React pour comprendre un type. Il utilise la doc officielle ou le type exporté, point.

4. Des prompts ultra ciblés

La façon dont tu formules une demande détermine directement le nombre de fichiers que Claude va explorer. Un prompt vague = exploration large = tokens inutiles. Un prompt ciblé = Claude lit ce qu'il faut, rien de plus.
La façon dont tu formules ta demande change radicalement la quantité de fichiers que Claude va explorer. C'est bête, mais c'est le levier le plus immédiat.
Au lieu de :
Regarde mon projet et dis-moi si le composant Hero est cohérent.
Tu écris :
Lis uniquement src/components/Landing/Hero.tsx et dis-moi si le pattern est cohérent avec les conventions du CLAUDE.md.
Dans le premier cas, Claude va explorer la structure du projet, lire 5-10 fichiers pour "comprendre le contexte", puis regarder Hero. Dans le deuxième, il lit un fichier et répond. La différence : 3000-5000 tokens d'exploration évités.
Chaque fichier que tu références explicitement, c'est un fichier que Claude n'a pas besoin de chercher.

5. Le @ pour pointer directement

Dans Claude Code, @fichier injecte le contenu d'un fichier directement dans le contexte du prompt, sans que Claude ait besoin de l'explorer ou de le chercher.
Dans Claude Code, tu peux utiliser @fichier pour injecter un fichier dans le contexte du prompt. C'est le raccourci ultime : au lieu de laisser Claude explorer pour trouver le bon fichier, tu le lui donnes.
@src/components/Landing/Hero.tsx refactore le useEffect pour éviter le re-render
Claude reçoit le contenu du fichier directement. Pas de Glob, pas de Grep, pas d'exploration. Il code tout de suite. Sur une session de 20 itérations, ça représente des centaines de tokens économisés par prompt.

Le mode agentique : une usine, pas une session

Le mode interactif c'est une conversation. Le mode agentique, c'est une chaîne de montage : plusieurs agents qui s'enchaînent, se délèguent des tâches, travaillent en parallèle. Et une chaîne de montage mal configurée brûle du carburant en continu, même quand elle ne produit rien d'utile.
Trois leviers changent tout ici.

Limiter les outils accessibles à chaque agent

Dans .claude/agents/, chaque fichier de définition d'agent expose un champ permission qui liste les outils auxquels il a accès : read, write, bash, grep, glob, task...
Un agent qui a accès à tout va naturellement explorer plus qu'un agent bridé. Un agent de recherche n'a pas besoin de write. Un agent de rédaction n'a pas besoin de bash. La règle : donner à chaque agent le minimum viable pour sa tâche.
# .claude/agents/recherche.md
permission:
  read: allow
  grep: allow
  glob: allow
  # write: non. bash: non. task: non.
Moins d'outils disponibles = moins de chemins d'exploration possibles = moins de tokens consommés par défaut.

Les Skills : charger le contexte métier à la demande

Sans Skills, le contexte métier (conventions du projet, règles de rédaction, guidelines techniques) est copié-collé dans le system prompt de chaque agent — et chargé à chaque appel, utile ou non.
Avec un fichier dans .claude/skills/, ce contexte n'est injecté que quand l'agent en a explicitement besoin. Sur un workflow de 10 appels agentiques, la différence est significative : tu ne paies le contexte que quand il sert.
Exemple concret : mon skill blog-writer.md contient 200 lignes de guidelines de rédaction. Sans Skills, ces 200 lignes sont dans le contexte de chaque appel. Avec, elles ne sont chargées que quand un agent rédige un article — pas quand il fait une recherche Tavily ou une analyse de code.

Les commands : des prompts pré-construits qui évitent le bruit

Une slash command dans .claude/commands/ c'est un prompt ultra structuré avec les contraintes déjà posées, les fichiers déjà référencés, le périmètre déjà défini. Versus un prompt vague tapé à la main qui va déclencher 2-3 tours d'exploration avant que l'agent comprenne ce qu'on veut.
# .claude/commands/article-blog.md
Rédige un article en suivant le skill blog-writer.
Lis uniquement : Blog-livate/content/Livate/Article de blog/fr/[dernier article].mdx
Ne pas explorer le reste du dossier.
La différence entre /article-blog et "écris-moi un article de blog" : le premier démarre avec le bon contexte et les bonnes contraintes. Le second explore, pose des questions, lit des fichiers pour comprendre le format. Quelques milliers de tokens d'écart, multiplié par chaque invocation.

Le modèle de chaque agent : Haiku pour les tâches simples

Dernier levier, souvent oublié : le champ model dans chaque agent. Haiku coûte 25 fois moins cher qu'Opus à résultat équivalent sur des tâches de scan, grep, résumé ou classification. Réserver Sonnet et Opus aux agents qui font vraiment de la génération complexe ou de l'analyse architecturale.
# Agent de recherche Tavily → Haiku suffit largement
model: claude-haiku

# Agent d'implémentation technique → Sonnet ou Opus
model: claude-sonnet
C'est une ligne dans un fichier YAML. C'est souvent l'optimisation la plus rapide à mettre en place.
Est-ce que tu as déjà mesuré ta consommation de tokens par session ? La plupart des devs ne le font pas — et c'est exactement pour ça que la facture explose sans qu'on sache pourquoi. Dis-moi en commentaire quel est ton setup actuel, je suis curieux de voir ce qui revient le plus.

Ce que je prépare

Je suis en train de packager tout ce setup : un template CLAUDE.md, le token-economy.md, les hooks de base, des exemples de prompts ciblés. L'idée c'est un repo GitHub public que tu peux cloner et adapter à ton projet en 10 minutes.
Si ça t'intéresse, dis-le moi sur X, LinkedIn ou en commentaire. Si y'a de la demande, je le sors la semaine prochaine.

FAQ — Optimiser les tokens Claude Code

Quelle est la différence entre /compact et les règles proactives ?
/compact est réactif : il résume le contexte une fois que la fenêtre est pleine. Les règles proactives (CLAUDE.md, hooks, fichiers de règles) empêchent le contexte de grossir en premier lieu. L'un répare, l'autre prévient.
Le CLAUDE.md a-t-il une taille limite ?
Oui. Anthropic recommande de le garder sous 500 lignes environ. Au-delà, il alourdit le contexte de chaque session y compris pour des tâches qui n'en ont pas besoin. La solution : déplacer les instructions spécialisées vers des Skills chargés à la demande.
Claude Haiku est-il vraiment 25x moins cher qu'Opus ?
Oui, d'après la grille tarifaire officielle Anthropic. Pour les subagents qui font des tâches simples (grep, recherche, classification), Haiku est le bon choix. Réserver Sonnet ou Opus pour les décisions d'architecture ou le code complexe.
Quel est le coût mensuel réel de Claude Code ?
Selon Anthropic, la moyenne constatée est de 100 à 200 $/dev/mois avec Claude Sonnet. 90 % des utilisateurs restent sous 12 $/jour. Avec le setup décrit dans cet article, j'ai ramené ma consommation dans la première moitié de cette fourchette.
Les hooks ralentissent-ils Claude Code ?
Non de façon perceptible. Un hook PreToolUse en bash qui filtre un chemin s'exécute en quelques millisecondes. Le gain en tokens économisés est sans commune mesure avec la latence ajoutée.

La vraie économie de tokens, c'est structurel

J'aurais pu continuer à /compact toutes les 30 minutes. C'est ce que je faisais. Et c'est ce que font la plupart des devs qui se plaignent de leur facture Claude Code. Mais /compact, c'est le Doliprane du contexte. Ça soulage, ça traite pas la cause.
La vraie économie, c'est empêcher le contexte de gonfler dès le départ. Un CLAUDE.md qui répond aux questions avant qu'elles soient posées. Des règles qui bloquent les lectures inutiles. Des hooks qui interceptent les dérives avant qu'elles arrivent. Des prompts qui ciblent exactement ce qu'il faut lire.
Tu la mets en place une fois, elle tourne seule.
Tu répares pas un contexte qui a gonflé. Tu l'empêches de gonfler.
Alex

À retenir

  • Le CLAUDE.md chargé à chaque session coupe 20-30% de tokens en éliminant les questions de contexte répétitives. C'est le premier investissement à faire.
  • Un fichier token-economy.md dans .claude/rules/ impose des règles d'économie automatiques : Grep avant Read, pas de récapitulatif, pas de lecture de node_modules.
  • Les hooks PreToolUse permettent de bloquer automatiquement les lectures dans les dossiers de build (node_modules, .next, dist). Des garde-fous invisibles.
  • Un prompt ciblé ('lis uniquement ce fichier') économise 3000-5000 tokens par rapport à un prompt vague ('regarde mon projet'). Le @ injecte le fichier directement.
  • En mode agentique : limiter les outils de chaque agent au minimum viable, charger le contexte métier via des Skills à la demande, et définir Haiku pour les agents de recherche. 25x moins cher qu'Opus sur les tâches simples.
  • /compact et /clear sont du réactif. La vraie économie de tokens est structurelle : tu empêches le contexte de gonfler au lieu de le réparer après coup.
← Retour aux articles

Articles similaires

Commentaires

Commentaires

Tu as un avis sur cet article ?

Crée un compte gratuit en 10 secondes pour commenter, laisser des likes et recevoir les prochains articles directement dans ta boîte mail.

Pas encore de compte ?

Ce site utilise des cookies pour les statistiques de visite et la publicité. Aucune donnée personnelle n'est revendue. En savoir plus