Comment mieux gérer les tokens dans Claude Code en session ?

Je gère les tokens dans Claude Code en préparant le contexte, en découpant les tâches et en limitant les réponses inutiles. Le vrai sujet, c’est pas d’avoir une session plus longue, c’est d’éviter de brûler du contexte sur du bruit.

Pourquoi les tokens partent si vite ?

Les tokens partent vite parce que Claude Code garde dans sa fenêtre de contexte l’historique de conversation, les fichiers fournis et ses propres réponses, même quand une partie n’est plus utile.

La fenêtre de contexte, c’est simplement la mémoire de travail de Claude pendant la session. C’est ce qu’il peut “voir” à un instant donné pour répondre correctement. Vos messages, le code que vous collez, les fichiers que vous lui donnez, ses analyses précédentes, ses propositions de correction… Tout ça prend de la place.

Le piège, c’est de croire que le problème vient seulement de la taille du projet. En réalité, ce qui coûte cher, c’est surtout ce qu’on met dans la session. Un petit projet mal présenté peut consommer plus qu’un gros projet bien cadré.

Je vois surtout trois sources de gaspillage :

• Envoyer des fichiers entiers alors qu’une fonction suffit. Si le bug est dans une fonction de 40 lignes, coller 900 lignes autour n’aide pas forcément. Ça noie le signal.
• Multiplier les échanges longs avec des explications redondantes. À force de reformuler le même besoin, on empile du texte qui ne sert plus vraiment.
• Réexpliquer plusieurs fois le même contexte. C’est fréquent quand on démarre mal. On ajoute une précision, puis une autre, puis on corrige la précédente. Claude garde tout ça, même les morceaux devenus obsolètes.

Quand le contexte commence à saturer, Claude Code peut perdre une partie de l’ancien contexte ou moins bien l’exploiter. Et là, la qualité baisse. Il oublie une contrainte, il propose une modification incohérente, il vous redemande une info déjà donnée. Ce n’est pas forcément qu’il “comprend moins bien”, c’est juste qu’on lui a mis trop de choses dans la tête en même temps.

J’ai eu le cas avec un client qui collait quasiment tout son projet dans la session, puis s’étonnait que Claude perde le fil au bout de quelques demandes. Le souci n’était pas Claude. Le souci, c’était la session transformée en grenier.

Avant de lancer Claude Code, je préfère donc préparer ce que je lui donne. Moins de bruit, plus de contexte utile, et une session qui tient beaucoup mieux dans la durée.

Comment préparer Claude Code avant la session ?

Je prépare Claude Code en lui donnant un contexte stable, court et réutilisable avant de lui demander de coder. C’est tout bête, mais ça change beaucoup de choses sur la consommation de tokens, parce que je ne repars pas de zéro à chaque message.

Le fichier le plus utile pour ça, c’est CLAUDE.md, placé à la racine du projet. Je m’en sers comme mémoire projet durable. Dedans, je mets les infos qui reviennent tout le temps : architecture, conventions, stack technique, règles de nommage, commandes utiles, contraintes métier, pièges connus. Claude Code peut s’appuyer dessus sans que je recolle les mêmes explications dans chaque prompt.

Je garde ce fichier court. Pas besoin d’écrire un roman. Un bon CLAUDE.md, c’est plutôt une fiche terrain qu’une documentation complète. Chez un client, on avait divisé par deux les échanges inutiles juste en posant les conventions de dossiers, les commandes de test et les règles d’API dans ce fichier. Rien de magique. Juste moins de bruit.

Avant la session, je prépare aussi un brief de tâche. Je précise les fichiers concernés, l’état actuel, l’état final attendu, les contraintes, et surtout ce qu’il ne faut pas toucher. Cette partie évite les changements trop larges, le fameux “j’ai corrigé le bug mais j’ai réécrit la moitié du module”.

<ul>
  <li><strong>Fichiers concernés :</strong> src/api/users.ts, src/services/auth.ts</li>
  <li><strong>État actuel :</strong> La validation du token expire mal côté refresh</li>
  <li><strong>État final attendu :</strong> Le refresh token doit être rejeté après expiration réelle</li>
  <li><strong>Contraintes :</strong> Garder la signature publique des fonctions existantes</li>
  <li><strong>À ne pas toucher :</strong> Base de données, routes publiques, format des réponses API</li>
</ul>

J’élague aussi les fichiers avant de les fournir. Je retire les commentaires inutiles, les imports morts, le code mort, le boilerplate qui n’aide pas la tâche. Le but n’est pas de cacher des infos, c’est de ne pas faire payer à Claude Code des tokens pour lire du bruit.

Je donne souvent une carte du projet avec une arborescence réduite. Ça donne une vision spatiale sans envoyer tous les fichiers. Par exemple : src/api pour les routes, src/services pour la logique métier, src/db pour l’accès aux données. Les pratiques documentées autour de Claude Code vont clairement dans ce sens : mieux vaut un contexte projet durable qu’un contexte conversationnel répété dix fois.

Préparation	Gain attendu	Risque évité
CLAUDE.md à la racine	Moins de répétition	Contexte oublié ou contradictoire
Brief de tâche clair	Réponse plus ciblée	Modifications trop larges
Fichiers élagués et carte projet	Moins de tokens consommés	Analyse noyée dans le bruit

Comment découper une grosse demande ?

Je découpe une grosse demande en petites unités qui peuvent être terminées dans une seule session sans saturer le contexte. C’est la règle la plus simple que j’utilise avec Claude Code, surtout quand je sens qu’une tâche peut partir dans tous les sens.

Une demande trop large pousse Claude Code à lire trop de fichiers, à produire trop d’explications, puis à garder trop d’historique dans la conversation. Le contexte, c’est la mémoire active du modèle pendant la session. Plus on la remplit avec des détails inutiles, plus il devient flou, lent, et parfois trop sûr de lui sur des choses qu’il n’a pas vraiment vérifiées.

Un gros refactoring, une migration ou une nouvelle fonctionnalité ne devrait pas être demandé en une seule fois. Je préfère fractionner par objectif clair. Par exemple, au lieu de dire “refactor toute la gestion des paiements”, je demande une étape précise, vérifiable, avec une sortie attendue.

Dans la pratique, je découpe souvent comme ça :

• Comprendre le flux existant, sans modifier le code.
• Identifier les fichiers réellement concernés.
• Modifier une seule fonction ou un seul module.
• Ajouter ou corriger un test ciblé.
• Nettoyer les imports et les dépendances inutiles.
• Vérifier les impacts sur les appels existants.

Le fil conducteur ne doit pas forcément vivre dans la conversation. Je préfère le mettre dans CLAUDE.md ou dans un brief court à la racine du projet. CLAUDE.md sert de mémo projet pour Claude Code : conventions, objectifs, contraintes, commandes utiles. Comme ça, je ne lui demande pas de se souvenir de toute la stratégie dans l’historique de chat.

Découper le travail, ce n’est pas perdre du temps. C’est l’inverse. Ça évite les allers-retours, les corrections massives, et les réponses où Claude mélange analyse, hypothèses et implémentation. J’ai vu des équipes gagner plus en cadrant mieux qu’en cherchant un modèle plus gros.

Demande trop large	Demande bien découpée
Refactor toute l’authentification.	Analyse le flux de login et liste les fichiers concernés.
Migre toute l’API vers la nouvelle version.	Migre uniquement l’endpoint /users, avec tests associés.
Ajoute la fonctionnalité complète de facturation.	Crée le modèle de facture, sans toucher à l’interface.
Corrige tous les problèmes du projet.	Corrige les imports inutilisés dans ce dossier précis.

Comment parler à Claude Code pendant la session ?

Pendant la session, je parle à Claude Code avec des consignes courtes, explicites et orientées résultat. Je pars du principe que chaque mot compte, pas seulement dans ma demande, mais aussi dans sa réponse.

Il y a un piège assez classique avec Claude Code : on lui demande une petite modification, et il répond avec un plan, une explication, un résumé, puis le code. C’est souvent propre, mais ça consomme des tokens pour rien. Quand je veux juste du code, je le dis clairement.

J’utilise souvent ce genre de consignes :

• Pas d’explications, juste le code.
• Donne seulement l’implémentation.
• Pas de récapitulatif.
• Modifie uniquement ce fichier.
• Réponds en patch minimal.

Ce sont des phrases simples, mais elles changent beaucoup de choses. Claude évite les justifications, les plans trop longs, les rappels de contexte et les conclusions inutiles. Sur une session de code, ça peut réduire fortement la taille des réponses, surtout quand on enchaîne plusieurs petites modifications.

Je fais aussi attention à ne pas ouvrir trop de portes. Si j’ai besoin d’une solution, je ne demande pas trois options. Si le contexte est déjà dans la session, je ne le recolle pas à chaque message. Et j’évite les relances vagues du style Tu peux améliorer ça ?. C’est le meilleur moyen de récupérer une réponse longue, générale, et pas toujours actionnable.

Je préfère écrire quelque chose comme :

Corrige uniquement le bug dans auth.ts.
Ne change pas l'API publique.
Pas d'explication.
Réponds en patch minimal.

Bien sûr, je ne coupe pas toutes les explications tout le temps. Quand une modification touche à la sécurité, à une migration de données, à une logique métier sensible, je demande à Claude de justifier sa décision. Mais je le fais volontairement. Pas par défaut.

La préparation de la session joue beaucoup ici. Si j’ai déjà donné les bons fichiers, les contraintes, l’objectif et les règles du projet, mes consignes courtes deviennent beaucoup plus efficaces. Claude n’a pas besoin de deviner. Il exécute.

Ma checklist pendant la session :

• Je demande une seule chose à la fois.
• Je précise le fichier ou la zone à modifier.
• Je coupe les explications quand elles ne servent à rien.
• Je demande un patch minimal dès que possible.
• Je ne recolle pas tout le contexte à chaque tour.
• Je demande une explication seulement quand le risque le justifie.

Quelles habitudes garder à chaque projet ?

Les bonnes habitudes à garder sont celles qui rendent le contexte plus petit, plus stable et plus actionnable à chaque session. C’est vraiment comme ça que je vois Claude Code au quotidien. Pas comme une machine à qui je balance tout le projet en vrac, mais comme un collègue très rapide qui travaille mieux quand le cadre est propre.

La routine que je garde, et que je conseille aux équipes comme aux freelances, est assez simple. Avant de lancer une session, je vérifie que CLAUDE.md est à jour, avec les règles du projet, les commandes utiles, les conventions, les pièges connus. Ce fichier sert de mémoire stable. Ça évite de répéter les mêmes consignes à chaque fois.

Ensuite, je prépare un brief court. Pas un roman. Juste le problème, les fichiers concernés, le résultat attendu, et les contraintes. J’ai vu un client diviser par deux ses allers-retours juste avec ça. Avant, Claude partait dans tous les sens. Après, il avait un angle clair.

Je nettoie aussi le contexte. Les vieux logs, les fichiers générés, les bouts de code morts, les discussions copiées-collées trois fois… Tout ça consomme des tokens pour rien. Un token, c’est un morceau de texte que le modèle doit lire et traiter. Plus il y en a, plus la session devient lourde, chère, et parfois confuse.

La meilleure routine ressemble à ça :

• Je maintiens CLAUDE.md comme une documentation vivante.
• Je donne une carte projet quand l’architecture n’est pas évidente.
• Je découpe les demandes en petites tâches vérifiables.
• Je demande des réponses courtes quand je veux juste une décision ou un patch.
• Je ne réinjecte pas le même contexte si Claude l’a déjà dans la session.

La gestion des tokens, ce n’est pas une astuce ponctuelle. C’est une hygiène de travail avec les assistants IA de code. Moins de bruit, ça veut dire moins de malentendus, moins de corrections inutiles, moins de perte de contexte. Et surtout des sessions plus propres, où Claude Code reste concentré sur le vrai sujet.

Habitude	Pourquoi ça économise des tokens	Quand l’utiliser
Maintenir CLAUDE.md	Les consignes stables ne sont pas répétées dans chaque prompt.	À chaque projet actif.
Préparer un brief court	Claude lit uniquement le problème utile.	Avant chaque nouvelle session.
Nettoyer les fichiers	Les éléments inutiles ne polluent pas l’analyse.	Avant une grosse modification.
Fournir une carte projet	Claude comprend plus vite où agir.	Quand le projet est large ou ancien.
Découper les tâches	Chaque session reste ciblée et légère.	Pour les bugs, refontes et features.
Limiter les réponses	Les sorties longues ne saturent pas le fil.	Quand je veux une réponse opérationnelle.

Le but n’est pas de parler moins à Claude Code. Le but, c’est de lui donner moins de bruit, pour qu’il comprenne mieux et qu’il produise plus juste.

Et si le vrai gain venait surtout du contexte ?

La gestion des tokens dans Claude Code, c’est surtout une affaire de discipline. Je prépare le terrain avec un CLAUDE.md utile, un brief clair, des fichiers nettoyés et une carte projet légère. Ensuite je découpe les demandes, je limite les réponses longues et j’évite de répéter le même contexte. Rien de magique là-dedans, mais ça change vraiment la qualité des sessions. Claude Code suit mieux, répond plus court, se disperse moins. Pour vous, le bénéfice est simple : vous gardez plus longtemps un contexte exploitable et vous avancez plus vite sur le code utile.

FAQ

• Qu’est-ce qui consomme le plus de tokens dans Claude Code ?
  Ce qui consomme le plus, c’est souvent le contexte inutile : fichiers trop longs, historique de conversation verbeux, réponses détaillées du modèle et répétition des mêmes informations. Le code compte, bien sûr, mais le bruit autour du code pèse vite lourd.
• À quoi sert le fichier CLAUDE.md ?
  CLAUDE.md sert à stocker le contexte récurrent du projet : architecture, stack, conventions, commandes utiles, contraintes. L’intérêt, c’est d’éviter de redonner ces informations à chaque session ou à chaque message.
• Faut-il envoyer tous les fichiers du projet à Claude Code ?
  Non, c’est rarement une bonne idée. Je préfère envoyer une arborescence courte, puis seulement les fichiers ou extraits vraiment utiles. Un fichier entier n’aide pas si la tâche concerne trois fonctions précises.
• Comment réduire les réponses trop longues de Claude Code ?
  Il faut le demander clairement. Par exemple : pas d’explications, juste le code ; donne uniquement l’implémentation ; pas de récapitulatif. Ça évite les réponses longues quand vous avez seulement besoin d’une modification concrète.
• Pourquoi découper les tâches économise des tokens ?
  Une tâche découpée demande moins de contexte, moins de fichiers et moins d’allers-retours. Claude Code reste concentré sur un objectif précis. La session est plus stable et vous réduisez le risque de perdre le fil en cours de route.

 

 

A propos de l’auteur

Je suis Franck Scandolera, responsable de l’agence webAnalyste et de l’organisme Formations Analytics. J’accompagne les entreprises sur le tracking avancé server-side, l’Analytics Engineering, l’automatisation No/Low Code avec n8n, l’intégration de l’IA dans les process métier et le SEO/GEO. J’ai travaillé avec des clients comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Si vous voulez industrialiser vos usages IA sans perdre du temps dans le flou, contactez-moi.