Optimiser les tokens d'un agent IA : que choisir

Fait partie du pilier réduire l'usage des tokens d'un agent de code. Cette page est l'entrée de catégorie : quel type d'outil il vous faut, avant quelle marque.

Quel outil d'optimisation de tokens choisir ?

Celui qui traite la cause que votre facture a réellement. Il y en a quatre, elles demandent des mécanismes différents, et aucun produit ne couvre bien les quatre — la première tâche est donc un diagnostic, pas une comparaison. La plupart des gens abordent cette décision par le mauvais bout : ils lisent un comparatif, prennent l'outil au plus gros pourcentage annoncé, l'installent, et voient la facture à peine bouger. Ce n'est pas que l'outil était mauvais. C'est qu'un outil qui filtre les sorties de commandes ne fait rien pour une facture dominée par les lectures de fichiers entiers, et que son pourcentage a été mesuré sur la partie qu'il touche. Diagnostiquez d'abord. Ça prend vingt minutes et ça décide de tout le reste.

Qu'essayez-vous réellement de corriger ?

L'une de quatre choses, et une semaine de mesure suffit à savoir laquelle.

Cause	À quoi ça ressemble	Ce que c'est
Récupération	L'agent ouvre huit fichiers pour répondre à une question	Lectures de fichiers entiers là où une fraction suffirait
Bruit de sortie	Une suite de tests ou un log de build arrive en entier	Sorties de commandes et d'outils non filtrées
Charge permanente	Le coût par tour reste élevé même sur des tours triviaux	Manifestes d'outils, fichiers de mémoire, prompt système
Historique	Le coût grimpe régulièrement au fil d'une longue session	Chaque tour précédent renvoyé au suivant

Sur du trafic agentique, l'entrée domine la sortie d'environ un ordre de grandeur : les quatre sont donc des problèmes entrants. Ça vous dit déjà quelque chose d'utile — optimiser ce que le modèle écrit est le petit côté de la facture. Pour trouver la vôtre, journalisez l'objet usage par appel, ou servez-vous de ce que votre agent fournit : opencode stats --tools, le /tokens d'Aider, le /usage de Claude Code. Comment mesurer l'usage des tokens d'un agent explique comment le faire correctement.

Quelle classe d'outil règle quelle cause ?

Quatre classes, et elles ne sont pas substituables entre elles. Les index de code (sémantiques ou par graphe d'appels) règlent la récupération. Ils construisent un index de symboles pour que l'agent interroge au lieu de lire. Ils ne font rien pour les sorties de commandes, rien pour l'historique, et ils ajoutent leur propre charge permanente sous forme de manifeste d'outils. Alternatives à tokensave et alternatives à CodeGraph comparent cette classe. Les filtres de sortie règlent le bruit. Ils se placent à la frontière du shell ou de l'outil et replient les sorties verbeuses avant qu'elles n'entrent dans le contexte. Ils ne font rien sur le choix des fichiers lus. Filtrer la sortie des commandes explique le mécanisme. Les compacteurs de contexte règlent l'historique. Ils résument, élaguent ou font expirer les vieux tours. La plupart des agents embarquent désormais une version native : vérifiez ce que vous avez déjà avant d'ajouter quoi que ce soit. Les compteurs ne règlent rien. Ils vous disent laquelle des quatre causes vous avez, ce qui est exactement ce qu'il faut en premier, et exactement pourquoi ils ne sont pas optionnels. Alternatives à ccusage couvre cette classe. La charge permanente est la cause qui a le moins d'outils dédiés, et le point gênant est qu'installer des outils des trois autres classes l'augmente en général.

Comment lire les pourcentages d'économies annoncés ?

Comme une affirmation sur la tranche que l'outil touche, pas sur votre facture — et demandez le dénominateur avant d'appliquer le chiffre à quoi que ce soit. C'est l'habitude la plus utile de cette catégorie, alors voici le schéma en entier. Un outil intercepte, disons, 12 % de votre trafic. Sur cette tranche il économise 80 %. Le titre annonce 80 %. Chaque proposition est vraie. L'effet sur votre facture est inférieur à 10 %, et le lecteur qui a fait le calcul de tête s'est trompé d'un ordre de grandeur. Personne ne ment. La mesure est réelle, et c'est la généralisation qui casse. Trois questions à poser à tout chiffre publié, y compris les nôtres :

Qu'a-t-on mesuré ? De la récupération face à des lectures de fichiers entiers, ce n'est pas un coût de session face à un témoin.
Sur quel dépôt ? Un auto-benchmark sur le code de l'éditeur avec un jeu de requêtes qu'il a choisi n'est pas la même affirmation qu'une mesure indépendante.
Contre quoi ? Une comparaison à un pire cas hypothétique, c'est de l'arithmétique. Une comparaison au même agent faisant la même tâche sans l'outil, c'est une expérience.

Les outils qui fournissent une commande pour rejouer leur benchmark sur votre propre dépôt méritent d'être salués pour ça — c'est un point sur la reproductibilité, pas sur la taille du nombre.

À quoi ressemble une preuve mesurée ?

Un bras de contrôle, des sessions réelles, et une méthode publiée que vous pouvez vérifier. Je maintiens un benchmark ouvert d'optimiseurs de tokens sur des sessions d'agent longues, comparées à l'absence totale d'outil. Il est public, y compris les tours qui font paraître mon propre produit ordinaire, et le résultat à connaître avant d'acheter quoi que ce soit dans cette catégorie est celui-ci : sur les douze outils testés, la plupart n'affichent aucune économie de coût de session mesurable. Plusieurs sont indiscernables de l'absence d'outil ; l'un termine plus cher que le témoin. Ce n'est pas un argument contre la catégorie. C'est un argument pour demander ce qu'un pourcentage couvrait, parce que les outils qui publient les plus grands nombres et ceux qui font bouger une facture de session ne sont pas le même ensemble. Divulgation, clairement : je maintiens ce benchmark et je vends l'un des outils qui y figurent. C'est précisément pourquoi la méthode et les résultats bruts sont publiés plutôt que résumés.

Comment choisir dès aujourd'hui

Mesurez une semaine avant d'acheter. Vous cherchez laquelle des quatre causes domine, pas un total.
Associez la classe à la cause. Un index pour la récupération, un filtre pour le bruit de sortie, un compacteur pour l'historique. Acheter en travers des catégories, c'est comme ça qu'on se retrouve avec trois outils et une facture inchangée.
Comptez la charge permanente ajoutée. Un manifeste d'outils est facturé à chaque tour, y compris ceux qui n'utilisent jamais l'outil.
Demandez le dénominateur de chaque pourcentage qu'on vous montre, les nôtres compris.
Re-mesurez après. Si vous ne voyez pas le changement dans l'instrument de l'étape un, l'outil n'a pas fait ce pour quoi vous l'avez acheté.

Ce qui cloche en pratique (anti-patterns)

Acheter le plus gros pourcentage. C'est en général la mesure la plus étroite. Le chiffre n'est pas faux ; le périmètre n'est pas celui que vous avez supposé. Installer plusieurs catégories d'un coup. Trois outils installés ensemble, c'est un changement qu'on ne peut attribuer à aucun, et l'un des trois ajoute probablement plus de charge permanente qu'il n'en retire. Sauter le compteur parce qu'il n'économise rien. C'est la seule classe qui vous dit de laquelle des trois autres vous avez besoin. Acheter sans lui, c'est deviner avec une carte bancaire. Supposer que votre agent n'a rien de tout ça nativement. La plupart embarquent désormais une compaction de contexte, certains des limites de sortie. Vérifiez avant de payer un deuxième exemplaire. Prendre un abonnement pour une raison de ne pas s'en soucier. Un forfait absorbe le coût en argent et vous le facture en limites de débit. Vous touchez le plafond plus tôt, simplement sans voir de ligne.

À lire aussi :

Réduire l'usage des tokens d'un agent de code — le pilier
Meilleurs optimiseurs de tokens pour Claude Code — le comparatif classé, une fois la classe identifiée
Comment mesurer l'usage des tokens d'un agent — faire l'étape un correctement