Comment réduire l’utilisation des tokens Claude Code ?

Réduire l’utilisation des tokens Claude Code demande de limiter le contexte envoyé au modèle et d’agir au bon niveau. Je détaille 5 actions concrètes : choisir le bon modèle, condenser CLAUDE.md, déléguer aux sous-agents, pointer fichiers/lignes et compacter la session.

Quel modèle choisir selon la tâche

Choisir un modèle adapté réduit l’utilisation de tokens en limitant l’effort de réflexion aux tâches qui l’exigent.

Commencer par un modèle léger permet d’économiser des tokens et de détecter rapidement si la tâche est triviale. La stratégie « start small, escalate » consiste à lancer les requêtes courantes sur Sonnet (tâches quotidiennes), basculer vers Haiku pour opérations rapides et vers Opus pour analyses profondes. Basculer seulement si la sortie est incomplète, si le taux d’erreur augmente ou si la latence/qualité exigée n’est pas atteinte.

Le paramètre /effort contrôle la profondeur de raisonnement et donc le coût. Le terme effort signifie l’intensité des calculs internes du modèle (plus d’étapes de réflexion, plus de tokens générés). Ajuster /effort de low à high influe directement sur la longueur et la précision de la réponse, et donc sur la facture en tokens.

Exemple concret de flux : Détection d’anomalie simple -> Sonnet + /effort low pour filtrage rapide. Si suspicion persistante -> Haiku + /effort medium pour diagnostic. Pour un audit complet -> Opus + /effort high pour explications détaillées et corrélations.

Tableau d’exemples pratiques :

Review PR	Sonnet	/effort low	Commentaires rapides et checklist
Résumé long d’un rapport	Haiku	/effort medium	Synthèse structurée en plusieurs points
Debug interactif	Opus	/effort high	Hypothèses, repros, pistes de correction

Règles simples pour automatiser la sélection : automatiser par taille d’entrée (ex : <2k tokens -> Sonnet), par complexité attendue (heuristique sur mots-clés comme « audit », « root cause » -> Opus) et par seuils /effort (si erreur > X% relancer en augmentant /effort). Exemple pseudo-commande :

# Démarrer léger
request --model Sonnet --effort low --input file.txt
# Bascule si besoin
request --model Opus --effort high --input file.txt

Tableau de synthèse :

Sonnet	Tâches quotidiennes, faible latence	Coût faible / Qualité correcte
Haiku	Opérations rapides, synthèses	Coût moyen / Qualité équilibrée
Opus	Analyses profondes, audits	Coût élevé / Qualité maximale

Que mettre dans CLAUDE.md

Commencez le chapitre par cette réponse, puis développez en HTML :

Le fichier CLAUDE.md centralise les règles stables et les instructions répétitives afin d’éviter de renvoyer le même contexte à chaque message et de facturer inutilement des tokens. Les « tokens » sont les unités de facturation et de contexte des modèles (entrée + sortie) ; réduire le contexte envoyé réduit donc le coût et améliore la latence.

1) Expliquer le rôle précis de CLAUDE.md : centraliser règles stables et instructions répétitives pour ne pas les renvoyer à chaque message.

2) Lister ce qu’il faut y conserver (règles d’écriture, conventions d’API, templates de réponse) et ce qu’il faut exclure (logs, historiques détaillés, notes temporaires, dumps de fichiers).

3) Fournir un exemple concret et minimal de CLAUDE.md présenté sous forme de table HTML avec colonne « But » et « Exemple de contenu ». La table doit rester concise et montrer des formulations réutilisables (ex : « Répondre en 6 points maximum », « Inclure snippets testables uniquement si demandé »).

4) Donner des pratiques opérationnelles : versionner CLAUDE.md, utiliser placeholders pour éléments variables, maintenir une taille réduite, et ajouter une checklist pour réviser le fichier avant chaque déploiement d’un nouveau workflow.

Exemples et conseils pratiques :

But	Exemple de contenu
Ton et format	Répondre en 6 points maximum. Utiliser « vous ». Préférer phrases courtes.
Code et snippets	Inclure snippets testables uniquement si demandé. Privilégier Python 3.9+.
Conventions API	Base URL: https://api.example.com/v1. Auth: Bearer TOKEN_PLACEHOLDER.
Restrictions	Ne pas inclure logs, dumps, ou historiques privés.

Pratiques opérationnelles :

• Versionner CLAUDE.md avec Git et tagguer les releases pour tracer les changements.
• Utiliser placeholders (TOKEN_PLACEHOLDER, DATE_PLACEHOLDER) pour éléments variables afin d’éviter les réécritures.
• Garder le fichier court (<500 mots idéalement) et relire avant chaque déploiement.
• Faire une checklist avant release : supprimer notes temporaires, confirmer conventions, tester templates.

Do	Don’t
Conserver règles stables et templates réutilisables.	Inclure historiques, logs ou dumps de données.
Versionner et utiliser placeholders.	Rendre le fichier trop verbeux ou spécifique à un seul cas.

Quand déléguer aux sous-agents

Déléguer aux sous-agents quand le travail est verbeux permet d’isoler sorties lourdes et ne renvoyer que des résumés pertinents.

1) Définir ce qu’est un sous-agent et dans quels cas il est pertinent (recherches de fichiers volumineux, dumps de logs, reasoning multi-étapes, tâches de scraping ou parsing).

2) Expliquer les coûts et bénéfices : coût de démarrage d’un sous-agent vs gains en réduction du contexte principal ; indiquer quand un sous-agent n’est pas rentable (petites tâches répétitives).

3) Décrire un workflow type avec étapes claires : lancer sous-agent, exécuter traitement verbeux, produire résumé structuré (longueur limitée), renvoyer seulement le résumé au fil principal. Inclure une table HTML présentant exemple de sous-agent, entrée, sortie résumée et critère d’utilisation.

4) Donner exemples d’implémentation au niveau conceptuel : orchestration via un outil no-code (exemple n8n), ou via simple API calls. Proposer un template de prompt pour le sous-agent qui produit un résumé de N tokens/phrases.

Quand déléguer : utiliser un sous-agent si la tâche génère beaucoup de texte (logs, dumps, pages web) ou nécessite plusieurs étapes de raisonnement. Sous-agent désigne un processus ou une instance qui reçoit et traite la charge verbeuse pour renvoyer une synthèse.

Coûts et bénéfices : lancer un sous-agent implique un coût initial (configuration, quelques appels API). Gains principaux : réduction du contexte principal, diminution des tokens transmis et clarté des réponses. Ne pas déléguer pour des tâches très courtes ou hautement répétitives où l’overhead l’emporte sur l’économie de tokens.

Workflow type :

Sous-agent	Entrée	Sortie résumée	Critère d’utilisation
Parser de logs	Fichier .log 200MB	Incidents + timestamps (max 200 mots)	Logs volumineux
Scraper HTML	100 pages	Liste d’items structurés	Scraping multi-pages
Reasoner multi-étapes	Problème + contexte 50k tokens	Plan d’action 5 étapes	Raisonnement profond

Implémentation : on peut orchestrer via n8n pour déclencher un flux sans code, ou faire des appels API directs pour lancer une instance dédiée qui retourne uniquement le résumé. Exemple de prompt :

Résumé demandé: Traite l'entrée fournie et produit un résumé structuré en N phrases ou N tokens max.
Contrainte: Inclure uniquement les faits essentiels, format JSON avec champs: title, issues[], recommendations[].
Ne rien ajouter en dehors du JSON.

Coût initial	Configuration + appel(s) API
Avantage	Réduction significative du contexte principal, clarté
Complexité	Faible à moyenne selon orchestration
Quand utile	Volumes importants, multi-étapes, outputs verbeux

Comment pointer précisément des fichiers et plages de lignes

Pointer précisément des fichiers et des plages de lignes réduit drastiquement le volume de tokens traités, accélère les retours et diminue les itérations coûteuses. Donner une cible claire évite au modèle d’explorer tout le dépôt et de produire des réponses verbeuses qui ne servent pas votre décision.

1) Expliquer pourquoi les requêtes vagues coûtent cher (exploration large, réponses verbeuses, multiples itérations) et pourquoi donner des cibles précises est plus économique.

Les requêtes vagues forcent le modèle à scanner beaucoup plus de contexte, ce qui augmente linéairement le nombre de tokens et donc le coût (les fournisseurs facturent par token; voir la documentation d’Anthropic/OpenAI). Les réponses vagues entraînent souvent plusieurs allers-retours pour préciser la cible. Indiquer un fichier et une plage de lignes réduit l’espace de recherche, produit des réponses plus concises et diminue le nombre d’itérations.

2) Proposer des formulations de requête efficaces : indiquer chemin exact, plage de lignes, format attendu de la réponse (résumé, patch, explication d’un bloc). Donner des exemples concrets de phrases à utiliser dans le prompt (ex : « Regarde src/auth/login.py lignes 120-170 et donne un résumé en 5 points et un patch si bug évident »).

# Exemples de formulations
"Analyse src/auth/login.py lignes 120-170. Donne un résumé en 5 points et propose un patch si tu trouves un bug."
"Vérifie app/services/payment.ts lignes 45-80. Renvoie uniquement: 1) bug potentiel, 2) patch minimal en diff."
"Résumé de docs/README.md lignes 10-50 en 3 phrases, pas d'exemples supplémentaires."

3) Expliquer et illustrer l’usage du mode plan (Shift+Tab) : obtenir un plan d’actions révisable avant d’exécuter opérations coûteuses, limiter les étapes effectives aux seules nécessaires.

Demander d’abord un plan (étapes prévues, risques, fichiers affectés) permet de valider la stratégie sans générer de gros patchs. Utiliser le mode plan évite d’exécuter des opérations coûteuses tant que vous n’avez pas approuvé l’approche.

4) Fournir une table HTML avec templates de requêtes selon l’objectif (debug, revue, résumé) et un exemple de workflow montrant plan -> vérification -> action limitée.

Objectif	Template
Debug	« Analyse {chemin} lignes {a}-{b}. Indique uniquement: cause probable, patch minimal en format diff. »
Revue	« Code review {chemin} lignes {a}-{b}. Donne 3 points d’amélioration et un commentaire sur la sécurité. »
Résumé	« Résumé {chemin} lignes {a}-{b} en {n} phrases, points clés uniquement. »

Workflow exemple: 1) Demander un plan sur src/api/users.py lignes 1-200. 2) Valider plan et limiter les fichiers à modifier. 3) Demander un patch minimal pour les lignes ciblées seulement.

Checklist pratique:

• Indiquez toujours le chemin exact et la plage de lignes.
• Précisez le format de sortie (patch, résumé, checklist).
• Demandez un plan avant d’exécuter des modifications.
• Limitez les actions au minimum nécessaire après vérification du plan.

Quand compacter et gérer la session

Je privilégie la compaction proactive des sessions pour éviter que le contexte ne devienne un brouillard coûteux en tokens et en latence.

1) Expliquer la différence entre compaction proactive et réaction à une explosion du nombre de tokens, et pourquoi la proactive est préférable.

La compaction proactive consiste à réduire régulièrement le contexte avant qu’il n’atteigne des limites critiques. La réaction à une explosion des tokens survient quand on attend d’être proche du plafond pour agir. La proactive est préférable parce qu’elle évite des interruptions de flux, limite la perte d’information (on compresse de façon contrôlée) et réduit les coûts en tokens. Les modèles ont des fenêtres de contexte limitées (par exemple, des dizaines de milliers de tokens pour certains modèles), donc mieux vaut répartir l’effort plutôt que de tout résoudre en urgence.

2) Décrire des stratégies pratiques : règles temporelles (ex : compacter après X tours), règles événementielles (après ajout de gros fichiers ou sorties verbeuses), et règles basées sur importance (conserver uniquement les éléments critiques).

Mettre en place des règles simples aide à l’opérationnel. Règles temporelles : compacter toutes les 8–12 interactions utilisateur/assistant. Règles événementielles : lancer la compaction après l’upload d’un fichier >1 Mo ou après une sortie >2 000 tokens. Règles d’importance : conserver uniquement les décisions, TODOs et données d’état; supprimer ou résumer logs détaillés et alternances conversationnelles mineures.

3) Présenter des techniques complémentaires : résumés périodiques (transformer N tours en un résumé synthétique), externalisation de mémoire longue via caches ou bases vectorielles pour éléments rarement nécessaires, et batch processing pour regrouper plusieurs requêtes avant envoi.

Résumé périodique : convertir N tours (p.ex. 10) en un résumé de 100–250 tokens. Externalisation : stocker les éléments rarement consultés dans une base vectorielle (embeddings = représentation numérique) et ne réhydrater que ce qui est pertinent. Batch processing : grouper plusieurs requêtes non urgentes pour les envoyer en lot et réduire les allers-retours.

4) Donner une politique d’exemple à appliquer en entreprise : seuils de triggers pour /compact, format de résumé (nombre de points, tokens approximatifs) et procédure pour ré-hydrater une session depuis la mémoire externe.

Politique d’exemple : déclencheur /compact automatique après 10 tours ou après ajout >1 Mo. Format de résumé : 6–8 points clés, 150–200 tokens (~100–150 mots). Ré-hydratation : interroger la base vectorielle avec l’embedding du prompt actuel, récupérer top-5 documents pertinents, injecter un court extrait (≤200 tokens) et ajouter un lien vers la source complète.

Trigger	Action	Effet attendu
Après 10 tours	Lancer /compact (résumé 150–200 tokens)	Réduction progressive du contexte, conservation des décisions
Upload >1 Mo	Extraire métadonnées et résumé, stocker dans vector DB	Empêche inflation de tokens, accès sur demande
Sortie >2 000 tokens	Compacter la sortie verbale en points clés	Moins de tokens pour le suivi

# Exemple de procédure (pseudo)
# 1. /compact -> créer résumé 6 points (~180 tokens)
# 2. Indexer résumé + fichier complet dans base vectorielle
# 3. Ré-hydrater: rechercher top-5, injecter extraits <=200 tokens

Prêt à réduire vos coûts tokens sans perdre en efficacité ?

En appliquant ces pratiques — choisir le bon modèle, condenser CLAUDE.md, déléguer le verbeux, pointer précisément les fichiers et compacter la session — vous réduisez le contexte inutile et limitez la consommation de tokens. Ces mesures gardent la qualité des résultats tout en faisant baisser le coût opérationnel. Vous gagnez en temps, en pertinence et en maîtrise budgétaire.

FAQ

• Qu'est-ce qu'un token et pourquoi ça coûte ?
  Un token est une unité de texte que le modèle traite (morceau de mot, mot ou ponctuation). Chaque élément de contexte envoyé au modèle consomme des tokens, et plus le contexte est grand plus le coût augmente. Contrôler le contexte réduit donc directement la facture.
• Que doit contenir CLAUDE.md pour être efficace ?
  CLAUDE.md doit contenir uniquement des règles stables et réutilisables (ton, templates, contraintes essentielles). Exclure logs, historiques ou notes temporaires pour éviter d'être facturé à chaque tour.
• Quand faut-il créer un sous-agent ?
  Créer un sous-agent quand le travail produit beaucoup de texte (dumps, recherches, reasoning multi-étapes) et qu'un résumé concis suffit au fil principal. Éviter pour les petites tâches où le coût de démarrage domine.
• Qu'est-ce que la commande /compact et quand l'utiliser ?
  /compact réduit et synthétise le contexte de la session. Il faut l'utiliser de manière proactive (règles régulières ou après opérations lourdes) plutôt qu'attendre une saturation du nombre de tokens.
• Comment savoir quel modèle choisir pour une tâche donnée ?
  Choisissez un modèle léger pour les tâches simples et rapides, un modèle intermédiaire pour revues ou résumés, et un modèle puissant pour analyses profondes. Automatisez la sélection avec heuristiques basées sur la taille d'entrée et la complexité attendue.

 

 

A propos de l'auteur

Franck Scandolera — expert & formateur en Tracking avancé server-side, Analytics Engineering, Automatisation No/Low Code (n8n), intégration de l'IA en entreprise et SEO/GEO. Responsable de l'agence webAnalyste et de l'organisme de formation 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.