Le harnais est une ligne de budget

Dans Guidelines vs guardrails, j’écrivais que si le harnais est le produit, une part de ce qu’on paie doit le financer, sans savoir fixer le pourcentage. Je ne le sais toujours pas exactement. Mais j’ai depuis les chiffres qui manquaient à cette phrase, et une règle pratique pour arrêter de la traiter comme une note de bas de page.

En scope global cumulé, RTK, un proxy CLI local qui filtre et compresse ce qui part vers l’agent, affiche 4,4 M de tokens « économisés » sur 9 892 commandes, soit 45,3 %, une des données qui nourrissent ce que j’appelle ailleurs l’ AI ROI . C’est le genre de chiffre qu’on lit comme une réduction de facture, point final. C’est faux, ou en tout cas incomplet.

Pourquoi 45 % n’est pas un gain net ?

Ces tokens économisés n’existent pas dans le vide. Ils sortent d’un outillage qu’il faut construire, puis faire vivre : le hook qui intercepte la commande, la logique de filtrage, les règles qui décident quoi compresser sans casser le résultat. Compter les tokens économisés sans compter le coût de ce qui les économise, c’est publier un chiffre d’affaires sans la ligne des charges.

La preuve tient dans le terminal, relevée le 12 août 2026 :

$ rtk gain
RTK Token Savings (Global Scope)
════════════════════════════════════════════════════
Total commands:    9892
Tokens saved:      4.4M (45.3%)

Le proxy fonctionne, l’économie est réelle : ce relevé est un instantané, pas une promesse. Un harnais qui économise des tokens aujourd’hui n’économise rien tout seul demain : quelqu’un doit le rouvrir, le réinitialiser, vérifier qu’il ne s’est pas mis à filtrer trop ou pas assez depuis le dernier passage.

Capex ou opex, pour un hook ?

Construire les quinze hooks d’un weekend, mettre en place le routing par type de tâche, brancher RTK : ça, c’est du capex, un coût ponctuel, encaissé une fois. Le routing par coût que je documente ailleurs part du même calcul : chiffrer avant de décider.

Le problème est ailleurs. Chaque mise à jour de CLI, chaque nouveau format de sortie du modèle, chaque faux positif qu’un hook déclenche à tort, ça, c’est de l’opex, une charge récurrente. Je l’ai traité pendant des mois comme si c’était encaissé une fois pour toutes en même temps que la construction. Un budget IA qui ne compte que le prix des tokens de génération sous-estime son propre coût réel, parce qu’il oublie la moitié récurrente de la facture.

Ma règle : pas un pourcentage, un budget-temps

Je n’ai pas de pourcentage propre à défendre ; je me méfierais de qui en affiche un sans mesure derrière. Ce que je fais concrètement : je note le temps passé à réparer ou ajuster chaque gate qui produit une économie significative. Si l’entretien d’un hook dépasse, sur un mois, ce qu’il fait gagner en tokens ou en temps de review, il est simplifié ou supprimé, la même logique que le faux positif qu’on désarme par réflexe, appliquée cette fois en euros plutôt qu’en confiance.

Ce budget-temps se revoit à la même cadence que je revois mes coûts de modèle. Traiter l’un sans l’autre, c’est optimiser une moitié de la facture et se féliciter du résultat.

Pour qui ce calcul ne compte pas ?

Si ton setup tient en trois hooks et un script jetable, ignore tout ça : le temps de mesurer coûterait plus cher que ce qu’il y a à économiser. Ce calcul ne devient utile qu’à partir du moment où le harnais a assez de pièces mobiles pour que son entretien soit un poste réel, pas un bruit de fond : une quinzaine de hooks, un routing multi-modèle, un proxy qui a déjà près de 10 000 commandes cumulées à son compteur. En dessous de ce seuil, c’est de l’over-engineering comptable : mesurer pour le plaisir de mesurer.

Ce que ça change concrètement

La prochaine fois qu’un chiffre d’économie de tokens tombe, 45 %, 4,4 M, peu importe, la question à se poser n’est pas « combien j’ai gardé », c’est « combien ça m’a coûté de le garder, et est-ce que je l’ai compté ». Un harnais qui économise sans qu’on budgète son entretien ne dort pas gratuitement : il attend juste le prochain hook outdated pour présenter l’addition.