Le coût réel d'une flotte d'agents

Sur sept semaines de construction de notre propre produit, une flotte d'agents a tourné 279 fois, cumulé 41,9 heures de travail, et lu 1,16 milliard de tokens en entrée pour en écrire 4 millions. Ce travail s'est matérialisé en 73 pull requests mergées. Une PR mergée a donc coûté environ 3,8 exécutions, 34 minutes de temps agent et 15,8 millions de tokens en entrée.

Le chiffre qui étonne est le ratio : 288 tokens lus pour chaque token écrit. Une flotte d'agents est avant tout une machine à lire. L'essentiel de son coût est dépensé à réétablir le contexte, pas à produire.

Ce qui est mesuré

Chaque invocation de sous-agent sur notre base de code est journalisée par un hook SubagentStop dans un fichier en ajout seul, puis poussée dans une table Postgres en production. Chaque ligne porte l'agent, la durée en temps réel, les tokens en entrée et en sortie, et un horodatage. Rien n'est échantillonné, rien n'est estimé.

La fenêtre couvre le 2026-06-09 au 2026-07-31, l'intégralité de la télémétrie au moment de la rédaction, relevée le 2026-08-03. Les chiffres ci-dessous sont ceux du tableau en bas de page, et le CSV adjacent en est une projection directe : ce que nous affichons et ce que nous fournissons ne peuvent pas diverger.

Le pendant vient du dépôt sur la même fenêtre : 73 pull requests squashées mergées sur la branche principale, 499 fichiers modifiés, 35 558 lignes ajoutées et 2 318 retirées.

| Par pull request mergée | | |---|---| | Exécutions | 3,8 | | Temps agent | 34 minutes | | Tokens en entrée | 15,8 millions | | Tokens en sortie | 55 000 |

| Par exécution | | |---|---| | Durée | 9 minutes | | Tokens en entrée | 4,1 millions | | Tokens en sortie | 14 400 |

53 agents distincts ont tourné sur la fenêtre. La plupart sont des spécialistes ponctuels, instanciés pour une tâche précise, pas un effectif permanent.

Ce que ces chiffres ne disent pas

Ce sont un plancher, pas un total. Le hook se déclenche sur les sous-agents uniquement. La session principale qui les orchestre, lit les fichiers et écrit la majeure partie du code n'est comptée nulle part dans ce jeu de données. Le coût réel en tokens des sept semaines est nettement supérieur à 1,16 milliard, et nous ne pouvons pas vous dire de combien, parce que nous ne le mesurons pas encore.

Ces chiffres ne disent rien sur l'exploitation d'un agent en production. Ceci mesure ce que coûte la construction de logiciel avec une flotte d'agents, sur notre base de code, avec nos conventions. Cela ne répond pas à ce que coûte l'exploitation de l'agent d'un client une fois déployé. Les deux sont constamment confondus, et ils n'ont rien à voir.

La colonne des erreurs est vide, et c'est un trou d'instrumentation, pas un bilan parfait. Le champ existe et est câblé, mais il n'a jamais été vrai sur 246 invocations journalisées. Sept semaines sans le moindre échec de sous-agent n'est pas crédible. Nous publions la colonne brute plutôt que de la supprimer discrètement, et nous n'en tirons aucune affirmation sur la fiabilité.

Les données du dépôt ne sont pas vérifiables pour vous. Les décomptes de pull requests et de lignes proviennent d'un dépôt privé. Ce sont des données de première main que nous assumons, mais vous ne pouvez pas les vérifier comme vous le feriez pour un benchmark public. Les lignes de code en particulier ne mesurent pas grand-chose, et elles ne sont incluses que pour donner une échelle aux chiffres de tokens.

Une fenêtre n'est pas une tendance. C'est la première ligne d'une série. Une seule mesure, sur une seule équipe, sur une seule base de code, dit ce qui s'est passé ici, pas ce qui se passera ailleurs.

Comment le reproduire

Le mécanisme tient en trois éléments, et aucun n'est spécifique à notre contexte. Un hook SubagentStop ajoute une ligne JSON par invocation à un journal local. Un script pousse les nouvelles lignes dans une table, avec une clé qui empêche le double comptage en cas de rejeu. Un second script lit une fenêtre fermée et ajoute une ligne à un fichier de données commité dans le dépôt.

La dernière étape est la décisive. Les chiffres générés au build sont réécrits à chaque déploiement, et « mesuré en août » devient silencieusement « mesuré au dernier déploiement ». Les nôtres sont ajoutés délibérément, revus dans une pull request, et un test échoue si une ligne publiée est modifiée. C'est pourquoi la série ci-dessous peut être citée : elle ne peut pas être altérée après coup sans que la modification soit visible.

Les projets produits par ce travail sont listés dans nos réalisations.