Comment gérer les tokens dans Claude Code ?

Je gère les tokens dans Claude Code en préparant mieux le contexte, en cadrant la tâche et en limitant les réponses inutiles. Le vrai gain vient rarement d’un seul hack. C’est plutôt une hygiène de session, simple, qui évite de brûler la fenêtre de contexte trop vite.

Qu’est-ce qui consomme vos tokens ?

Les tokens, c’est le carburant de Claude Code. Chaque morceau de texte envoyé ou gardé dans la session en consomme. Et le piège, c’est qu’on ne les perd pas toujours là où on croit.

La fenêtre de contexte, c’est la mémoire temporaire que Claude Code utilise pendant votre session. Elle contient l’historique de conversation, les fichiers inclus, les consignes que vous donnez, et aussi les réponses générées par Claude. Chaque nouveau message reste dans cette fenêtre et grignote l’espace utile. Plus elle se remplit, moins Claude a de place pour raisonner proprement sur le code important.

Les tokens partent surtout dans trois endroits très classiques.

• Les fichiers trop longs. Quand vous envoyez un gros fichier complet alors que seules 40 lignes comptent, Claude doit quand même lire le reste. Un fichier de config, un bundle généré, un gros JSON ou un vieux composant React de 2 000 lignes peut vite manger une grosse partie du contexte.
• Les échanges trop bavards. Un brief flou crée des allers-retours. Claude demande des précisions, vous réexpliquez, il reformule, vous corrigez. J’ai souvent vu des équipes perdre plus de tokens à expliquer le problème qu’à le résoudre. Un brief court mais précis coûte moins cher qu’une discussion longue.
• Le contexte répété plusieurs fois. Copier-coller les mêmes consignes, les mêmes extraits de code ou le même résumé à chaque message, ça semble rassurant. En réalité, ça remplit la session avec du doublon. Il vaut mieux poser une base claire une fois, puis faire référence à cette base.

Le bon réflexe, c’est de traiter le contexte comme une ressource limitée. Vous ne donnez pas “tout le projet”. Vous donnez ce qui aide Claude à décider, modifier ou vérifier.

Source de dépense	Effet	Correction simple
Fichiers énormes sans tri	Le contexte se remplit avec du bruit	Inclure seulement les fichiers et lignes utiles
Brief flou	Plus d’allers-retours et de reformulations	Donner l’objectif, la contrainte et le résultat attendu
Infos réinjectées plusieurs fois	Les mêmes tokens sont payés plusieurs fois	Résumer une fois puis référencer ce résumé

Comment préparer Claude Code avant la session ?

Je prépare toujours un peu le terrain avant de lancer Claude Code. Pas par maniaquerie, juste parce que chaque flou finit payé en tokens. Si je peux clarifier le contexte avant, je préfère le faire une fois, proprement, plutôt que de le répéter dans chaque prompt.

Le fichier le plus utile pour ça, c’est CLAUDE.md, placé à la racine du projet. La documentation Claude Code d’Anthropic le présente comme un moyen de fournir du contexte projet réutilisable. En clair, c’est une mémoire persistante du projet. Claude peut s’en servir pour comprendre où il met les pieds sans que vous ayez à tout réexpliquer.

Je m’en sers pour poser les bases qui évitent les mauvaises hypothèses :

• Vue d’ensemble : Ce que fait le projet, en quelques lignes.
• Stack : Les technos utilisées, par exemple framework, base de données, outils de test.
• Conventions : Style de code, architecture, patterns à respecter.
• Règles de nommage : Comment nommer les fichiers, composants, fonctions, routes.
• Commandes utiles : Tests, lint, build, lancement local.
• Zones sensibles : Les fichiers à ne pas modifier sans raison, ou les parties fragiles.

Un exemple simple de structure peut ressembler à ça :

# Aperçu
Projet web existant. Objectif : maintenir l’architecture actuelle et éviter les refontes inutiles.

# Stack
Runtime :
Framework :
Base de données :
Tests :

# Conventions
Respecter la structure actuelle.
Préférer des changements petits et ciblés.
Ne pas renommer sans raison.

# Commandes
Tests :
Lint :
Build :

# Contraintes
Ne pas modifier les migrations déjà appliquées.
Ne pas toucher aux fichiers de configuration sans validation.

Je nettoie aussi les fichiers avant de les donner à Claude. Les commentaires inutiles, les imports non utilisés, le dead code, le boilerplate sans intérêt… tout ça consomme du contexte pour rien. Et parfois ça l’embrouille. J’ai déjà vu Claude partir sur une vieille fonction commentée comme si elle était encore active. Classique.

Je préfère aussi générer une carte courte du projet plutôt que balancer tout le dépôt. Une commande de ce genre suffit souvent, à adapter selon votre environnement :

tree -L 3 -I "node_modules|dist|.git"

Le but n’est pas de cacher des infos à Claude. Le but, c’est de lui donner le bon contexte au bon moment. Moins de contexte brut, plus de contexte utile. C’est exactement la logique du chapitre précédent, et c’est souvent là que les économies de tokens commencent vraiment.

Quel brief donner pour éviter les allers-retours ?

Un bon brief, ce n’est pas un roman. C’est juste assez d’information pour que Claude Code comprenne quoi modifier, où regarder, ce qu’on attend à la fin, et ce qu’il ne doit pas toucher. C’est là que vous économisez des tokens, parce que chaque ambiguïté finit souvent en question, en correction, ou en détour inutile.

Le template que j’utilise ressemble à ça :

Contexte :
Le comportement actuel est [décrire le problème en 1 ou 2 phrases].

Objectif :
Je veux obtenir [résultat attendu précis].

Fichiers :
Interviens uniquement dans :
- chemin/du/fichier
- autre/fichier si nécessaire

Contraintes :
- Ne modifie pas l’interface publique.
- Ne change pas les noms existants sauf si indispensable.
- Garde le style du code actuel.
- Explique brièvement ce que tu as changé.

Tâche :
Analyse le code concerné, propose la modification, puis applique-la.

Ce format marche bien parce qu’il coupe les zones grises. Claude n’a pas besoin de deviner l’état final. Il sait quels fichiers sont concernés. Il sait aussi quelles règles respecter. Et surtout, il évite de relire tout le projet pour une petite modification locale.

Quand je cadre bien la demande, je préfère passer 3 minutes avant plutôt que 10 messages après. Je l’ai vu chez un client sur une base de code assez brouillonne : les demandes vagues faisaient partir l’outil dans trois directions. Les demandes cadrées produisaient des changements plus propres, avec moins de contexte consommé.

Exemple de brief court :

Contexte :
La fonction de validation accepte actuellement des valeurs vides alors qu’elles doivent être refusées.

Objectif :
Modifier la validation pour retourner une erreur quand la valeur est vide.

Fichiers :
Interviens uniquement dans le fichier qui contient cette fonction de validation.

Contraintes :
Ne change pas le nom de la fonction.
Ne modifie pas les autres règles de validation.
Garde le style actuel du code.

Tâche :
Trouve la fonction concernée, corrige le comportement, puis résume la modification.

Un brief précis n’est pas forcément long. Il doit éviter les ambiguïtés, pas raconter toute l’histoire du projet. Si une information ne change pas la décision de Claude Code, je ne la mets pas. C’est une bonne règle simple.

Brief flou	Brief utile
Corrige le bug de validation.	La validation accepte les valeurs vides. Elle doit retourner une erreur quand la valeur est vide.
Regarde dans le projet.	Interviens uniquement dans le fichier qui contient la fonction de validation.
Fais au mieux.	Ne change pas le nom de la fonction, garde le style actuel, résume les changements.
Risque d’allers-retours, de suppositions et de tokens gaspillés.	Moins de questions, moins de contexte inutile, résultat plus proche du besoin.

Comment limiter les réponses trop longues ?

Je limite les réponses trop longues avec une règle simple : je demande à Claude Code de produire uniquement ce dont j’ai besoin, rien de plus. Parce qu’on oublie vite un truc important : les réponses de Claude consomment aussi des tokens. Pas seulement vos prompts, pas seulement les fichiers envoyés en contexte. Chaque explication, chaque résumé, chaque bloc de code répété, ça compte.

Sur des tâches de codage, c’est souvent là qu’on gaspille le plus. Claude explique ce qu’il va faire, puis ce qu’il a fait, puis pourquoi il l’a fait. C’est utile parfois, mais pas quand je veux juste une correction ciblée. Chez un client, on a réduit pas mal de coûts juste en ajoutant des consignes plus sèches dans les demandes de refactor. Rien de magique. Juste moins de blabla.

Les formulations qui marchent bien sont très directes :

• Pas d’explications, seulement le code.
• Pas de préambule, uniquement l’implémentation.
• Donne-moi uniquement le diff logique.
• Réponds en liste courte.

Le “diff logique”, c’est simplement la liste des changements à appliquer, sans réécrire tout le fichier. Par exemple : “Dans telle fonction, remplace cette condition”, “Ajoute ce paramètre”, “Supprime cet import”. C’est souvent largement suffisant pour avancer vite.

Quand je travaille sur du code, supprimer les explications inutiles peut réduire fortement le volume de réponse. Souvent de l’ordre de 30 à 50 %, selon la nature de la demande. Surtout quand Claude aurait tendance à renvoyer des fichiers complets alors qu’on a besoin de trois modifications.

Je ne coupe pas les explications tout le temps non plus. Si je suis en phase de compréhension, de debug compliqué ou d’architecture, je veux le raisonnement. Là, économiser 500 tokens et prendre une mauvaise décision, c’est une fausse économie. Je distingue vraiment deux modes : exploration, où je veux comprendre, et exécution, où je veux produire vite et proprement.

Situation	Consigne à utiliser	Pourquoi ça économise
Correction simple dans un fichier	Pas d’explications, seulement le code.	Évite le résumé, le raisonnement et les commentaires inutiles.
Implémentation déjà décidée	Pas de préambule, uniquement l’implémentation.	Supprime les phrases d’introduction et les justifications.
Modification ciblée	Donne-moi uniquement le diff logique.	Évite de renvoyer des fichiers entiers.
Comparaison ou décision rapide	Réponds en liste courte.	Force une réponse synthétique, sans développement long.
Architecture ou debug complexe	Explique ton raisonnement avant de proposer le code.	Ça consomme plus, mais ça évite les mauvaises décisions.

Quand découper une grosse tâche ?

Je découpe une grosse tâche dès qu’elle commence à mélanger trop de choses à la fois. Analyse du besoin, choix d’architecture, modification de code, validation, effets de bord possibles… Là, je sais que la session Claude Code peut vite devenir lourde.

Le piège, c’est de vouloir tout garder dans la même conversation “pour ne pas perdre le fil”. En vrai, c’est souvent l’inverse. Plus la session dure, plus l’historique pèse dans la fenêtre de contexte. La fenêtre de contexte, c’est la quantité d’informations que Claude peut garder en tête à un instant donné. Quand elle se remplit, les réponses deviennent moins nettes, les détails importants se mélangent avec du bruit, et Claude peut commencer à simplifier ou à oublier des contraintes.

Je préfère fragmenter les gros sujets en morceaux plus courts, plus propres, plus faciles à piloter. Ce n’est pas une procédure militaire. C’est juste une façon d’éviter que la conversation devienne un sac de nœuds.

En général, je garde une logique simple :

• Une session pour comprendre : lire le code, identifier les fichiers clés, repérer les risques, clarifier ce qu’il faut faire.
• Une session pour modifier : donner un objectif précis, limiter le périmètre, demander les changements sans rouvrir toute l’analyse.
• Une session pour tester ou relire : vérifier les impacts, relancer les tests, relire les diffs, corriger les petits oublis.

Ce découpage marche bien parce que chaque session a une intention claire. Claude Code n’a pas besoin de porter toute l’histoire du projet à chaque fois. Il a besoin du bon résumé, des bons fichiers, et d’une demande bien cadrée. J’ai vu ça chez un client sur une refonte d’API interne. La première session avait fini avec 12 fichiers ouverts, 4 options d’architecture, et des réponses qui partaient dans tous les sens. On a résumé les décisions, relancé proprement, et la modification est devenue beaucoup plus simple.

Quand le contexte devient trop dense, je préfère demander un résumé utile. Pas un résumé littéraire. Un résumé actionnable avec les décisions prises, les fichiers concernés, les contraintes, et la prochaine étape. Puis je repars dans une nouvelle session.

Signal	Ce que je fais
Trop de fichiers ouverts	Je réduis le périmètre et je garde seulement les fichiers utiles.
Trop de décisions encore ouvertes	Je fais une session dédiée au choix d’architecture avant de coder.
Claude reformule mal la demande	Je stoppe, je résume, puis je repars avec un objectif plus clair.
Les réponses dérivent	Je découpe la tâche et je lance une nouvelle session plus ciblée.

Et si le vrai hack c’était de mieux cadrer vos sessions ?

Gérer les tokens dans Claude Code, ce n’est pas chercher une astuce magique. C’est surtout éviter de nourrir la session avec du bruit. Je prépare le contexte dans CLAUDE.md, je nettoie les fichiers, je donne un brief clair, je limite les réponses quand je veux juste du code, et je découpe les grosses tâches avant qu’elles débordent. C’est très simple, mais ça change tout. Moins de tokens gaspillés, moins d’allers-retours, plus de travail utile dans la même fenêtre de contexte. Le bénéfice pour vous est direct : des sessions plus longues, plus propres et plus productives.

FAQ

• Qu’est-ce qu’un token dans Claude Code ?
  Un token est une unité de texte traitée par le modèle. Dans Claude Code, vos messages, les fichiers inclus, les consignes et les réponses générées consomment des tokens. Plus la session accumule d’historique et de contenu, plus la fenêtre de contexte se remplit.
• Pourquoi Claude Code consomme autant de tokens ?
  La consommation explose souvent à cause de fichiers inclus trop larges, de briefs flous qui créent des allers-retours, et du même contexte répété plusieurs fois. Le problème vient rarement du code seul. Il vient surtout du bruit autour du code.
• À quoi sert le fichier CLAUDE.md ?
  CLAUDE.md sert à donner à Claude Code un contexte projet réutilisable : conventions, stack, commandes, règles importantes, structure générale. Ça évite de réexpliquer les mêmes choses à chaque session et ça garde un contexte plus propre.
• Comment réduire les réponses trop longues de Claude Code ?
  Il faut le demander clairement. Par exemple : Pas d’explications, seulement le code. Ou : Pas de préambule, uniquement l’implémentation. Sur les tâches de codage, ça peut réduire fortement la taille des réponses, surtout quand vous savez déjà ce que vous voulez.
• Faut-il découper les grosses tâches dans Claude Code ?
  Oui, dès qu’une tâche mélange trop d’analyse, de fichiers, de décisions et de modifications. Une session courte et bien cadrée donne souvent de meilleurs résultats qu’une longue conversation qui accumule trop d’historique. Vous gardez le contrôle et vous consommez moins de tokens inutiles.

 

 

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, intégration de l’IA en entreprise et SEO/GEO. J’accompagne des équipes qui veulent utiliser l’IA sérieusement, pas juste tester deux prompts dans leur coin. Avec webAnalyste et Formations Analytics, j’ai travaillé pour Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football, Texdecor et d’autres. Si vous voulez mettre Claude Code, l’IA ou l’automatisation au service de votre business, contactez-moi.