Chaque fichier lu par votre agent reste sur la facture. Un refactoring a coûté 14,29 dollars
By Surya Pratap
2 septembre 2026
11 min de lecture
IA et technologie
2 septembre 2026
11 min de lecture
Le mécanisme et le compteurHover to exploreSonar a publié cette semaine une mesure de coût plus utile que le produit qu'elle vend.
Le titre annonce que la navigation sémantique du code rend les agents de codage moins chers. C'est vrai, et l'effet est modeste et dépend de la tâche. Le chiffre que je noterais est la référence : un seul refactoring préservant le comportement d'une classe Java open source a coûté 14,29 dollars de dépense modèle.
Pas un sprint. Pas une fonctionnalité. Un commit.
La méthodologie mérite d'être créditée avant les résultats, car elle est plus stricte que celle de la plupart des benchmarks d'éditeurs.
Le dispositif de Sonar
Six commits de refactoring issus de vrais projets open source
Cette dernière ligne est ce qui rend le reste digne de lecture. Une comparaison de coûts où le côté le moins cher a le droit d'échouer n'est pas une comparaison de coûts : c'est une mesure de la vitesse à laquelle on peut produire quelque chose de faux. Filtrer sur la compilation et les tests relève de la même discipline que Thinkingbox notant la base de données plutôt que la transcription, et cela reste assez rare pour être signalé.
Voici la phrase qui explique tout le phénomène, dans les mots de Sonar :
Chaque fichier que l'agent lit pour construire cette carte reste résident dans le contexte de la conversation jusqu'à la fin de l'exécution.
C'est le point que la plupart des discussions sur le coût manquent. Ce qui coûte cher, ce n'est pas de lire le fichier. C'est que le fichier, une fois lu, est transporté dans le contexte et refacturé à chaque tour suivant de la boucle.
Lisez huit fichiers au troisième tour d'une exécution de quarante tours et vous n'avez pas payé huit lectures. Vous avez payé huit fichiers × trente-sept tours.
Et si les agents lisent des fichiers entiers, c'est structurel : la recherche textuelle trouve où un symbole apparaît, mais ne peut pas répondre à « où est-ce réellement utilisé » — l'agent ouvre donc des candidats pour le savoir. Ce que Sonar a construit est un graphe interrogeable du code (classes, méthodes, champs, interfaces et leurs relations) qui répond directement à trace-callers ou get-type-hierarchy, de sorte que moins de fichiers entrent dans le contexte.
Pourquoi c'est la même maladie que le catalogue d'outils MCP
Dans l'article sur la feuille de route MCP, le coût était le catalogue d'outils : tous les outils, descriptions et schémas de paramètres chargés en contexte au démarrage de la session, que la tâche en ait besoin ou non, et repayés à la tâche suivante. Ici ce sont des fichiers source. Même maladie, autre porteur : du contenu chargé sans condition puis facturé de façon répétée. Le remède est le même : rendre le chargement conditionnel et laisser l'agent aller chercher à la demande.
Les chiffres absolus sont la partie sur laquelle les fondateurs devraient s'arrêter, car presque personne n'a mesuré les siens.
Les tokens ont suivi l'argent : tokens d'entrée en baisse de 11 à 31 %, tokens de sortie de 4 à 35 %.
Le chiffre marketing attaché à ce travail est « jusqu'à 36 % moins cher ». La fourchette mesurée va d'environ −6 % à −34 %, et les auteurs disent clairement pourquoi :
Le moteur de navigation n'aidera pas sur les tâches où la navigation n'est pas la contrainte.
Ils vont plus loin, notant que les gains sont apparus sur « le même petit changement, préservant le comportement, répété sur chaque implémentation d'une abstraction partagée », et que « le gain est lié au type de travail, il n'est donc pas promis sur chaque tâche ».
C'est d'une honnêteté inhabituelle pour une étude d'éditeur, et cela mérite d'être crédité plutôt que raillé. Sonar vend le remède, donc décotez le cadrage — mais ils ont publié la tâche où leur produit n'a fait que 6 %, nommé la condition dans laquelle il ne sert à rien, et indiqué que leur graphe cède de la précision de résolution de types face à un compilateur en échange de fraîcheur. La plupart des benchmarks d'éditeurs ne font aucune de ces trois choses.
L'économie n'est pas la leçon. La leçon, c'est que le coût par tâche est désormais un chiffre réel et que vous ne connaissez probablement pas le vôtre.
Il y a aussi un lien direct avec le constat McKinsey d'hier, selon lequel 32 % des organisations ont renoncé à un achat de logiciel pour construire avec des agents de codage. Si un seul refactoring coûte dix dollars de dépense modèle, le dossier « on va le construire nous-mêmes » a besoin d'une ligne que la plupart de ces décisions n'avaient pas. Cela ne les rend pas fausses. Cela rend l'arithmétique moins évidente qu'elle n'en a l'air dans une démo.
Six tâches restent six tâches. De vrais refactorings de vrais projets, bien mieux que du synthétique, mais un échantillon de cette taille soutient une direction, pas un taux. L'affirmation honnête est « les refactorings intensifs en navigation ont nettement baissé sur ces six-là », pas « votre facture baisse d'un tiers ».
La référence est une configuration coûteuse. Opus 4.8 en effort élevé avec sous-agents est proche du haut de la courbe de coût par construction : c'est le bon choix pour mesurer un plafond, et cela signifie que ces montants ne sont pas ce que produirait un modèle moins cher sur une base plus petite.
Le coût n'est pas le seul axe. Une configuration qui lit moins de fichiers est moins chère et peut aussi être moins bien informée. Le filtre compilation-et-tests protège de la version la plus grossière de ce risque, mais il ne dit pas si le changement était bon — seulement qu'il compilait et que les tests visés restaient au vert.
Sonar a mesuré ce qu'un agent de codage coûte pour terminer un vrai commit de refactoring, filtré sur la compilation et les tests, et a publié la fourchette : de 1,71 à 14,29 dollars par tâche sur une configuration de pointe en effort élevé. La navigation sémantique a réduit cela de 6 % à 34 % selon que la navigation était ou non la contrainte.
Le mécanisme mérite d'être emporté même si vous n'achetez jamais le produit : un fichier lu par votre agent n'est pas facturé une fois, il est facturé à chaque tour jusqu'à la fin de l'exécution. C'est pourquoi les longues boucles d'agents deviennent chères d'une façon qui semble disproportionnée au travail accompli, et c'est la même forme que le problème du catalogue d'outils MCP.
Allez mesurer cinq de vos propres tâches de bout en bout. Le chiffre intéressant n'est pas la remise que quelqu'un vous vend. C'est la référence que vous n'avez jamais regardée.
Sources : Sonar, « Cut your coding agent's cost with semantic code navigation » · Page produit Sonar Vortex · Documentation du contexte Sonar Vortex · Les coûts par tâche, les variations de tokens, la méthodologie et les réserves citées sont ceux publiés par Sonar, qui vend l'outil mesuré ; la lecture et les précautions de la section 6 sont les miennes.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.