Un benchmark en conditions réelles montre que les agents de programmation nécessitent encore une intervention humaine pour la plupart des tâches

Selon un nouveau benchmark fondé sur des demandes réelles d’utilisateurs, les agents de programmation dotés d’IA peuvent réaliser une grande partie d’une modification logicielle tout en échouant à fournir un résultat pleinement fonctionnel. Le test a montré que même le système le plus performant n’achevait toutes les parties requises d’une tâche que dans 26,4 % des cas. Une intervention humaine restait donc nécessaire pour près de trois missions sur quatre.

Le benchmark, baptisé Co-Design Bench, a été élaboré par des chercheurs d’Alibaba et de plusieurs universités asiatiques. Comme le rapporte The Decoder, il évalue les agents sur des modifications apportées à des applications web existantes plutôt que sur des problèmes de programmation isolés. Les tâches peuvent inclure des références visuelles, de l’audio, de la vidéo et des documents, reflétant les entrées mixtes que les équipes produit et ingénierie fournissent de plus en plus aux outils d’IA.

Un test plus exigeant pour les agents de programmation

Co-Design Bench vise à répondre à ce que ses chercheurs décrivent comme la saturation des évaluations de programmation établies. Lorsque les modèles peuvent exécuter, inspecter et réparer leur propre code, ils peuvent dépasser 99 % dans certains anciens benchmarks, laissant peu de marge pour distinguer les systèmes.

Le nouveau test s’appuie au contraire sur des demandes issues de véritables sessions de programmation. Les chercheurs ont sélectionné des cas dans lesquels les utilisateurs avaient déjà dû reformuler leurs demandes ou annuler des modifications infructueuses. Ces cas vont de tâches relativement ciblées, comme extraire un montant d’un reçu et mettre à jour les totaux associés, à des refontes plus larges d’applications.

Cette conception rend le benchmark moins représentatif d’un exercice de programmation propre et autonome, et davantage représentatif du travail désordonné qu’implique la maintenance d’un produit en production. Elle signifie également que les résultats ne doivent pas être considérés comme une mesure universelle de tous les flux de travail de programmation. Ils mettent toutefois en évidence l’écart entre la production d’un code plausible et l’exécution complète de la demande d’un utilisateur.

Les éléments derrière le résultat de 26,4 %

Selon l’article décrit par The Decoder, GPT-6 Astra a été le modèle le plus performant parmi les dix testés. Il a satisfait en moyenne environ 70 % des exigences des tâches, mais n’en a résolu entièrement que 26,4 %. Une tâche n’était considérée comme terminée que lorsque toutes les fonctionnalités requises fonctionnaient dans l’application.

Claude Opus 5 et Qwen3.8-Max suivaient GPT-6 Astra dans le classement publié, tandis que Grok 4.6 occupait la dernière place. Pour les refontes d’applications plus importantes, le modèle plus petit Qwen3.8-27B est monté à la deuxième place, sans que les chercheurs considèrent ce résultat comme la preuve d’un avantage général du modèle.

Le processus d’évaluation était également plus strict qu’une simple revue de code. Un évaluateur automatisé testait l’application terminée dans un navigateur, tandis qu’un second examinateur vérifiait les résultats positifs et recherchait des maquettes visuelles, des sorties codées en dur ou d’autres raccourcis pouvant donner l’impression qu’une demande était satisfaite sans que le comportement sous-jacent soit réellement implémenté.

Il s’agit de résultats de recherche, et non de mesures d’adoption ou de productivité vérifiées indépendamment. Les auteurs du benchmark reconnaissent que leurs évaluateurs automatisés peuvent se tromper, et les tâches utilisent une demande unique et fixe plutôt qu’une conversation en direct au cours de laquelle un utilisateur pourrait répondre à des questions ou corriger un agent pendant son travail. Les résultats montrent donc où les agents ont rencontré des difficultés dans ce cadre de test, et non la quantité exacte de travail humain requise dans chaque environnement de production.

Le modèle n’est qu’une partie du système

L’une des principales conclusions du benchmark concerne le harness de l’agent : l’environnement logiciel qui permet à un modèle de lire des fichiers, de modifier du code, d’exécuter des applications et d’inspecter les résultats. Dans une comparaison distincte, Qwen3.8-27B a obtenu 75 % sur les grandes refontes avec un harness, mais seulement 56 % avec un autre. Le classement relatif de deux modèles changeait également selon l’environnement.

Ce résultat remet en question la pratique consistant à comparer les agents de programmation uniquement au moyen de classements de modèles. Les performances d’un modèle dépendent des outils qu’il peut appeler, du contexte qu’il reçoit, de sa manière d’observer le comportement du navigateur et de son efficacité à se remettre d’une modification incorrecte. Pour les acheteurs qui évaluent un assistant de programmation IA, l’unité de comparaison pratique est donc la combinaison du modèle et du harness.

L’étude a également constaté que l’augmentation des ressources de calcul ne réduisait pas systématiquement l’écart. GLM-5.2 a utilisé près de six fois plus de tokens que GPT-6 Astra sur les petites modifications, tout en obtenant un score nettement inférieur. Un raisonnement plus approfondi ou une exécution plus longue peuvent aider pour certaines tâches, mais le résultat suggère qu’une utilisation accrue des tokens ne remplace pas une meilleure décomposition des tâches, des tests et une interaction plus efficace avec l’application.

Ce que ces résultats signifient pour les développeurs et les entreprises

Pour les équipes d’ingénierie, la conclusion immédiate est que les agents de programmation IA restent surtout utiles comme partenaires d’implémentation supervisés, plutôt que comme responsables autonomes des modifications produit. Un agent peut créer l’essentiel d’une fonctionnalité, mais les équipes doivent toujours vérifier les cas limites, la fidélité visuelle, la gestion des données et les interactions entre exigences.

Le risque est particulièrement élevé pour les tâches qui combinent des modifications de mise en page, de design, d’interaction et de contenu. Le benchmark a montré que les performances diminuaient pour tous les modèles à mesure que davantage de types de modifications étaient combinés, alors même que ces exigences imbriquées sont courantes dans le travail produit réel. Un flux de travail qui traite chaque demande comme un seul prompt peut donc produire une implémentation partielle convaincante tout en laissant d’importants détails inachevés.

Les équipes qui évaluent des outils devraient les tester sur des tâches internes représentatives, notamment des modifications de bases de code et d’applications existantes, plutôt que sur des exemples de projets entièrement nouveaux uniquement. Elles devraient mesurer l’acceptation complète, les taux de régression, le temps de revue et la fréquence des corrections manuelles. Cela complète des évaluations établies comme SWE-bench Verified, mais ne doit remplacer ni la revue humaine ni les mesures de sécurité lors du déploiement.

Ces résultats concernent également les développeurs de plateformes d’agents. Une meilleure inspection du navigateur, un suivi plus clair de l’état, une restauration fiable et une validation plus robuste pourraient améliorer les résultats autant qu’un modèle sous-jacent plus grand. Le résultat relatif au harness indique que les équipes produit devraient évaluer l’ensemble du flux de travail, notamment les permissions, la fiabilité des outils, l’observabilité et la récupération après erreur.

Les prochaines évolutions à surveiller

Le prochain signal utile sera de voir si Co-Design Bench ou des évaluations similaires s’étendent au-delà des demandes fixes en une seule étape. Le véritable travail logiciel implique des clarifications, des exigences changeantes et des retours d’utilisateurs ou de responsables de projet. Des versions interactives du test pourraient donc donner une image différente de l’utilité des agents.

Les chercheurs et les acheteurs devraient également surveiller les résultats qui présentent le modèle et le harness ensemble, plutôt que de publier un classement unique des modèles. Une réplication indépendante aiderait à déterminer si le classement annoncé et les importants effets liés à l’environnement persistent à travers différents dépôts de code et types d’applications.

Enfin, les taux d’acceptation dans les équipes d’ingénierie réelles resteront plus significatifs que le seul taux de réussite des benchmarks. The Decoder a cité des recherches antérieures de METR montrant que les responsables de projet acceptaient le code généré par l’IA à un taux inférieur d’environ 24 points de pourcentage aux scores obtenus sur SWE-bench Verified. Cet écart rappelle que la réussite apparente d’une tâche ne se traduit pas automatiquement par un logiciel prêt à être déployé.

Le point de vue de Creati.ai

Co-Design Bench est important parce qu’il mesure la dernière étape du travail des agents de programmation : non pas la capacité d’un agent à produire du code, mais le fait que la modification produit demandée fonctionne réellement dans toute l’application. Son taux de réussite complète de 26,4 % rappelle que l’automatisation partielle peut encore créer d’importantes obligations de revue et de réparation.

Pour les concepteurs d’IA et les acheteurs en entreprise, la leçon pratique est de cesser de considérer le modèle comme le produit dans son ensemble. Une exécution fiable dépendra de la combinaison du modèle, du harness, des tests, du contexte applicatif et de l’approbation humaine. Tant que ces composants ne seront pas évalués ensemble sur des tâches réalistes, les affirmations sur le développement logiciel autonome devront être considérées avec prudence.