Comment gérer les tokens dans Claude Code ?

Je gère les tokens dans Claude Code en cadrant mieux la session, en limitant le contexte envoyé et en évitant les réponses trop longues. Le vrai sujet, c’est pas la taille du modèle. C’est ce qu’on lui donne à lire, et combien de fois on le répète.

Qu’est-ce qui consomme vos tokens ?

Les tokens partent surtout dans les fichiers trop longs, les échanges de clarification et le contexte répété plusieurs fois.

Un token, c’est juste un petit morceau de texte que le modèle lit ou écrit. Dans Claude Code, chaque message que vous envoyez, chaque réponse générée, chaque fichier inclus dans la conversation consomme une partie de la fenêtre de contexte. Cette fenêtre, c’est la quantité d’information que Claude peut garder “en tête” pendant la session.

Le problème arrive vite. Vous collez 500 lignes de code alors que 20 lignes autour de la fonction suffisent. Vous laissez Claude détailler chaque modification comme dans un compte rendu de réunion. Vous répétez à chaque prompt la stack, l’architecture, les conventions de nommage, les contraintes métier. Sur le moment ça paraît prudent. En réalité, ça remplit la session avec du bruit.

Je le vois souvent chez des équipes dev. Le gaspillage ne vient pas d’un mauvais outil. Il vient d’un réflexe assez naturel. On envoie trop large “au cas où”. On donne tout le fichier, tout le module, parfois tout le contexte produit, alors que la demande porte sur une erreur précise ou une petite refacto.

Premier drain : Les fichiers volumineux. Plus un fichier est long, plus Claude doit lire de tokens avant même de répondre. Si vous bossez sur une fonction, envoyez la fonction, ses imports utiles, le message d’erreur, et éventuellement le contrat attendu. Pas tout le repository.

Deuxième drain : La conversation trop verbeuse. Si Claude explique pendant 80 lignes ce qu’il a changé, ça consomme aussi. Demandez des réponses courtes, un patch ciblé, ou seulement les fichiers modifiés quand vous êtes en phase d’exécution.

Troisième drain : La réinjection du même contexte. Répéter dix fois “on utilise Next.js, Prisma, PostgreSQL, conventions X” coûte cher. Mieux vaut garder un contexte stable dans un fichier de consignes ou le rappeler uniquement quand ça sert vraiment.

Comprendre ces trois drains permet d’allonger une session sans changer d’outil. Vous ne rendez pas Claude plus puissant. Vous lui donnez juste moins de choses inutiles à porter.

Source de consommation	Exemple concret	Correction simple
Fichiers volumineux	Coller 500 lignes pour corriger une fonction	Envoyer seulement les 20 à 40 lignes utiles
Conversation trop verbeuse	Demander une explication complète à chaque changement	Demander une réponse courte ou un patch ciblé
Contexte répété	Rappeler la stack et les conventions à chaque prompt	Centraliser les consignes et ne rappeler que le nécessaire

Comment préparer une session efficace ?

Une session efficace se prépare avant d’ouvrir une longue conversation avec Claude Code.

Je commence souvent par mettre un fichier CLAUDE.md à la racine du projet. Ce fichier sert de mémoire persistante pour Claude Code : architecture, conventions de nommage, stack technique, commandes utiles, chemins importants, règles métier, choses à ne pas toucher. Ça évite de répéter les mêmes consignes à chaque demande, et franchement, sur un gros projet, ça change tout.

Je cadre aussi la tâche avant de lancer Claude. Pas besoin d’écrire un roman, mais il faut donner les bons repères. Les fichiers concernés, l’état final attendu, les contraintes, les limites à respecter. Un brief précis coûte beaucoup moins cher qu’une série de questions-réponses floues. Chaque aller-retour consomme des tokens, et souvent le modèle finit par déduire des choses qu’on aurait pu lui dire dès le départ.

Je fais aussi attention aux fichiers que j’inclus. Si un fichier contient 800 lignes dont 500 ne servent pas au problème, je n’envoie pas tout par réflexe. Je retire les commentaires non pertinents, les imports inutilisés, le code mort, le boilerplate qui n’aide pas Claude à comprendre. Attention, je ne parle pas de modifier le projet n’importe comment. Je parle de donner à Claude Code une version utile du contexte, pas une benne entière de code.

Pour les grosses demandes, je fractionne. Une session doit viser une unité de travail claire. Corriger un bug précis. Ajouter un endpoint. Refactorer un composant. Pas “refais-moi toute l’architecture” si le contexte sature déjà. J’ai vu ça chez un client sur une app Next.js assez massive : dès qu’on découpait par dossier et par objectif, Claude devenait beaucoup plus fiable.

Je colle aussi une cartographie projet limitée. Une sortie tree du dossier concerné suffit souvent, au lieu d’envoyer tout le dépôt.

src/features/billing
├── components
│   └── InvoiceTable.tsx
├── api
│   └── invoices.ts
└── types.ts

Mon brief ressemble généralement à ça :

<p><strong>Contexte</strong> : Application Next.js avec une feature billing existante.</p>
<p><strong>Objectif</strong> : Ajouter un filtre par statut dans la table des factures.</p>
<p><strong>Fichiers</strong> : src/features/billing/components/InvoiceTable.tsx, src/features/billing/types.ts.</p>
<p><strong>Contraintes</strong> : Ne pas modifier l’API, garder les conventions TypeScript actuelles.</p>
<p><strong>Tâche</strong> : Proposer le patch minimal et expliquer les changements.</p>

Comment parler à Claude sans gaspiller ?

Il faut demander moins de texte, moins d’explications et plus d’actions ciblées.

Dans Claude Code, chaque réponse compte. Pas seulement le code généré. La conversation elle-même devient une source de consommation. Si Claude vous répond avec trois paragraphes de contexte, un rappel de ce que vous avez demandé, un préambule du style “Je vais analyser le fichier”, puis un résumé final, tout ça part dans les tokens. Et comme ces tokens restent dans le contexte de la session, ils réduisent la marge disponible pour la suite.

Le hack est bête, mais vraiment efficace : il faut cadrer la forme de réponse. Quand vous savez déjà ce que vous voulez, demandez explicitement pas d’explications, juste le code, skip preamble, donne uniquement le diff, ou réponds court. Ça marche très bien pour les corrections simples, les refactors ciblés, la génération de tests, ou l’ajustement d’un fichier déjà identifié.

Voici des formulations que j’utilise souvent, prêtes à copier :

• Modifie uniquement ce fichier. Pas de résumé. Donne seulement le code final.
• Skip preamble. Applique la correction directement. Réponds uniquement avec le diff.
• Pas d’explications. Ajoute uniquement les tests manquants dans ce fichier.
• Réponds court. Liste uniquement les fichiers à modifier et pourquoi en une phrase chacun.
• Ne réexplique pas le contexte. Corrige seulement l’erreur signalée.

Si vous voulez être encore plus strict, vous pouvez écrire ça :

Modifie uniquement src/api/users.ts.
Pas de préambule.
Pas de résumé.
Donne uniquement le diff final.

La limite, c’est le raisonnement. Si vous arbitrez une architecture, si vous cherchez un bug tordu, ou si plusieurs options techniques sont possibles, zéro explication peut vous faire perdre du temps. Dans ce cas, je demande une explication courte. Pas un roman. Juste le raisonnement utile.

Explique en 5 lignes maximum le problème probable.
Puis propose la correction la plus simple.
Pas de résumé final.

J’ai vu des sessions tenir beaucoup plus longtemps simplement en coupant les préambules et les récap automatiques. C’est basique, presque trop simple, mais ça marche. Et sur une grosse base de code, cette discipline fait une vraie différence.

Comment réduire le contexte redondant ?

Il faut centraliser le contexte stable et ne renvoyer que le contexte qui change vraiment. C’est le levier le plus simple pour réduire les tokens dans Claude Code, et franchement, c’est souvent là que je vois le plus de gaspillage chez les équipes.

La redondance coûte cher. Si je répète à chaque demande la stack technique, les règles de nommage, les choix d’architecture, les contraintes métier, les conventions Git ou la façon de structurer les tests, je remplis la fenêtre de contexte avec des infos déjà connues. Claude Code peut les relire, oui, mais vous payez en tokens et vous réduisez la place disponible pour le vrai sujet du moment.

Le bon réflexe, c’est de séparer les couches de contexte. Le fichier CLAUDE.md garde le contexte projet stable. Le brief dans le prompt sert à cadrer la tâche en cours. L’inclusion ciblée de fichiers sert à montrer uniquement la partie utile du code, pas tout le dépôt “au cas où”.

Je fais souvent ça avec mes clients quand leur usage de Claude Code devient flou. On pose une règle simple :

• Le permanent va dans CLAUDE.md : Stack, conventions, architecture, règles métier stables.
• La tâche va dans le prompt : Objectif, contrainte du moment, résultat attendu.
• Le fichier va en extrait ciblé : Fonction concernée, composant modifié, test à corriger.

Il y a aussi un point qu’on sous-estime : les grosses tâches doivent être découpées. Si je garde une discussion ouverte pendant deux heures, avec quinze corrections, trois pistes abandonnées et des bouts de code intermédiaires, je transporte trop d’historique conversationnel. À un moment, il vaut mieux repartir proprement avec un brief court sur l’étape suivante. Claude Code n’a pas besoin de toute la saga, il a besoin de l’état actuel, de l’objectif, et des fichiers utiles.

Où mettre l’information	À mettre	À éviter
CLAUDE.md	Conventions projet, stack, architecture, règles métier stables, commandes importantes.	Demandes ponctuelles, bugs du jour, détails temporaires.
Prompt	Objectif précis, contexte de la tâche, contraintes immédiates, résultat attendu.	Répéter toute la documentation projet déjà présente dans CLAUDE.md.
Fichiers inclus	Extraits utiles, fichiers directement concernés, tests liés à la modification.	Inclure tout le dossier, tout le dépôt, ou des fichiers sans lien direct.
Conversation	Étapes courtes, décisions récentes, prochaines actions claires.	Continuer une discussion trop longue avec trop d’historique inutile.

Quels réflexes garder à chaque session ?

Les bons réflexes sont de préparer, réduire, cadrer, puis nettoyer la conversation au fil de l’eau.

Avant une session Claude Code, je gagne du temps en préparant le terrain. Je vérifie les fichiers utiles, je retire ce qui n’a rien à voir, et je mets les règles importantes dans CLAUDE.md. Ce fichier sert de mémoire de travail au projet : conventions, commandes, architecture, pièges connus. Ça évite de tout répéter à chaque prompt.

Au début, je donne une tâche claire. Pas “améliore ce module”, plutôt “corrige ce bug dans tel fichier, sans modifier l’API publique, et propose le patch le plus petit possible”. Claude Code travaille mieux quand je lui ferme des portes. C’est un peu contre-intuitif, mais plus je cadre, moins il consomme de tokens pour deviner.

Pendant la session, je limite les réponses. Je demande souvent “réponds sans préambule”, “ne résume pas les fichiers”, ou “donne seulement le diff et les commandes à lancer”. Après une étape, je repars court. Je ne recopie pas tout l’historique. Je dis ce qui vient d’être validé, ce qui bloque, et la prochaine action attendue.

Ma checklist courte ressemble à ça :

• CLAUDE.md propre : Je garde les règles stables du projet au même endroit.
• Brief structuré : Je donne l’objectif, les contraintes, les fichiers concernés, le résultat attendu.
• Fichiers épurés : Je retire les logs, dumps, vieux prompts et contenus inutiles.
• Tâche fractionnée : Je découpe en petites demandes vérifiables.
• Arborescence limitée : Je pointe seulement les dossiers utiles.
• Réponses sans préambule : Je demande du concret, pas un roman.
• Contexte non répété : Je résume l’état courant au lieu de recoller toute la conversation.

Ce qui est intéressant, c’est que ces réflexes ne servent pas qu’à Claude Code. Je les réutilise avec ChatGPT, Gemini, Cursor, Copilot, ou même dans des automatisations low code. Ils obligent à formuler le problème, isoler les bons fichiers et limiter le bruit. Chez un client, on a juste clarifié les briefs et réduit les fichiers envoyés aux assistants IA. Le gain a été immédiat : moins de réponses hors sujet, moins de lenteur, moins de corrections derrière.

Situation	Action à prendre
La session devient lente	Je réduis le contexte, je ferme les fichiers inutiles, et je repars sur une demande courte.
Claude se perd	Je reformule l’objectif, je donne les contraintes, et je limite la tâche à un seul résultat.
Les réponses sont trop longues	Je demande une réponse sans préambule, avec uniquement le diff, les commandes ou les points bloquants.
Le contexte est répété	Je renvoie un résumé minimal de l’état actuel au lieu de recopier tout l’historique.

Et si le vrai levier était votre contexte ?

Gérer les tokens dans Claude Code, c’est surtout apprendre à ne pas tout envoyer tout le temps. Je prépare un CLAUDE.md, je cadre la tâche, je limite les fichiers, je coupe les explications inutiles et je découpe les gros sujets. Rien de magique, mais c’est souvent là que la différence se fait. Une session plus propre donne des réponses plus nettes, moins d’allers-retours, moins de contexte perdu. Et ça rend aussi votre façon de travailler avec l’IA plus robuste. Le bénéfice est simple : vous gardez plus de marge dans vos sessions et vous avancez plus vite avec moins de bruit.

FAQ

• Pourquoi Claude Code consomme autant de tokens ?
  Claude Code consomme des tokens avec vos messages, ses réponses et les fichiers que vous incluez dans la session. Le plus gros gaspillage vient souvent des fichiers trop longs, des explications inutiles et du même contexte répété plusieurs fois.
• À quoi sert un fichier CLAUDE.md ?
  Un fichier CLAUDE.md sert à garder un contexte projet stable : architecture, conventions, stack, règles importantes. L’intérêt, c’est d’éviter de recoller ces informations dans chaque prompt. Vous économisez des tokens et Claude Code comprend plus vite votre cadre de travail.
• Faut-il envoyer tous les fichiers à Claude Code ?
  Non. Il vaut mieux envoyer uniquement les fichiers ou extraits vraiment utiles à la tâche. Si 20 lignes suffisent pour comprendre le problème, envoyer 500 lignes ajoute du bruit et réduit la fenêtre de contexte disponible.
• Comment réduire les réponses trop longues de Claude Code ?
  Vous pouvez demander explicitement des réponses courtes : pas d’explications, juste le code, skip preamble, donne uniquement le diff. C’est très utile pour les corrections ciblées, les petits refactors ou la génération de tests simples.
• Quelle est la meilleure habitude pour économiser des tokens ?
  La meilleure habitude, c’est de cadrer la tâche avant de lancer la session. Un brief court avec contexte, objectif, fichiers, contraintes et tâche évite les allers-retours. Et les allers-retours sont souvent ce qui vide le plus vite votre contexte.

 

 

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 pour produire mieux, automatiser plus intelligemment et garder le contrôle sur leurs process. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez structurer vos usages IA et automatisation dans votre business, contactez-moi.