Optimiser sa consommation de tokens avec Claude Code et Copilot : ce qui marche vraiment

Réduire sa consommation de tokens n'est pas qu'une question de coût. Un contexte encombré de contenu inutile ne coûte pas seulement plus cher : il dilue aussi ce qui compte vraiment dans la fenêtre de contexte, et dégrade la qualité des réponses avant même d'atteindre une limite technique. Les techniques qui suivent servent les deux objectifs à la fois, pas seulement la facture.

Les leviers, en un coup d'œil

Levier	Ce qu'il économise	Coût si on l'ignore
Lecture ciblée (grep, offset/limit) plutôt que fichier entier	Tokens d'entrée à chaque lecture	Des milliers de lignes non pertinentes chargées pour une seule fonction
Prompt caching (préfixe stable)	Jusqu'à 90 % sur les tokens en cache	Réécriture complète du contexte stable à chaque appel
Sous-agents pour l'exploration large	Contexte principal préservé	La conversation principale gonfle de résultats intermédiaires jetables
Ne pas re-vérifier ce que l'outil garantit déjà	Une lecture entière évitée	Une relecture systématique après chaque édition, sans valeur ajoutée
Appels d'outils indépendants en parallèle	Nombre d'allers-retours	Contexte retransmis à chaque tour séquentiel
Préférences stables en mémoire/CLAUDE.md	Répétition dans chaque prompt	Le même rappel réécrit à la main dans chaque conversation

Le prompt caching, expliqué simplement

Le mécanisme de cache d'Anthropic fonctionne sur un préfixe stable : la partie du contexte qui ne change pas d'un appel à l'autre (instructions système, structure du projet, fichiers de référence) peut être marquée comme cacheable. Le premier appel paie un surcoût d'écriture, mais chaque appel suivant qui réutilise exactement ce même préfixe lit le cache à environ 10 % du tarif normal, tant que le délai de validité n'est pas dépassé.

Durée de cache	Surcoût à l'écriture	Réduction à la lecture
5 minutes	×1,25 le tarif standard	−90 %
1 heure	×2 le tarif standard	−90 %

Ce mécanisme explique pourquoi la position du contenu dans une conversation compte : un système d'instructions et un CLAUDE.md placés en tête, qui ne changent pas d'un tour à l'autre, profitent du cache. Un contexte reconstruit différemment à chaque appel (fichiers dans un ordre variable, contenu reformaté) invalide le préfixe et paie le tarif plein à chaque fois, sans qu'on s'en rende compte si on ne surveille pas la facture.

La lecture ciblée plutôt que le fichier entier

La tentation la plus fréquente est de charger un fichier en entier pour répondre à une question qui ne concerne qu'une fonction. Sur un fichier de plusieurs milliers de lignes, grep pour localiser le symbole recherché, suivi d'une lecture limitée aux lignes pertinentes, coûte une fraction du prix d'une lecture complète, pour un résultat identique sur la question posée.

# Coûteux : charge tout le fichier, même les 1900 lignes non pertinentes
lire src/services/billing.ts (2000 lignes)

# Ciblé : localise d'abord, puis lit seulement la zone concernée
grep "calculateInvoice" src/services/billing.ts
lire src/services/billing.ts, lignes 340-410

Les sous-agents comme cloison, pas seulement comme parallélisme

L'intérêt le plus sous-estimé des sous-agents n'est pas la vitesse d'exécution parallèle, c'est l'isolation du contexte. Une recherche large dans une base de code (« où est configuré tel comportement ? ») peut nécessiter d'explorer des dizaines de fichiers avant de trouver la bonne réponse. Déléguer cette exploration à un sous-agent, qui ne renvoie que sa conclusion, évite que la conversation principale n'accumule tous les résultats intermédiaires qui n'ont plus aucune valeur une fois la réponse trouvée.

Faire confiance à ce que l'outil garantit déjà

Un piège fréquent : relire systématiquement un fichier après l'avoir modifié, par excès de prudence. Si l'outil d'édition confirme le succès de l'opération, cette relecture n'apporte aucune information nouvelle, elle ne fait que payer une deuxième fois pour un contenu déjà connu. La vérification a du sens quand un résultat est réellement incertain, pas de façon systématique par réflexe.

Le cas particulier de Copilot : le contexte, ce n'est pas que le prompt

Sur GitHub Copilot, il n'y a pas de contrôle explicite du cache côté utilisateur, mais le principe reste le même sous une autre forme : l'ensemble des fichiers ouverts dans l'éditeur influence la suggestion, pas seulement le fichier actif. Fermer les fichiers sans rapport avec la tâche en cours, garder les fonctions courtes et bien nommées, et remplacer de longs échanges en chat par un commentaire précis au bon endroit dans le code, réduit ce qui doit être pris en compte pour chaque suggestion, avec un effet similaire à un contexte plus ciblé côté agent conversationnel.

Ce que l'optimisation ne doit jamais sacrifier

Toutes ces techniques visent à retirer ce qui ne sert à rien, jamais à couper ce qui est réellement nécessaire à la tâche. Un contexte trop comprimé qui oblige l'assistant à deviner une information manquante coûte toujours plus cher au global, en itérations de correction, qu'un contexte un peu plus généreux mais correct du premier coup. L'objectif n'est pas de minimiser les tokens à tout prix, c'est de ne payer que pour ce qui apporte réellement de la valeur à la réponse.