Comment réduire la consommation de tokens Claude Code ?

Réduire la consommation de tokens Claude Code passe par le contrôle du contexte, le choix du modèle adapté et l’isolation des sorties verbeuses. Cet article détaille 5 stratégies pratiques : modèles par tâche, CLAUDE.md minimal, subagents, ciblage de fichiers/lignes et compaction proactive.

Quel modèle choisir selon la complexité ?

Utiliser un modèle adapté à la complexité de la tâche réduit significativement la consommation de tokens en évitant des traitements trop coûteux pour des tâches simples.

Voici des modèles courants et leur rôle :

• Sonnet : Modèle léger optimisé pour la rédaction quotidienne, génération d’e-mails, résumés courts et tâches répétitives où la précision fine n’est pas critique.
• Haiku : Modèle ultra-rapide conçu pour exécutions courtes et interactions temps réel, comme la validation de formats, l’extraction de champs ou des réponses UI à faible latence.
• Opus : Modèle à haute capacité pour analyses profondes, génération de code complexe, reasoning long et tâches demandant maintien du contexte sur de nombreux tokens.

Stratégie opérationnelle : démarrer les sessions sur un modèle économique (Haiku ou Sonnet) et monter en gamme uniquement si l’évaluation montre un besoin d’intensité cognitive supplémentaire.

Explication du paramètre /effort : Ce paramètre représente le « budget de réflexion » accordé au modèle, généralement sur une échelle 0.0–1.0, où 0.0 minimise le raisonnement interne et 1.0 maximise profondeur et vérifications. Réduire /effort diminue la génération de tokens internes et la latence, mais augmente le risque d’erreurs ou d’omissions et peut nécessiter des relances supplémentaires.

Exemple pratique de workflow :

Set_Model Sonnet
Set_Effort 0.3
Ask "Donne un résumé de 3 lignes du ticket #123"
If QualityTooLow:
  Set_Model Opus
  Set_Effort 0.9
  Reask "Approfondis l'analyse du ticket #123 en ajoutant causes et solutions"

Tableau synthétique :

Modèle	Usage recommandé	Avantage	Risque/Coup
Haiku	Réponses UI, validations rapides	Faible coût, latence minimale	Précision limitée sur sujets complexes
Sonnet	Rédaction quotidienne, résumés	Bon compromis qualité/coût	Peut manquer d’analyse profonde
Opus	Analyses profondes, code, reasoning	Haute fiabilité et capacité	Coût et consommation de tokens élevés

Checklist d’action immédiate :

• Identifier les tâches simples pouvant rester sur Haiku ou Sonnet.
• Paramétrer /effort bas (≈0.2–0.4) par défaut pour ces tâches.
• Implémenter un contrôle qualité léger pour détecter quand monter en Opus.
• Automatiser le basculement de modèle seulement après échec de la passe économique.

Que mettre dans CLAUDE.md pour limiter les tokens ?

Limiter CLAUDE.md aux règles stables et indispensables évite de renvoyer des blocs volumineux à chaque tour et réduit le coût récurrent par message.

Privilégier l’essentiel : conventions de nommage courtes et non redondantes, contraintes de sécurité critiques, procédures de test obligatoires et dossiers à ignorer. Éviter les descriptions longues de conception, les guides méthodologiques détaillés et les notes de réunion. Réserver les histoires de conception aux documents séparés référencés par lien.

• Conventions de nommage essentielles : PatronDeBranch, PréfixeTag, FormatCommit.
• Contraintes de sécurité : Niveau minimum d’authentification, interdictions explicites (ex : stockage de secrets en clair).
• Procédures de test obligatoires : Tests unitaires requis, seuil de couverture minimal.
• Dossiers à ignorer : /node_modules, /dist, /build, fichiers volumineux générés.
• Ce qu’il faut éviter : Notes longues, spécifications d’architecture, brainstorming.

Modèle minimal (copier-coller) :

Conventions: Branches feat/, fix/, chore/
Sécurité: Ne pas commiter de secrets; vérifier with git-secrets
Tests: Exiger tests unitaires pour PRs; coverage >= 70%
Ignore: /node_modules, /dist, /build
Responsable: TechLead (revue trimestrielle)
Révision: Tous les 3 mois ou après changement majeur

Versionner et maintenir : Placer CLAUDE.md à la racine du dépôt et l’inclure dans le pipeline CI pour validation minimale. Prévoir une revue trimestrielle et après toute modification de processus majeur. Désigner un mainteneur clair (TechLead ou propriétaire de repo).

Phrases types courtes à privilégier : « Toujours : », « Interdit : », « Priorité : », « Ignorer : », « Obligatoire : ».

Dos	Don’ts
Conserver règles stables et courtes	Inclure guides longs ou discussion
Référencer documents externes	Copier toute la doc détaillée

Checklist rapide :

• Limiter à règles indispensables.
• Utiliser phrases courtes et verbes d’action.
• Mettre responsable et fréquence de revue.
• Référencer docs volumineux au lieu d’inclure.

Quand créer des subagents pour isoler le verbeux ?

Créer des subagents est pertinent quand des tâches produisent des sorties très verbeuses dont seul un résumé doit retourner au contexte principal, car cela réduit l’encombrement du contexte principal malgré un coût de démarrage.

Un subagent est un processus (ou une instance de modèle) dédié à une sous-tâche verbeuse : extraction de logs, génération de rapports détaillés ou analyses volumineuses. L’intérêt pratique consiste à isoler ces flux lourds, conserver le contexte principal léger et ne renvoyer que des synthèses pertinentes. On gagne en clarté, en coût de ré-encodage du contexte et en capacité d’itération.

Architecture type d’un workflow intégrant subagents :

• Flux principal : collecte des instructions et du contexte minimal.
• Déclencheur : règles qui envoient la tâche au subagent (taille, type, priorité).
• Subagent : exécution, stockage temporaire des sorties détaillées, création d’un résumé.
• Retour : résumé compact (quelques dizaines ou centaines de tokens) réintégré au contexte principal.

Règles pratiques pour décider d’un subagent :

• Mesurer d’abord : collecter l’historique des sorties en octets et en tokens via un tokenizer officiel (permet d’obtenir des chiffres fiables).
• Analyser la distribution : utiliser percentiles (p50, p75, p90). Si p90 dépasse votre budget de contexte, envisager un subagent.
• Tester en A/B : simuler 1000 requêtes, mesurer coûts tokens, latence et taille moyenne de contexte.
• Définir seuils par tests internes, pas par intuition ; automatiser le routage au subagent au-delà du seuil.

Coûts à anticiper et situations à éviter :

• Démarrage : temps CPU/mémoire pour lancer un subagent (cold-start).
• Stockage temporaire : persistances intermédiaires pour audits.
• Latence accrue : pipeline en deux étapes.
• Éviter les subagents pour les petites tâches rapides et très fréquentes.

Main -> SubagentExtraction -> GénérationDétail -> StockageTemporaire -> Résumé(≤X tokens) -> Main

Avantages	Inconvénients
Réduction du contexte principal, meilleur contrôle des coûts tokens.	Latence et coût de démarrage supplémentaires.
Isolation des logs et des rapports volumineux pour audit.	Système plus complexe à gérer et monitorer.

• Checklist de déploiement : Instrumenter la mesure tokens/octets, définir seuils via percentiles, implémenter routage automatique, prévoir stockage sécurisé, monitorer latence et coûts, itérer après tests A/B.

Comment cibler fichiers et plages de lignes précisément ?

Fournir des fichiers et plages de lignes exactes évite les explorations inutiles du dépôt et diminue nettement la consommation de tokens.

Fournir le chemin relatif d’un fichier et un intervalle de lignes précis limite la surface à parcourir, réduit les allers-retours et économise des centaines voire des milliers de tokens par requête sur de grands dépôts.

Pourquoi les recherches vagues coûtent cher : parcourir tout un dépôt implique d’envoyer beaucoup de contexte au modèle et d’effectuer plusieurs passes pour trouver l’information utile. Chaque ligne ajoutée au contexte augmente directement la consommation de tokens en entrée et en sortie.

Comment formuler des requêtes ciblées :

• Donner le nom de fichier relatif, par exemple src/api/user_service.py.
• Spécifier un intervalle de lignes, par exemple lignes 40-90.
• Limiter les motifs regex avec ancres ou groupes pour éviter les correspondances larges, par exemple /def get_user_by_id\\(user_id\\):/.
• Préciser le format de réponse attendu (résumé, patch git, tableau de défauts).

Usage du mode plan (toggle Shift+Tab) : demander systématiquement un plan étape par étape avant d’exécuter des actions coûteuses permet de valider l’approche, d’identifier les étapes inutiles et d’éviter plusieurs itérations. Exiger le plan réduit la probabilité de revenir en arrière.

Question :
"Modifier src/controllers/user_controller.rb lignes 120-145 pour ajouter une validation du token."

Plan :
1) Lister les fonctions affectées dans 120-145.
2) Proposer le patch minimal.
3) Simuler un test unitaire.

Exécution :
Fournir le patch git formaté et les commandes de test.

Phrases modèles à réutiliser en production :

• Analyse uniquement le fichier chemin/vers/fichier.ext entre les lignes X-Y et propose un patch minimal.
• Fournis un plan étape par étape (toggle Shift+Tab) avant d’appliquer des changements.
• Utilise le regex /motif/ limité pour cibler les occurrences.

Checklist avant d’envoyer la requête :

• Chemin relatif du fichier indiqué.
• Plage de lignes précise fournie.
• Motif ou fonction ciblée précisée.
• Format de sortie attendu défini.
• Demande de plan avant exécution activée.

Action	Pourquoi	Exemple
Spécifier fichier + lignes	Réduit le contexte et la recherche	src/api/auth.py lignes 10-45
Utiliser regex limité	Évite les correspondances massives	/def authenticate_user\\(/
Exiger plan	Diminue les itérations coûteuses	Demande de plan étape par étape (Shift+Tab)

Quand et comment utiliser /compact proactivement ?

Exécuter /compact de façon proactive, avant des opérations coûteuses, réduit le contexte actif et donc les tokens consommés lors des étapes suivantes.

Un token est une unité de texte (mots ou fragments de mots selon le modèle) utilisée pour mesurer la consommation. La compaction manuelle via la commande /compact force la réduction immédiate du contexte actif. La compaction automatique intervient quand le système détecte un besoin (garbage collection de contexte), mais son timing peut être hors de propos pour votre tâche.

La différence clé tient au contrôle. La compaction manuelle donne un point précis où l’on sacrifie des détails de contexte pour alléger le prompt. La compaction automatique peut intervenir trop tard (après une étape coûteuse) ou trop tôt (perte d’informations utiles). Le timing est crucial parce que compacter juste avant une analyse longue maximise l’économie de tokens, alors que compacter pendant une série d’itérations rapides crée des rétablisements de contexte coûteux.

Scénarios où lancer /compact :

• Lancer avant une analyse longue ou une requête de génération de rapport pour réduire le contexte actif.
• Lancer après une phase de clarification ou de collecte de données verbeuse, une fois les décisions prises.
• Lancer avant une tâche batch qui traitera beaucoup de texte en entrée pour chaque item.

Scénarios où éviter /compact :

• Éviter lors de petites itérations rapides nécessitant le maintien de mémoire conversationnelle.
• Éviter si vous prévoyez de revenir sur des détails supprimés dans l’immédiat.

Stratégie de cadence : mesurer et ajuster plutôt que choisir des nombres arbitraires. Mesurer la consommation de tokens sur un workflow de référence, réaliser des tests A/B (avec et sans /compact) et calculer le gain net en tokens. Ajuster le seuil selon le ratio économie/coût en latence et en perte d’information. Estimer la charge future par la longueur prévue du prompt et de la sortie, puis déclencher /compact si l’économie attendue dépasse l’overhead mesuré.

Exemple de séquence d’opérations (actions chronologiques) :

• Collecte inputs utilisateurs.
• Clarifications et nettoyage.
• Exécuter /compact.
• Lancer analyse longue ou génération de rapport.
• Archiver résultats et éventuellement recharger contexte réduit.

Impact attendu : réduction du contexte actif, baisse des tokens consommés pendant l’analyse et économie de coûts; contrepartie potentielle : perte de détails si compaction trop agressive.

Situation	Action recommandée
Analyse longue à venir	Exécuter /compact avant
Itérations rapides	Éviter /compact
Phase de clarification terminée	Exécuter /compact

• Mettre en place métriques de tokens consommés par étape.
• Automatiser tests A/B pour valider gain net.
• Définir seuils adaptatifs basés sur économie vs overhead.
• Documenter quelles informations sont sûres à compacter.

Prêt à appliquer ces bonnes pratiques pour réduire vos coûts de tokens ?

En contrôlant le contexte (CLAUDE.md réduit), en choisissant le bon modèle, en isolant les sorties verbeuses avec des subagents, en ciblant précisément fichiers et lignes, et en compactant proactivement, on réduit significativement la consommation récurrente de tokens. Ces actions diminuent les coûts, accélèrent les cycles et rendent les réponses plus pertinentes. Adopter ces pratiques vous permettra d’optimiser votre budget IA et d’obtenir des workflows plus efficaces pour votre business.

FAQ

• Qu’est‑ce qui fait gonfler la consommation de tokens Claude Code ?
  Le principal coupable est le contexte persistant : messages, fichiers préchargés (CLAUDE.md), résultats d’outils et instructions de fond renvoyés à chaque tour. Les requêtes vagues qui entraînent des explorations du dépôt augmentent aussi fortement les tokens.
• Comment mesurer l’impact d’une optimisation sur les tokens ?
  Mesurez le nombre de tokens consommés par session avant et après modification sur des cas types. Comparez itération par itération sur workflows réels et estimez la réduction moyenne pour décider de déployer la pratique.
• Quand vaut‑il mieux utiliser un subagent plutôt que compacter ?
  Privilégiez un subagent quand une tâche produit des sorties très volumineuses et fréquemment; la compaction réduit le contexte actif mais n’isole pas les sorties détaillées comme le fait un subagent.
• Que doit contenir en priorité un CLAUDE.md minimal ?
  Conservez uniquement les règles stables et indispensables : contraintes de sécurité, conventions critiques, procédures de test obligatoires et dossiers à ignorer. Évitez guides longs et historiques de conception.
• À quelle fréquence exécuter une compaction proactive ?
  La fréquence optimale dépend du flux de travail : compactez avant opérations lourdes ou après phases longues d’échanges verbeux. Mesurez et ajustez la cadence selon les économies observées.

 

 

A propos de l’auteur

Franck Scandolera — expert et formateur en tracking server-side, Analytics Engineering, automatisation No/Low Code (n8n) et intégration d’IA en entreprise. Responsable de l’agence webAnalyste et de l’organisme Formations Analytics. Références clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.