Comment mieux gérer les tokens Claude Code ?

Je gère mieux les tokens Claude Code en préparant le contexte avant la session, en découpant les tâches et en limitant les réponses inutiles. Le vrai sujet, c’est pas juste la limite de contexte. C’est tout ce qu’on envoie sans s’en rendre compte.

Qu’est-ce qui mange vos tokens ?

Les tokens partent surtout dans les fichiers trop longs, les échanges verbeux et le même contexte répété plusieurs fois.

Dans Claude Code, la fenêtre de contexte, c’est la mémoire de travail du modèle à un instant donné. Elle contient vos messages, les fichiers que vous lui donnez, les fichiers qu’il lit, ses propres réponses, et parfois du contexte réinjecté au fil de la conversation pour garder le fil.

Un token, pour simplifier, c’est un petit morceau de texte. Pas forcément un mot entier. Chaque bout de code, chaque commentaire, chaque log, chaque explication consomme une partie de cette fenêtre. Et quand elle se remplit, Claude doit compresser, oublier, ou vous demander de repartir plus proprement.

Le point important, c’est simple : si je ne sais pas ce qui consomme, je ne peux pas optimiser. Beaucoup de développeurs pensent qu’ils perdent leur session parce que leur code est trop complexe. En réalité, ils ont souvent juste envoyé trop de bruit. Trop de fichiers, trop de contexte répété, trop de discussions autour du problème au lieu du problème lui-même.

Je vois trois gros drains revenir tout le temps.

• Les fichiers entiers envoyés par réflexe. On balance un composant de 900 lignes alors que 40 lignes autour de la fonction cassée auraient suffi. Parfois, une simple arborescence du projet donne déjà assez de contexte.
• Les conversations en plusieurs tours. Chaque clarification, chaque reformulation, chaque réponse longue reste dans la fenêtre. Ce n’est pas grave au début, mais au bout de 15 échanges, ça pèse.
• La répétition du contexte. Quand on recopie à chaque prompt l’architecture, les contraintes, l’objectif, les règles métier… On croit aider Claude, mais on recharge la même valise à chaque fois.

Sur des projets client, le problème vient rarement d’un seul prompt catastrophique. C’est plutôt une accumulation de petites pertes. Un fichier trop large ici, une explication trop longue là, un rappel inutile de l’objectif trois messages plus tard. À la fin, on a cramé la moitié du budget contexte sans s’en rendre compte.

Source de consommation	Symptôme visible	Optimisation à faire
Fichiers entiers	Claude se perd dans du code non lié au problème	Envoyer seulement l’extrait utile, la fonction, ou l’arborescence
Conversations longues	Les réponses deviennent moins précises	Résumer, trancher, repartir sur un prompt propre
Contexte répété	La fenêtre se remplit avec les mêmes infos	Référencer le contexte existant au lieu de le recopier

Comment préparer la session ?

Je prépare la session en donnant à Claude Code le bon contexte une seule fois, dans un format court, stable et réutilisable. Ça paraît basique, mais c’est souvent là que les tokens partent en fumée.

Le premier réflexe, c’est de créer un fichier CLAUDE.md à la racine du projet. Je m’en sers comme mémo permanent pour Claude Code : architecture générale, stack, conventions de nommage, commandes utiles, règles récurrentes. Pas besoin d’en faire une encyclopédie. Si le fichier devient trop long, il recrée le problème qu’on voulait éviter. Je garde ce qui aide vraiment à travailler sans répéter les mêmes consignes à chaque message.

Avant de lancer une vraie session, je pré-définis aussi la tâche. Quels fichiers sont concernés ? Quel état final j’attends ? Quelles contraintes ne doivent pas bouger ? Comment je saurai que c’est réussi ? Un brief flou coûte cher, parce que Claude Code va soit poser des questions, soit partir dans une direction moyenne. J’ai vu ça chez un client sur une migration front : trois messages pour clarifier ce qui aurait pu tenir en dix lignes au départ.

Je nettoie aussi les fichiers avant inclusion. Pas pour faire joli. Pour réduire le contexte envoyé. Je retire ce qui ne sert pas à la demande :

• Les commentaires périmés ou sans rapport.
• Les imports inutilisés.
• Le code mort.
• Le boilerplate qui n’aide pas Claude Code à comprendre.
• Les gros blocs qui ne touchent pas au problème.

Les grosses tâches doivent être découpées. Une refonte complète, une migration ou une correction multi-fichiers, ça ne rentre pas bien dans une seule intention. Je préfère demander d’abord une analyse, ensuite les modifications, puis les tests. C’est plus propre, et surtout ça évite de remplir la session avec trop de décisions en même temps.

Voici le modèle de brief que je réutilise souvent :

Contexte :
Application Next.js avec API interne et base PostgreSQL.

Objectif :
Corriger le bug de création utilisateur sans modifier le schéma DB.

Fichiers :
src/app/api/users/route.ts
src/lib/user-service.ts
src/lib/validators/user.ts

Contraintes :
Garder les signatures publiques existantes.
Ne pas toucher à l'authentification.

Tâche :
Analyser la cause, proposer le correctif, puis modifier uniquement les fichiers nécessaires.

Je donne aussi une carte du projet quand Claude Code a besoin de se repérer. Une arborescence compacte suffit. L’idée, c’est de donner une vision spatiale du projet sans envoyer tout le code.

Projet/
├── src/
│   ├── app/
│   ├── lib/
│   └── components/
├── prisma/
└── package.json

Une bonne préparation peut économiser plus de tokens qu’une optimisation pendant la session.

Comment parler à Claude Code ?

Je parle à Claude Code avec des consignes courtes, orientées action, et je coupe les explications quand elles ne servent pas la tâche. C’est bête, mais ça change beaucoup la consommation de tokens.

Pendant une session, chaque réponse générée consomme aussi des tokens. On pense souvent aux fichiers qu’on envoie dans le contexte, aux gros composants, aux logs, aux diffs. C’est normal. Mais derrière, on laisse parfois Claude produire trois paragraphes de récap, une intro polie, une justification, puis une conclusion. C’est confortable, oui. Mais c’est coûteux, surtout quand on itère vingt fois dans la même session.

Le petit hack, c’est de lui dire explicitement le format attendu. Pas juste “sois concis”, parce que concis peut vouloir dire plein de choses. Je préfère cadrer la sortie dès le départ.

Voici des formulations que j’utilise souvent :

• Réponds uniquement avec le patch à appliquer.
• Pas de résumé, pas d’explication, juste le code.
• Liste uniquement les fichiers à modifier et les changements à faire.
• Si tu n’as pas besoin d’une précision, exécute directement.

Je l’ai vu chez un client sur un gros projet React. Les prompts étaient propres, les fichiers bien choisis, mais Claude répondait avec des mini rapports à chaque modification. Rien de dramatique sur une demande. Sur une matinée complète, ça devenait une vraie fuite de tokens.

Ça ne veut pas dire qu’il faut rendre Claude muet. Il y a des moments où l’explication vaut largement son coût. Une décision d’architecture, un bug difficile, un sujet de sécurité, de la dette technique, ou un changement qui touche plusieurs modules. Là, je veux comprendre le raisonnement. Je veux voir les risques, les alternatives, les impacts possibles.

La nuance importante, c’est qu’une réponse courte ne doit pas devenir ambiguë. Le bon réflexe, c’est de demander un format précis, pas une réponse “courte” au sens vague.

Besoin	Mauvais prompt	Meilleur prompt
Corriger un bug	Corrige ce bug et explique-moi.	Identifie la cause, puis réponds uniquement avec le patch à appliquer.
Modifier un composant	Améliore ce composant.	Modifie uniquement le composant concerné. Pas de résumé, pas d’explication, juste le code final.
Analyser un fichier	Dis-moi ce que tu penses de ce fichier.	Liste uniquement les problèmes bloquants, avec le numéro de ligne et l’action recommandée.

Le but, ce n’est pas d’avoir moins d’intelligence. C’est d’éviter de payer pour du texte qui ne sert pas la décision ou l’exécution.

Comment découper sans perdre le fil ?

Je découpe le travail en sessions qui ont chacune un objectif clair, un périmètre limité et un point de reprise propre.

Ce n’est pas juste une astuce de confort. C’est une façon de protéger la fenêtre de contexte. La fenêtre de contexte, c’est la mémoire utile que Claude Code garde pendant la session. Plus elle se remplit, plus le modèle doit jongler avec des infos anciennes, des décisions intermédiaires, des bouts de code, des corrections, parfois même des pistes abandonnées.

Quand une tâche est trop grosse, tout se mélange. Analyse, refactor, écriture de code, tests, bugs, décisions produit, renommage de fichiers. La conversation enfle. Au début Claude est précis, puis petit à petit il commence à rater des détails. J’ai déjà vu ça chez un client sur une migration un peu sale. On voulait tout faire dans la même session. Résultat, au bout d’un moment, on ne savait plus si une décision venait du code réel ou d’une hypothèse faite 40 messages plus tôt.

Je fais simple. Comprendre, modifier, vérifier. D’abord je demande à Claude Code de lire et d’expliquer le périmètre. Puis je lui fais modifier une zone limitée. Puis je lui demande de tester, relire, ou chercher les effets de bord. Pour une migration ou une grosse correction, je préfère séparer les blocs de travail comme ça :

• Audit rapide : Comprendre les fichiers, les dépendances, les risques.
• Plan de modification : Choisir quoi changer et dans quel ordre.
• Modification d’un module : Toucher une partie précise du code.
• Tests : Lancer, corriger, vérifier les cas limites.
• Nettoyage : Supprimer les restes, harmoniser, documenter si besoin.

Pour garder le fil entre deux sessions, je termine avec un résumé opérationnel très court. Pas un roman. Juste ce qu’il faut pour reprendre sans recharger toute l’ancienne conversation.

• Fait : Migration du module auth vers la nouvelle API.
• Fichiers : src/auth/login.ts, src/auth/session.ts, tests/auth.test.ts.
• Reste à faire : Vérifier les erreurs 401 côté front.
• Attention : Ne pas modifier le format du token JWT, il est utilisé par l’app mobile.

Il y a quand même un piège inverse. Trop découper crée de la friction. Si chaque session ne produit qu’un micro-changement, on perd du temps à relancer, résumer, réexpliquer. Je vise une taille de tâche assez petite pour tenir dans la session, mais assez grande pour sortir avec un vrai résultat.

Le bon découpage transforme une limite technique en cadence de travail propre.

Quels réflexes rendre automatiques ?

Les meilleurs gains viennent quand la gestion des tokens devient un réflexe d’équipe, pas une astuce qu’on applique seulement quand la session bloque. Avec Claude Code, je cherche surtout à éviter le bruit. Moins l’agent lit de choses inutiles, plus il raisonne proprement sur ce qui compte.

Les cinq compétences que je rends systématiques sont simples, mais elles changent tout.

• Savoir résumer un projet dans CLAUDE.md. Je mets l’architecture, les commandes utiles, les conventions, les pièges connus. Pas l’historique complet du produit. CLAUDE.md doit aider l’agent à démarrer vite, pas devenir une documentation fourre-tout.
• Savoir briefer une tâche. Je donne l’objectif, les fichiers concernés, les contraintes, puis le résultat attendu. Exemple simple : “Modifie tel composant, garde cette API, ajoute le test, ne touche pas au design system”.
• Savoir réduire le contexte. Je n’envoie pas tout le repo “au cas où”. Je donne les fichiers utiles, les erreurs exactes, les logs propres, et je retire les morceaux qui n’aident pas.
• Savoir contrôler le format des réponses. Je demande une réponse courte, un diff, une liste d’actions, ou seulement les fichiers à modifier. Sinon l’agent peut partir dans une explication longue qui consomme des tokens sans faire avancer le code.
• Savoir clôturer une session. Je termine avec un résumé compact de reprise : ce qui a été fait, ce qui reste, les fichiers touchés, les décisions prises, les commandes à relancer.

J’ai vu ça chez plusieurs clients. Les équipes qui gagnent le plus ne sont pas forcément celles qui ont les prompts les plus sophistiqués. Ce sont celles qui standardisent leurs briefs et qui évitent de réexpliquer le projet dix fois à chaque nouvelle session.

Avant une session, je vérifie quelques points concrets.

• Le fichier CLAUDE.md est à jour et lisible.
• La tâche tient en une demande claire.
• Les fichiers utiles sont identifiés.
• Les contraintes importantes sont écrites noir sur blanc.
• Le format de sortie attendu est précisé.

Pendant la session, je garde aussi quelques réflexes.

• Je coupe les digressions dès qu’elles apparaissent.
• Je demande des réponses courtes quand je veux juste décider.
• Je relance avec un contexte minimal, pas avec tout l’historique.
• Je fais résumer avant une grosse bascule de sujet.
• Je clôture dès que la tâche est stable.

La gestion des tokens, ce n’est pas de l’optimisation pour faire joli. C’est de la productivité. Moins de contexte inutile, c’est plus de temps passé sur le code, moins de sessions interrompues, et moins d’erreurs liées à un contexte confus.

Et si vos tokens devenaient un vrai levier de productivité ?

La gestion des tokens dans Claude Code, c’est surtout une question d’hygiène de travail. Je prépare le contexte une fois, je garde les fichiers propres, je découpe les grosses tâches, je demande des réponses utiles et je termine chaque session avec un point de reprise clair. Rien de magique là-dedans, mais ça change beaucoup de choses au quotidien. On évite les conversations qui gonflent, les sessions qui coupent au mauvais moment et les prompts qui repartent de zéro. Le bénéfice pour vous est simple : plus de continuité, moins de friction, et des sessions Claude Code vraiment plus productives.

FAQ

• Pourquoi Claude Code consomme autant de tokens ?
  Claude Code consomme des tokens avec les messages, les fichiers inclus, les réponses générées et le contexte qui revient dans la conversation. Le problème vient souvent de fichiers trop longs, de prompts flous et d’explications répétées plusieurs fois.
• À quoi sert un fichier CLAUDE.md ?
  Un fichier CLAUDE.md sert à donner à Claude Code les informations stables du projet : architecture, stack, conventions, commandes utiles et règles récurrentes. L’intérêt, c’est d’éviter de répéter ce contexte dans chaque prompt.
• Faut-il envoyer tous les fichiers du projet à Claude Code ?
  Non, il vaut mieux envoyer uniquement les fichiers vraiment utiles à la tâche. Une arborescence compacte peut suffire pour donner la structure, puis quelques extraits ciblés permettent de travailler sans saturer inutilement la fenêtre de contexte.
• Comment réduire les réponses trop longues de Claude Code ?
  Je demande un format de réponse précis : juste le code, pas de résumé, pas d’explication, ou uniquement la liste des fichiers à modifier. Il faut garder les explications pour les décisions importantes, pas pour chaque petite modification.
• Quelle est la meilleure façon de découper une grosse tâche ?
  Je sépare l’analyse, la modification, les tests et le nettoyage. Chaque session doit avoir un objectif clair et un périmètre limité. À la fin, je garde un résumé court avec ce qui a été fait, les fichiers touchés et ce qui reste à faire.

 

 

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 concrètement, dans leurs workflows, leur code, leurs données et leurs process business. Avec mon agence webAnalyste et l’organisme Formations Analytics, j’ai travaillé pour des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez mettre l’IA au service de vos équipes sans perdre du temps dans des usages flous, contactez-moi.