Ce qui s’est passé.

Deux papers publiés en juillet proposent des benchmarks qui mesurent les coding agents sur ce qu’ils font vraiment en 2026 : prendre une intention vague et construire un projet fonctionnel dessus. ICAE-Bench (480 tâches, 12 langages) simule un utilisateur qui confie à l’agent une demande de produit incomplète, évaluant la planification, la clarification des requirements, le débogage et l’intégration au niveau du repository. Tencent WorkBuddy Bench construit des tâches rétro-ingéniérées à partir de commits et pull requests réels, sur quatre domaines : code, web, office, sécurité.

Pourquoi ça te concerne.

Si tu utilises Claude Code ou Codex, tu sais que la partie difficile n’est plus de leur faire écrire une fonction. La partie difficile est de leur expliquer ce que tu veux quand toi-même tu ne le sais pas encore vraiment. Les benchmarks traditionnels comme SWE-bench, comme nous l’expliquions dans le guide du paper qui a défini le domaine, donnent à l’agent une issue GitHub avec des instructions précises et mesurent s’il la résout. ICAE-Bench et WorkBuddy partent d’une hypothèse différente : l’input est flou, l’agent doit poser des questions, prendre des décisions de design, gérer des contraintes cachées.

Les résultats d’ICAE-Bench le disent clairement : les agents reproduisent le comportement visible mais peinent sur les contraintes cachées, les cas limites et l’intégration sur des horizons longs. C’est exactement le point où ton travail de contexte et de vérification fait la différence entre un prototype qui fonctionne et un logiciel qui tient.

En détail

Le changement de paradigme est net. SWE-bench, le benchmark qui a défini comment nous mesurons les coding agents jusqu’à présent, part d’issues GitHub avec des descriptions déjà précises : il y a un bug, une feature demandée, l’agent doit produire un patch qui passe les tests. C’est un modèle qui correspond au travail d’un programmeur qui reçoit un ticket bien écrit.

Le vibe-coding, le terme par lequel s’est répandu l’utilisation d’agents qui construisent des logiciels à partir de descriptions informelles, a déplacé le centre de gravité. Ceux qui utilisent Claude Code ou Codex n’écrivent plus de spécifications complètes : ils jettent une idée, l’agent pose des questions, ils itèrent. Les benchmarks devaient s’adapter.

ICAE-Bench affronte le problème avec une architecture intéressante. Chaque tâche dérive d’un repository open-source réel avec un comportement exécutable vérifié. L’ambiguïté n’est pas inventée : elle vient de la différence entre ce qu’un utilisateur demanderait avec des mots et ce que le code doit vraiment faire. Un User Agent automatique simule la contrepartie humaine, révélant les contraintes cachées au fur et à mesure que l’agent pose des questions, sans inventer de nouveaux requirements ni laisser filtrer la solution. L’évaluation combine des tests black-box standardisés avec des diagnostiques multi-dimensionnels : exactitude fonctionnelle, similarité sémantique et API, fidélité structurelle, qualité du design, qualité de l’interaction.

Les résultats sur six modèles et deux frameworks agentiques montrent un pattern récurrent. Les agents réussissent à reproduire le comportement visible de l’application, mais échouent sur les contraintes cachées, les cas aux limites et l’intégration sur des horizons longs. La démo fonctionne, les détails non.

Tencent WorkBuddy Bench prend une direction différente pour le même objectif. Au lieu d’adapter des textes d’issues publiques, chaque tâche est reconstruite à rebours à partir d’un commit, d’une pull request ou d’un scénario réel d’entreprise, puis reformulée pour résister à la contamination (le risque que le modèle ait déjà vu la solution dans les données d’entraînement). Il couvre quatre domaines : code, web, office, sécurité. L’accent mis sur la contamination est pertinent : quand les benchmarks reposent sur des repositories publics, les plus grands modèles ont un avantage fallacieux parce qu’ils ont mémorisé le code pendant l’entraînement.

Qu’est-ce qui change pour ceux qui utilisent ces outils ? Deux choses pratiques. D’abord, quand tu lis un score de coding agent, vérifie ce qu’il mesure : un nombre élevé sur des tâches avec des spécifications précises te dit peu sur comment l’agent se débrouillera avec ta demande floue du vendredi après-midi. Deuxièmement, les points faibles que met en lumière ICAE-Bench (contraintes cachées, cas limites, intégration longue) sont exactement ceux où ton travail de clarification et de vérification par échantillonnage fait la différence entre livrer un prototype et livrer un logiciel utilisable.

Les limites des deux benchmarks doivent être déclarées. ICAE-Bench simule l’utilisateur avec un modèle, ce qui introduit la variabilité typique du LLM-as-a-judge : l’User Agent pourrait être plus ou moins collaboratif qu’un vrai humain. WorkBuddy est construit par une équipe Tencent et la documentation complète de la méthodologie se trouve dans le paper, mais le classement cross-model n’est pas encore public sous une forme vérifiable indépendamment.