NeurIPS 2026 : comment évaluer un agent de code sans se limiter aux tests réussis ?

Cet article s’adresse aux équipes qui évaluent ou reproduisent des agents de code dans leurs propres dépôts. Il propose une méthode pour examiner les résultats, les traces d’exécution et les conditions de validation, avec une comparaison des approches de test.

Le jeu SWE-bench comprend 2 294 problèmes issus de dépôts logiciels réels, selon sa publication de référence. Un résultat positif sur les tests ne suffit donc pas à conclure qu’un agent de code est fiable : évaluez aussi le résultat dans son contexte, la trace d’exécution et la validation, puis répétez l’essai dans un environnement contrôlé.

Décision — adapté si vous comparez des agents, construisez un protocole d’évaluation ou reproduisez une expérience sur un dépôt. Moins adapté si vous cherchez seulement un classement rapide fondé sur un unique taux de réussite.

Cet article s’adresse aux ingénieurs qui évaluent des agents de génération ou de réparation de code. Il aidera les responsables de plateforme d’évaluation à diagnostiquer les échecs, au-delà du résultat final. Les équipes de recherche y trouveront des repères pour reproduire une étude dans leur propre environnement.

Pourquoi un test vert ne suffit-il pas ?

Un test réussi répond à une question limitée : le code soumis satisfait-il les vérifications exécutées dans cette configuration ? Il ne dit pas, à lui seul, si l’agent a compris la demande, s’il a modifié la bonne zone du dépôt, ni si son résultat tient face aux contraintes qui ne sont pas couvertes par les tests.

La distinction est importante pour un agent logiciel chargé de corriger un défaut. Il peut parvenir à une modification acceptable après plusieurs tentatives mal dirigées, laisser des changements temporaires ou s’appuyer sur un comportement implicite de l’environnement. Il peut aussi produire un correctif qui passe la suite de tests disponible, mais qui contourne le problème au lieu de le résoudre. Si l’équipe ne conserve que la dernière sortie, elle ne pourra pas distinguer ces cas d’une réparation propre.

Le jeu SWE-bench formule des tâches de résolution de problèmes à partir de problèmes logiciels documentés dans des dépôts existants. Sa définition et ses règles d’utilisation sont décrites dans le dépôt du projet SWE-bench. Cette conception donne un contexte plus proche de la maintenance réelle qu’un exercice de programmation isolé. Elle ne transforme toutefois pas automatiquement le résultat d’un essai en preuve de fiabilité pour les dépôts, dépendances et pratiques internes d’une équipe.

Pourquoi l’évaluation d’un agent de code ne peut-elle pas s’arrêter au taux de tests réussis ? Parce que ce taux dépend du périmètre des tests, de leur état et des conditions de lancement. Une suite incomplète peut ne pas détecter une régression ; un résultat instable peut disparaître lors d’un nouvel essai. Il faut donc conserver le résultat des tests, mais aussi vérifier ce que l’agent a fait pour l’obtenir.

Pour illustrer l’écart entre succès apparent et qualité de procédure, imaginez une tâche de correction où l’agent exécute un test ciblé, voit un échec, modifie plusieurs fichiers sans examiner le diagnostic, puis relance les tests. Si le dernier essai passe, l’issue semble positive. Pourtant, sans les événements intermédiaires, il est difficile d’identifier la modification déterminante, de détecter une erreur masquée ou de reproduire l’échec initial. Cet exemple est un scénario de diagnostic, pas une mesure de fréquence.

Il faut également résister à une autre confusion : une trace volumineuse n’est pas nécessairement une trace de qualité. Des appels d’outils répétés peuvent révéler une boucle inefficace, mais leur simple comptage ne permet pas de juger le raisonnement ni la justesse du correctif. L’équipe doit relier chaque événement à la tâche, à l’état du dépôt et à une règle de validation.

Distinguer le résultat, la procédure et la robustesse

Nous séparons l’évaluation en trois questions. Premièrement, le changement résout-il le problème demandé sans introduire de défaut détecté ? Deuxièmement, le chemin suivi reste-t-il compréhensible et contrôlable ? Troisièmement, un nouvel essai dans des conditions comparables aboutit-il à une conclusion cohérente ?

Cette séparation évite de donner une note globale trompeuse à des comportements très différents. Un agent peut avoir un bon résultat final, mais une procédure difficile à auditer. Un autre peut échouer sur la tâche tout en fournissant une trace suffisamment claire pour diagnostiquer une dépendance manquante. Pour améliorer le système, ces deux cas ne demandent pas la même intervention.

Comment savoir si l’agent a réellement corrigé le problème plutôt que de tomber sur un succès fortuit ? Commencez par examiner le correctif lui-même, puis rapprochez-le de l’énoncé, des tests ciblés et des tests de régression. Vérifiez ensuite que l’état du dépôt avant l’essai était celui prévu et que le résultat reste reproductible après réinitialisation. Un test vert isolé ne tranche pas ces questions.

Pour chaque tâche, consignez des critères d’acceptation lisibles par une personne : fichiers ou comportements concernés, tests à exécuter, changements interdits, et conditions de réussite. Lorsque la demande est ambiguë, indiquez ce qui sera considéré comme acceptable avant le lancement. Cette précaution empêche d’ajuster l’interprétation après avoir vu le résultat, ce qui rendrait la comparaison entre agents moins équitable.

Les résultats doivent aussi distinguer les types d’échec. Une tâche peut échouer parce que l’agent a mal compris le problème, parce qu’un outil n’était pas disponible, parce que les tests ont échoué, ou parce que le protocole lui-même n’a pas pu être exécuté. Regrouper ces situations sous une unique étiquette « échec » facilite la lecture d’un tableau de bord, mais réduit fortement sa valeur pour le débogage.

Construire un jeu de tâches représentatif du dépôt

Un jeu d’évaluation utile ne se limite pas aux tâches les plus faciles à reproduire. Il doit refléter les demandes auxquelles l’agent sera réellement confronté : correction locale, changement traversant plusieurs modules, mise à jour d’une interface, traitement d’un défaut lié aux dépendances ou adaptation d’un comportement décrit dans la documentation. La sélection exacte dépend du dépôt ; l’objectif est de rendre explicite cette diversité plutôt que de prétendre qu’un petit ensemble représente tous les usages.

Pour chaque tâche, conservez l’énoncé original, le point de départ du dépôt, les prérequis, les fichiers ou composants pertinents et les conditions d’acceptation. Ajoutez les commandes de validation attendues et notez les limites connues, comme un service externe indisponible. Si une tâche dépend de données non présentes dans le dépôt, mentionnez-le : une erreur d’environnement ne doit pas être interprétée comme une incapacité de l’agent à corriger le code.

Classez les tâches selon leur nature et leur difficulté perçue, sans inventer une précision que l’équipe ne peut pas défendre. Les catégories doivent servir à comparer des cas analogues et à repérer les zones non couvertes. Si les tâches de documentation sont surreprésentées, par exemple, le score général ne doit pas laisser penser que les réparations de code plus complexes ont été évaluées avec la même ampleur.

La définition de SWE-bench fournit un point de comparaison pour organiser des problèmes ancrés dans des dépôts et des demandes réelles. La présentation d’OpenAI sur SWE-bench Verified et son processus de vérification montre également qu’un jeu de tâches peut nécessiter un examen des énoncés et des critères de validation. Ces références éclairent la conception d’un protocole ; elles ne dispensent pas de vérifier si les tâches retenues ressemblent à celles de votre équipe.

Quelles traces d’exécution faut-il conserver ? Gardez les appels aux outils et leurs paramètres pertinents, les commandes lancées, les sorties et erreurs, les modifications de fichiers, les étapes de récupération après un échec, ainsi que la validation finale. Associez ces événements à l’identifiant de la tâche et à l’état initial du dépôt. Ce lien permet de reconstruire la séquence sans confondre deux essais.

La documentation de SWE-agent sur les traces d’exécution décrit le type d’informations qui peut être conservé pour examiner le déroulement d’une tâche. Dans votre propre système, adaptez le niveau de détail aux questions de diagnostic : une trace doit aider à comprendre un changement, un test ou une récupération, sans enregistrer aveuglément tout ce qui est disponible.

Organiser l’exécution pour rendre les écarts explicables

Un protocole reproductible commence avant le lancement de l’agent. Identifiez la révision du dépôt, les dépendances et les outils nécessaires. Préparez une copie de travail dédiée, vérifiez que les tests prévus peuvent être lancés, puis définissez comment seront conservés les journaux et les changements produits. L’objectif est de comparer les agents sur un point de départ commun, pas de supposer que deux répertoires ressemblent suffisamment.

Voici une séquence que nous utilisons pour structurer une évaluation :

• Fixer les tâches, leurs consignes, leur état initial et leurs critères d’acceptation.
• Préparer un environnement isolé par essai, avec les outils nécessaires et un accès réseau explicitement contrôlé.
• Lancer l’agent en enregistrant les événements, les sorties d’outils et les modifications apportées au dépôt.
• Exécuter les validations prévues sans effacer les échecs intermédiaires ni les changements non retenus.
• Réinitialiser le point de départ et répéter l’exécution lorsque la mesure dépend du comportement de l’agent ou de l’environnement.
• Examiner les correctifs et les traces, puis classer séparément les succès, les échecs de tâche et les incidents d’exécution.

L’isolation réduit les interférences entre essais, mais ne règle pas à elle seule les problèmes de reproductibilité. Il faut vérifier que la révision du code, les dépendances, les variables d’environnement, les autorisations et les services externes ne changent pas silencieusement. Pour les environnements reposant sur des conteneurs, la documentation Docker sur l’exécution des conteneurs détaille les options de lancement, notamment celles qui influent sur les processus et les ressources accessibles. Une configuration de conteneur n’est pas une garantie générale de sécurité : l’équipe doit contrôler les montages, les privilèges et les accès accordés à son propre agent.

Une précaution souvent oubliée concerne les modifications déjà présentes au lancement. Un fichier non suivi, une dépendance installée localement ou un test laissé dans un état particulier peut expliquer un résultat qui semble attribuable au modèle. Enregistrez l’état initial et vérifiez le contenu du dépôt avant l’expérience. Si l’essai nécessite un secret ou un service externe, évitez de l’inclure dans les traces partagées et documentez plutôt la règle d’accès utilisée.

Pour les essais répétés, ne confondez pas stabilité et répétition mécanique. Relancer le même agent sur un répertoire déjà modifié ne constitue pas une répétition comparable. Chaque nouvel essai doit repartir de la condition définie pour la tâche, avec les mêmes ressources prévues et les mêmes règles de validation. Notez toute différence qui ne peut pas être contrôlée, comme une dépendance distante mise à jour ou un service temporairement indisponible.

Lire les travaux de NeurIPS 2026 avec prudence

La page officielle des téléchargements de NeurIPS 2026 répertorie des travaux liés aux agents de génie logiciel. Une entrée de conférence est un point de départ pour la veille, pas une validation générale d’une méthode en contexte de production. Avant de reprendre une conclusion, consultez le texte intégral, vérifiez la version du manuscrit et recherchez les matériaux rendus publics par les auteurs.

Un préprint associé est accessible sous la référence arXiv:2605.21996. Nous ne transposons pas ici de résultats expérimentaux qui ne sont pas explicitement vérifiés dans le texte et les matériaux correspondants. Pour une reproduction, relevez d’abord ce que les auteurs ont réellement évalué : les tâches, les dépôts, les outils autorisés, les conditions d’exécution et les critères de succès. Puis consignez séparément les adaptations imposées par votre infrastructure. Une reproduction adaptée peut être utile, mais elle ne doit pas être présentée comme une répétition exacte de l’expérience originale.

Cette distinction est particulièrement importante lorsque le code public évolue. Le dépôt peut ne plus correspondre à la version du manuscrit ou au protocole décrit dans celui-ci. Conservez donc la référence de la version consultée et la date de votre propre essai dans vos notes de recherche. Vérifiez aussi si les résultats reposent sur des composants qui ne sont pas disponibles dans votre environnement ; dans ce cas, indiquez clairement ce qui a été remplacé ou omis.

Comment reproduire une évaluation d’agent dans son propre dépôt ? Commencez par sélectionner un ensemble de tâches locales et définissez leurs conditions d’acceptation avant l’exécution. Fixez ensuite une révision du dépôt et un environnement documenté. Lancez les essais en enregistrant les traces, réinitialisez le point de départ entre les tentatives, puis faites examiner les correctifs et les résultats de validation. Enfin, comparez vos conclusions aux conditions de l’étude publiée, sans assimiler des protocoles différents.

La reproductibilité ne signifie pas que toutes les équipes doivent obtenir des résultats identiques. Elle signifie qu’elles peuvent expliquer les différences : une tâche absente, une dépendance différente, un droit d’accès plus limité ou une version de code distincte. Pour cette raison, un journal expérimental devrait préciser les éléments effectivement contrôlés et ceux qui ne l’étaient pas. Sans ces informations, un écart de performance peut être attribué à tort au modèle.

Comparer les approches avant d’étendre l’évaluation

Avant d’augmenter le nombre de tâches ou d’ouvrir l’accès à davantage d’outils, évaluez le coût de vérification. Une trace riche peut améliorer l’analyse, mais demande de l’espace, des règles de conservation et parfois une revue de confidentialité. À l’inverse, un journal minimal est plus facile à gérer, mais peut rendre impossible l’explication d’un échec. Le bon compromis dépend des risques et des décisions que l’évaluation doit éclairer.

La grille ci-dessous propose des appréciations qualitatives, et non un barème universel. Utilisez-la pour décider si votre protocole est prêt à comparer des agents ou s’il faut d’abord améliorer l’observabilité.

Une appréciation « solide » dans cette grille ne signifie pas que le protocole est complet pour tous les usages. Si le système peut modifier des fichiers sensibles, accéder à des services externes ou exécuter des commandes non prévues, il faut aussi examiner les permissions et les limites de l’environnement. Si l’évaluation sert à choisir un agent pour un déploiement, ajoutez les tâches et vérifications correspondant aux usages réels, plutôt que de vous reposer sur un classement générique.

Pour organiser une première expérimentation sur une machine distante, les environnements Mac proposés par ZekVPS peuvent être examinés si le dépôt ou les outils à tester requièrent macOS. Vérifiez les caractéristiques effectivement annoncées avant de retenir cette option : cet article ne suppose ni configuration particulière, ni mécanisme d’isolation ou de livraison précis. Une page consacrée à la location de Mac en Corée du Sud permet de consulter une offre géographique, mais le choix doit rester subordonné à vos contraintes de latence, d’accès et de compatibilité.

Si l’environnement actuel est un poste partagé, une machine locale difficile à remettre à zéro ou un hôte Linux qui ne reproduit pas le comportement de macOS, il peut compliquer les essais : état résiduel, accès concurrents ou différences de système. Pour une validation qui exige réellement macOS, louer un Mac auprès de ZekVPS peut offrir une expérience plus adaptée qu’un achat immédiat, à condition que l’offre consultée satisfasse les besoins de l’expérience. En revanche, pour une charge soutenue et stable, un Mac déjà possédé peut être plus cohérent ; si le projet ne dépend pas de macOS, un environnement local ou une autre solution distante peut suffire. Le choix ne remplace jamais un protocole reproductible : il fournit seulement le cadre matériel à vérifier avant de lancer les agents.