Nouveau benchmark d'Alibaba : les agents IA remplissent une partie des exigences, mais pas la tâche entière

Alibaba, avec l'Université chinoise de Hong Kong, l'Université Jiao-tong de Shanghai et l'Université technologique de Nanyang, a présenté Co-Design Bench. Il s'agit d'un ensemble de tâches pour les agents IA qui écrivent du code. Les modèles sont évalués sur ce que les utilisateurs demandent réellement : prendre une application web déjà fonctionnelle et la modifier d'après une description, parfois accompagnée d'une capture d'écran, d'un enregistrement vocal, d'une vidéo ou d'un document. Voici le bilan pour les dix modèles testés. Le meilleur remplit une part notable des exigences en moyenne par tâche, mais ne résout entièrement qu'une part moindre des tâches. Il traite les points un à un, mais ne parvient pas à tout assembler.

Des tâches issues de vraies sessions, pas de données synthétiques

De nombreux tests pour agents de code sont construits artificiellement : on casse une page de référence et on demande de la réparer, ou on fournit un ensemble de modifications prédéfini. Les auteurs de Co-Design Bench ont pris une autre voie. Ils ont repris des requêtes issues de sessions réelles d'utilisateurs, supprimé les doublons et conservé celles où il y a quelque chose à vérifier. Pour chaque tâche, ils ont reconstitué l'application exécutable « avant modification », ainsi que l'historique de la session et les pièces jointes.

Le test comporte deux volets :

• Multimodal Editing (ME) — modifications locales : mise en forme, structure, contenu. L'agent dispose d'une page, d'une zone sélectionnée et d'une requête, parfois accompagnée d'une image, d'un audio, d'une vidéo ou d'un document. Exemple : un reçu indique un montant, qu'il faut mettre à jour de façon cohérente dans le tableau et dans les récapitulatifs finaux. • Repository Editing (RE) — changements cohérents dans un dépôt frontend : composants, routes, état, flux de données. Exemple : un éditeur de clips vidéo sportifs, où il faut limiter le nombre et la durée des clips, aligner la timeline lors du zoom et réactiver l'insertion après la suppression ou la découpe d'un clip.

Les tâches sont évaluées selon trois axes : compréhension du contexte (Grounded Understanding), transformation de l'interface (UI Transformation) et implémentation des fonctions (Functional Implementation).

Avant d'entrer dans le jeu de tâches, l'application doit se compiler, se lancer dans un conteneur et s'afficher dans Playwright (outil d'automatisation du navigateur). Les tâches qui nécessitent des services externes inaccessibles ont été exclues. Les requêtes ont été classées selon leur difficulté, leur vérifiabilité et des signes d'échecs passés, comme les reformulations et les retours en arrière. Des experts ont ensuite ramené les requêtes à une formulation claire et rédigé des critères d'acceptation cachés.

Comment vérifier sans code de référence

La tâche n'a pas de solution de référence, car une même modification peut se faire de plusieurs façons. Les critères décrivent donc le résultat : ce qui doit apparaître et comment cela doit se comporter. Ils ne dictent pas l'implémentation. La comparaison avec l'application d'origine aide à comprendre ce qui a changé et ce qu'il fallait conserver.

La vérification se déroule en plusieurs étapes :

• D'abord, un agent évaluateur examine l'application finale : le diff des sources, les pages rendues et les actions enregistrées dans le navigateur. Un gestionnaire d'événements dans le code ne prouve rien si l'utilisateur ne peut pas l'atteindre via l'interface. • Ensuite, un vérificateur LLM distinct reçoit les verdicts et les preuves collectées, et tente de les réfuter.

Il recherche les bouchons, les réponses codées en dur, les points d'entrée inaccessibles, les défaillances avec d'autres données d'entrée et les écarts par rapport à la requête. • Un audit obligatoire exige un rendu réussi et des captures d'écran pour les affirmations visuelles, ainsi que des journaux d'actions dans le navigateur pour les affirmations interactives. En l'absence de preuves, l'évaluation est interrompue avant même le calcul des points.

Tous les verdicts et journaux sont conservés, de sorte que chaque évaluation peut être retracée jusqu'aux preuves. Deux experts frontend ont en outre vérifié manuellement une partie des évaluations. Les auteurs reconnaissent honnêtement que cela n'élimine pas complètement les erreurs des juges.

Ce que montrent les dix modèles

Dix endpoints de modèles ont été exécutés dans un même harnais agentique : l'agent peut consulter le code, modifier des fichiers, compiler et lancer l'application. Plusieurs conclusions ressortent des résultats.

• La part de critères remplis et la part de tâches entièrement résolues divergent nettement. Un utilisateur dont la demande est réalisée en grande partie se retrouve malgré tout avec un scénario qui ne fonctionne pas. • Le classement des modèles diffère d'un volet à l'autre : le meilleur sur les modifications locales n'est pas forcément le meilleur sur les modifications de dépôt. • Chez les dix modèles, l'exhaustivité de l'exécution est moins bonne sur les tâches de dépôt comportant trois ou quatre types de changements (structure, style, interactivité, contenu) que sur celles qui en comportent un ou deux.

Les auteurs montrent par ailleurs que le mode de fonctionnement modifie l'évaluation. Sur les tâches WebCompass-edit, le passage d'une tentative unique à un mode agentique avec outils a sensiblement relevé la part moyenne de fonctions réalisées, alors que la grille, le juge et le rendu n'ont pas changé. Les chiffres issus de tests utilisant des modes différents ne peuvent donc pas être comparés directement.

Les auteurs situent Co-Design Bench par rapport à d'autres benchmarks. Design2Code, WebSight-Test et WebRenderBench évaluent la conversion d'une capture d'écran en code. IWR-Bench ajoute la vidéo d'interaction. WebGen-Bench et FrontendBench testent des sites créés de zéro. DesignBench, MT-Web2Code, WebCompass et FronTalk portent sur les modifications et le dialogue. SWE-bench, SWE-bench Multimodal et SWE-Lancer tirent leurs tâches de GitHub et du freelancing. La nouveauté de Co-Design Bench tient à la combinaison de sessions réelles, de pièces jointes multimodales, d'un état source exécutable, d'une vérification sans référence et d'un vérificateur adverse.

Pour les équipes qui déploient des agents de code, la conclusion est pratique. La métrique « pourcentage de points validés » surestime le niveau de préparation : il vaut mieux mesurer la part de tâches closes entièrement et examiner séparément les modifications complexes à composantes multiples. Pour contrôler du code produit par IA, il est utile d'exiger des preuves comme des captures d'écran et des enregistrements d'actions dans le navigateur. Du code dans un diff ne prouve pas qu'une fonction marche.