L'illusion des tokens

Un schéma revient sans cesse dans les sessions d'agents IA en production : tu donnes une tâche simple à ton assistant, il fait du bon travail, et puis tu regardes le compteur de tokens et tu restes perplexe.

Un développeur a récemment instrumenté une session où un agent a clos un ticket GitHub. Lecture du problème, modification d'un fichier, exécution des tests, commit, ouverture d'une pull request. Du travail propre et utile.

Le résultat ? Environ 10 300 tokens de raisonnement et de génération.

Le contexte total traité ? Environ 1,55 million de tokens.

Laisse ça résonner. Un ratio travail/surcharge de 1:150. L'agent ne pensait pas avec 1,5 million de tokens. Il les trimballait comme des meubles dans un camion de déménagement qu'il ne pouvait pas décharger.

Si tu utilises des agents de code dans ton workflow — pour du développement startup, de l'automatisation DevOps, ou simplement accélérer les revues de code — ce ratio grignote ton budget en silence, gonfle ta latence, et augmente le risque de pourriture contextuelle (quand le modèle commence à perdre le fil parce que la fenêtre de conversation est trop encombrée pour parser proprement).

Alors décomposons où ces tokens vont vraiment.

Anatomie d'une session hypertrophiée

Après avoir passé en revue des données de session sur plusieurs runs d'agents, le schéma devient limpide. L'essentiel de la consommation de tokens ne vient pas du raisonnement du modèle. Elle vient du échafaudage contextuel — l'infrastructure que l'agent a besoin simplement pour fonctionner.

L'explosion du catalogue d'outils. C'est le gros morceau, et ça arrive sournoisement. Plus tu connectes de serveurs MCP (Model Context Protocol), plus de définitions d'outils sont injectées dans la fenêtre contextuelle. Dans une session, neuf serveurs MCP étaient connectés, exposant environ 260 outils. Quand deux d'entre eux se sont attachés en cours de session, un serveur seul listait autour de 180 noms d'outils. Ça arrive une fois par connexion, mais ça ne quitte jamais l'historique. Ça reste là, s'accumule, ajoute du poids à chaque tour suivant.

La taxe du catalogue de skills. Contrairement aux dumps d'outils, qui sont un coût unique, le catalogue de skills est une dépense par tour. Des dizaines de skills, chacun avec des descriptions multi-phrases, chargés à chaque interaction. Ça ne fait pas monter le compteur dramatiquement — ça soulève juste le plancher. Session après session, ça gonfle silencieusement ta base.

Les overheads système et infrastructure. Avant que ton agent ne fasse quoi que ce soit, tu es déjà au-delà de 100k tokens dans beaucoup de configs. Le prompt système, les politiques de sécurité, les schémas d'outils, les instructions de formatage — tout ça se charge à chaque tour. C'est nécessaire, mais c'est pas le travail.

La tâche réelle. Voici la partie inconfortable : le texte du problème, les modifications de fichiers, la sortie des tests, le message de commit — tout ça combiné représente quelques milliers de tokens. La tâche est minuscule à côté de l'atelier.

Pourquoi c'est plus important que tu ne le penses

Tu pourrais être tenté de hausser les épaules. "Les tokens sont pas chers, non ?"

Ils le sont — jusqu'à ce que tu fasses tourner vingt sessions d'agents par jour, chacune gonflée par des facteurs que tu ne savais même pas contrôlables. Les maths se compoundent vite. Et c'est pas juste une question de coût.

Un volume contextuel élevé signifie une latence plus haute. Le modèle doit traiter plus à chaque tour, ralentissant les temps de réponse pile quand t'as besoin de vitesse.

Plus critique encore, la pourriture contextuelle devient un vrai problème. Quand le contexte de travail de ton agent est bourré de définitions d'outils, de descriptions de skills, et d'historique de conversation qu'il n'a pas besoin pour la tâche immédiate, il commence à perdre le ratio signal/bruit. Il peut oublier du contexte pertinent du début de la session, mal interpréter ce que tu demandes, ou prendre des décisions basées sur de l'info obsolète enfouie profondément dans la conversation.

Pour des startups qui bougent vite, c'est pas un petit inconvenient — c'est un problème de fiabilité.

Comment mesurer vraiment ce que tu dépenses

L'instinct c'est de deviner. "Cette session est peut-être grosse parce que la tâche est complexe." D'habitude, c'est pas le cas. D'habitude, c'est l'infrastructure.

Trois approches qui fonctionnent vraiment :

1. Lis le bloc usage sur ta réponse API finale. Chaque réponse de ton modèle porte des stats d'usage : output tokens (ce que le modèle a généré), input tokens (ce que tu as envoyé), et cache_read_input_tokens (ce qui a été lu depuis l'historique). Ce chiffre cache_read c'est ton arme. S'il lit 1,5 million de tokens et que ton output était de 10k, tu as une image claire du ratio d'overhead.

2. Vérifie le statut contexte de ta session en cours de run. La plupart des frameworks d'agents modernes ont une commande comme /context qui montre exactement ce qui occupe ta fenêtre en ce moment, catégorisé. C'est comme ça que tu interceptes les coûts par tour — le catalogue de skills et les schémas — qu'un bloc usage final ne peut pas séparer proprement de la tâche réelle.

3. Audite tes connexions d'outils avant d'en ajouter. Avant de connecter un autre serveur MCP ou d'ajouter une autre capacité à ton agent, demande-toi : ça va me coûter combien par tour ? Une seule définition d'outil, c'est peut-être OK. Cent définitions d'outils à travers des dizaines de serveurs, c'est un tueur de budget silencieux.

Les leviers concrets pour réduire le ratio

Maintenant la partie utile. Si t'as identifié que tes sessions d'agents sont token-lourdes, voici par où commencer à tailler.

Rationalise tes connexions d'outils. Audite chaque serveur MCP et demande-toi s'il porte son poids. Si un serveur expose 50 outils et que ton agent en a utilisé 3, y'a un décalage. Demande-toi si t'as vraiment besoin de tous ces outils connectés tout le temps, ou si tu pourrais les scopés par phase de tâche.

Utilise des contextes focalisés au lieu de globaux. Plutôt que de charger ton catalogue d'outils entier et ta bibliothèque de skills dans chaque session, pense à des configurations spécifiques par tâche. Un agent qui aide sur une revue de code n'a pas besoin du même contexte qu'un agent qui écrit du code d'infrastructure.

Surveille par session, pas juste par mois. Vérifier les coûts agrégés cache les outliers. Regarde les compteurs de tokens par session individuelle et tu commences à voir des patterns — quelles tâches font planter, quelles connexions gonflent, quels skills sont jamais utilisés mais toujours chargés.

Considère des modèles et frameworks pensés pour l'efficacité. Certains frameworks d'agents sont plus token-efficients que d'autres par conception. L'environnement de développement assistée par IA de Vibe Hosting est conçu avec ça en tête — te donnant la puissance des workflows agentiques sans l'overhead caché qui bouffe tes marges.

Le mot de la fin

La prochaine fois que tu lances un agent de code et que tu sens que le ratio intelligence/coût est déséquilibré, t'as probablement raison. Les tokens ne vont pas là où tu crois. La plupart d'entre eux portent l'atelier — les outils, skills, schémas, et échafaudage de conversation — pas le vrai travail.

Mesure d'abord. Le bloc usage et les commandes contextuelles mentent pas. Une fois que tu vois où vont les tokens, tu peux prendre des décisions éclairées sur quoi tailler. Dans la plupart des cas, tu trouveras une marge d'optimisation significative sans sacrifier les capacités.

Ton agent n'a pas besoin de trimballer tout l'atelier. Il a juste besoin des bons outils pour le job. Assure-toi de lui donner exactement ça.