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

Réduire l’utilisation des tokens Claude Code demande d’optimiser le contexte : choisir le bon modèle, garder CLAUDE.md concis, déléguer les sorties verbeuses, pointer précisément les fichiers et compacter le contexte proactivement. Je détaille 5 stratégies concrètes et actions opérationnelles.

Quel modèle choisir selon la complexité ?

Adaptez le modèle à la complexité de la tâche pour économiser des tokens et conserver la qualité.

Principe. Les modèles plus puissants coûtent plus parce qu’ils mobilisent plus de paramètres et plus d’opérations de calcul pour chaque token. La couche d’attention a un coût qui croît approximativement en O(n²) avec la longueur de la séquence (n), et les « scaling laws » montrent que la perte diminue selon une loi de puissance quand on augmente taille et compute (Kaplan et al., 2020). Pour des tâches simples et répétitives, un modèle allégé suffit et évite un surcoût inutile.

• Grille pratique. Sonnet : famille légère, usage pour petites opérations répétitives, reformattage, extraction. Haiku : intermédiaire, usage pour tâches quotidiennes, résumé, génération d’e-mails structurés. Opus : haute capacité, usage pour analyses profondes, raisonnement multi‑étapes, correction de code complexe. Le compromis reste latence/coût/qualité : Sonnet = faible coût, faible latence, qualité suffisante ; Opus = coût élevé, latence plus longue, meilleure qualité sur cas complexes.
• Paramétrage du « budget de réflexion ». Baisser la temperature réduit la variance et l’exploration (0 = déterministe). Réduire un paramètre d’effort (si disponible dans l’API) diminue le temps de recherche interne. Exemple de prompt système simple pour limiter l’effort :

// Exemple pour API (illustratif)
{"system":"Répondre concisément, effort de raisonnement : faible, température : 0.2"}

• Processus opérationnel. Évaluer la complexité (décrire en 3 critères : profondeur de raisonnement, longueur de contexte, variabilité des réponses). Tester sur 2–3 cas réels représentatifs. Mesurer tokens utilisés et qualité (score de 0–100 ou checklist). Basculer vers le modèle le moins coûteux qui atteint le seuil qualité choisi.

Usage-type	Quand privilégier	Avantages	Inconvénients
Sonnet	Tâches courtes, répétitives	Coût faible, latence faible	Moins performant sur raisonnement
Haiku	Tâches quotidiennes, résumé	Bon équilibre coût/qualité	Peut manquer sur cas très complexes
Opus	Analyses profondes, debug	Meilleure qualité, raisonnement	Coût et latence élevés

Trois recommandations concrètes et mesurables.

• Tester Sonnet vs Opus sur 3 cas représentatifs et choisir l’option la moins coûteuse qui obtient ≥95% du score qualité cible.
• Pour tâches déterministes (formatage, extraction), fixer temperature ≤0.2 et effort faible ; mesurer la variance sur 50 exécutions.
• Limiter le contexte actif en résumant l’historique à 500–1 000 tokens pour réduire le coût d’attention d’au moins 30%.

Comment garder CLAUDE.md utile et court ?

Limitez CLAUDE.md aux règles stables et essentielles car il est rechargé à chaque tour et génère des tokens permanents.

Claude.md est le fichier de directives système chargé à chaque échange avec le modèle. Les tokens consommés par ce contexte persistent dans la facturation : plus le contexte est long, plus chaque tour coûte. Un token correspond en moyenne à ~4 caractères ou ~0,75 mot, donc réduire le contexte de 2 000 à 200 tokens réduit le coût de ce contexte par tour d’environ 90%.

À garder	À retirer
Règles d’exécution des tests (format, critères de réussite).	Logs verbeux et historiques d’incidents.
Conventions critiques (naming, sécurité, données sensibles).	Brainstorming, idées non stabilisées.
Contraintes architecturales immuables (limites API, schémas).	Gros exemples de code ou extractions d’API.

Externaliser le reste vers des fichiers versionnés (Git), une base de connaissances (KB) ou des résumés courts stockés en mémoire secondaire diminue le contexte. Utiliser des liens internes ou des IDs de document plutôt que copier-coller. Mettre un résumé de 1-2 phrases dans CLAUDE.md pointant vers la source détaillée.

• Revue hebdo : Vérifier les règles inchangées et supprimer ce qui n’a pas été utilisé depuis 30 jours.
• Règles de contribution : Toute règle >5 lignes doit être externalisée et approuvée par 1 reviewer.
• Checklist par règle (5 lignes max) : But, Entrée, Sortie, Erreur attendue, Source.
• Exemples de phrases concises à insérer : « Réponds uniquement en JSON. », « Limite de tokens de sortie : 300. », « Ne divulguer aucune donnée PII. »

Exemple optimisé (3 lignes) :
Respecte le format JSON strict sans explications supplémentaires.
Limite de sortie : 300 tokens maximum.
Ne transmettre aucune donnée personnelle identifiée (PII).

• Vérifier : Chaque règle est-elle essentielle et stable ? (1 min)
• Nettoyer : Supprimer tout log, brainstorm et exemple lourd. (1 min)
• Externaliser : Pointer vers doc Git/Kb pour détails. (1 min)
• Rédiger : Résumer chaque règle en ≤5 lignes. (1 min)
• Contrôler : Commit + review rapide avant merge. (1 min)

Quand et comment utiliser des subagents ?

Utilisez des subagents pour isoler le travail verbeux et ne renvoyer au contexte principal que des résumés utiles, mais pesez le coût de démarrage et l’overhead. Cette approche réduit le « bruit » dans le contexte principal en déplaçant les sorties longueurs vers des instances dédiées, à condition que l’économie de tokens compense les appels supplémentaires.

Définition et isolation

Un subagent est une instance dédiée (modèle, processus ou job) qui réalise une tâche ciblée et retourne uniquement un résumé ou une référence. Cette isolation empêche d’injecter des milliers de tokens de logs, de parsing ou de rapports dans le contexte principal. Le subagent peut écrire les détails en stockage externe et ne renvoyer que l’essentiel.

Cas d’usage pertinents

• Génération de rapports longs: Produire un rapport complet mais n’envoyer au moteur principal que le résumé et le lien vers le rapport.
• Nettoyage de données: Appliquer transformations verbeuses et ne renvoyer que les anomalies détectées.
• Parsing verbeux: Extraire structure et garder uniquement le schéma résumé.
• Tests automatisés: Exécuter suites lourdes et renvoyer résultats synthétiques (pass/fail, erreurs critiques).

Coûts et seuil de rentabilité

Coûts directs: appels supplémentaires, latence et stockage. Coûts indirects: complexité d’orchestration et maintenance. Règle pratique: si l’utilisation de tokens du contexte principal est réduite de 20–30% ou plus, ou si chaque appel principal gagne sensiblement en clarté, alors le subagent devient rentable. Mesurer via A/B: comparer tokens consommés et temps de réponse avec/sans subagent.

Pattern exemple

// Lancer subagent, récupérer résumé structuré
{
  "title":"Analyse API / Endpoint X",
  "bullets":[
    "Point clé 1",
    "Point clé 2",
    "Point clé 3"
  ],
  "verdict":"Action recommandée"
}

Champ	Exemple
Title	Analyse API / Endpoint X
Bullets	3 points synthétiques
Verdict	Action recommandée

Implémentations pratiques

• Orchestration via n8n: Composer flows qui déclenchent subagents et stockent résultats.
• Scripts server-side: Lancer instances isolées et renvoyer uniquement le résumé au frontend.
• Jobs batch: Écrire les détails dans un stockage consultable (S3, DB) et garder des pointeurs dans le contexte.

Quatre règles de gouvernance

• Définir des SLA clairs: latence acceptable et fréquence des appels.
• Limiter la duplication de travail: éviter que plusieurs subagents refassent les mêmes tâches.
• Mesurer systématiquement: tokens consommés, coûts monétaires et gains en lisibilité.
• Revoir périodiquement: désactiver les subagents dont l’overhead dépasse la valeur ajoutée.

Comment pointer Claude sur fichiers et plages précises ?

être précis sur fichiers et plages de lignes réduit les recherches inutiles et les tokens gaspillés.

Préciser le fichier et la plage de lignes évite d’envoyer des kilooctets de texte non pertinents, donc moins de tokens consommés. Donner un chemin exact et des numéros de ligne transforme une requête large en une requête ciblée, réduisant les allers-retours et les itérations coûteuses.

• Pourquoi la précision économise des tokens : En ciblant un extrait, on envoie uniquement le contenu utile au modèle au lieu de tout le dépôt. Cela réduit le texte encodé et le nombre d’étapes nécessaires pour obtenir une réponse correcte.
• Formulations claires à copier/coller :
  • Ouvrir le fichier précis :

    # Exemple :

  • Indiquer chemin+fichier+lignes :

    /repo/service/api.py Lignes 120-160 — Expliquer la fonction process_order()

  • Utiliser marqueurs :

    /docs/README.md -- START:FEATURE_X -- END:FEATURE_X — Résumer uniquement le bloc entre ces marqueurs

• Usage du mode plan (Shift+Tab) : Générer d’abord un plan étape par étape permet de valider l’approche avant d’exécuter. Donner l’instruction « Propose un plan en 3 étapes » (avec Shift+Tab pour basculer) réduit les essais/erreurs et donc les tokens gaspillés.
• Découper de gros fichiers (chunking) : Fractionner un fichier en fragments logiques (fonction, classe, section) et n’envoyer que le chunk pertinent. Méthode : 1) Identifier la section utile ; 2) Extraire 1-3 chunks autour ; 3) Envoyer seulement ces morceaux. Pour des corpus très volumineux, préférer RAG (Retrieval-Augmented Generation — recherche + génération) avec une base de données vectorielle (vector DB) pour récupérer uniquement les passages pertinents.

Exemples comparatifs :

Requête vague (texte envoyé ~5000 caractères) : « Expliquez comment marche l’API dans ce dépôt entier. »

Requête précise (texte envoyé ~250 caractères) : « /repo/service/api.py Lignes 120-160 — Expliquer la logique de la fonction process_order() et lister les entrées/sorties. »

Format de réponse attendu pour limiter la verbosité : Commencer par un résumé 2-3 lignes, puis bullets pour entrées/sorties et un court exemple de code (si pertinent). Ne pas demander d’explications longues sauf si nécessaire.

Question vague	Question précise	Gain attendu
« Expliquer l’API entière »	« /repo/service/api.py L120-160 — Expliquer process_order() »	Réduction des tokens et des itérations, réponses plus actionnables

Quand et comment compacter le contexte avec /compact ?

Compacter le contexte de façon proactive réduit les tokens facturés en supprimant ou résumant l’historique non pertinent avant qu’il ne devienne coûteux.

La commande /compact réécrit l’historique en supprimant ou en compressant les messages redondants et en conservant les points clefs sous forme condensée. La temporisation est essentielle : compacter juste avant des sessions longues évite l’accumulation, et compacter après des étapes majeures (livrable, décision, pivot) préserve l’essentiel sans perdre le fil.

Voici une stratégie de compaction proactive :

• Seuils : Compacter après ~10 échanges longs ou lorsque l’historique dépasse 2 000–5 000 tokens (un token ≈ 4 caractères selon OpenAI).
• Points de sauvegarde : Générer des résumés à chaque jalon (design, tests, livraison) et stocker hors-session dans un fichier ou une base de connaissances.
• Fréquence : Exécuter /compact au moins une fois par tâche terminée ou toute les 30–60 minutes pendant une session intensive.

Automatisation possible (workflow) :

# Déclencheur : fin de tâche ou seuil atteint
# Génération : demander au modèle un résumé synthétique (1-3 paragraphes)
# Stockage : écrire résumé dans stockage externe (fichier CLAUDE.md ou DB)
# Action : appeler /compact pour réduire le contexte

Vérifier que la compaction préserve l’information nécessaire par des tests rapides :

• Vérifier la présence des points clefs via checksums ou hashes sur extraits critiques.
• Inclure des IDs de référence dans les résumés permettant de recharger des détails à la demande.
• Effectuer des requêtes de contrôle (questions ciblées) après compaction pour confirmer que les réponses restent exactes.

Modèles de résumé à 3 niveaux et emplacement :

• Bullet (1–3 lignes) : Lister décisions et livrables courts — À garder dans CLAUDE.md pour contexte rapide.
• Executive (1 paragraphe) : Synthèse de l’objectif, progrès et risques — À garder dans CLAUDE.md et mémoire active.
• Archive détaillée : Notes complètes, logs et preuves — À stocker hors-contexte (archive) et référencer par ID.

Quand compacter	Action	Résultat attendu
Après 10 échanges longs	Générer résumé + /compact	Contexte réduit, points clefs conservés
À la fin d’une tâche	Archiver détail + garder executive	Restauration possible, coûts réduits
Session > 30 min	Compaction intermédiaire	Stabilité de la latence et maîtrise des tokens

Prêt à appliquer ces optimisations et réduire vos coûts tokens ?

Ces cinq leviers (choix de modèle, CLAUDE.md concis, subagents bien conçus, requêtes précises et compaction proactive) permettent de réduire fortement le gaspillage de tokens tout en maintenant la qualité des résultats. En appliquant les processus décrits — tests A/B, règles de contribution, workflows d’orchestration et résumés automatisés — vous diminuez coûts et latence, facilitez la maintenance et gagnez en prévisibilité. Le bénéfice concret : moins de dépenses liées au contexte, des réponses plus rapides et une équipe qui travaille sur l’essentiel. Si vous voulez accélérer la mise en place, je peux vous accompagner.

FAQ

• Qu’est-ce qui génère le plus de tokens dans une session Claude Code ?
  Les éléments persistants et verbeux comme l’historique de messages, les fichiers chargés, les mémoires persistantes (ex. CLAUDE.md) et les sorties d’outils. Chaque tour ré-expose souvent ces éléments, ce qui augmente rapidement le nombre de tokens facturés.
• Comment réduire les tokens sans perdre en qualité de réponse ?
  Adaptez le modèle à la tâche, limitez CLAUDE.md aux règles essentielles, déléguez les sorties longues à des subagents et pointez toujours sur fichiers/plages précises. Compacter le contexte avant qu’il ne devienne volumineux permet aussi de conserver l’information utile tout en réduisant les tokens.
• Les subagents coûtent-ils plus qu’ils n’économisent ?
  Ils ont un coût de démarrage et des frais généraux. Ils sont rentables quand ils réduisent suffisamment le désordre du contexte principal pour diminuer les appels coûteux et les itérations. Mesurez le seuil de rentabilité en testant sur cas réels.
• Que mettre absolument dans CLAUDE.md ?
  Uniquement les règles stables et indispensables : conventions critiques, contraintes architecturales et instructions d’exécution des tests. Évitez les notes historiques, exemples longs ou logs — externalisez-les et conservez un résumé court si nécessaire.
• Quand utiliser la commande /compact ?
  Plutôt de façon proactive : après des étapes majeures ou quand l’historique dépasse un seuil (nombre d’interactions ou taille en tokens). Créez un résumé synthétique avant la compaction et stockez le détail hors-session pour pouvoir le récupérer si besoin.

 

 

A propos de l’auteur

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