En préparant mieux la session, en limitant les fichiers envoyés et en coupant les réponses inutiles. Le vrai sujet, c’est pas juste la taille du contexte Claude Code, c’est ce qu’on met dedans. Mal géré, ça part vite. Bien cadré, on travaille beaucoup plus longtemps.
Qu’est-ce qui consomme les tokens ?
Ce qui consomme le plus de tokens dans Claude Code, ce sont les fichiers trop longs, les échanges verbeux et le contexte répété plusieurs fois.
Dans Claude Code, la fenêtre de contexte sert à garder en mémoire ce qui est utile à la tâche en cours : vos prompts, les réponses de Claude, les fichiers lus, les extraits de code, les consignes projet, parfois aussi des logs ou des résultats de tests. Chaque message et chaque contenu injecté prend une partie du budget disponible. C’est bête, mais c’est souvent là que le gâchis commence.
Quand cette fenêtre se remplit, la session devient moins efficace. Claude peut compacter le contexte, c’est-à-dire résumer ce qui a été dit pour faire de la place. Il peut aussi perdre en précision si trop d’informations se mélangent, ou si les éléments importants sont noyés dans des blocs énormes. Le modèle n’a pas une mémoire magique infinie. Il travaille avec ce qu’on lui donne, dans une limite donnée.
Les gros drains sont assez faciles à repérer :
- Les fichiers inclus en entier alors qu’une fonction suffit. Si le problème est dans une méthode de 20 lignes, envoyer un service de 900 lignes coûte cher pour rien.
- Les conversations longues où on réexplique plusieurs fois la même chose. Chaque répétition revient dans le contexte, même si elle n’apporte rien de nouveau.
- La réinjection du même contexte dans chaque prompt. Copier-coller les mêmes règles, les mêmes fichiers, les mêmes logs à chaque demande, c’est comme payer plusieurs fois le même ticket.
Un cas classique : un développeur bloque sur un bug dans une API. Il envoie tout le fichier de service, le contrôleur complet, trois fichiers de tests et 400 lignes de logs. Au final, le bug est dans une condition mal placée sur 20 lignes. Claude peut s’en sortir, oui. Mais vous avez rempli la fenêtre avec du bruit, et vous avez réduit la place disponible pour raisonner proprement.
J’ai souvent vu des équipes perdre plus de temps à nourrir l’outil qu’à lui demander précisément ce qu’elles voulaient. C’est un réflexe humain. On se dit “je vais tout donner, comme ça il aura le contexte”. Sauf que trop de contexte, c’est parfois moins de clarté.
| Source de consommation | Pourquoi ça coûte cher | Réflexe à adopter |
| Fichiers complets | Claude doit lire beaucoup de code inutile avant d’arriver à la zone importante. | Envoyer l’extrait ciblé, puis ajouter le reste seulement si nécessaire. |
| Conversations longues | Les anciennes consignes, réponses et corrections continuent d’occuper la fenêtre. | Résumer l’état actuel et repartir sur une demande claire. |
| Contexte répété | Les mêmes informations sont payées plusieurs fois dans la session. | Référencer le contexte existant au lieu de le recoller partout. |
Comment préparer une session plus légère ?
Je prépare une session Claude Code plus légère en donnant le contexte une seule fois, en cadrant la tâche avant d’ouvrir la conversation et en évitant d’importer du bruit.
Le premier réflexe, c’est de mettre un fichier CLAUDE.md à la racine du projet. Ce fichier sert de mémoire courte pour Claude Code. J’y mets l’aperçu d’architecture, les conventions de code, la stack, les versions importantes, les commandes utiles, les règles récurrentes. L’intérêt est simple : je ne répète pas le même contexte dans chaque message. Et ça évite aussi les réponses à côté parce que Claude a dû deviner comment le projet fonctionne.
Avant une session, je fais aussi un pré-cadrage de tâche. Rien de compliqué, mais je note ce qui compte vraiment.
- Les fichiers concernés.
- L’objectif attendu.
- Les contraintes techniques ou métier.
- Le comportement actuel.
- Le résultat final que je veux obtenir.
Ça paraît basique, mais c’est souvent là que les tokens partent en fumée. Si Claude doit poser trois questions de clarification avant de toucher au code, on a déjà consommé du contexte pour rien. J’ai vu ça chez un client sur une base React assez grosse : la moitié des échanges servait juste à retrouver les fichiers, comprendre les règles de nommage et deviner le comportement voulu. Avec un brief propre, la session devenait deux fois plus courte.
Je nettoie aussi les fichiers avant de les inclure. Je retire les commentaires non essentiels, les imports inutilisés, le code mort, le boilerplate, et les sections qui n’ont aucun lien avec la demande. Je ne supprime pas tout pour faire joli. Je garde ce qui aide Claude Code à raisonner : les types, les dépendances utiles, les fonctions appelées, les conventions importantes.
<p><strong>Contexte</strong> : Projet en [stack], module concerné : [module]. Règles importantes : [règles].</p>
<p><strong>Objectif</strong> : [Résultat attendu en une phrase claire].</p>
<p><strong>Fichiers</strong> : [Liste des fichiers à modifier ou lire].</p>
<p><strong>Contraintes</strong> : [Performance, sécurité, compatibilité, style, tests].</p>
<p><strong>Tâche demandée</strong> : [Ce que Claude Code doit faire précisément].</p>Une bonne session Claude Code commence souvent avant Claude Code.
Pourquoi découper les tâches ?
Je découpe les tâches parce qu’une grosse demande consomme trop de contexte, crée plus d’allers-retours et devient difficile à reprendre si la session sature.
Une demande du type “refactorise tout ce module, corrige tous les tests et améliore l’architecture” paraît efficace sur le papier. En pratique, c’est rarement idéal dans une seule session Claude Code. Elle mélange trop de choses à la fois : diagnostic, décision, édition, validation, documentation. Chaque couche ajoute des tokens, c’est-à-dire des morceaux de texte que le modèle doit lire, garder en mémoire et réutiliser. Le contexte, lui, c’est la fenêtre utile dans laquelle Claude Code travaille. Quand elle se remplit avec du bruit, les réponses deviennent moins précises.
Je préfère transformer une grosse tâche en unités plus courtes. D’abord comprendre le bug. Ensuite isoler les fichiers utiles. Puis proposer une modification minimale. Après, écrire ou adapter un test. Et seulement après ça, refactoriser si nécessaire. Refactoriser, c’est améliorer la structure du code sans changer son comportement. Ça vient souvent après la correction, pas avant.
Ce n’est pas une méthode bureaucratique. C’est juste une façon de garder le contexte utile et contrôlable. Claude Code travaille mieux quand il sait où regarder, pourquoi il regarde là, et ce qu’il doit produire maintenant.
Un truc simple qui aide beaucoup, c’est la carte projet compacte. Au lieu d’envoyer tout le dépôt, je génère une arborescence pertinente avec seulement les dossiers et fichiers concernés.
- src/
- src/modules/billing/
- src/modules/billing/invoice.service.ts
- src/modules/billing/invoice.repository.ts
- src/modules/billing/__tests__/invoice.service.test.ts
- src/shared/money.ts
- package.json
Sur des projets avec beaucoup de legacy, j’ai vu que cette carte projet faisait gagner énormément de temps. Claude Code comprend où regarder sans avaler tout le code. Et honnêtement, sur certains vieux monolithes, c’est la différence entre une session propre et une session qui part dans tous les sens.
| Demande trop large | Demande découpée |
| Refactorise tout le module, corrige les tests et améliore l’architecture. | Identifie la cause du bug dans le service de facturation. |
| Beaucoup de fichiers chargés dès le départ. | Seulement les fichiers nécessaires dans le contexte. |
| Diagnostic, édition et validation mélangés. | Une intention claire par session. |
| Risque élevé de saturation et d’oublis. | Reprise plus simple si la session bloque. |
Comment parler à Claude Code pendant la session ?
Pendant la session, je parle à Claude Code avec des consignes courtes, explicites, et je limite volontairement les explications quand elles ne servent pas.
Le hack le plus simple, c’est de lui dire clairement le format attendu. Pas vaguement. Pas “fais au mieux”. Je préfère cadrer dès le départ, surtout quand la tâche est opérationnelle.
- Pas d’explication, juste le patch
- Réponds uniquement avec les fichiers modifiés
- Donne-moi seulement la commande et le résultat attendu
- Ne détaille pas le raisonnement, applique la correction
- Si tu modifies du code, ne résume que les changements critiques
Ça marche parce que les explications coûtent cher. Un token, c’est un petit morceau de texte traité par le modèle. Plus Claude Code lit ou écrit de texte, plus la session consomme. Sur des tâches de code, les longues justifications peuvent représenter une grosse partie de la réponse, parfois plus que le patch lui-même. En coupant les préambules, les résumés inutiles et les “voici pourquoi”, j’ai souvent vu une baisse de consommation autour de 30 à 50% sur certains cas. Pas toujours. Ça dépend de la tâche, de la taille du diff, et du niveau d’ambiguïté.
Je ne coupe pas tout non plus. Ce serait idiot. Pour une décision d’architecture, un bug vraiment tordu ou une migration risquée, je demande une justification courte. Je veux comprendre le choix, pas lire une dissertation. Pour une modification mécanique, je demande le minimum. Chez un client, on a gagné pas mal juste en arrêtant de demander “explique-moi tout” à chaque petit changement de test. Les explications étaient propres, mais elles ne servaient à rien dans 80% des cas.
| Situation | Consigne utile | Niveau d’explication |
| Bug simple | Corrige le bug, pas d’explication, juste le patch | Minimum |
| Refactor | Applique le refactor et liste seulement les fichiers modifiés | Faible |
| Test | Ajoute ou corrige les tests, donne seulement la commande et le résultat attendu | Minimum |
| Architecture | Propose l’option recommandée avec une justification courte et les risques | Modéré |
La règle que j’utilise est simple. Si je dois décider, je veux une explication. Si Claude Code doit exécuter, je veux du concret.
Quels réflexes garder pour durer plus longtemps ?
Pour faire durer une session Claude Code, je garde le contexte propre, je résume les décisions importantes et je n’ajoute jamais un fichier juste au cas où.
Le bon réflexe, c’est de démarrer avec un CLAUDE.md utile. Pas un roman. Un fichier qui dit comment le projet fonctionne, quelles commandes lancer, quelles conventions respecter, où sont les zones sensibles. J’ai vu des équipes mettre 800 lignes dedans, puis se plaindre que Claude partait dans tous les sens. Normal. Trop d’info tue le signal.
Ensuite, je prépare un brief court et structuré. Ce que je veux obtenir. Les fichiers concernés. Les contraintes. Ce qu’il ne faut pas toucher. Les outils de développement assistés par IA fonctionnent mieux quand le contexte transmis est précis, limité et proche de la tâche. Le sujet n’est pas seulement la limite technique de tokens. Le vrai sujet, c’est la qualité du signal dans le contexte.
Pour moi, le Claude Code token management, ce n’est pas chercher une astuce magique pour gratter quelques tokens. C’est une hygiène de session. Je nettoie les fichiers avant de les donner. Je retire les logs, les vieux essais, les bouts de code morts, les commentaires temporaires. Je découpe aussi les tâches. Une session pour comprendre. Une session pour modifier. Une session pour tester. Quand on mélange tout, on paie en clarifications, en répétitions, et en réponses molles.
Je partage aussi une carte projet compacte quand le repo est gros. Quelques lignes suffisent souvent : architecture, dossiers importants, flux métier, dépendances clés. Ça évite à Claude Code de reconstruire mentalement le projet à chaque demande.
Enfin, je contrôle le style des réponses pendant la conversation. Si je veux un patch minimal, je le dis. Si je veux une analyse avant modification, je le dis. Si une réponse devient trop longue, je recadre. Le bénéfice est très concret : moins de clarification, moins de répétition, plus de production utile par session.
- Vérifier que le CLAUDE.md est court, utile et à jour.
- Donner un objectif clair avant d’envoyer des fichiers.
- Limiter le contexte aux fichiers vraiment liés à la tâche.
- Nettoyer logs, brouillons et code mort avant la session.
- Découper les demandes longues en blocs simples.
- Partager une carte projet compacte si le repo est large.
- Recadrer le format des réponses dès que Claude devient trop verbeux.
Et si le vrai gain venait surtout du cadrage ?
Le Claude Code token management, je le vois comme une discipline simple : moins de bruit, plus de contexte utile. On gagne déjà beaucoup en préparant un CLAUDE.md propre, en cadrant la tâche, en envoyant seulement les fichiers nécessaires et en découpant les demandes trop larges. Pendant la session, il faut aussi oser dire à Claude Code de répondre court quand l’explication n’apporte rien.
Ce n’est pas une optimisation gadget. C’est ce qui permet d’éviter les sessions qui partent dans tous les sens. Le bénéfice pour vous est clair : plus de travail produit, moins d’allers-retours, et une IA qui reste concentrée plus longtemps.
FAQ
- Qu’est-ce que le Claude Code token management ?
C’est la façon de gérer ce que vous envoyez dans une session Claude Code pour éviter de remplir trop vite la fenêtre de contexte. Ça concerne vos prompts, les réponses, les fichiers inclus, les explications et le contexte répété. - Pourquoi Claude Code consomme autant de tokens avec les fichiers ?
Parce qu’un fichier entier peut contenir beaucoup plus d’informations que nécessaire. Si la tâche concerne une fonction précise, envoyer tout le module, les commentaires, le code mort et le boilerplate consomme du contexte pour rien. - À quoi sert un fichier CLAUDE.md ?
Il sert à donner à Claude Code un contexte projet stable : architecture, conventions, stack, commandes utiles, règles importantes. L’intérêt, c’est d’éviter de répéter ces informations dans chaque prompt. - Faut-il toujours demander des réponses courtes ?
Non. Pour une correction simple ou une modification mécanique, une réponse courte suffit souvent. Pour une décision d’architecture, une migration ou un bug risqué, je préfère demander une justification courte plutôt qu’une absence totale d’explication. - Quelle est la meilleure habitude pour économiser des tokens ?
Préparer la session avant de la lancer. Un brief clair, des fichiers nettoyés, une carte projet compacte et une tâche découpée font souvent plus gagner que n’importe quelle astuce isolée.
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, pas juste en démo, avec des méthodes propres, mesurables et maintenables. 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 mettre en place des workflows IA utiles dans votre business, contactez-moi.
⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐
Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…
Mon terrain de jeu :
Data Analyst & Analytics engineering : tracking avancé (GTM server, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.