Comment optimiser les tokens Claude Code en session de code ?

J’optimise les tokens Claude Code en préparant mieux le contexte, en limitant les fichiers envoyés et en cadrant chaque échange. Le vrai sujet, ce n’est pas juste payer moins. C’est garder la session utile plus longtemps sans perdre le fil du projet.

Pourquoi les tokens partent si vite ?

Les tokens partent vite parce que Claude Code consomme tout ce qu’on lui donne à lire : le contexte de conversation, les fichiers ou morceaux de code inclus, et ses propres réponses. La fenêtre de contexte est limitée. Donc chaque prompt, chaque réponse, chaque fichier collé prend de la place. Sur un vrai projet, ça va très vite, surtout quand on travaille dans l’urgence et qu’on balance “tout le dossier” pour être sûr.

Le premier gros poste, c’est l’inclusion de fichiers trop longs. Quand je vois un client envoyer un fichier de 2 000 lignes alors que le bug est dans une fonction de 40 lignes, je sais déjà qu’on va brûler du contexte pour rien. Claude Code peut analyser beaucoup de choses, oui, mais ça ne veut pas dire qu’il faut tout lui mettre sous le nez à chaque fois.

Le deuxième poste, c’est les échanges trop verbeux. Des prompts flous, des réponses longues, puis trois allers-retours pour repréciser ce qu’on voulait au départ. Là, on paie en tokens pour clarifier une demande qui aurait pu être cadrée dès le début. Et au bout d’un moment, le contexte utile se dilue dans du bruit.

Le troisième poste, plus sournois, c’est la réinjection répétée du même contexte. On recolle les mêmes règles métier, le même extrait de code, la même erreur, la même architecture. C’est humain, on veut aider l’outil. Mais en réalité, on remplit la fenêtre avec des infos déjà vues ou qui devraient être stockées autrement, par exemple dans un fichier de notes projet, une convention claire, ou un résumé court.

Ces trois habitudes cassent la productivité. On perd du contexte, on doit recommencer, et on paie des tokens pour répéter ce que l’outil sait déjà ou pourrait retrouver plus proprement. Mon observation honnête, c’est que sur les projets de code, le problème vient rarement du modèle lui-même. Le vrai sujet, c’est la manière dont on lui sert le contexte. Une bonne gestion des tokens Claude Code, c’est d’abord une discipline de contexte.

Source de tokens	Risque	Réflexe à adopter
Fichiers trop longs	Le contexte se remplit avec du code inutile.	Donner seulement les fichiers ou fonctions concernés.
Échanges verbeux	Les allers-retours mangent la fenêtre de contexte.	Poser une demande courte, précise, avec l’objectif attendu.
Contexte répété	On paie plusieurs fois pour la même information.	Créer un résumé projet et le mettre à jour au lieu de tout recoller.

Que préparer avant la session ?

Avant la session, je prépare un contexte stable, une portée claire et un brief court pour éviter les clarifications inutiles. La préparation, c’est le meilleur levier pour économiser des tokens, parce qu’elle évite de brûler les premières minutes à expliquer le projet, la stack, les règles, les dossiers, puis à corriger les suppositions de Claude Code.

Je mets presque toujours un fichier CLAUDE.md à la racine du projet. Ce fichier sert de mémoire de démarrage. Il peut contenir l’architecture générale, les conventions de nommage, la stack technique, les commandes utiles, les règles de test, les zones sensibles, les patterns à respecter. L’idée est simple : je n’ai pas envie de recoller les mêmes infos à chaque session. Claude Code les lit au démarrage et part avec un socle propre.

Un bon CLAUDE.md peut rester très court. Pas besoin d’écrire un roman. Par exemple, j’y mets souvent :

• Le framework utilisé et les versions importantes.
• Les dossiers principaux et leur rôle.
• Les conventions de code à respecter.
• Les commandes pour tester, lint, build.
• Les fichiers ou modules à ne pas modifier sans raison.

Avant d’ouvrir Claude Code, je définis aussi la portée de la tâche. Quels fichiers sont concernés ? Quel état final j’attends ? Quelles contraintes il doit respecter ? Quelles limites je veux poser ? Une tâche floue crée mécaniquement des tours de conversation. Et chaque tour consomme des tokens pour clarifier ce qui aurait pu être dit dès le départ. Je l’ai vu chez un client sur une refonte React : on a divisé la session par deux juste en cadrant les composants touchés avant de lancer l’agent.

Voici le modèle de brief que j’utilise quand je veux aller vite :

Contexte :
Application Next.js avec API routes. Auth déjà en place.

Objectif :
Ajouter l’export CSV des utilisateurs filtrés.

Fichiers :
app/users/page.tsx
app/api/users/export/route.ts
lib/users.ts

Contraintes :
Ne pas modifier le modèle de données.
Garder le style existant.
Ajouter un test simple si nécessaire.

Tâche :
Implémenter l’export CSV et vérifier que le fichier respecte les filtres actifs.

Je prépare aussi une carte du projet plutôt que de donner tout le code. Une arborescence pertinente donne un contexte spatial sans remplir inutilement la fenêtre de contexte. Claude Code comprend où il est, sans devoir avaler 80 fichiers qui ne servent à rien.

app/
  users/
    page.tsx          # Liste et filtres utilisateurs
  api/
    users/
      export/route.ts # Endpoint CSV à créer
lib/
  users.ts            # Accès aux données utilisateurs
components/
  ui/                 # Ne pas modifier
prisma/
  schema.prisma       # Ne pas modifier

Le but n’est pas de tout documenter. Le but, c’est de donner juste assez de contexte pour que Claude Code fasse le bon travail sans poser dix questions avant de commencer.

Comment réduire le contexte envoyé ?

Je réduis le contexte envoyé en ne donnant à Claude Code que ce qui est utile à la tâche immédiate. Ça paraît évident, mais dans la pratique on a vite le réflexe de coller un fichier entier “par sécurité”. C’est confortable, oui. Mais c’est souvent le moyen le plus rapide de saturer la session et de faire perdre de la précision au modèle.

Quand j’inclus un fichier, je l’épure avant. Je retire les commentaires qui n’aident pas à comprendre le problème, les imports inutilisés, le code mort, le boilerplate, c’est-à-dire le code standard qui se répète partout, et les sections qui n’ont aucun rapport avec la demande. L’objectif n’est pas de cacher une information importante. L’objectif, c’est d’éviter que Claude Code consacre sa fenêtre de contexte à lire du bruit.

Un exemple simple. Si je veux corriger une fonction de validation, je n’ai pas besoin d’envoyer tout le module, tous les types, tous les tests, toute la config et trois fichiers voisins “au cas où”. Je peux donner la fonction, les types vraiment nécessaires, l’erreur, et éventuellement un test qui échoue. C’est souvent suffisant.

Je découpe aussi les gros chantiers. Une grosse refonte, ce n’est pas une bonne unité de travail pour une session. Je préfère la transformer en petites unités : une correction, une refonte ciblée, une évolution isolée, une vérification. C’est moins spectaculaire, mais beaucoup plus fiable.

Ce découpage aide aussi quand la session s’arrête ou quand le contexte devient trop lourd. On sait exactement ce qui a été fait, ce qui reste à faire, et on peut relancer une session propre sans traîner tout l’historique derrière soi.

J’ai souvent vu des équipes demander à l’IA de résoudre un sujet trop large, puis s’étonner que les réponses deviennent approximatives. Le souci, ce n’est pas forcément Claude Code. C’est la taille du paquet qu’on lui donne.

Avant d’envoyer du code à Claude Code, je vérifie ça :

• Ce fichier est-il vraiment nécessaire pour la tâche ?
• Cette section aide-t-elle Claude Code à comprendre ou à modifier le code ?
• Cette tâche tient-elle dans une seule session raisonnable ?
• Est-ce que je peux remplacer une partie du code par une arborescence ou une synthèse claire ?

Comment guider les réponses ?

Je guide les réponses en demandant explicitement du court, du ciblé, et parfois uniquement le code. C’est bête, mais ça change beaucoup de choses. Les réponses de Claude Code consomment aussi des tokens, pas seulement vos prompts ou les fichiers qu’il lit. Donc chaque longue explication automatique, chaque résumé trop généreux, chaque “voici ce que j’ai fait” a un coût direct dans la session.

Mon réflexe, quand l’explication n’apporte rien, c’est d’être très clair dans la consigne. Je demande pas d’explication, seulement le code, ou skip the preamble, ou encore réponds uniquement avec le diff utile. Le “diff”, c’est juste la partie modifiée du code, pas tout le fichier recopié. Sur des tâches répétitives, genre corriger 5 composants, ajouter un champ, renommer une fonction, ça réduit énormément la taille des réponses.

J’utilise souvent des formulations simples comme celles-ci :

• Réponds uniquement avec le code modifié, sans explication.
• Donne-moi seulement le patch à appliquer.
• Pas de préambule, pas de résumé, juste la solution.
• Si tu dois expliquer, fais-le en 3 lignes maximum.

Attention quand même, je ne coupe pas toutes les explications tout le temps. Quand on explore une architecture, une décision technique, ou un bug un peu tordu, l’explication peut être rentable. Elle évite de partir dans la mauvaise direction. Mais quand je sais déjà ce que je veux, je préfère éviter les préambules. Un client m’a déjà envoyé des sessions Claude Code avec des réponses ultra longues pour des corrections minuscules. Le problème n’était pas Claude. C’était la consigne trop ouverte.

Je limite aussi les échanges multi-tours. Je donne une consigne complète dès le départ, je demande une clarification seulement si c’est vraiment nécessaire, et j’évite de revenir trois messages plus tard avec un détail oublié. Un bon brief réduit les tours. Un contexte propre réduit les corrections. Une réponse courte garde la fenêtre disponible. C’est exactement comme ça qu’on économise des tokens sans perdre en qualité.

Situation	Consigne à donner	Pourquoi
Modification simple, tâche répétitive, correction évidente	Uniquement le code ou le diff utile	J’évite de payer des explications que je connais déjà.
Choix technique léger, doute ponctuel, comportement à valider	Explication courte, puis code	Je garde le raisonnement utile sans remplir la session.
Architecture, bug complexe, refactor risqué	Analyse plus longue acceptée	Je dépense plus de tokens, mais j’évite une mauvaise décision.

Comment rendre ces réflexes réutilisables ?

Je rends ces réflexes réutilisables en les transformant en routines de travail, pas en astuces isolées. Le vrai gain arrive quand j’applique les mêmes principes à chaque session Claude Code, et pas seulement les jours où je pense à “faire attention aux tokens”. Sinon, ça reste fragile. Un bon réflexe oublié une fois sur deux, ce n’est pas encore une méthode.

Dans mes sessions, je cherche surtout à éviter de répéter le même contexte, les mêmes contraintes, les mêmes explications. C’est là que les tokens partent vite. Et souvent pour rien.

Les routines que j’installe en priorité sont simples :

• Garder un CLAUDE.md propre, avec les règles du projet, les conventions de code, les commandes utiles, les pièges connus. Ce fichier sert de mémoire de travail à Claude Code.
• Utiliser toujours le même modèle de brief, avec l’objectif, les fichiers concernés, les contraintes, ce qu’il ne faut pas toucher, et le format de réponse attendu.
• Préparer une arborescence utile, pour éviter de demander à Claude d’explorer tout le dépôt quand trois fichiers suffisent.
• Découper les grosses tâches, parce qu’une demande énorme produit souvent une réponse énorme, donc plus de tokens, plus d’erreurs, plus de flou.
• Cadrer les réponses attendues, par exemple “réponds court”, “donne seulement le patch”, “liste les fichiers à modifier avant d’agir”.

Ces pratiques peuvent aussi devenir des skills ou des modèles de consignes réutilisables. Une skill, dans ce contexte, c’est juste une capacité préparée à l’avance avec ses règles, son contexte et sa façon de répondre. Ça évite de réécrire toujours le même brief. J’ai vu ça chez un client avec un gros monorepo : au début, chaque session repartait presque de zéro. Après quelques templates propres, Claude Code arrêtait de redemander le contexte évident, et les échanges devenaient beaucoup plus courts.

Le bénéfice business est très concret. Moins de tokens gaspillés. Moins de sessions interrompues. Moins de contexte perdu. Plus de livrables corrects par session. Avec un contexte mieux géré, viser 2 à 3 fois plus de productivité par session n’est pas délirant. Et quand ces principes sont industrialisés dans des routines réutilisables, les coûts de tokens baissent fortement.

Je commencerais petit. Un fichier CLAUDE.md, un template de brief, et une règle simple sur les réponses courtes. Pas besoin de tout automatiser le premier jour.

Mieux travailler avec Claude Code, c’est surtout mieux structurer son propre travail. Les tokens ne font que rendre visible ce qui était déjà flou.

Et si on arrêtait de payer du contexte inutile ?

La gestion des tokens Claude Code, ce n’est pas une optimisation de geek. C’est une manière de garder la session exploitable plus longtemps. Je prépare le contexte avec un CLAUDE.md, je cadre la tâche avant de démarrer, je nettoie les fichiers envoyés, je découpe les gros sujets et je demande des réponses courtes quand c’est suffisant. Ces réflexes évitent les allers-retours inutiles et les réexplications permanentes. Le gain est très concret : vous avancez plus vite, vous gardez le fil technique, et vous consommez moins de tokens pour produire le même résultat, souvent avec plus de qualité.

FAQ

• Qu’est-ce qui consomme des tokens dans Claude Code ?
  Les tokens sont consommés par vos prompts, l’historique de conversation, les fichiers ou extraits de code inclus, et les réponses générées par Claude Code. Les gros fichiers, les échanges trop longs et les répétitions du même contexte sont les principaux postes de gaspillage.
• À quoi sert un fichier CLAUDE.md ?
  Un fichier CLAUDE.md sert à donner un contexte persistant au projet : architecture, stack, conventions, règles de code et informations récurrentes. L’intérêt est simple : éviter de réexpliquer les mêmes choses à chaque session.
• Faut-il envoyer tous les fichiers à Claude Code ?
  Non, c’est rarement une bonne idée. Il vaut mieux envoyer les fichiers réellement concernés, nettoyer ce qui ne sert pas, et parfois fournir une arborescence plutôt que du code complet. Moins de bruit, c’est souvent une meilleure réponse.
• Comment éviter les allers-retours inutiles ?
  Le plus efficace est de préparer un brief clair avec le contexte, l’objectif, les fichiers concernés, les contraintes et la tâche attendue. Une demande précise réduit les clarifications, donc les tokens consommés pour rien.
• Quand demander une réponse courte à Claude Code ?
  Quand vous savez déjà ce que vous voulez, demandez une réponse courte, uniquement le code, ou uniquement le diff utile. Gardez les explications longues pour les décisions techniques, les bugs complexes ou les choix d’architecture.

 

 

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 rendre leurs workflows IA plus propres, mesurables et vraiment utiles au business. 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, vos automatisations ou vos données, contactez-moi.