Des scores IA proches cachent des modèles très différents

Deux scores de benchmark IA proches peuvent cacher des modèles qui travaillent très différemment dans un vrai dépôt. DeepSWE place Luna Max à 2,2 points de Sol High, mais Luna effectue presque trois fois plus d’étapes. Un taux de réussite ne suffit pas à prévoir la supervision nécessaire ni à savoir si j’accepterais la pull request.

Que mesure un score de benchmark de 67 % contre 69 % ?

Il mesure la réussite par tentative dans une configuration précise de DeepSWE. Sol High atteint 69,4 %, contre 67,2 % pour Luna Max, mais cet écart reste inférieur à l’incertitude publiée entre les exécutions [2]. Le résultat justifie de tester les deux modèles, pas de choisir entre eux pour mon travail.

Mesure	Luna Max	Sol High
Réussite par tentative, %	67,2	69,4
Intervalle à 95 % entre exécutions	63,2–71,2 %	68,0–70,8 %
Tentatives notées	448	451
Tâches avec ≥1 réussite, %	90,3 (Meilleure valeur de la ligne)	86,7
Coût moyen par tentative, $	0,61 (Meilleure valeur de la ligne)	3,47
Tokens de sortie par tentative, milliers	73,4	28,5 (Meilleure valeur de la ligne)
Étapes d’agent par tentative	101,7	36,9 (Meilleure valeur de la ligne)

Les données DeepSWE v1.1 de Datacurve comptent 301 tentatives réussies sur 448 pour Luna Max et 313 sur 451 pour Sol High [1] [2]. Ce sont ces totaux qui produisent les scores présentés dans la figure 1.

DeepSWE maintient plusieurs variables importantes constantes. Ses 113 tâches proviennent de 91 dépôts open source et couvrent TypeScript, Go, Python, JavaScript et Rust [1]. Elles ont été écrites pour cette évaluation au lieu d’être reprises dans d’anciennes issues GitHub. Chaque modèle a aussi utilisé mini-swe-agent avec le même outil bash et le même prompt de base [5]. Un conteneur neuf a ensuite vérifié chaque patch pour le comportement attendu et les régressions.

Ces contrôles rendent la comparaison utile, mais le résultat reste incertain. Datacurve donne à Luna un intervalle à 95 % compris entre 63,2 % et 71,2 %, contre 68,0 % à 70,8 % pour Sol [2]. Ces intervalles se chevauchent, donc l’écart de 2,2 points est inférieur à la variation observée entre les exécutions. Datacurve ne publie pas de comparaison statistique des deux modèles sur les mêmes tâches. Les données ne permettent donc pas d’affirmer que l’avance de Sol se reproduira.

Les deux configurations n’utilisent pas non plus le même niveau d’effort : max pour Luna et high pour Sol. Le classement s’inverse avec le Pass@4 empirique de Datacurve, qui indique si au moins l’une des tentatives enregistrées a résolu chaque tâche. Selon cette mesure, Luna couvre 90,3 % des 113 tâches, contre 86,7 % pour Sol [2]. Sol mène sur la réussite par tentative, tandis que Luna mène sur la couverture des tâches, car ces mesures répondent à deux questions différentes.

Toutes les mesures de la figure 1 appartiennent aux tâches et à la configuration d’agent de DeepSWE. Mon dépôt peut favoriser d’autres qualités et révéler d’autres échecs. La manière dont chaque modèle atteint son résultat devient donc la question suivante.

Des scores proches peuvent cacher presque trois fois plus d’étapes

Un taux de réussite ignore le chemin suivi pour produire le patch. Deux scores proches peuvent donc demander des quantités de travail très différentes. Je regarde si le modèle trouve les bons fichiers, respecte la conception existante, demande confirmation avant une hypothèse risquée et s’arrête à temps. DeepSWE ne note pas ces comportements séparément.

Les données brutes de DeepSWE donnent tout de même un indice. Luna Max a utilisé en moyenne 101,7 étapes d’agent et 73 400 tokens de sortie par tentative, contre 36,9 étapes et 28 450 tokens pour Sol High [2]. Luna a donc effectué environ 2,8 fois plus d’étapes et produit 2,6 fois plus de tokens pour un taux de réussite proche. Les deux modèles n’ont pas travaillé de la même façon.

Le coût affiché demande lui aussi du contexte. Les essais de Luna ont eu lieu le 7 juillet 2026, lorsque les tokens consommés revenaient à environ 3,03 dollars par tentative [2] [3]. OpenAI a baissé le prix des tokens de Luna de 80 % le 30 juillet 2026 [4], puis DeepSWE a recalculé l’ancienne consommation au nouveau tarif. C’est ainsi que 3,03 dollars sont devenus le montant affiché de 0,61 dollar. Ce chiffre estime correctement ce que la même consommation coûte aujourd’hui, mais pas ce que Datacurve a payé lors du test.

Le coût d’API par tentative diffère aussi du coût nécessaire pour obtenir une modification acceptée. Le prix du classement ne compte ni les nouvelles tentatives, ni la relecture, ni les corrections manuelles, ni l’attente, ni un second modèle chargé de vérifier ou réparer le travail du premier. Une tentative peut coûter six fois moins cher tout en revenant plus cher au total si un développeur doit surveiller chaque décision.

Les développeurs appellent parfois ces différences le « big model smell » : l’impression qu’un modèle plus puissant comprend le travail avec moins d’explications et prend moins de décisions à annuler ensuite. L’expression est informelle, mais l’expérience qu’elle décrit se mesure. Je peux compter combien de fois je dois réorienter le modèle, réparer son travail ou rejeter un patch qui avait passé les tests.

Cette impression devient alors une série de questions concrètes. Le modèle a-t-il gardé toutes les contraintes en tête, pris des décisions adaptées au dépôt et évité les changements sans rapport ? Lorsqu’il a échoué, le problème était-il facile à repérer et à annuler ? Un seul taux de réussite ne répond à aucune de ces questions.

Dans quelle mesure la configuration change-t-elle le score ?

Dans les exemples publiés ci-dessous, la configuration du benchmark a déplacé les scores d’environ 5 à 15 points sans changer le modèle [6] [7]. C’est plus que l’écart de 2,2 points entre Luna et Sol. Un benchmark de programmation mesure donc tout le système testé, pas seulement le modèle.

L’article SWE-agent publié à NeurIPS fournit un exemple clair. Avec le même GPT-4 Turbo sur SWE-bench Lite, une interface limitée au shell a résolu 11 % des tâches, contre 18 % avec l’interface SWE-agent complète [6]. Lorsque les chercheurs ont remplacé les résultats de recherche répétés par un outil qui les résumait, le score est passé de 12 % à 18 %. Limiter l’affichage des fichiers à 100 lignes, plutôt que de renvoyer le fichier entier, l’a fait passer de 12,7 % à 18 %. Ces changements d’interface ont ajouté cinq à sept points sans modifier le modèle.

Le nombre de tentatives déplace encore davantage le chiffre mis en avant. Six exécutions de la même combinaison GPT-4 et SWE-agent ont atteint 17,94 % en moyenne à la première tentative. Compter une tâche comme résolue dès que l’une des six tentatives réussissait a fait monter la couverture à 32,67 % [6]. Cette hausse de 14,73 points est utile si un système en production génère réellement six candidats et sait reconnaître le bon. Elle induit en erreur lorsqu’elle apparaît à côté d’un résultat en une tentative sans étiquette claire.

L’infrastructure peut aussi ajouter du bruit. Anthropic a gardé le modèle Claude, le harness et les tâches de Terminal-Bench 2.0 constants, puis a seulement modifié les limites de CPU, de mémoire et de durée. La configuration sans plafond strict a obtenu environ six points de plus, tandis que les erreurs d’infrastructure sont passées de 5,8 % à 0,5 % [7]. Une ligne de classement doit donc être lue comme le résultat d’un système testé, pas comme une valeur permanente attachée au nom du modèle.

Les quatre changements de configuration ci-dessous ont tous déplacé les scores de plus que l’écart entre Luna et Sol.

Modification du système	Avant	Après	Écart
Shell seul → interface SWE-agent	11,0 %	18,0 %	+7,0 pts
Fichier entier → affichage de 100 lignes	12,7 %	18,0 %	+5,3 pts
Une → six tentatives	17,94 %	32,67 %	+14,73 pts
Limites strictes → exécution sans plafond	Non publié	Non publié	environ +6 pts

Ces résultats ne rendent pas les benchmarks inutiles. Ils montrent que la configuration fait partie du résultat. Avant de comparer deux scores, je vérifie donc la version des tâches, la configuration de l’agent, les ressources, le nombre de tentatives et la règle de notation.

Pourquoi un patch validé peut-il échouer à la revue de code ?

Réussir un benchmark signifie que le patch a passé les contrôles prévus par ce benchmark. C’est un indice utile sur le fonctionnement du code, pas l’équivalent d’une revue de code. Les contrôles peuvent manquer une correction incomplète ou ignorer la maintenabilité, l’architecture existante, les changements sans rapport et le travail nécessaire avant la fusion.

L’article EvalPlus publié à NeurIPS a montré à quel point le choix des tests peut modifier le résultat. Les chercheurs ont multiplié par environ 80 la taille des suites de tests de HumanEval et évalué 26 modèles. Avec ces tests plus exigeants, les taux de réussite des modèles les plus touchés ont perdu entre 19,3 et 28,9 points, et certains classements se sont inversés [8]. Les réponses n’avaient pas changé. Les suites plus grandes ont simplement détecté davantage d’erreurs.

Les benchmarks sur dépôt ont le même problème. En février 2026, OpenAI a audité 138 tâches de SWE-bench Verified qu’o3 ratait de façon irrégulière sur 64 exécutions. L’équipe a trouvé des défauts importants dans 59,4 % de ce groupe ciblé, notamment des tests qui rejetaient des solutions valides et d’autres qui exigeaient un comportement absent de l’issue [9]. L’audit visait volontairement des tâches suspectes, donc ces 59,4 % ne décrivent pas l’ensemble des 500 tâches. Il montre néanmoins que des erreurs dans les tâches et les tests peuvent fausser les écarts entre des modèles très performants.

L’erreur inverse compte tout autant : un patch peut passer les tests automatisés sans être acceptable. METR a demandé à des mainteneurs d’examiner 296 pull requests générées par IA dans trois dépôts et pour 95 tâches. Leur taux d’acceptation était inférieur de 24,2 points au score automatisé de SWE-bench [10]. Les mainteneurs ont rejeté des patches pour des défauts de fonctionnalité centrale, des dégâts sans rapport, une mauvaise qualité du code et d’autres problèmes d’intégration. Un score binaire cache toutes ces raisons derrière la même étiquette de réussite ou d’échec.

plus de tests dans EvalPlus

80×

certains classements inversés

défauts dans un audit ciblé

59,4 %

pas représentatif des 500 tâches

écart entre automatisation et mainteneurs

24,2 pts

METR a revu 296 pull requests

Ensemble, ces résultats montrent que la qualité des tests et la revue humaine répondent à des questions différentes. « Le patch a réussi » reste une information utile, mais elle ne me dit pas si je veux laisser ce modèle modifier ma branche chaque jour.

Que masque une moyenne ? La répétabilité et les tâches longues

Un taux de réussite moyen rassemble toutes les réussites et tous les échecs dans un seul nombre. Il ne montre ni la régularité du modèle, ni la baisse de sa fiabilité sur les tâches longues, ni la gravité de ses échecs. Ces différences comptent lorsque j’utilise le modèle tous les jours au lieu de le tester une seule fois.

L’article tau-bench publié sur arXiv montre le problème de répétabilité avec pass^k, une mesure qui demande si l’agent réussit la même tâche à chaque essai. GPT-4o a obtenu 61,2 % sur les tâches de vente au détail dans une vue à une seule tentative, mais son pass^8 est tombé sous 25 % [11]. Un modèle qui fonctionne trois fois et échoue à la quatrième peut conserver une moyenne respectable. Comme collaborateur quotidien, il paraît imprévisible.

La durée des tâches crée une séparation comparable. METR a évalué des agents sur 170 tâches, avec environ huit exécutions par paire de modèle et de tâche. La durée à laquelle un modèle réussissait dans 80 % des cas était quatre à six fois plus courte que son horizon de réussite à 50 % [12]. Un modèle peut donc obtenir du crédit pour d’impressionnantes tâches de deux heures au seuil de 50 %, tout en ne restant fiable que sur du travail bien plus court.

Cela explique pourquoi mon expérience peut contredire un classement. L’usage quotidien comprend des tâches répétées, du contexte de dépôt facile à manquer, des commandes cassées, des exigences ambiguës, des cycles de revue et les conséquences des pires échecs. Mon impression peut elle aussi être fausse si une réponse élégante ou un seul échec désastreux domine ma mémoire. Je ne choisis donc pas entre benchmark et intuition. Je mesure les parties de mon flux de travail qui ont créé cette impression.

Comment comparer les modèles pour mon propre travail ?

J’utilise les benchmarks publics comme filtre. Ils m’indiquent quels modèles méritent mon temps et mon argent, et une évaluation contrôlée comme DeepSWE apporte bien plus qu’une démonstration de lancement. Mon choix final vient tout de même d’une petite évaluation construite à partir de mon propre travail.

Anthropic recommande de commencer l’évaluation d’un agent avec 20 à 50 tâches tirées des contrôles manuels, des échecs courants, des rapports de bugs et des demandes déjà rencontrées en développement [13]. Ce volume suffit à révéler de grands écarts sans prétendre produire un classement universel. Pour une comparaison serrée, je répéterais les mêmes tâches en gardant l’environnement, les outils, les prompts, le niveau d’effort et le budget constants.

Avant d’examiner les résultats, je définirais ce qui rend un patch acceptable. Les tests viennent en premier, mais ils ne constituent pas toute la grille. Je noterais aussi :

• l’acceptation dès la première tentative ;
• le temps total jusqu’à un résultat accepté, relecture et réparation comprises ;
• les minutes de relecture active, distinctes de la latence du modèle ;
• les demandes de précision, réorientations, redémarrages et corrections manuelles ;
• les fichiers modifiés inutilement et les écarts aux conventions du dépôt ;
• les échecs graves, comme une régression de sécurité, un risque de perte de données ou des dégâts sans rapport ;
• les tokens et le coût d’API du résultat complet et accepté.

Pour juger le code, je masquerais le nom des modèles et examinerais les patches concurrents dans un ordre aléatoire lorsque c’est possible. Je publierais les résultats par type de tâche au lieu de regrouper corrections de bugs, revues, refactorings et longues fonctionnalités dans un seul total. Si deux modèles restent proches après plusieurs essais, je choisirais le moins cher. Mais si le surcroît de relecture annule l’économie d’API, ce n’est pas le modèle le moins cher pour mon flux de travail.

DeepSWE m’a donné assez de raisons pour ajouter Luna Max à ma liste de modèles à tester. Ma prochaine comparaison gardera les tâches et les outils constants, puis comptera tout le chemin jusqu’à un patch accepté : réorientation, relecture, réparation et essais ratés. Si le prix d’API inférieur de Luna résiste à ces coûts, il sera moins cher pour mon travail. Sinon, le prix du classement n’est pas celui que je paie.