Le 30 août 2026, JetBrains a publié une analyse de la méthodologie d’évaluation des grands modèles de langage utilisés au sein de l’agent de programmation Junie, appelant à dépasser la dépendance à un indicateur unique : le « taux de résolution » (resolve rate). Selon l’entreprise, savoir si l’agent a réussi les tests de la tâche est important, mais cela ne révèle pas à lui seul comment il est parvenu au résultat, combien cela a coûté, ni si le correctif logiciel est limité et maintenable.
L’idée s’appuie sur une comparaison réalisée par JetBrains entre Claude Opus 4.7 et Gemini 3.5 Flash sur son propre benchmark. Les deux modèles ont résolu le même nombre de tâches, mais Opus a nécessité en moyenne 184 étapes, pour un coût d’exécution de 2,79 dollars, contre 271 étapes et 1,24 dollar pour Gemini. Le résultat final identique ne reflétait pas clairement les différences de parcours d’exécution ou d’efficacité dans l’utilisation des outils.
Que dissimule le taux de résolution ?
Junie fonctionne dans le contexte d’une issue et d’un dépôt logiciel, et permet au modèle d’examiner les fichiers, de rechercher des symboles, de modifier le code, ainsi que d’exécuter des commandes et des tests. Ces actions forment un « parcours d’exécution » qui peut être observé sans prétendre révéler le raisonnement interne du modèle. Ce parcours permet de déterminer si l’agent a identifié l’emplacement du problème avant la modification, s’il a répété des recherches, s’il a testé ses hypothèses ou s’il a terminé la tâche sans vérifier le correctif final.
JetBrains propose donc un pipeline réunissant quatre angles d’évaluation : le résultat fonctionnel, l’efficacité de l’exécution, la qualité du correctif et la qualité du processus. Les mesures précises comprennent les résultats des tests, le temps d’exécution, le nombre de jetons ainsi que les appels au modèle et aux outils, le coût, le nombre de fichiers et de symboles modifiés, l’évolution de la complexité, les opérations répétées de lecture de fichiers, la réexécution de commandes dont les résultats n’ont pas changé et les boucles d’échec des outils.
Du résultat au parcours qui y mène
JetBrains a testé la méthodologie sur quatre benchmarks comprenant 523 tâches lors de la comparaison entre Claude Opus 4.7 et Gemini 3.5 Flash. Opus a résolu 267 tâches, soit un taux de 51,1 %, tandis que Gemini en a résolu 254, soit 48,6 %. Le résultat était identique pour 430 tâches : les deux modèles ont réussi 214 tâches et échoué à 216 tâches. La différence effective ne concernait donc que 93 tâches, ce qui rend les différences comportementales plus importantes que l’écart brut dans le classement.
Dans l’exemple d’une tâche réussie par les deux modèles, chacun a commencé par ouvrir un fichier pertinent à l’étape 15, a identifié la cause racine et effectué une vérification complète. Cependant, Opus a utilisé une recherche plus ciblée et commencé l’exécution après 13 étapes. Il a terminé la tâche en 53 étapes, avec six transitions entre exploration, exécution et vérification. Gemini, pour sa part, a examiné plus largement la grande unité, effectué la première vérification exécutable à l’étape 30 et n’a réalisé la première modification du code de production qu’à l’étape 88. Il a ensuite eu besoin de 192 étapes et de 34 transitions entre les phases.
Les deux modèles ont réussi les tests et modifié le même fichier et les mêmes symboles que le correctif de référence. Toutefois, Opus n’a touché aucun autre fichier, tandis que le correctif de Gemini s’est étendu à quatre fichiers supplémentaires. Le processus d’évaluation l’a décrit comme large, avec une répétition notable et quelques hallucinations. JetBrains souligne que cet exemple est illustratif et ne constitue pas un résultat statistique indépendant.
L’échec n’est pas un état unique
L’analyse des 216 tâches auxquelles les deux modèles ont échoué a montré que plus de 85 % des cas comportaient, selon l’évaluation, une identification complète ou partielle de la cause racine. Dans l’un des cas, les deux agents ont compris que le dépassement de la limite de caractères par le texte provoquait l’erreur, mais ils ont proposé de tronquer le texte au lieu de le diviser en parties correctes. Dans un autre cas, ils ont corrigé un paramètre de téléchargement dans un parcours et manqué le même problème dans un parcours associé.
En pratique, ces cas diffèrent de l’échec d’un agent à trouver le composant responsable. La cause peut être une implémentation incomplète, la modification de la mauvaise couche, le non-respect du contrat précis de la tâche ou l’arrêt avant la vérification. Le parcours d’exécution peut donc aider à déterminer où intervenir : améliorer la navigation dans le dépôt, ajuster la formulation de la tâche, renforcer l’achèvement des modifications ou imposer une étape de vérification finale.
Des profils comportementaux plutôt qu’un classement unique
JetBrains a conclu que Claude Opus 4.7 était davantage porté à identifier la cause sous-jacente des défauts ambigus, et qu’il avait résolu 53 tâches auxquelles Gemini avait échoué. Toutefois, 123 de ses exécutions ne comportaient aucune vérification exécutable, dont 68 tâches considérées comme résolues. L’entreprise estime que ce comportement peut laisser non détectés des risques liés aux régressions ou aux cas limites.
À l’inverse, Gemini 3.5 Flash était davantage porté à exécuter une vérification et à utiliser son résultat pour améliorer la solution lorsque le comportement attendu était clair et que le composant responsable était relativement bien défini. Il a cependant montré des problèmes de convergence vers la solution et d’ancrage dans le dépôt : il a répété des recherches ou des commandes équivalentes, consacré de nombreuses étapes à la structure de compilation et davantage dépendu d’interfaces, de dépendances, de parcours ou de configurations de test non documentés. Parmi ses exécutions, 195, soit 37,3 %, ont été classées comme comportant des hallucinations modérées ou importantes, contre 130 pour Opus. De même, 80 de ses exécutions, soit 15,3 %, ont présenté une répétition importante ou sévère, contre 6,5 % pour Opus.
Qu’est-ce que cela signifie en pratique ?
Dans une comparaison plus large incluant GPT-5.5, Claude Opus 4.7, Gemini 3.5 Flash et Qwen 3.6 27B FP8 sur 522 tâches communes, GPT-5.5 a obtenu le taux de résolution le plus élevé, à 51,5 %, et a été le seul modèle à exécuter une vérification exécutable à chaque fois. Opus a dominé les indicateurs de qualité des correctifs, tandis que Qwen 3.6 27B FP8 a résolu 38,9 % des tâches pour un coût d’exécution équivalant à 3 % de celui de GPT-5.5.
Ces chiffres montrent que le choix du modèle dépend de l’emplacement des coûts et des risques. Le modèle le plus performant pour le diagnostic peut être adapté à un dépôt inconnu ou à un défaut ambigu, tandis qu’un modèle plus rigoureux dans la vérification peut être préférable lorsque les tests et les retours sont disponibles. Un modèle peu coûteux peut aussi devenir une option pratique lorsque le coût d’une tentative infructueuse est limité, même avec un taux de résolution inférieur. Cette lecture ne signifie toutefois pas qu’un modèle aura un comportement constant dans tous les environnements.
JetBrains met en garde contre la généralisation des profils comportementaux aux modèles eux-mêmes, car les résultats dépendent de l’architecture spécifique de Junie. En outre, les jugements des évaluateurs fondés sur de grands modèles de langage ne constituent pas une « vérité de référence » et sont fortement influencés par un unique correctif de référence, alors que des solutions correctes peuvent utiliser des fichiers ou des couches architecturales différents. Le taux de résolution reste donc une base nécessaire, mais sa valeur augmente lorsqu’il est accompagné d’éléments sur l’efficacité, la qualité de la modification et le parcours de travail, plutôt que réduit à un classement global unique.