Sept agents de code, 718 vrais prompts de développeurs, six points et demi de performance qui s'évaporent. Des chercheurs de Séoul viennent de prouver ce que tout le monde soupçonnait : les benchmarks mesurent des tickets propres, pas des humains pressés. Et ils donnent la recette pour que votre agent arrête de se planter.
Le laboratoire contre le terrain
SWE-bench est devenu le baromètre officiel des agents de code. Chaque lab, de DeepSeek à Anthropic, brandit son score comme un trophée de chasse. Le problème : ce benchmark est construit sur des tickets GitHub. Longs. Structurés. Renseignés. Un ticket SWE-bench, c'est un rapport d'incident rédigé par un ingénieur consciencieux : voici le bug, voici l'environnement, voici les étapes pour le reproduire, voici le comportement attendu.
La réalité, elle, ressemble à autre chose. « ça crashe sur input vide, corrige ». Huit mots. Pas de contexte, pas de reproduction, pas de spec. C'est ce que tapent les vrais développeurs dans Claude Code, Cursor ou Gemini CLI, entre deux réunions, la moitié du temps en fin de journée.
Cinq chercheurs de l'université Sungkyunkwan de Séoul ont décidé de mesurer l'écart. Ils ont publié RealSWE fin août 2026, un benchmark open source (licence MIT) qui confronte sept LLM contemporains à des prompts réellement écrits par des humains. Pas des tickets. Pas des énoncés d'examen. Des messages de devs, avec leurs fautes, leurs ellipses et leur absence totale de contexte.
La méthode vaut le détour, parce qu'elle est plus propre que la concurrence. RealSWE construit 381 familles de tâches (192 corrections de bug, 189 demandes de fonctionnalité). Dans chaque famille, la tâche et le correctif de référence sont identiques. Seule la composition de l'information et le style linguistique varient. On peut donc attribuer la cause d'une baisse de performance à un champ précis, pas à un fourre-tout de transformations simultanées. Les benchmarks précédents, eux, changeaient tout à la fois.
Le constat est limpide. Et il fait mal.
Ce que les vrais prompts ne disent jamais
Les chercheurs ont disséqué 718 prompts humains, extraits du dataset SWE-chat (5 851 sessions collectées auprès de développeurs qui utilisent Claude Code, Cursor, Gemini CLI, OpenCode et Factory AI Droid). Ils ont compté les champs d'information dans chaque message.
Le résultat tient en une phrase : 88 % des requêtes réelles ne contiennent qu'un énoncé du problème. Rien d'autre. Contre 7 % des problèmes de benchmark. Autrement dit, le benchmark est treize fois plus bavard que la réalité.
Dans le détail, ça devient caricatural. Le « comportement attendu », ce que le logiciel doit faire une fois corrigé, apparaît dans 73,5 % des tickets de benchmark. Dans les vrais prompts ? 5,4 %. La motivation, elle, est présente dans 96,1 % des tickets. Dans les messages réels ? 8,9 %.
Le prompt réel moyen transporte 1,4 champ d'information. Le ticket de benchmark, 2,9. Et le style n'échappe pas à la règle : 87 % des prompts réels sont écrits de façon décontractée, contre 94 % de problèmes formels côté benchmark. Deux espèces qui ne parlent pas la même langue, séparées par un abîme de politesse. Même la syntaxe diverge : 51 % de phrases impératives dans les vrais prompts, contre 89 % de phrases déclaratives dans les tickets. L'humain ordonne, le ticket décrit. L'agent, lui, est entraîné sur le second.
Six points et demi qui s'évaporent
Voilà le chiffre qui fâche. Quand on passe des tickets propres aux prompts réels, les sept modèles testés perdent 6,4 points de pourcentage en moyenne. Et ce n'est pas uniforme.
Modèle | Score benchmark | Score prompts réels | Perte |
DeepSeek V4 Pro | 53,9 | 45,9 | −8,0 |
DeepSeek V4 Flash | 49,7 | 41,6 | −8,0 |
MiMo V2.5 Pro | 49,1 | 44,0 | −5,1 |
MiMo V2.5 | 48,4 | 40,7 | −7,7 |
Claude Haiku 4.5 | 42,1 | 36,7 | −5,4 |
Qwen3.7 Plus | 50,1 | 43,5 | −6,6 |
MiniMax M3 | 34,1 | 30,1 | −4,0 |
Les deux DeepSeek dégringolent de huit points. MiniMax M3, déjà dernier au départ, en perd quatre. Et surtout : le classement change. Le papier note que l'écart entre les modèles forts et les modèles faibles se resserre, et que l'ordre relatif peut s'inverser selon le type de tâche. En bug fix, DeepSeek V4 Pro et Flash plongent de plus de dix points, quand Claude Haiku 4.5 en perd à peine un demi en feature request. Traduction : votre « n°1 du leaderboard » n'est pas forcément le meilleur sur un prompt dégueulasse tapé à la va-vite un vendredi soir.
L'autre chiffre qui fait réfléchir, c'est le coût. Claude Haiku 4.5 facture 33,9 cents par tâche, pour 66,9 étapes en moyenne. DeepSeek V4 Flash, 1,3 cent, pour 47,7 étapes. Un rapport de vingt-six pour un. Et la performance ? Sur les prompts réels, Flash fait mieux que Haiku selon le papier. Payer vingt-six fois plus cher pour un résultat moins bon, il y a des directeurs financiers que ça devrait réveiller.
Le plan mode de Claude Code pollue les données
Le papier réserve une découverte aussi savoureuse qu'inquiétante. Pour obtenir leurs 718 « vrais » prompts, les chercheurs ont dû en jeter 871 qui n'avaient rien d'humain.
542 avaient été générés par des LLM. Et là, le détail qui pique : 523 de ces 542 prompts artificiels sortaient du « plan mode » de Claude Code. Traduction : les logs d'utilisation des agents de code sont pollués par les agents eux-mêmes. Le plan mode de Claude Code pond des requêtes qui ressemblent à des humains, mais n'en sont pas. Un benchmark qui ne nettoie pas ça mesure en partie des LLM qui se répondent à eux-mêmes. Le serpent qui se mord la queue, version token.
273 autres prompts avaient été injectés par des outils, dont 221 wrappers Conductor. Bref, sur 1 589 requêtes brutes, plus de la moitié n'étaient pas écrites par un développeur. Si votre dataset « d'usage réel » n'a pas été filtré comme ça, méfiez-vous.
La recette : dites-leur ce que vous voulez
Le papier ne se contente pas de constater. Il teste quoi ajouter pour améliorer les résultats. Et la réponse est contre-intuitive, au point d'être immédiatement exploitable.
Ajouter le « comportement attendu » à un bug fix : +8 points, soit +17 % de résolution en relatif. C'est énorme pour une seule phrase. Ajouter la « motivation » à une demande de fonctionnalité : jusqu'à +7 points.
Concrètement, « ça crashe sur input vide, corrige » devient « ça crashe sur input vide ; le comportement attendu est de retourner une liste vide ; la motivation : l'API est appelée par des clients mobiles sans paramètres ». Même point de départ, deux lignes en plus, huit points de gagnés. Le papier le démontre par paires contrôlées, avec des écarts statistiquement solides.
Et le plus drôle, c'est ce qui ne sert à rien.
Les étapes de reproduction ne servent à rien
Les chercheurs ont testé l'ajout des « étapes de reproduction » et des « informations d'environnement ». Le réflexe de tout bon ingénieur : « je te décris exactement comment reproduire le bug ». Résultat : aucun bénéfice mesurable. Les mots du papier sont durs : ces champs « ajoutent des tokens sans bénéfice mesurable ».
Autrement dit, le conseil qu'on vous répète depuis des années — « ajoutez du contexte, décrivez votre environnement » — est partiellement faux pour les agents de code. Ce qui compte, c'est le comportement attendu et la motivation. Le reste, c'est du bruit qui coûte des tokens.
Nuance quand même, et le papier la reconnaît lui-même : ce résultat est mesuré sur des modèles non-frontier, en single-turn, sans conversation itérative. Dans une session interactive, des étapes de reproduction pourraient déclencher des questions de clarification utiles. Mais pour le prompt one-shot, la messe est dite.
Ce que le papier ne dit pas
RealSWE a ses trous. Pas de modèle frontier testé : GPT-5.6, Opus 5 et Kimi K3 sont absents. Les auteurs l'écrivent noir sur blanc, leurs résultats pourraient ne pas se généraliser aux meilleurs modèles de code. Un modèle plus fort pourrait être moins sensible à la pauvreté d'information. Ou plus. On ne sait pas.
Les tâches viennent de SWE-bench Verified et Pro, donc de dépôts Python populaires. Le biais de sélection est audité dans l'annexe du papier, mais il existe. Et le projet est jeune : le dépôt GitHub affichait zéro étoile et zéro fork au moment de l'enquête. Pas de description, pas de README. Un papier académique solide, mais pas encore passé au crible de la communauté.
Verdict
RealSWE n'est pas le benchmark du siècle. C'est mieux : c'est un rappel à l'ordre. Les leaderboards ne mesurent pas votre réalité. Ils mesurent des tickets de musée.
Ce que le papier vous offre tient en une phrase : pour qu'un agent de code fasse ce que vous voulez, dites-lui ce que vous voulez. Le comportement attendu. La motivation. Deux lignes, huit points.
Le reste — étapes de reproduction, environnement, description exhaustive du contexte — c'est du gras de ticket. De la politesse de benchmark. Et votre agent s'en fout.
Pendant que les labs se battent à coups de scores sur des tickets parfaits, vous pouvez gagner huit points avec deux phrases. C'est peut-être la nouvelle la plus rentable de l'été. Le n°1 du leaderboard, lui, continue de faire semblant.
Sources
- RealSWE — arXiv 2608.27831
- RealSWE — version HTML complète
- RealSWE — Hugging Face Daily Papers
- Dépôt GitHub RealSWE (MIT)
- Analyse CCTest.ai de RealSWE
- SWE-chat — arXiv 2604.20779
- Site du dataset SWE-chat
- SWE-chat — Hugging Face
- BeyondSWE — limites des benchmarks mono-repo
- CursorBench — benchmark fermé concurrent
✦ Idée d'illustration : un podium de course en bois brut, style néobrutaliste, avec trois agents IA stylisés en coureurs sur la plus haute marche. Le premier brandit un trophée en or marqué « 53,9 » pendant qu'un développeur, au premier plan, tape sur son clavier un prompt bancal affiché en énorme (« ça crashe sur input vide, corrige ») et que le trophée fond littéralement en flaques de pixels dorés. Palette rouge/orange/bleu électrique sur fond crème, grain papier, éclairage dur, léger clin d'œil aux affiches de sport des années 80. Le chiffre « 6,4 » tombe en pluie de caractères depuis le haut du podium.
