Deux benchmarks publiés à quelques jours d’intervalle mesurent l’écart entre les conditions de test et la réalité opérationnelle. SWE-Touch évalue ce qui se passe quand un utilisateur humain modifie le code pendant qu’un agent IA travaille sur un repository. Le SWE-bench classique supposait que le code restait inchangé du début à la fin de la tâche : en réalité, les développeurs continuent à faire des commits pendant que l’agent travaille.

ExtractBench, dont nous avons parlé le 3 août, place les agents face à 4.869 pages de documents d’entreprise réels avec des mises en page complexes, plutôt qu’à des textes propres. Là aussi, les modèles frontier raccourcissent les enregistrements longs et les coding agents coûtent trop cher par rapport à la valeur qu’ils apportent.

Dans les deux cas, le schéma est identique : les benchmarks traditionnels mesuraient le meilleur qu’un agent peut faire en conditions idéales. Ces deux-ci mesurent ce qui se passe quand les conditions ne le sont pas, et les frontier model perdent en performance de façon significative.

Pour ceux qui déploient des agents en production, la différence compte. SWE-bench te dit ce que vaut un modèle quand personne ne touche à rien. La vrai production a des développeurs qui commitent pendant que l’agent travaille, des documents avec des tableaux cassés, un contexte qui bouge. L’écart entre le score sur le benchmark propre et celui sur le benchmark réaliste mesure votre exposition quand l’agent sort de la démo.

En détail

Le problème qu’affrontent SWE-Touch et ExtractBench est structurel. SWE-bench, le benchmark de référence pour les coding agents, prend des issues réelles sur GitHub et mesure si un agent résout le problème. Mais il fige le repository au moment de l’ouverture de l’issue : personne ne touche au code pendant que l’agent travaille. Dans la vraie vie, un collègue fait un push, une dépendance se met à jour, le fichier que l’agent est en train de lire change sous lui. SWE-Touch simule exactement cela : l’utilisateur humain modifie le code pendant l’exécution de l’agent, et le benchmark mesure comment l’agent réagit.

ExtractBench affronte un problème similaire du côté documentaire. Les benchmarks d’extraction de données traditionnels utilisent des documents avec une structure prévisible. ExtractBench rassemble 67 types de documents d’entreprise réels, pour 4.869 pages au total, et mesure quatre dimensions ensemble : précision, complétude, traçabilité et coût. Les résultats montrent que les vision-language models raccourcissent les enregistrements quand ils sont longs, et les coding agents qui naviguent le document étape par étape dépensent trop pour la valeur qu’ils apportent.

Ce qui unit les deux benchmarks est l’idée que l’évaluation doit se rapprocher des conditions de production. La mesure multi-dimensionnelle, pas seulement la précision mais aussi le coût et la traçabilité, change le jugement sur les modèles. Un agent qui a 90% de précision sur SWE-bench peut s’effondrer quand le code change en cours de travail, parce que son plan d’action était construit sur un état qui n’existe plus.

La limite des deux est qu’elles restent des simulations. SWE-Touch simule les modifications humaines selon des schémas prédéfinis, ne capture pas la créativité destructrice d’un vrai développeur qui réécrit un fichier entier pendant que l’agent travaille sur l’ancienne version. ExtractBench utilise des documents réels mais les sélectionne, ne couvre pas tous les cas qu’un pipeline documentaire d’entreprise peut rencontrer. Pour ceux qui veulent se faire une idée concrète de la façon dont leur agent tient en production, la méthode du bench personnalisé reste l’étape suivante : prendre vos propres cas, les salir, et mesurer.