Databricks a publié l’un des benchmarks les plus intéressants du moment pour les agents de programmation, non pas parce qu’il utilise une batterie publique d’exercices, mais parce qu’il s’appuie sur son propre code. La société a évalué des modèles et des harnesses d’agents sur des tâches réelles extraites de pull requests internes, impliquant des modifications sur une base de code de plusieurs millions de lignes et utilisant plusieurs langages, notamment Python, Go, TypeScript, Scala, Rust et Java.

Le résultat le plus frappant est que GLM 5.2, un modèle open source de Z.ai, figure parmi les modèles aux capacités élevées et est statistiquement à égalité avec Claude Opus 4.8 en termes de qualité lors de ce test interne réalisé par Databricks. La différence réside dans le coût : GLM 5.2 consiste en 1,28 dollar par tâche, contre 1,94 dollars par tâche pour Opus 4.8 dans la configuration comparée.

La conclusion n’est pas que l’un remplace automatiquement l’autre dans tous les scénarios. La véritable lecture est différente : dans les tâches d’ingénierie réelles, la frontière de l’efficacité ne revient plus à un seul fournisseur. Selon Databricks, la frontière de Pareto de leurs tests inclut des modèles d’OpenAI, d’Anthropic et open source, ce qui indique un avenir où les entreprises ne choisiront pas de façon fixe “le meilleur modèle” mais opteront pour différentes voies en fonction du coût, de la complexité et du type de tâche.

Le benchmark que les entreprises devraient construire elles-mêmes

Databricks explique que les benchmarks publics comme SWE-bench ou TerminalBench sont utiles, mais ne répondent pas à ses interrogations internes. La raison est simple : les tâches publiques peuvent, avec le temps, se retrouver dans les données d’entraînement, et ne reflètent pas nécessairement la réalité d’une base de code d’entreprise spécifique. C’est pourquoi la société a construit sa propre évaluation à partir de PRs réels, récents et revus, comprenant des tests de qualité et des modifications limitées à des modules précis.

Cette approche fait toute la différence. Un benchmark public mesure une capacité générale. Un benchmark interne évalue si un agent aide à résoudre des problèmes concrets propres à une société, avec ses modèles, ses frameworks, ses conventions, ses systèmes de build et ses décisions historiques.

Databricks a filtré les changements générés par des bots, des comptes de service, du code entièrement auto-généré par IA ou des commits automatisés. Ensuite, ils ont transformé les PRs sélectionnées en tâches : en résumant l’intention, en supprimant les indices sur la solution, en séparant les tests, et en évaluant la capacité de l’agent à produire une implémentation correcte. La société a également évité d’utiliser un juge basé sur un LLM pour valider la réponse, considérant que cette méthode pouvait favoriser les réponses convaincantes mais incorrectes.

Un autre point technique important concerne la gestion des fuites internes. Lors de leurs premiers expérimentations, Databricks a constaté que certaines solutions semblaient “trop bonnes” parce que l’agent pouvait récupérer l’implémentation correcte depuis l’historique Git. Pour neutraliser cela, ils ont verrouillé l’historique pendant l’exécution de chaque tâche, empêchant l’agent de remonter jusqu’aux commits précédents pour trouver la réponse.

Ce procédé rend l’expérience très pertinente pour toute équipe d’ingénierie : beaucoup d’entreprises possèdent déjà leur propre benchmark, sans en avoir conscience. Il se trouve dans leurs PRs fermés, leurs tests, leurs incidents résolus ou encore leurs changements révisés par des humains.

L’importance du modèle, mais aussi de l’harness

L’élément technique central de l’étude est la distinction entre le modèle et l’harness. Dans un agent de code, le modèle raisonne, propose des modifications et écrit du code. L’harness est la couche qui lui permet de fonctionner : rechercher des fichiers, exécuter des commandes, lire des sorties, gérer le contexte, décider des informations à envoyer à chaque étape, et garder la tâche sous contrôle.

L’industrie tend à comparer des modèles comme s’ils fonctionnaient isolément. Databricks montre que cela est insuffisant. Lors de leurs tests, en exécutant le même modèle avec le même effort de raisonnement via deux harnesses différents, le coût par tâche variait de plus de 2 fois dans certains cas, alors que la qualité restait stable. La cause principale tenait à la quantité de contexte que chaque harness envoyait au modèle à chaque étape.

Pi, l’harness interne privilégié dans cette étude, envoyait environ trois fois moins de contexte à chaque étape. Selon Databricks, cela lui permettait de mieux gérer le flux de travail, de maintenir une fenêtre plus resserrée, et de finaliser les tâches en moins d’exécutions.

Ce chiffre modifie la discussion autour des coûts. Il ne suffit pas de regarder le prix par million de tokens. Si un agent lit trop, renvoie du contexte inutile, boucle trop souvent ou ne maintient pas le focus, il peut revenir plus cher, même si le tarif du modèle est inférieur.

Le coût par token peut être trompeur

Databricks donne un exemple illustratif : Sonnet 5 coûtait environ 1,7 fois moins cher par token que Opus 4.8, mais pour ses tâches, il revenait en réalité plus cher par tâche — 2,09 dollars contre 1,94 dollars — avec un taux de succès inférieur : 81 % contre 87 %. La raison ? Sonnet 5 consommait environ 1,9 fois plus de tokens pour arriver à une même solution.

Ainsi, la métrique essentielle n’est pas le tarif unitaire du token, mais le coût total pour résoudre une tâche valide. Dans le cas des agents de code, cela englobe les tokens d’entrée, de sortie, le raisonnement, les appels à des outils, les réessais, le temps d’exécution, la lecture de contexte et les éventuelles erreurs.

Ce détail deviendra de plus en plus crucial dans les entreprises qui passeront de tests de copilotes à l’exploitation à grande échelle d’agents. Une réduction apparente des coûts tarifaires peut disparaître si le modèle doit faire beaucoup plus de tours ou si l’harness lui fournit trop d’informations inutiles.

GLM 5.2 et le nouveau rôle de l’open source

GLM 5.2 ne se contente pas d’apparaître dans ce benchmark comme une curiosité peu coûteuse, mais comme une option capable de rivaliser dans des tâches avancées en contexte réel. Z.ai présente GLM 5.2 comme un modèle open source sous licence MIT, conçu pour des tâches à long terme, renforçant ainsi son attrait pour les entreprises souhaitant évaluer des modèles ouverts aux côtés d’alternatives fermées.

Cela ne signifie pas que toutes les équipes peuvent le télécharger et l’utiliser sans coûts opérationnels. Les grands modèles open source nécessitent une infrastructure, des GPU, de la mémoire, une ingénierie d’inférence, de la sécurité, de l’observabilité et une opération. Mais cela modifie la stratégie : une entreprise peut intégrer ces modèles ouverts dans son système de routing, s’en servir pour certaines tâches, tout en conservant d’autres alternatives fermées, et mesurer ses performances avec ses propres indicateurs.

Son analyse stratégique est limpide. Le recours exclusif à un seul fournisseur devient de moins en moins pertinent quand la qualité, le coût et l’efficacité varient selon la tâche, le modèle et l’harness. Une architecture IA mature pour le développement doit permettre d’expérimenter, de router et de remplacer des modèles sans tout repenser.

Databricks annonce d’ailleurs œuvrer dans cette direction, en évoquant l’utilisation de capacités de routage intelligent via Unity AI Gateway et Omnigent pour aider ses développeurs à choisir les agents les plus adaptés, tout en maintenant efficacité et contrôle.

Ce que les équipes d’ingénierie devraient retenir

L’étude de Databricks livre plusieurs leçons pratiques. La première est que les benchmarks publics ne sont qu’un point de départ. Ils servent à explorer le marché, mais la décision doit rester basée sur ses propres tâches, ses propres tests et ses propres métriques.

La deuxième est que l’agent complet constitue l’unité d’évaluation. Modèle, harness, outils, permissions, contexte, tests et flux de révision forment un système. Comparer uniquement les modèles peut conduire à de mauvaises décisions.

La troisième est que le routage occupera une place centrale. Toutes les tâches ne nécessitent pas le modèle le plus coûteux. Databricks a observé qu’environ un quart des tâches analysées étaient de faible complexité et que 60 % l’étaient de moyenne complexité, même si les modèles coûteux étaient souvent utilisés par défaut.

La quatrième est que l’open source ne peut plus être ignoré. Si un modèle ouvert peut atteindre une haute qualité à moindre coût par tâche, il faut l’évaluer. Il ne gagnera pas nécessairement toujours, mais l’ignorer systématiquement deviendra de plus en plus difficile à justifier.

L’ingénierie assistée par l’IA entre ainsi dans une phase plus mature. Il ne suffit plus de demander quel modèle écrit le mieux du code en démo. Il faut mesurer quel agent résout efficacement les tâches réelles, à quel coût, avec quelle supervision, quels risques et comment il s’intègre dans l’architecture de développement de la société.

L’avenir des agents de code ne sera pas uniquement dicté par le modèle le plus puissant. Ce sera celui qui saura combiner modèles, harnesses, tests et routage avec ses propres données. Databricks montre là une méthode solide pour débuter.

Questions fréquentes

Que précisèment a testé Databricks ?
Il a évalué des agents de code sur des tâches réelles issues de pull requests internes, en utilisant un code de plusieurs millions de lignes avec des tests propres pour valider l’efficacité des solutions.

Pourquoi GLM 5.2 est-il si important dans ce benchmark ?
Parce qu’il se situe dans le groupe de capacité élevé et est statistiquement à égalité avec Opus 4.8 en qualité, tout en affichant un coût par tâche inférieur dans l’évaluation de Databricks.

Qu’est-ce qu’un harness dans un agent de code ?
C’est la couche qui gère outils, contexte, recherche de fichiers, commandes terminal, résultats de tests et interaction entre le modèle et le référentiel.

Pourquoi le coût par token n’est pas une métrique suffisante pour comparer des modèles ?
Parce qu’un modèle moins cher par token peut consommer bien plus de tokens ou demander plus de tours, rendant le coût total par tâche effectué la véritable mesure de performance.

Les entreprises devraient-elles créer leurs propres benchmarks ?
Oui, surtout si elles exploitent des agents à grande échelle. Les PRs historiques, tests et changements réels offrent une évaluation précise de la performance sur des tâches propres à leur ingénierie, plutôt que sur des problématiques génériques.