Benchmark d’agents de code : scores et limites
Un benchmark de 20 agents de programmation révèle des scores, coûts et biais inattendus. Analysez ses limites et les contrôles à exiger avant de comparer.
Agents de programmation à l'épreuve : ce que révèle un benchmark conçu pour les déstabiliser
Comparer des agents de programmation à partir d'un classement, c'est tentant : on regarde le score, le coût par tâche, le temps d'exécution, puis on choisit le meilleur. Le problème, c'est que ces chiffres ne disent pas toujours pourquoi un agent gagne (ou perd). Il peut échouer parce qu'il n'arrive pas à raisonner sur le code, parce que l'environnement lui met des limites, ou parce qu'il a refusé une instruction jugée ambiguë.
C'est exactement ce que met sur la table KillSwitch-Bench. Le benchmark fait travailler vingt associations de modèles et d'outils d'exécution sur un langage expérimental pensé pour être pénible à lire et à écrire. Ce qui est appréciable, c'est qu'il affiche aussi le coût et la durée, au lieu de réduire l'évaluation à un unique score. Mais en parcourant le dépôt et les règles, on voit aussi des limites : les refus ne sont pas toujours clairement distingués des erreurs, le score agrège des critères discutables, et le comportement de l'interpréteur introduit une part d'aléatoire.
Bref : on peut dire certaines choses avec confiance à partir de l'expérience, d'autres pas, et il y a des contrôles utiles à remettre sur la table quand on évalue un agent en entreprise.
Un langage conçu pour mettre les agents en difficulté
KillSwitch est un langage à pile où le code prend la forme de phrases. Une instruction d'entrée peut ressembler à « this story starts », une valeur est appelée par une référence descriptive, et les identifiants sont retrouvés via des anagrammes. Une partie du texte d'un programme est ignorée par l'interpréteur : du coup, le « code logique » peut se retrouver enfoui dans un récit.
Ce choix est assumé. L'objectif annoncé est de séparer la capacité d'un modèle à raisonner sur un langage « nouveau » de sa capacité à reproduire des constructions déjà vues pendant l'entraînement. C'est une idée défendable : si le test se contente d'un langage familier, on mesure vite autant la familiarité que la compréhension.
Quand la syntaxe ressemble à une attaque
Le hic, c'est que certaines instructions valides empruntent ouvertement au vocabulaire qu'on associe aux tentatives d'injection. L'appel de fonction contient une formulation proche de « ignore previous instructions ». Le langage comprend aussi une instruction nommée « hack » et un mot-clé de retour formulé comme une référence à un événement historique sensible.
Résultat : produire du code « correct » peut obliger un modèle à générer une chaîne que ses mécanismes de sécurité pourraient interpréter comme une manipulation. Et quand ça échoue, on ne sait pas ce qui s'est réellement passé : mauvaise compréhension de la grammaire, ou reconnaissance d'une formulation risquée et auto-censure. Or le classement ne sépare pas ces cas. Un refus, une erreur de compilation, une réponse incorrecte ou un dépassement de délai peuvent se retrouver dans une même catégorie de résultat négatif.
Cette distinction change tout, justement parce qu'elle conditionne l'interprétation. Le dépôt évoque des garde-fous de sécurité « trop sensibles », mais les chiffres ne montrent pas clairement quels modèles du bas du classement sont concernés. On trouve par exemple Claude Fable 5.1 en 6e position sur 20 avec 46,7 % ; Gemini 4 Argon en 5e avec 47,1 %. Ces résultats ne prouvent ni que les garde-fous n'ont rien fait, ni qu'ils expliquent les échecs. Ils rappellent surtout qu'avant d'attribuer un refus à un « manque de compréhension », il faut une mesure dédiée à ce type d'événement.
Une spécification plus volumineuse que le contexte disponible
Chaque tâche est accompagnée de deux fichiers : un SPEC.md d'environ 17 Ko et un AI_SPEC.md d'un peu plus de 5,1 millions de caractères (autour de 1,3 million de jetons). Dans les conditions habituelles, aucun modèle « courant » ne peut absorber tout ça en une seule passe.
Le document volumineux contient du texte de domaine public, des consignes éparpillées, et des indications qui se contredisent. L'analyse du dépôt décrit le dispositif comme un test de saturation du contexte : l'agent ne peut pas tout lire, et les règles pertinentes sont noyées dans beaucoup de bruit. Certaines notes du dépôt signalent même que certaines sections peuvent contenir des affirmations fausses.
Le test est donc intéressant pour la sélection d'information. Mais il ne mesure pas uniquement la compréhension du langage. Il mesure aussi la façon dont l'agent gère un contexte trop grand, une documentation bruitée et des consignes « adverses ». En entreprise, ces compétences peuvent être utiles. Mais si l'on compare des modèles, ces facteurs devraient être distingués plutôt que fondus dans un score unique.
Des scores difficiles à interpréter sans leurs causes
Le classement présente plusieurs modèles et outils associés, avec un score, un coût moyen par tâche et une durée. Dans l'idée, c'est plus concret qu'un palmarès seul : une réponse obtenue en trente secondes et « quelques centimes » n'a pas le même profil qu'une autre qui mobilise plusieurs minutes et plusieurs euros.
Le problème, c'est que le score principal mélange des dimensions qui ne répondent pas aux mêmes questions. D'après l'analyse du dépôt, le score composite combine le taux de réussite, le coût et la taille de l'implémentation. Ces éléments ne devraient pas être agrégés automatiquement, sans quoi on compare deux choses différentes.
La taille du programme n'est pas une mesure de justesse
Si un agent produit un programme correct mais plus long qu'un autre, il a quand même résolu la tâche. La longueur peut dire quelque chose sur la concision ou la manière de générer le code, mais elle n'est pas, en soi, une mesure de correction. Pénaliser la longueur dans un score de réussite mélange deux questions : « est-ce que ça fonctionne ? » et « est-ce que la forme correspond à une préférence ? ».
Le coût, lui, a une logique opérationnelle. Une équipe qui exécute des milliers de tâches doit arbitrer entre qualité, délai et budget. Elle peut vouloir connaître le prix d'un résultat correct, ou le coût moyen par tâche terminée. Mais ces métriques devraient être publiées séparément du taux de réussite, avec une méthode de calcul claire.
Un classement exploitable devrait donc afficher, au minimum :
- le taux de tâches réussies (mesure principale de correction) ;
- le coût moyen et sa distribution (pour estimer le budget réel) ;
- le temps d'exécution, avec les dépassements de délai ;
- la taille ou la concision du code (comme indicateur distinct) ;
- les statuts de fin (pour différencier réussite, refus, erreur et expiration).
Le principe reste simple : un indicateur composite peut aider à décider, mais seulement si ses composantes restent visibles. Sinon, un rang peut s'expliquer par une meilleure correction, ou par un coût plus faible, ou par une pénalité de style.
Le cas des résultats à 0 % et 0 €
Deux lignes du classement affichent 0,0 % de réussite et 0,00 € par tâche : GPT-5.6 Luna et Qwen3.8 27B. Pour le second, le dépôt indique qu'il a atteint la limite d'exécution de trente minutes. Un coût à zéro ne veut pas dire « rien n'a été fait » au sens utile : ça indique surtout qu'aucun jeton facturé n'a été comptabilisé dans le reporting. À lui seul, ce chiffre ne dit pas ce qui a réellement bloqué.
Refus de la tâche ? Harnais défaillant avant l'appel au modèle ? Arrêt anticipé, erreur de configuration, problème de suivi de facturation ? Le score publié ne répond pas à ces questions. Et dans un test bâti autour d'instructions adverses, le fait qu'un agent ne commence même pas à travailler peut être aussi informatif que son échec après plusieurs essais.
La bonne approche n'est pas de « deviner » à partir du prix. Il faut enregistrer un statut terminal explicite pour chaque exécution : terminée, refusée, erreur technique, délai dépassé, ou autre interruption. Les traces devraient ensuite permettre de vérifier ce statut sans divulguer d'informations sensibles.
L'aléatoire rend les résultats moins stables qu'ils n'en ont l'air
Le benchmark présente son évaluation comme déterministe, mais l'analyse du fonctionnement de l'interpréteur mentionne des comportements aléatoires. La valeur d'une instruction peut dépendre du comptage des lignes, et quand une ligne contient plusieurs valeurs possibles, l'interpréteur en choisirait une au hasard. Il est aussi question d'un « état de bonheur » qui influe sur la sévérité de l'analyse syntaxique.
Faire tourner chaque modèle au moins deux fois par tâche est donc une précaution utile. Mais publier une valeur unique masque la dispersion, surtout quand l'environnement peut produire des résultats différents à entrée égale. Pour comparer sérieusement, il faut publier le nombre d'essais, une moyenne, une mesure de variabilité, et la règle de traitement des échecs. Deux exécutions donnent un premier signal, mais ce n'est pas forcément suffisant pour estimer une performance stable.
Les contrôles d'intégrité les plus instructifs
Le dépôt contient aussi des mécanismes d'intégrité moins visibles dans le tableau, mais particulièrement intéressants pour les équipes qui construisent des évaluations. L'interpréteur inspecte la chaîne de processus qui l'a lancé et cherche des exécutables associés à des agents connus, notamment Cursor, Claude, Codex, OpenCode ou Aider.
S'il en détecte un, il renvoie un faux message d'erreur qui demande de dessiner un pélican en combinaison spatiale. Si le fichier demandé existe déjà, le message indique que le dessin n'est pas satisfaisant. En clair : l'instruction est construite pour être impossible à satisfaire, et elle bloque l'agent au milieu de son exécution.
Vérifier le contexte d'exécution, pas seulement le résultat
Ce mécanisme pose une question importante : on mesure le modèle « seul », ou le modèle tel qu'il fonctionne dans un harnais, avec des outils, dans un environnement donné ? Dans un benchmark d'agents, le résultat dépend souvent du système complet. Le modèle peut être identique, mais le nombre d'outils disponibles, la stratégie de boucle, les limites de temps ou la gestion des erreurs changent la performance.
L'inspection du processus parent n'est pas une garantie absolue contre toute manipulation. Elle peut aussi générer de faux positifs, ou rendre les résultats dépendants de l'environnement d'exécution. Mais l'idée est réutilisable : documenter le contexte technique qui a produit chaque résultat. Sans cette information, deux lignes présentées comme « même modèle » peuvent en réalité comparer deux systèmes différents.
Le dépôt ajoute aussi un fichier AGENTS.md demandant à un agent qui le lit de ne pas consulter le dossier concerné, même si l'utilisateur le lui demande. Cette consigne entre en conflit avec la spécification volumineuse qui, elle, invite à le lire. Le test ne porte donc plus uniquement sur la grammaire : il met aussi en concurrence plusieurs canaux d'instructions.
Ces dispositifs rendent le benchmark plus riche, mais aussi plus difficile à interpréter. Une consigne contradictoire teste la hiérarchie des instructions, la lecture de fichiers, la résistance aux contenus adverses, et la capacité à suivre la demande utilisateur. Il faut donc savoir quelle capacité est réellement évaluée avant de conclure qu'un modèle est « meilleur ».
Comparer des versions exige de contrôler le harnais
La comparaison la plus parlante porte sur deux lignes utilisant le même harnais Claude Code. Claude Sonnet 5 obtient 17,3 %, pour 2,55 dollars par tâche et 11 minutes 35 secondes. Claude Sonnet 5.5 obtient 7,4 %, pour 0,15 dollar et 53 secondes.
Le modèle plus récent est ici beaucoup moins coûteux et plus rapide, mais son score est inférieur de plus de moitié. D'autres lignes vont dans le même sens : Claude Opus 5 affiche 66,8 %, contre 58,7 % pour Claude Opus 5.5 ; GPT-6.1 Sol atteint 59,2 %, contre 28,0 % pour GPT-6 Sol.
Ces résultats ne prouvent pas que les versions plus récentes seraient « globalement moins bonnes ». Ils montrent seulement qu'avec ce benchmark et cette configuration, la numérotation de version ne prédit pas le score. La durée très courte de certains essais peut aussi refléter une stratégie d'exécution différente, mais le classement seul ne permet pas d'en connaître la cause. Pour comprendre, il faut consulter les traces, les paramètres et les règles du harnais avant d'interpréter l'écart.
Une méthode pratique pour mieux évaluer les agents
Pour une équipe produit, une jeune pousse de la French Tech ou une direction informatique, un benchmark n'est jamais une fin en soi. Il sert à choisir quel système tester, dans quelles conditions, et avec quel niveau de risque. Une approche pragmatique consiste à séparer ce qu'on mesure, au lieu de chercher un score universel.
1. Définir la capacité mesurée
Commencez par clarifier la décision que le test doit éclairer. Cherchez-vous la correction du code ? La résistance aux consignes adverses ? La capacité à naviguer dans un dépôt ? Le coût d'une tâche ? L'autonomie de l'agent ? Ces dimensions peuvent se recouper, mais elles ne sont pas interchangeables.
Si le test contient des chaînes qui ressemblent à des instructions malveillantes, prévoyez une catégorie explicite pour les refus de sécurité. Si l'objectif est de mesurer la compréhension d'un langage inhabituel, indiquez aussi que la saturation du contexte et la hiérarchie des consignes peuvent faire varier le résultat.
2. Séparer modèle, harnais et environnement
Pour chaque essai, consignez la version du modèle, le harnais, les outils disponibles, les limites de temps et de jetons, ainsi que les paramètres pertinents. Le nom du modèle ne suffit pas : l'entité « testée » est le système complet qui reçoit la tâche et produit la réponse.
Quand c'est possible, gardez le harnais identique pour comparer deux modèles. Quand ce ne l'est pas, publiez la différence et évitez de présenter les résultats comme directement équivalents.
3. Conserver un statut terminal et des traces vérifiables
Chaque exécution doit se terminer par un statut clair : réussite, refus, réponse incorrecte, erreur de compilation, erreur d'environnement, délai dépassé. Ajoutez aussi les coûts et les durées avec une méthode de calcul explicite.
Les traces brutes comptent autant : elles montrent si l'agent a vraiment tenté la tâche, s'il a rencontré une erreur, ou s'il s'est arrêté dès la première instruction. Vous n'êtes pas obligé de rendre tout public si cela expose des informations sensibles, mais le protocole doit permettre un audit indépendant raisonnable.
4. Publier les composants avant le classement
Avant de proposer un score composite, affichez les métriques séparément. Si vous construisez un indice global, expliquez les pondérations et montrez comment le classement évolue quand on change ces pondérations. La longueur du code peut intéresser certains acheteurs ; elle ne devrait pas être cachée dans une mesure « de justesse ».
Enfin, si l'interpréteur ou le modèle n'est pas déterministe, répétez les tâches. Publiez les moyennes et la dispersion, pas seulement le meilleur résultat ou une valeur isolée. Oui, c'est plus coûteux. Mais ça évite de transformer un tirage favorable en « preuve » générale.
Dans une évaluation de revue de code en entreprise, la logique est la même : une règle écrite dans un fichier de consignes n'est pas forcément appliquée dans les faits. Le moyen le plus simple de le vérifier est un changement témoin, ou canari, conçu pour déclencher cette règle, puis l'observation dans la chaîne d'intégration continue : blocage effectif, commentaire seul, ou absence de détection.
Conclusion : publier des résultats que l'on peut auditer
KillSwitch-Bench pose une bonne question : celle du coût et du temps, souvent absents des classements. Mais son intérêt ne se réduit pas à son palmarès. Les tensions entre syntaxe et garde-fous, la documentation démesurée, les comportements aléatoires et les mécanismes d'intégrité montrent à quel point il est facile de confondre plusieurs capacités dans un seul chiffre.
La règle pratique est simple : avant de tirer une conclusion sur un modèle, publiez les composants, les statuts de fin et le contexte d'exécution. Si vous évaluez déjà un agent dans votre chaîne de développement, commencez par un essai témoin et vérifiez ce que le système a réellement fait, pas seulement la note affichée. Pour comprendre le protocole d'origine, voir l'analyse de KillSwitch-Bench.