Évaluer un agent de code : SWE-bench et au-delà

Leçon réécrite le 2 novembre 2026. La version précédente donnait des paliers de score SWE-bench et un tableau de concurrents sans source ; ils ont été retirés. Les chiffres de Devstral sont ceux de l’annonce officielle de Mistral (9 décembre 2025), les formats de SWE-bench ceux du site du benchmark. Devstral est retiré de l’API depuis le 31 juillet 2026 : ses scores servent ici d’exemple de lecture. Sources : Devstral 2 et Mistral Vibe CLI (Mistral) · SWE-bench.

Mesurer un agent, pas une fonction

Comment évaluer objectivement un modèle conçu pour résoudre des problèmes de développement ? Les benchmarks classiques de génération de code, comme HumanEval ou MBPP, vérifient qu’un modèle sait écrire une fonction isolée à partir d’un énoncé. Ils ne disent pas s’il sait s’orienter dans un dépôt de plusieurs centaines de milliers de lignes et y corriger un bug réel. Un modèle peut exceller sur les premiers et rester décevant sur le second exercice.

C’est ce vide que comble SWE-bench, devenu la référence pour les agents de code.

SWE-bench : de vrais tickets, de vrais tests

SWE-bench évalue les modèles sur des tickets GitHub réels issus de dépôts Python populaires. Le protocole reproduit le travail d’un développeur : le modèle reçoit la description d’un bug ou d’une demande, sans qu’on lui indique où regarder ; il explore le dépôt, localise le problème et propose un correctif ; ce correctif est ensuite jugé automatiquement par les tests du projet, ceux-là mêmes qui protègent le code en production.

Le benchmark existe en plusieurs formats :

Le site du benchmark publie aussi des variantes Multilingual et Multimodal, utiles si votre code n’est pas en Python ou si vos tickets contiennent des captures d’écran.

Lire un score : l’exemple de Devstral

Un score SWE-bench de X % signifie que l’agent a résolu X % des tickets du jeu de test, c’est-à-dire produit un correctif qui fait passer les tests du projet. Il ne signifie pas que le modèle écrit du bon code X % du temps.

À son lancement, le 9 décembre 2025, Mistral annonçait 72,2 % sur SWE-bench Verified pour Devstral 2 (123 milliards de paramètres) et 68,0 % pour Devstral Small 2 (24 milliards). L’écart est faible au regard de la différence de taille : c’est ce qui rendait Devstral Small 2 intéressant, et c’est pourquoi la documentation de Vibe le recommande encore aujourd’hui pour un usage local.

La même annonce illustre une précaution essentielle. Mistral y revendiquait un coût jusqu’à sept fois inférieur à celui de Claude Sonnet sur des tâches réelles, tout en indiquant que des évaluations humaines préféraient encore nettement Claude Sonnet 4.5 à Devstral 2. Un score de benchmark, un coût et une préférence humaine mesurent trois choses différentes ; aucune ne remplace les deux autres.

Ce que SWE-bench ne dit pas

SWE-bench teste un style de travail précis : la correction de bugs dans des projets Python open source, avec une suite de tests existante. Votre quotidien en TypeScript, en Java ou sur une application sans tests peut n’avoir aucun rapport avec ce cadre.

Les conditions d’évaluation pèsent lourd : le nombre de tentatives autorisées, l’outillage (scaffolding) fourni à l’agent, les limites de temps déplacent les scores de plusieurs points. Deux chiffres publiés séparément, par deux éditeurs, avec deux outillages différents, ne sont donc pas toujours comparables. Préférez les classements qui évaluent les modèles dans un cadre commun, et lisez toujours la méthode avant le chiffre.

La taille compte aussi, et pas seulement pour la facture : un modèle de 24 milliards de paramètres qui tient sur une seule carte graphique s’exploite là où un modèle beaucoup plus gros exige un cluster et une équipe pour l’entretenir.

Votre propre benchmark

La meilleure évaluation est celle que vous construisez sur votre dépôt. Prenez trois à cinq tickets déjà résolus, avec le correctif que votre équipe avait écrit et les tests associés. Faites-les traiter par les modèles candidats, par exemple Mistral Small 4 et Large 4 par l’API, ou Vibe Code avec son modèle intégré, puis comparez :

• le taux de réussite : les tests passent-ils avec le correctif proposé ?
• la qualité du diff : est-il minimal, lisible, conforme à vos conventions ?
• le coût et le temps : tokens consommés, durée de la session, nombre d’interventions humaines.

Aucun classement public ne remplacera ce test, et il se rejoue en une heure à chaque nouveau modèle.

Points clés à retenir

• SWE-bench évalue les agents sur de vrais tickets GitHub, jugés par les tests des projets
• Trois formats principaux : complet (2 294 tâches), Lite (300), Verified (500, filtrées par des humains)
• Devstral 2 et Devstral Small 2 annonçaient 72,2 % et 68,0 % sur SWE-bench Verified
• Score, coût et préférence humaine mesurent des choses différentes ; l’outillage d’évaluation change les chiffres
• Le test décisif se fait sur vos propres tickets résolus