Un score de benchmark n'est pas un avis sur le modèle

Deux points d’avance dans un benchmark de programmation ne signifient pas que deux modèles travailleront presque de la même manière dans un vrai dépôt. Le score porte sur un jeu de tâches, une configuration d’agent et une règle de notation. Il ne dit pas combien de supervision chaque modèle demande, combien coûtent ses échecs ni si j’accepterais sa pull request.

DeepSWE en donne un bon exemple. Luna Max obtient 67,2 % et Sol High 69,4 %, alors que le coût affiché de Luna est environ six fois inférieur [2]. Ce résumé fait de Luna le choix évident. En pratique, des taux de réussite proches peuvent pourtant masquer de grandes différences dans le temps que je passe à guider le modèle, vérifier ses hypothèses et réparer son travail.

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

Que mesurent vraiment 67 % et 69 % ?

Dans les données DeepSWE v1.1 de Datacurve, Luna Max réussit 301 tentatives sur 448 et Sol High 313 sur 451 [1] [2]. Ces totaux donnent les scores de 67,2 % et 69,4 %. Ils montrent un écart de 2,2 points sur ce test, mais pas que les deux modèles travaillent de la même manière au quotidien.

DeepSWE maintient constantes plusieurs variables importantes. Ses 113 tâches viennent 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. Tous les modèles ont aussi utilisé mini-swe-agent, le même outil bash et le même prompt de base [5], puis un conteneur neuf a vérifié chaque patch pour le comportement requis et les régressions.

Ces contrôles rendent la comparaison utile, mais le résultat garde une part d’incertitude. Datacurve donne à Luna un intervalle à 95 % de 63,2 % à 71,2 %, tandis que celui de Sol va de 68,0 % à 70,8 % [2]. Les 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 tâche par tâche. Les données ne prouvent donc pas que l’avance de 2,2 points de Sol se répétera.

Les deux configurations utilisent aussi des niveaux d’effort différents : max pour Luna et high pour Sol. Le classement change avec le Pass@4 empirique de Datacurve, qui demande 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 et Sol 86,7 % [2]. La réussite par tentative favorise Sol, tandis que la couverture des tâches favorise Luna, car ces deux mesures répondent à des questions différentes.

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)

La comparaison complète me donne une raison de tester les deux modèles, mais pas de les considérer comme équivalents. Toutes les mesures de la figure 1 viennent des tâches et de la configuration d’agent de DeepSWE. Mon dépôt peut favoriser d’autres qualités et révéler d’autres échecs.

Pourquoi deux scores proches peuvent-ils donner des sensations si différentes ?

Deux modèles peuvent réussir le même nombre de tâches tout en demandant des quantités de travail très différentes au développeur. Je regarde si le modèle trouve les bons fichiers, respecte la conception existante, pose une question avant une hypothèse risquée, récupère après l’échec d’une commande et s’arrête une fois la modification demandée terminée. DeepSWE réduit le résultat final à une réussite ou un échec et ne note donc pas ces comportements séparément.

Les données brutes de DeepSWE fournissent 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 atteindre un taux de réussite comparable. Les données ne disent pas si ces étapes supplémentaires étaient utiles, mais elles montrent clairement que les deux modèles n’ont pas travaillé de la même manière.

Le coût affiché demande lui aussi du contexte. Les essais de Luna ont eu lieu le 7 juillet, quand la consommation de tokens enregistrée coûtait environ 3,03 dollars par tentative [2] [3]. OpenAI a baissé le prix des tokens de Luna de 80 % le 30 juillet [4], et DeepSWE a recalculé l’ancienne consommation au nouveau tarif. C’est ainsi que 3,03 dollars sont devenus les 0,61 dollar affichés. Ce chiffre estime correctement le prix actuel de la même consommation, mais pas la somme payée par Datacurve 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 leaderboard ignore les nouvelles tentatives, le temps de relecture, les corrections manuelles, l’attente et tout second modèle appelé pour vérifier ou réparer le premier. Une tentative peut coûter six fois moins cher et revenir malgré tout plus cher au total si l’ingénieur doit surveiller chaque décision.

Ces différences dans le travail sont ce que le « big model smell » tente de décrire. Les questions utiles sont concrètes : le modèle a-t-il gardé toutes les contraintes en tête ? A-t-il pris des décisions adaptées à ce dépôt ? A-t-il évité les changements sans rapport, exprimé clairement son incertitude et échoué d’une manière facile à repérer et à annuler ? Un seul taux de réussite ne peut répondre à aucune de ces questions.

Jusqu’où la configuration peut-elle changer le score ?

Un benchmark de programmation teste un système complet, pas seulement le modèle. Le prompt, les outils, la politique de contexte, les limites d’exécution, le nombre de tentatives et l’évaluateur influencent tous le résultat. En changer un seul peut déplacer le score alors même que le modèle reste exactement identique.

Le paper SWE-agent publié à NeurIPS fournit un exemple contrôlé. 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 % pour l’interface SWE-agent complète [6]. Lorsque les chercheurs ont remplacé les retours de recherche répétés par un outil qui résumait les résultats, le score est passé de 12 % à 18 %. Limiter l’affichage d’un fichier à 100 lignes, au lieu de renvoyer le fichier entier, l’a fait passer de 12,7 % à 18 %. Ces modifications de l’interface ont ajouté cinq à sept points sans changer le modèle.

Le nombre de tentatives fait encore davantage varier 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. Si une tâche comptait comme résolue dès que l’une des six tentatives réussissait, la couverture montait à 32,67 % [6]. Ce gain de 14,73 points a du sens lorsqu’un système en production génère vraiment six candidats et sait choisir le bon. Sans étiquette claire, le placer à côté d’un résultat en une tentative induit en erreur.

L’infrastructure ajoute aussi du bruit. Anthropic a gardé le modèle Claude, le harness et les tâches Terminal-Bench 2.0 identiques, puis a seulement changé les limites de CPU, de mémoire et de durée. La configuration sans limites strictes a obtenu environ six points de plus, tandis que les erreurs d’infrastructure sont tombées de 5,8 % à 0,5 % [7]. Une ligne de leaderboard doit donc se lire comme le résultat d’un système testé, pas comme un numéro définitif attaché au nom du modèle.

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 → sans limites	Non publié	Non publié	environ +6 pts

Les quatre changements de la figure 2 dépassent l’écart de 2,2 points entre Luna et Sol. Cela ne rend pas les benchmarks inutiles, mais leur 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 qui passe les tests peut-il être rejeté ?

Réussir un benchmark signifie qu’un patch a passé les contrôles du benchmark. Cela indique utilement que le code fonctionne, mais ne remplace pas une revue de code. Les contrôles peuvent laisser passer une correction incomplète et ne tiennent pas forcément compte de la maintenabilité, de l’architecture existante, des changements sans rapport ou du travail requis avant la fusion.

EvalPlus a montré à quel point les tests retenus peuvent influencer le résultat. Les chercheurs ont multiplié par environ 80 les 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 que 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]. Puisque l’audit ciblait volontairement des tâches suspectes, ce pourcentage ne décrit 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 capables.

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 sur 95 tâches. Leur taux d’acceptation était inférieur de 24,2 points au score SWE-bench automatisé [10]. Ils 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 se sont inversés

défauts dans un audit ciblé

59,4 %

pas représentatif des 500 tâches

écart avec les 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 que ce modèle modifie ma branche chaque jour.

Que masque une moyenne sur la fiabilité ?

Un taux de réussite moyen combine toutes les réussites et tous les échecs en un seul nombre. Il ne montre pas si le modèle réussit régulièrement, si sa fiabilité s’effondre sur les tâches longues ni si un échec produit un petit mauvais diff ou endommage l’état de travail. Ces différences comptent lorsque j’utilise le modèle plusieurs fois au lieu de le tester une seule fois.

Le paper tau-bench rend la répétabilité visible avec pass^k, qui demande si un 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 à un seul essai, 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. Au quotidien, il paraît imprévisible.

La durée de la tâche produit une séparation similaire. METR a évalué des agents sur 170 tâches, avec environ huit exécutions par paire modèle-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 sur 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 les impressions pratiques peuvent contredire un leaderboard. 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. Les impressions personnelles peuvent aussi être fausses, car une réponse élégante ou un seul échec désastreux peut dominer ma mémoire. Au lieu de choisir entre benchmarks et intuition, je dois mesurer 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 du temps et de l’argent, et une évaluation contrôlée comme DeepSWE apporte beaucoup plus qu’une démo de lancement. Mon choix final vient tout de même d’une petite évaluation bâtie à partir de mon propre travail.

Anthropic recommande de commencer avec 20 à 50 tâches d’agent tirées des contrôles manuels, des échecs courants, des rapports de bugs et des demandes réelles déjà rencontrées en développement [13]. Ce volume suffit à révéler de gros décalages sans prétendre produire un leaderboard universel. Pour départager des résultats proches, je répéterais les mêmes tâches en gardant l’environnement, les outils, les prompts, le niveau d’effort et le budget identiques.

Avant de voir les sorties, je définirais ce qui rend un résultat 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’au résultat accepté, relecture et réparation comprises ;
• les minutes de relecture active, séparées 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 les noms 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 mélanger corrections, 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. Si son coût de revue plus élevé annule l’économie d’API, ce n’est toutefois pas le modèle le moins cher pour mon flux.

Le résultat DeepSWE donne une bonne raison de tester sérieusement Luna Max. Son taux de réussite reste dans l’incertitude autour de Sol High et son prix d’API actuel est bien inférieur. Cela ne rend pas les modèles interchangeables. Pour savoir lequel est moins cher et meilleur pour mon travail, je dois aussi compter le guidage, la relecture, les réparations et les essais ratés que le leaderboard ignore.