Comment réduire les tokens Claude Code sans perdre le code ?

Je réduis les tokens Claude Code en cadrant mieux la session, en donnant moins de fichiers et en coupant les réponses inutiles. Le vrai sujet, c’est pas de coder moins. C’est d’arrêter de remplir la fenêtre de contexte avec du bruit.

Pourquoi Claude Code sature-t-il ?

Quand une session Claude Code part en vrille au bout d’une heure, ce n’est pas magique. C’est souvent juste une histoire de place. Claude Code travaille avec une fenêtre de contexte, c’est-à-dire une zone mémoire temporaire où il garde ce que vous lui avez donné pendant la session : vos demandes, ses réponses, les fichiers ouverts, les extraits de code, les consignes, les corrections, les hésitations.

Cette fenêtre n’est pas infinie. Elle se remplit avec des tokens. Un token, c’est un petit morceau de texte. Ça peut être un mot, une partie de mot, un symbole, une indentation, une ligne de code. Plus vous injectez de contenu, plus vous consommez de tokens.

Le piège, c’est que le problème ne vient pas seulement de la taille du projet. Il vient surtout de la façon dont on amène l’information dans Claude Code. J’ai vu ça chez un client récemment. Le développeur voulait corriger une fonction précise. Au lieu de coller les 40 lignes utiles, il a ajouté un fichier complet de 900 lignes. Puis il a ajouté trois longues explications sur l’historique du bug. Puis il a relancé quasiment la même question, avec encore plus de détails. Résultat, la session est devenue lourde, lente, confuse.

À ce moment-là, Claude Code peut encore répondre, mais il commence à perdre le fil. Les éléments anciens peuvent être résumés, compactés, ou simplement sortir du contexte vraiment utile. Et quand ça arrive, vous avez cette impression désagréable : “Il savait ça il y a dix minutes, pourquoi il l’oublie maintenant ?”

Ce qui entre dans la session	Ce que ça provoque
Fichiers complets inutiles	Beaucoup de tokens consommés pour peu de valeur
Explications longues et répétées	Contexte plus lourd, moins précis
Même question relancée plusieurs fois	Historique gonflé sans nouveau signal clair

Pour moi, c’est le point clé à comprendre avant d’optimiser quoi que ce soit. Claude Code ne sature pas juste parce que votre codebase est grosse. Il sature parce que la session accumule trop d’informations, parfois mal ciblées. Pour économiser des tokens sans perdre le code, il faut d’abord savoir ce qui les consomme vraiment.

Qu’est-ce qui mange les tokens ?

Les tokens ne disparaissent pas par magie. Ils partent dans ce que Claude Code doit lire, garder en contexte, puis produire en réponse. Et le piège, c’est qu’on pense souvent au code uniquement, alors qu’une grosse partie de la consommation vient de tout ce qu’on met autour.

Premier drain : les fichiers trop larges. C’est le classique. On donne un fichier entier de 800 lignes alors que seules deux fonctions comptent vraiment. Claude Code doit quand même absorber le reste, même si 80 % du fichier ne sert pas à résoudre le problème. Le bon réflexe, c’est de pointer la zone utile, ou de coller seulement les fonctions concernées avec un minimum de contexte autour.

Deuxième drain : les conversations trop longues. Quand la demande de départ est floue, on multiplie les allers-retours. “Tu peux regarder ?”, “Non pas comme ça”, “En fait il faut aussi tenir compte de…” Chaque clarification consomme des tokens. Je le vois souvent chez des équipes qui bossent vite, avec un besoin réel, mais pas encore formulé proprement. Une demande un peu plus cadrée au départ coûte moins cher qu’une discussion de dix messages.

Troisième drain : le contexte répété. Recoller encore et encore la même architecture, les mêmes règles métier, les mêmes contraintes API, ça finit par peser lourd. Claude Code ne lit pas magiquement tout votre projet avec une mémoire infinie. Il travaille avec ce qu’on lui donne dans la session et ce qui est disponible dans le contexte. Si vous répétez les mêmes infos à chaque prompt, vous payez plusieurs fois la même chose.

Sur des projets data ou tracking, j’ai souvent vu plus de tokens partir dans les explications autour du problème que dans le code à modifier. C’est un peu frustrant, mais c’est aussi là qu’on gagne vite. Demander des réponses sans explications peut réduire fortement la sortie, souvent de l’ordre de 30 à 50 % sur des tâches de code simples.

Source de consommation	Symptôme	Réflexe utile
Fichiers trop larges	Claude lit beaucoup de code inutile pour toucher une petite zone.	Donner seulement les fonctions ou blocs concernés, avec le contexte minimum.
Conversations trop longues	La demande se précise après plusieurs messages.	Formuler le résultat attendu, les contraintes et les fichiers concernés dès le départ.
Contexte répété	Les mêmes règles métier ou choix techniques sont recollés partout.	Centraliser ces infos dans un court résumé stable, puis y faire référence.

Comment préparer la session ?

Je prépare la session avant d’ouvrir Claude Code, parce que les tokens les moins chers sont ceux que je n’envoie jamais. C’est bête, mais c’est souvent là que je gagne le plus. Pas dans une commande magique, plutôt dans le fait d’arriver avec un contexte propre.

Je mets presque toujours un fichier CLAUDE.md à la racine du projet. La documentation officielle de Claude Code le présente comme une mémoire projet. En clair, c’est un fichier que Claude peut relire pour retrouver les infos stables, au lieu de me les redemander à chaque session.

Dedans, je garde ce qui revient tout le temps :

• La structure générale du projet et les dossiers importants.
• La stack utilisée, par exemple Next.js, FastAPI, PostgreSQL, Stripe.
• Les conventions de code, de nommage, de tests, de commits.
• Les commandes utiles pour lancer, tester, builder ou lint le projet.
• Les règles récurrentes, par exemple “ne pas modifier l’API publique” ou “ne pas toucher aux migrations sans validation”.

Avant de lancer la session, je cadre aussi la demande. J’écris les fichiers concernés, l’état final attendu, les contraintes, et surtout ce que je ne veux pas changer. Cette dernière partie évite beaucoup de dérives. J’ai vu des agents “corriger” un bug en réécrivant trois couches applicatives. Techniquement ça marche parfois. Dans une vraie codebase, c’est souvent un problème.

Je fais aussi un petit élagage avant l’analyse. Je retire les commentaires inutiles, les imports morts, le vieux code obsolète et le boilerplate qui ne sert pas à comprendre le sujet. Moins Claude lit de bruit, plus il raisonne sur le signal.

Le brief peut rester très simple :

Contexte	Résumé court du module et du problème.
Objectif	État final attendu, formulé clairement.
Fichiers	Liste limitée aux fichiers utiles.
Contraintes	Ce qui ne doit pas bouger.
Tâche	Action précise à réaliser dans cette session.

Je découpe aussi les grosses tâches. Une bonne session, c’est corriger un bug, refactorer un module, écrire un test, sécuriser une fonction. Pas “refaire toute l’application”. Plus la tâche est large, plus Claude consomme de tokens pour explorer, hésiter, comparer, revenir en arrière.

Pour la carte du projet, je partage un arbre de répertoires compact, limité à la zone utile. Pas tout le dépôt. Juste assez pour comprendre où on est.

Contexte : Le bug concerne la validation du formulaire de paiement.

Objectif : Corriger le cas où une carte expirée passe encore côté frontend.

Fichiers : src/payments/PaymentForm.tsx, src/payments/validators.ts, tests/payments.test.ts

Contraintes : Ne pas modifier l’API backend. Ne pas changer le design du formulaire.

Tâche : Corriger la validation et ajouter un test ciblé.

Comment durer en session ?

Le hack le plus immédiat, c’est de cadrer la réponse dès la première ligne : Pas d’explications, seulement le code. Ou encore : Réponse courte, patch uniquement. Ça paraît bête, mais sur Claude Code, ça change vite la consommation.

Sur les tâches de code, les préambules, les justifications et les longs raisonnements affichés peuvent gonfler la réponse pour rien. Je ne veux pas payer en tokens pour lire “je vais maintenant analyser le fichier” si je sais déjà ce que je demande. Je veux le changement, le diff, ou la commande à lancer.

Mon réflexe, c’est de garder la session sèche. Je donne juste le contexte utile, je cible les fichiers, et j’évite de recoller trois fois le même bloc de code. Si Claude Code a déjà accès au repo, je préfère lui dire quel fichier regarder plutôt que de vider tout le projet dans le prompt.

Réflexe ou commande	Quand je l’utilise
Réponse courte, patch uniquement	Quand je veux limiter les explications et obtenir directement la modification.
Références de fichiers ciblées	Quand je veux éviter d’envoyer trop de contexte inutile.
Diff ou modification localisée	Quand une petite correction suffit et que je ne veux pas une refonte complète.
/compact	Quand la session devient lourde et que je veux résumer l’historique.
/clear	Quand le contexte est pollué et que je préfère repartir proprement.
/cost	Quand je veux surveiller la consommation.
/memory	Quand je veux gérer les informations persistantes du projet.

Ces commandes sont documentées, mais elles peuvent évoluer selon l’environnement Claude Code. Je vérifie toujours l’aide disponible dans mon terminal avant de construire une routine dessus. J’ai déjà vu des équipes perdre du temps parce qu’elles appliquaient des habitudes d’une version à une autre sans vérifier.

Une demande optimisée ressemble plutôt à ça :

Analyse uniquement la fonction `calculateInvoiceTotal` dans `src/billing/invoice.ts`.

Objectif : corriger le bug d'arrondi sur la TVA.

Réponse courte.
Patch minimal uniquement.
Ne réexplique pas l'architecture.
Ne modifie pas les autres fichiers sauf nécessité.

Je valide aussi par petites étapes. Une fonction, un fichier, un comportement. Puis je continue. C’est moins spectaculaire qu’un énorme prompt “refactor tout le module”, mais c’est beaucoup plus stable, et surtout beaucoup moins cher en tokens.

Ma règle simple : si je dois réexpliquer trois fois la même chose, je la mets dans CLAUDE.md ou dans un brief propre. Comme ça, Claude Code récupère le contexte au bon endroit, sans que je transforme chaque session en roman.

Quand utiliser les skills ?

J’utilise les skills quand je vois une consigne revenir trois, quatre, dix fois dans Claude Code. À ce moment-là, ce n’est plus un prompt, c’est un mode opératoire. Et si je le recolle à chaque fois, je brûle des tokens pour rien.

Dans l’écosystème Claude, une skill, c’est simplement un paquet d’instructions et de ressources que Claude peut charger quand la tâche correspond. Ça peut contenir une méthode, des règles projet, des exemples, des fichiers de référence, ou des contraintes métier. L’idée, ce n’est pas de tout mettre dans le prompt principal. C’est de créer une compétence réutilisable.

Ce qui est intéressant, c’est le chargement progressif décrit par Anthropic. Claude n’a pas besoin d’avaler toute la documentation d’un coup. Il peut commencer par les métadonnées de la skill, comprendre à quoi elle sert, puis charger seulement les détails utiles si la tâche le demande. C’est exactement ce qu’on cherche quand on veut réduire les tokens sans perdre la qualité du code.

Concrètement, une bonne skill évite de répéter toujours les mêmes consignes. Elle standardise les attentes. Elle réduit les oublis. Elle limite aussi les allers-retours du type “Non, respecte plutôt notre convention de nommage” ou “Ajoute les tests comme dans les autres modules”. J’ai vu ça chez un client avec des conventions de tracking analytics. Avant, chaque ticket repartait avec un pavé de contexte. Après, on a mis une skill propre, et les sorties étaient plus régulières.

Les cas où ça marche bien sont assez clairs :

• Revue de code avec une grille de contrôle stable.
• Génération de tests unitaires ou d’intégration selon vos standards.
• Migration de composants d’un framework ou d’une version à une autre.
• Conventions de tracking pour les événements produit.
• Requêtes analytics avec vos tables, dimensions et métriques habituelles.
• Documentation technique avec votre format attendu.

Certains benchmarks annoncent jusqu’à 70 % de réduction de coût avec des skills bien conçues. Je le prends comme un maximum observé, pas comme une promesse magique. Une skill trop longue, trop vague, ou remplie de règles inutiles peut faire l’inverse. Elle ajoute du bruit, elle charge du contexte pour rien, et Claude devient moins précis.

Cas d’usage	Ce que la skill évite	Gain attendu
Revue de code	Répéter la checklist qualité à chaque demande.	Moins d’oublis et retours plus homogènes.
Génération de tests	Réexpliquer les conventions de test du projet.	Tests plus rapides à produire et mieux alignés.
Migration de composant	Recoller les règles de migration dans chaque prompt.	Moins de tokens et moins d’erreurs répétitives.
Tracking analytics	Redéfinir les événements, propriétés et règles métier.	Implémentations plus cohérentes.
Documentation technique	Réexpliquer le format et le niveau de détail attendu.	Documentation plus stable et plus rapide à générer.

Et si le vrai gain venait du contexte mieux rangé ?

Je ne cherche pas à gratter des tokens pour le plaisir. Je veux que Claude Code reste utile plus longtemps, sans perdre le contexte au mauvais moment. Le levier principal, c’est simple : préparer le brief, limiter les fichiers, couper les réponses inutiles, compacter quand il faut et transformer les consignes répétées en mémoire ou en skills. Les gains peuvent être très nets, parfois 2 à 3 fois plus de travail productif par session quand le cadre est propre. Le bénéfice pour vous, c’est moins de sessions cassées, moins de coûts inutiles et un assistant de code qui reste concentré sur le vrai problème.

FAQ

• Pourquoi Claude Code atteint-il une limite de contexte ?
  Claude Code atteint une limite parce que la session accumule l’historique, les fichiers, les consignes et les réponses. Quand la fenêtre de contexte se remplit, le modèle peut perdre une partie du contexte utile ou devenir moins fiable sur les éléments anciens.
• CLAUDE.md sert-il vraiment à économiser des tokens ?
  Oui, surtout quand vous répétez souvent les mêmes informations. CLAUDE.md permet de centraliser l’architecture, les conventions, la stack et les règles projet. Ça évite de recoller le même contexte dans chaque session.
• Faut-il donner tout le dépôt à Claude Code ?
  Non, c’est rarement une bonne idée. Je préfère donner une carte compacte du projet, puis seulement les fichiers ou fonctions concernés. Un gros fichier complet peut coûter beaucoup de tokens alors que quelques lignes suffisent parfois.
• Quelle consigne simple réduit vite les réponses trop longues ?
  La consigne la plus directe reste : pas d’explications, seulement le code. Sur des tâches de code simples, ça peut réduire fortement les tokens de sortie, parce que Claude évite les préambules et les justifications inutiles.
• Les skills Claude peuvent-elles réduire les coûts ?
  Oui, si elles sont bien conçues. Une skill évite de répéter des consignes longues et charge seulement ce qui est utile pour une tâche récurrente. Certains benchmarks annoncent jusqu’à 70 % de réduction de coût, mais je le vois comme un potentiel, pas comme une promesse automatique.

 

 

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 proprement, pas juste empiler des prompts. 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 cadrer vos usages Claude Code, automatiser vos workflows ou réduire vos coûts IA, contactez-moi.