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

Le résultat le plus frappant : GLM 5.2, un modèle open source de Z.ai, se hisse parmi les modèles les plus performants et se retrouve statistiquement à égalité avec Claude Opus 4.8 en qualité sur ce test interne. La différence se joue sur le coût : 1,28 dollar par tâche pour GLM 5.2, contre 1,94 dollar pour Opus 4.8 dans la configuration comparée.

La leçon n’est pas qu’un modèle remplace automatiquement l’autre partout. Elle est ailleurs : dans les tâches d’ingénierie réelles, la frontière de l’efficacité ne tient plus à un seul fournisseur. La frontière de Pareto observée par Databricks mélange des modèles d’OpenAI, d’Anthropic et de l’open source, ce qui annonce des entreprises qui ne choisiront plus un « meilleur modèle » fixe mais arbitreront selon le coût, la complexité et le type de tâche.

Le benchmark que chaque entreprise devrait construire elle-même

Databricks explique que les benchmarks publics comme SWE-bench ou TerminalBench restent utiles mais ne répondent pas à ses propres questions. Les tâches publiques finissent parfois dans les données d’entraînement, et ne reflètent pas la réalité d’une base de code d’entreprise spécifique. La société a donc construit sa propre évaluation à partir de PRs réels, récents et relus, avec des tests de qualité et des modifications limitées à des modules précis.

Un benchmark public mesure une capacité générale. Un benchmark interne mesure si un agent aide vraiment à résoudre les problèmes propres à une société, avec ses frameworks, ses conventions et ses décisions historiques. Databricks a écarté les changements générés par des bots, des comptes de service ou du code entièrement auto-généré, puis a transformé les PRs retenues en tâches en résumant l’intention, en supprimant les indices sur la solution et en séparant les tests. La société a aussi évité un juge basé sur un LLM pour valider les réponses, ce type de méthode ayant tendance à favoriser les réponses convaincantes mais fausses.

Un détail technique compte particulièrement : certaines solutions semblaient trop bonnes parce que l’agent pouvait retrouver l’implémentation correcte dans l’historique Git. Databricks a verrouillé cet historique pendant l’exécution de chaque tâche pour empêcher l’agent de remonter jusqu’aux commits précédents. Beaucoup d’entreprises possèdent déjà, sans le savoir, leur propre benchmark : il dort dans leurs PRs fermées, leurs tests et leurs incidents résolus.

Le modèle compte, l’harness aussi

Dans un agent de code, le modèle raisonne, propose des modifications et écrit le code. L’harness est la couche qui l’entoure : rechercher des fichiers, exécuter des commandes, lire des sorties, gérer le contexte, décider quoi envoyer au modèle à chaque étape. L’industrie compare souvent les modèles comme s’ils fonctionnaient isolément, mais Databricks montre que ça ne suffit pas : avec le même modèle et le même effort de raisonnement, deux harnesses différents ont fait varier le coût par tâche du simple au double, à qualité stable. La cause principale : la quantité de contexte envoyée à chaque étape.

Pi, l’harness interne privilégié dans cette étude, envoyait environ trois fois moins de contexte à chaque étape, ce qui lui permettait selon Databricks de mieux gérer le flux de travail et de terminer les tâches en moins d’exécutions. Cela déplace la discussion sur les coûts : regarder le seul prix par million de tokens ne suffit pas. Un agent qui lit trop, renvoie du contexte inutile ou boucle trop souvent peut coûter plus cher même avec un tarif de modèle inférieur, un problème proche de celui décrit dans notre article sur la facture invisible des agents d’IA.

Le coût par token peut tromper

Databricks donne un exemple parlant : Sonnet 5 coûtait environ 1,7 fois moins cher par token qu’Opus 4.8, mais revenait en réalité plus cher par tâche, 2,09 dollars contre 1,94 dollar, avec un taux de succès inférieur, 81 % contre 87 %. Sonnet 5 consommait environ 1,9 fois plus de tokens pour atteindre la même solution.

La métrique qui compte n’est donc pas le tarif unitaire du token, mais le coût total pour résoudre une tâche valide : tokens d’entrée, de sortie, raisonnement, appels aux outils, réessais et temps d’exécution. Ce détail deviendra central pour les entreprises qui passent de simples copilotes à des agents exploités à grande échelle, une transition déjà en cours si l’on en croit les prévisions de Gartner sur des équipes d’ingénierie plus petites.

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

GLM 5.2 n’apparaît pas dans ce benchmark comme une curiosité bon marché, mais comme une option capable de rivaliser sur des tâches avancées en contexte réel. Z.ai le présente comme un modèle open source sous licence MIT, conçu pour des tâches longues. Cela ne veut pas dire que n’importe quelle équipe peut le télécharger sans coûts opérationnels : les grands modèles ouverts demandent infrastructure, GPU, mémoire, ingénierie d’inférence, sécurité et observabilité. Mais ça change la stratégie possible : une entreprise peut intégrer un modèle ouvert dans son système de routing pour certaines tâches, tout en gardant des alternatives fermées ailleurs.

Databricks dit avancer dans cette direction, avec un routage intelligent via Unity AI Gateway et Omnigent pour aider ses développeurs à choisir l’agent le plus adapté sans sacrifier efficacité ni contrôle.

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

Les benchmarks publics ne sont qu’un point de départ, la décision doit reposer sur ses propres tâches et ses propres métriques. L’agent complet, modèle, harness, outils, permissions, tests et flux de revue, forme un système : comparer uniquement les modèles peut conduire à de mauvaises décisions. Le routage va prendre une place centrale, car toutes les tâches ne nécessitent pas le modèle le plus cher : Databricks a observé qu’environ un quart des tâches analysées était de faible complexité et 60 % de complexité moyenne, alors que les modèles coûteux étaient souvent utilisés par défaut.

Enfin, l’open source ne peut plus être ignoré par principe. Si un modèle ouvert atteint une qualité élevée à moindre coût, il faut l’évaluer ; il ne gagnera pas systématiquement, mais l’écarter d’office deviendra de plus en plus difficile à justifier. L’ingénierie assistée par l’IA entre 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 les tâches réelles, à quel coût et avec quelle supervision.

Questions fréquentes

Que precisement a testé Databricks ?
Des agents de code sur des tâches réelles issues de pull requests internes, sur une base de code de plusieurs millions de lignes, avec des tests propres pour valider les solutions.

Pourquoi GLM 5.2 compte-t-il autant dans ce benchmark ?
Parce qu’il se hisse parmi les modèles les plus performants et se retrouve statistiquement à égalité avec Opus 4.8 en qualité, avec un coût par tâche inférieur.

Qu’est-ce qu’un harness dans un agent de code ?
La couche qui gère outils, contexte, recherche de fichiers, commandes terminal, résultats de tests et interaction entre le modèle et le dépôt.

Pourquoi le coût par token ne suffit-il pas 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 réussie la vraie mesure de performance.

Les entreprises devraient-elles construire leurs propres benchmarks ?
Oui, surtout si elles exploitent des agents à grande échelle. Leurs PRs historiques, tests et incidents résolus offrent une évaluation plus précise que des problèmes génériques.