Bonnes pratiques d'agentic coding pour des coûts en tokens

Quelles sont les bonnes pratiques pour garder l'agentic coding peu coûteux ?

La meilleure pratique en agentic coding est de contrôler ce que l'agent lit, car dans une boucle d'utilisation d'outils c'est l'input — pas l'output — qui consomme votre argent. Tout le reste découle de cette seule idée. Je construis du tooling de tokens pour gagner ma vie, et j'ai vu la même erreur se rejouer sur chaque agent que j'ai profilé : les gens s'obsèdent à écrire le prompt parfait pendant que l'agent avale en silence un fichier de 4 000 lignes, déverse un log de tests verbeux dans le contexte, puis renvoie cette transcription entière au tour suivant, et au suivant, et au suivant. Le prompt n'a jamais été le problème. C'était le contexte. Ce n'est donc pas une listicle de « hacks de prompt ». C'est l'ensemble des habitudes qui font vraiment bouger la facture, classées grossièrement selon ce qu'elles économisent. Si vous voulez d'abord la vue d'ensemble, l'article pilier est Comment réduire l'usage de tokens des agents de coding IA.

Pourquoi la boucle de l'agent coûte-t-elle autant au départ ?

Les coûts de l'agentic coding s'accumulent parce que chaque tour renvoie en input l'intégralité de la conversation accumulée ; le contexte n'est donc pas un coût ponctuel — c'est une taxe récurrente. Un simple chat envoie votre prompt une seule fois. Une boucle agentique lit des fichiers, exécute des commandes, observe la sortie, et recommence — souvent des dizaines de fois pour une seule tâche. Au tour 12, le modèle relit les tours 1 à 11 en input. Les fichiers qu'il a ouverts au tour 2 sont toujours embarqués au tour 20. C'est pourquoi un « petit correctif » peut discrètement brûler des centaines de milliers d'input tokens : le context window ne fait que grandir, et vous payez le tout à chaque étape. La tarification rend l'enjeu concret. Sur Claude Opus 4.8, l'input revient à $5 par million de tokens et l'output à $25 ; Sonnet 4.6 est à $3 / $15 ; Haiku 4.5 à $1 / $5 ; GPT-5.5 à $5 en input / $30 en output. L'output est plus cher par token, c'est vrai — mais dans une longue boucle d'agent vous lisez en général bien plus que vous n'écrivez, donc c'est la colonne input qui fait des dégâts cumulés.

Bonne pratique 1 : faire une recherche sémantique au lieu de lire des fichiers entiers

L'habitude la plus rentable est de ne jamais laisser l'agent lire un fichier entier quand il n'a besoin que d'une fonction. Les lectures de fichiers entiers sont la principale source unique d'input tokens gaspillés que je rencontre. Le comportement par défaut de l'agent est brutalement littéral : il veut comprendre auth.ts, alors il lit les 1 200 lignes, même si le bug vit dans un seul handler de 15 lignes. Multipliez ça sur toute une session de debug et vous avez payé pour des milliers de lignes que le modèle a survolées puis oubliées. La solution, c'est la semantic code search — récupérer les extraits pertinents par le sens plutôt que de grepper ou d'avaler des fichiers. Tirez les trois fonctions qui comptent vraiment, pas les quatre fichiers où elles vivent. J'ai détaillé le face-à-face dans Semantic Search vs Grep ; en résumé, grep trouve des correspondances de chaînes et la semantic search trouve des concepts, et ce sont généralement les concepts que vous déboguez.

Bonne pratique 2 : filtrer la sortie des commandes avant qu'elle n'atteigne le contexte

Réduisez toujours l'output des outils à son signal avant que l'agent ne l'ingère. Une suite de tests qui passe, un npm install réussi, un log de build verbeux — l'agent n'a pas besoin des 800 lignes pour apprendre « ça a marché ». C'est le levier le plus sous-estimé, parce que le gaspillage est invisible. Vous lancez les tests, ils passent, vous passez à la suite — et l'agent a tranquillement absorbé la sortie complète du reporter, puis l'a transportée à chaque tour suivant. L'output filtering ramène ça à la seule ligne qui compte : pass/fail, l'erreur, le diff. J'ai décortiqué des exemples concrets dans Output Filtering for Command Logs. Une règle de pouce que j'applique : si un humain survolerait un log et n'en lirait qu'une ligne, l'agent devrait recevoir une ligne.

Bonne pratique 3 : gardez vos fichiers CLAUDE.md et de règles légers

Élaguez vos fichiers d'instructions de projet sans pitié, car ils sont préfixés à chaque requête et vous les payez à chaque tour, que l'agent les utilise ou non. CLAUDE.md, .cursorrules et leurs semblables sont du contexte persistant. Un fichier de règles boursouflé de 600 lignes qui documente toute votre architecture, ce sont 600 lignes de taxe sur chaque message — y compris ceux où l'agent ne fait que renommer une variable. J'ai vu des fichiers d'instructions plus gros que le code qu'ils décrivent. Réduisez-les aux règles que l'agent doit réellement suivre, et déplacez le matériel de référence dans des fichiers qu'il peut récupérer à la demande. Plus de détails sur ce mode d'échec dans CLAUDE.md Token Bloat.

Bonne pratique 4 : charger les outils MCP paresseusement, pas tous d'un coup

Ne déclarez pas chaque serveur MCP que vous possédez à chaque session. Chaque définition d'outil, ce sont des tokens dans votre contexte avant même que l'agent n'ait fait quoi que ce soit. Les serveurs MCP sont merveilleux, et c'est précisément le piège — il est facile d'en brancher dix et de ne jamais remarquer que la somme de leurs schémas d'outils dévore des milliers de tokens en haut de chaque conversation. Le lazy loading signifie que les définitions d'outils n'entrent dans le contexte que lorsqu'elles sont plausiblement pertinentes. Si vous choisissez quels serveurs garder, je tiens une shortlist à jour dans Best MCP Servers for Claude Code.

Bonne pratique 5 : cadrer la tâche et laisser le contexte se compresser

Donnez à l'agent une tâche étroitement cadrée et laissez les longs historiques se compresser, car un objectif illimité produit une boucle illimitée. « Corrige les tests qui échouent dans le module paiements » est un travail. « Améliore le codebase » est une invitation à lire tout ce que vous possédez. Plus le cadrage est étroit, moins l'agent touche de fichiers et plus la boucle est courte. Pour les longues sessions inévitables, la compression de contexte résume les premiers tours pour que le modèle garde les conclusions sans repayer la transcription brute. C'est la discipline du context engineering : vous êtes l'éditeur de ce que le modèle voit.

Bonne pratique 6 : exploiter le prompt caching au lieu de le combattre

Structurez vos sessions pour que les parties stables de votre contexte restent identiques octet pour octet, car les lectures d'input en cache coûtent environ 10 % d'un input normal. Le prompt caching est le seul endroit où les fournisseurs vous offrent une vraie réduction, et la plupart des gens y renoncent par accident — ils modifient le system prompt en cours de session, ou réorganisent l'ordre du contexte, et cassent le cache. Gardez le préfixe stable (votre fichier de règles, votre system prompt, la vue d'ensemble du projet) constant et laissez la partie volatile changer à la fin. Un cache hit sur Opus 4.8 transforme ce $5/MTok d'input en environ $0,50/MTok pour le segment mis en cache. Ce n'est pas une erreur d'arrondi ; sur une journée de travail agentique, c'est l'essentiel de votre facture.

Comment appliquer tout ça dès aujourd'hui ?

Voici l'ordre dans lequel je le ferais vraiment, le retour le plus rapide d'abord :

Allégez vos fichiers d'instructions. Ouvrez CLAUDE.md / .cursorrules maintenant et coupez tout ce dont l'agent n'a pas strictement besoin. Cinq minutes, des économies récurrentes à chaque tour.
Élaguez vos serveurs MCP. Désactivez ceux que vous n'utilisez pas dans cette session.
Arrêtez de lire les fichiers entiers. Prenez l'habitude de demander la fonction précise, pas le fichier.
Filtrez les commandes bruyantes. Faites passer les outils verbeux par quelque chose qui renvoie le résumé.
Cadrez étroitement les tâches. Un travail par requête.
Protégez votre cache. Ne réorganisez pas et n'éditez pas le préfixe stable en cours de session.
Mesurez. On ne peut pas corriger ce qu'on ne voit pas — instrumentez votre usage de tokens avant et après.

La plupart sont des habitudes, ce qui veut dire qu'elles sont faciles à oublier sous la pression d'une deadline. C'est la raison honnête pour laquelle j'ai construit Tokenade : il fait la semantic search, l'output filtering, la compression par skeleton et le chargement paresseux des MCP automatiquement, puis vous montre les économies sur un dashboard pour que vous ne deviniez pas. Il fonctionne à travers Claude Code, Cursor, Codex, Copilot, Windsurf et les autres, il est source-available sous licence MIT, et le tier gratuit couvre environ 10M tokens par mois — assez pour que vous puissiez vérifier les économies avant même de penser au plan Pro à 19,90 $/mois.

Ce qui tourne mal : les anti-patterns

Les modes d'échec sont surtout l'inverse des pratiques ci-dessus, mais quelques-uns méritent d'être soulignés car ils sont faciles à commettre tout en se sentant productif.

Faire du prompt-golfing pendant que le contexte enfle. Passer vingt minutes à ciseler le prompt pendant que l'agent lit la moitié du repo dès le premier tour. Le prompt, c'est peut-être 5 % de la dépense.
Lectures de fichiers « par sécurité ». Dire à l'agent de lire les fichiers liés de manière préventive. Il les lira, en oubliera l'essentiel, et traînera le reste comme un poids mort pour tout le reste de la session.
Traiter les output tokens comme l'ennemi. Les gens plafonnent max_tokens agressivement et se sentent économes, puis se demandent pourquoi la facture n'a pas bougé — parce que l'input représentait 80 % du total depuis le début. Consultez le détail des coûts en tokens si vous ne me croyez pas.
Casser le cache par habitude. Éditer le system prompt ou réorganiser le contexte en cours de tâche, jetant en silence la réduction de 90 %.
Aucune mesure. Le plus courant. Si vous ne comptez pas les tokens, vous volez à l'aveugle ; commencez par un token counter et le calculateur de coûts pour mettre de vrais chiffres sur une tâche.

Rien de tout cela n'exige un modèle plus petit ou un agent moins bon. Cela exige d'être délibéré sur la seule variable qui fait vraiment grimper votre facture : ce que le modèle lit.

Voir aussi (hub-and-spoke) :

Bonnes pratiques d'agentic coding pour des coûts en tokens raisonnables