Au-delà des LLM, les « harnais IA » font grimper la facture du développement

Le prix au million de tokens n’est pas un bon indicateur, jugent les spécialistes

Il faut noter un changement récent de tendance. Les fournisseurs de LLM commencent à réduire le volume de tokens consommé pour générer une réponse plus rapidement. C’est-à-dire qu’ils utilisent à l’entraînement des modèles les plus récents des flux de travail débarrassés des boucles inutiles, des échecs ou d’autres comportements coûteux que les précédentes générations de LLM pouvaient présenter. Parmi les modèles qui bénéficient de ces efforts d’efficience, l’on peut citer GPT-5.6 Sol et Claude Opus 4.8.

Oui, ils sont plus chers que la plupart des LLM sur le marché, mais leurs capacités supérieures les rendent maintenant plus économes.

« Sonnet 5 coûte environ 1,7 fois moins cher par token qu’Opus 4.8, mais, pour nos tâches, nous avons constaté que Sonnet coûtait 2,09 dollars par tâche contre 1,94 dollar pour Opus 4.8, tout en affichant un taux de réussite inférieure de 6 points de pourcentage (81 % contre 87 %) », illustre à nouveau Databricks. « Cela s’explique principalement par le fait que Sonnet 5 a fonctionné plus longtemps et a lu davantage de données pour y parvenir, ce qui lui a fait consommer 1,9 fois plus de tokens ».

À noter qu’un modèle open weight comme GLM 5.2, plutôt gourmand en tokens, n’est pas forcément un mauvais choix. Il compense sa gourmandise par la relative faiblesse de son coût et la qualité de ces résultats. Et Databricks d’assurer que, pour le cas d’usage le plus courant de l’IA générative, à savoir le développement, seule une combinaison d’outils et de LLMs permet d’obtenir des résultats pertinents.

Si l’éditeur a mené des benchmarks internes sur des millions de lignes de code, les développeurs commençaient déjà à faire part de cette tendance dans leur ressenti.

Ce n’est pas que la faute des modèles : Claude Code et Codex pointé du doigt pour leur inefficience

Mais une autre tendance apparaît dans les parangonnages : les outils utilisés en combinaison des LLM influencent fortement ce rapport prix-performance.

Dans son benchmark qualitatif Warden consacré aux vulnérabilités dans le code, l’expert de l’observabilité Sentry met indirectement en évidence la différence de comportement entre le SDK de Claude et Pi. Pi est un framework open source sous forme de harnais IA minimaliste développé par la startup Earendil. Lorsque Claude Opus 4.8 high est appairé au SDK d’Anthropic, il trouve 17 des 86 vulnérabilités listées pour un prix total de 80 dollars. Le même modèle intégré au Framework Pi en trouve 24 pour moins de 22 dollars. Un schéma similaire est observable avec Claude Sonnet 4.6 et Opus 4.6 lorsqu’ils sont appairés aux mêmes outils.

GitHub a comparé son propre harnais agentique avec Codex et Claude Code. Résultat, sur les benchmarks académiques, « le harnais GitHub Copilot atteint des taux de complétion de tâches comparables à ceux des harnais proposés par d’autres fournisseurs de LLM, tout en affichant une consommation de tokens inférieure dans la plupart des configurations ». L’outil consommerait au bas mot 30 % de tokens de moins par tâche.

Dans son banc d’essai exploitant des données de production, Databricks confirme que certains CLI/IDE/harnais sont mieux dotés que d’autres.

« Lorsque nous avons exécuté le même modèle avec le même effort de réflexion via deux harnais différents (Claude Code/Codex et Pi), nous avons constaté que le coût par tâche variait considérablement (plus du double dans certains cas), alors que la qualité restait identique », expliquent les ingénieurs de Databricks. « La principale différence tenait à la quantité de contexte que chaque harnais fournissait au modèle à chaque tour ».

À ce jeu, face à Claude Code d’Anthropic et Codex d’OpenAI envoient respectivement deux et trois fois plus de tokens en entrée que Pi. Du même coup, dans les essais de Databricks, le recours à Pi coûte 1,20 à 2,08 fois moins cher à modèle et effort équivalent.

Alors que ces résultats semblent démontrer l’efficience de Pi par rapport aux harnais IA concurrents, Databricks argue que le choix de cet outil et du modèle « n’est qu’une pièce du puzzle ». De fait, les IDE et CLI agentique sont régulièrement mis à jour. Ainsi Pi pourrait être dépassé par un outil existant ou un nouveau venu.

L’émergence des « méta-harnais IA »

C’est l’une des raisons qui a poussé Databricks à proposer Omniagent, un métaharnais open source pour les agents de programmation. Il se veut la couche d’orchestration entre Claude Code, Codex, Cursor, OpenCode, Hermes, Pi et les agents eux-mêmes. Le framework est par ailleurs compatible avec les modèles d’API OpenAI et Anthropic, ainsi que les souscriptions à Claude et ChatGPT. L’éditeur met également à disposition un banc d’essai pour vérifier la pertinence du métaharnais suivant un cas d’usage donné.

Ce travail est en partie inspiré d’une équipe de chercheurs de l’Université de Stanford (là où Matei Zaharia, cofondateur et CTO de Databricks enseigne). Eux définissent un métaharnais comme « système de boucle externe qui recherche dans le code d’encadrement des applications LLM ». « Il utilise un agent qui accède au code source, aux scores et aux traces d’exécution de tous les candidats précédents via un système de fichiers ».

Ce métaharnais permettrait de consommer quatre fois moins de tokens en entrée tout en améliorant les résultats d’une tâche de classification de textes. Databricks n’a pas comparé les résultats d’Omniagent à Pi, Claude Code, Codex et les autres.

S’ils ne construisent pas forcément des « harnais de harnais IA », d’autres acteurs prennent à bas le corps cette gestion des coûts des tokens dans les cycles de développement. Cursor dispose d’un moyen de gérer finement les budgets par projet et par profil. Jetbrains, avec son offre Jetbrains Central, prend cette voie en sus de donner à travers sa souscription un accès aux CLI agentique du marché et un moyen de les orchestrer.