Comment réduire les tokens Claude Code efficacement ?

Réduire les tokens Claude Code demande de maîtriser le contexte : modèles adaptés, compaction proactive, sous‑agents, CLAUDE.md concis et ciblage de fichiers. Je détaille 5 approches pratiques et critères pour choisir la bonne stratégie selon vos tâches.

Quel modèle choisir selon la complexité ?

Choisir un modèle adapté réduit directement la consommation de tokens et le coût en réservant les modèles coûteux aux tâches complexes.

Principe : différencier modèles légers pour opérations répétitives (extractions, formatages), modèles intermédiaires pour transformations textuelles et modèles lourds pour analyses profondes ou raisonnement multi‑étapes. Cette partition permet d’exécuter 80% des tâches courantes sur des modèles peu coûteux et de réserver les modèles lourds aux 20% restants.

Paramètres : l’« effort » (ou niveau de réflexion) correspond au budget compute alloué au modèle pour produire des raisonnements approfondis. Diminuer l’effort sur tâches simples réduit le temps de calcul et les tokens générés par des sorties longues ou des chaînes de pensée inutiles. Ajuster aussi max_tokens, temperature et top_p pour limiter la verbosité.

Critères de sélection : prendre en compte la latence acceptable, la précision requise, le volume d’entrée attendu et la fréquence des appels. Une tâche à haute fréquence et faible sensibilité peut utiliser un modèle léger même si la précision n’est pas parfaite.

Workflow recommandé : démarrer la session avec un modèle léger et n’appeler un modèle plus coûteux que si le résultat dépasse un seuil de confiance ou de complexité. Utiliser un score de confiance interne, un tag ‘analysis’ détecté ou la longueur du prompt pour monter en gamme.

Exemples concrets :

// Pseudo‑code JavaScript de sélection de modèle
async function chooseModel(prompt, tags, confidence){
  if(tags.includes('analysis') || prompt.length>2000 || confidence

Métriques à surveiller : tokens par requête, latence moyenne et coût par 1 000 requêtes. Utiliser ces métriques pour identifier les endpoints coûteux, puis A/B tester la substitution par un modèle léger et mesurer l'économie en tokens et en latence.

Sources et bonnes pratiques : consulter la documentation officielle des modèles pour connaître les coûts relatifs et les paramètres disponibles. Tester en A/B et instrumenter les logs pour quantifier les économies réelles avant déploiement.

Modèle	Usage conseillé	Avantages	Inconvénients
Léger	Extractions, formatages, réponses factuelles simples	Faible coût, faible latence	Moins précis sur raisonnement complexe
Intermédiaire	Paraphrase, résumé, transformations textuelles	Bon compromis précision/coût	Coût et latence modérés
Lourd	Analyses profondes, raisonnement multi‑étapes	Haute précision et raisonnement	Coûteux et plus lent

Que mettre dans CLAUDE.md pour limiter les tokens ?

Garder CLAUDE.md concis et strictement utile évite de facturer la même information à chaque tour.

Contenu recommandé : Inclure uniquement les règles stables du projet qui doivent être connues à chaque échange. Préciser comment lancer les tests (commande exacte), le gestionnaire de paquets utilisé (npm, pip, mvn...), les conventions de formatage (ex. : Prettier, Black, règles clés), les contraintes d'architecture (ex. services critiques, limites de latence), et les répertoires à ignorer pour l'analyse automatique. Exclure explicitement les notes de réunion, l'historique de conception, les dumps de code ou tout log trop volumineux qui alourdira le contexte.

Structure pratique : Organiser en sections courtes et normalisées. Chaque section commence par une phrase d'intention (une ligne) suivie de 2 à 5 bullets clairs. Ajouter un sommaire court en tête pour pointer vers les sections (facilite la référence). Cette structure permet aux assistants de reconnaître rapidement la règle sans relire des pages de texte.

Taille cible et justification : Viser quelques centaines de mots — typiquement 150–400 mots. Les tokens sont facturés par modèle ; à titre indicatif, 1 token ≈ 4 caractères et 1 000 tokens ≈ 750 mots. Réduire la taille du fichier diminue la répétition de tokens facturés à chaque tour et améliore la pertinence des réponses.

Mécanismes complémentaires : Externaliser les guides d'implémentation, historiques et exemples lourds dans un dépôt ou un wiki. Référencer précisément des chemins/sections dans CLAUDE.md (ex. docs/testing.md#ci) plutôt que coller le contenu. Utiliser ancres et chemins de fichiers pour pointer vers la section exacte.

Procédé d'entretien : Mettre en place une revue mensuelle ou déclenchée après une grosse refonte. Inscrire la mise à jour dans la checklist de release pour éviter l'accumulation de texte obsolète.

• Intention : Règles minimales nécessaires pour interagir avec l'IA.
• Tests : npm test --ci
• Paquet : Node.js 18+ / npm
• Format : Prettier + ESLint (règles principales)
• Ignorer : /node_modules, /build, /.cache
• Références : docs/testing.md#ci, docs/arch.md#services

Moins de répétition signifie moins de tokens facturés et des réponses plus ciblées.

Quand créer des sous agents ?

On crée un sous‑agent quand une tâche verbeuse ou technique (dumps de logs, recherches de fichiers, raisonnements multi‑étapes) polluerait le fil principal et quand la synthèse suffit au workflow.

• Raisons d'utiliser un sous‑agent : Isolation du contexte pour éviter la dérive de la conversation principale. Possibilité d'itérer sans encombrer la session principale, ce qui réduit les tokens visibles en continu. Production d'une synthèse dédiée et structurée réintégrable facilement dans le fil.
• Coût et limites : Mise en place d'un sous‑agent entraîne un overhead : définition d'outils/permissions, coûts fixes d'initialisation (par exemple 150–300 tokens pour prompt d'initialisation), et allers‑retours API. Estimer le point d'équilibre en comparant tokens générés internement vs overhead. Exemple chiffré : si l'analyse génère 2 000 tokens et que l'init du sous‑agent coûte 200 tokens, le gain net est ~1 800 tokens dans le fil principal.
• Règle pratique : Employer un sous‑agent quand l'effort de nettoyage du fil principal est supérieur au coût d'initialisation, ou quand un traitement isolé/parallelisable est nécessaire.
• Architecture et orchestration : Modèle simple : session principale → lancer sous‑agent via API (Application Programming Interface) → sous‑agent exécute recherches/analyses → renvoie un résumé structuré. Documenter l'interface avec format attendu (title, summary, actions), métadonnées (task_id, timestamp, provenance) et schema JSON clair.
• Automatisation : Exemple No/Low Code : n8n (outil d'automatisation visuelle) déclenche une requête POST vers le sous‑agent, attend la réponse, puis insère la synthèse dans la session principale. Payload JSON attendu :

{
  "task_id":"abc123",
  "input":"Dump de logs ou requête",
  "instructions":"Analyser et renvoyer title, summary, actions",
  "response_format":{
    "title":"string",
    "summary":"string (

On implémente une logique de retry minimale : retry exponentiel (backoff x2) jusqu'à 3 tentatives, journaliser chaque échec et basculer vers un mode dégradé si nécessaire.

• Bonnes pratiques : Privilégier des synthèses courtes et normalisées (title, summary, actions). Loguer séparément les données volumineuses pour audit plutôt que les renvoyer en clair. Prévoir des métadonnées de traçabilité (task_id, durée, tokens générés).

Cas d'usage	Critère d'activation	Bénéfice attendu
Analyse de logs volumineux	Output estimé > 1 000–2 000 tokens	Réduction du fil principal, synthèse actionnable
Recherche de fichiers distribués	Nécessité d'isoler credentials/permissions	Sécurité et auditabilité améliorées
Raisonnement multi‑étapes	Itérations internes fréquentes	Itération rapide sans polluer la conversation

Comment cibler précisément fichiers et lignes ?

Indiquer chemins de fichiers et plages de lignes précises réduit les explorations inutiles du dépôt et donc la consommation de tokens. Les tokens sont les unités de texte facturées par le modèle : plus vous envoyez de texte inutile, plus le coût et le temps augmentent.

Étapes concrètes pour cibler précisément fichiers et lignes :

• Formulation des requêtes : Soyez explicite sur les chemins et plages de lignes pour limiter l’entrée. Exemple de prompt ciblé : Compare src/auth/login.js lignes 1-120 avec src/auth/session.js lignes 1-90 et liste les différences de logique d'auth.
• Outils et commandes pratiques : Utilisez des commandes shell pour extraire seulement les extraits nécessaires avant de les envoyer.

# Extraire plages avec sed
sed -n '1,120p' src/auth/login.js > /tmp/login_excerpt.txt
sed -n '1,90p' src/auth/session.js > /tmp/session_excerpt.txt

# Concaténer avec headers pour coller dans le prompt
echo "=== src/auth/login.js (1-120) ===" > /tmp/prompt_payload.txt
cat /tmp/login_excerpt.txt >> /tmp/prompt_payload.txt
echo "" >> /tmp/prompt_payload.txt
echo "=== src/auth/session.js (1-90) ===" >> /tmp/prompt_payload.txt
cat /tmp/session_excerpt.txt >> /tmp/prompt_payload.txt

Automatisation simple : Générer d'abord un plan (mode plan, par exemple Shift+Tab ou commande équivalente) pour valider la stratégie d'analyse avant d'envoyer les extraits. Pourquoi ? Pour éviter des allers-retours coûteux et itératifs avec le modèle.

Techniques complémentaires : Indexez le dépôt avec rg (ripgrep) ou Sourcegraph pour retrouver rapidement les zones pertinentes sans tout transmettre. Ajoutez des métadonnées ou tags (ex. // OWNER: auth) dans les fichiers pour faciliter la recherche ciblée.

Exemple de prompt complet, prêt à l'emploi (collez après avoir extrait les extraits) :

Compare les deux extraits ci‑dessous.
Fichier A: src/auth/login.js lignes 1-120
Fichier B: src/auth/session.js lignes 1-90

1) Liste structurée des différences de logique (points numérotés).
2) Impact potentiel sur la sécurité et les sessions (3 points maximum).
3) Résumé en 5 lignes.
4) 3 suggestions d'actions prioritaires.

=== DEBUT EXTRAITS ===
[COLLER ICI /tmp/prompt_payload.txt]
=== FIN EXTRAITS ===

Produisez un petit tableau de synthèse montrant 'action', 'commande', 'quand l'utiliser' pour référence rapide.

Quand et comment utiliser /compact ?

Utiliser /compact de façon proactive, après des séquences longues ou avant de lancer des opérations coûteuses, permet de réduire la fenêtre de contexte et les tokens facturés par la suite.

La compaction consiste à résumer et éliminer les parties redondantes d'une conversation pour diminuer le nombre de "tokens" (unités de texte utilisées par le modèle) et la taille de la fenêtre de contexte (capacité mémorielle de la session).

• Quand : Après des sessions multi‑échanges (recherches, corrections, itérations) pour éliminer la redondance. Avant de basculer vers un modèle plus coûteux. Lorsque la session contient beaucoup d'informations historiques non pertinentes.
• Comment procéder : Déclencher /compact sur l'ID de session, vérifier le rapport de compaction qui liste ce qui a été résumé ou supprimé, et relancer les étapes critiques si nécessaire pour s'assurer qu'aucune décision n'a été perdue.
• Stratégies complémentaires : Combiner /compact avec des résumés structurés (Titre, Points clés, Décisions, Actions). Conserver les détails volumineux hors session (S3, dépôt Git, base documentaire) et insérer en session une référence concise (lien, ID, bref extrait).
• Mesure de l'impact : Comparer le nombre de tokens avant/après compaction via les compteurs d'usage de l'API ou un compteur local. Mesurer le temps de latence et le coût estimé si vous passez sur un modèle payant.

Workflow pas à pas :

/compact --session-id=abc123
# Attendre le rapport JSON de compaction
# Vérifier "résumé" et "supprimés"
# Réinjecter uniquement : titre + points clés + actions

Exemple de prompt réinsérant la synthèse :

Résumé court : [Titre] ; Points clés : 5 bullets ; Décisions : 2 items ; Actions : 3 tâches (responsable, échéance)

• Seuils et triggers : Après 5–10 itérations sur le même sujet, ou quand la pertinence des réponses chute, ou à 70% de la capacité de contexte utilisée. Automatiser la compaction via hooks (webhook après N échanges) ou dans un workflow d'orchestration (ex. GitHub Actions, Airflow).
• Risques et contrôles : Ne pas compacter avant d'avoir extrait les décisions critiques. Conserver un log d'audit (diffs) et un backup externe. Pour restaurer, recharger le dump externe et réinjecter les parties manquantes ou demander au modèle de "réhydrater" depuis le lien fourni.

Trigger	Action de compaction	Bénéfice	Précaution
Après 5–10 itérations	Lancer /compact et garder le résumé	Réduction tokens, meilleure réactivité	Vérifier décisions extraites
Avant modèle coûteux	Compacter puis switch	Moindre coût d'appel	Conserver logs d'audit
Session très longue (70% contexte)	Compacter sélectivement	Évite d'atteindre la limite	Backup des détails volumineux

Prêt à réduire vos coûts et la latence en maîtrisant le contexte ?

La maîtrise des tokens Claude Code passe par des choix simples et répétables : sélectionner un modèle adapté, maintenir un CLAUDE.md concis, déléguer le travail verbeux à des sous‑agents, pointer précisément fichiers et plages, et compacter la session au bon moment. Ces actions réduisent les tokens facturés, accélèrent les cycles et améliorent la pertinence. En appliquant ces règles vous diminuez directement vos coûts opérationnels et gagnez en efficacité pour les utilisateurs et les équipes.

FAQ

• Comment les tokens sont-ils facturés dans une session Claude Code ?
  La facturation porte généralement sur la taille du contexte (messages envoyés, fichiers ajoutés) et les réponses renvoyées. Réduire la taille et la répétition du contexte diminue directement la consommation de tokens.
• Que doit contenir strictement CLAUDE.md ?
  Seules les règles stables et utiles au projet : comment lancer les tests, gestionnaire de paquets, conventions de formatage, contraintes architecturales et répertoires à ignorer. Évitez notes de réunion et guides volumineux.
• Les sous‑agents valent-ils le coût supplémentaire ?
  Oui si la tâche génère beaucoup d'informations ou d'itérations : un sous‑agent isolé peut produire une synthèse propre qui évite d'encombrer le fil principal. Évaluez l'équilibre entre surcoût d'initialisation et gains en propreté du contexte.
• Quand utiliser la commande /compact ?
  Proactivement après des séquences longues, avant des opérations coûteuses ou lors de basculements de modèle. Combinez la compaction avec des résumés structurés pour préserver les décisions clés.
• Comment éviter d'envoyer tout un dépôt au modèle ?
  Ciblez précisément les fichiers et plages de lignes, utilisez des commandes pour extraire uniquement les extraits pertinents et servez‑vous d'un outil d'indexation/code search pour localiser les zones utiles.

 

 

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 Formations Analytics. Références : Logis Hôtel, Yelloh Village, BazarChic, Fédération Française de Football, Texdecor. Dispo pour aider les entreprises => contactez moi.