Agents de code : pourquoi 26,4 % de réussite interpelle

Un agent de code peut satisfaire 69,9 % des critères d’une tâche et pourtant échouer à la terminer entièrement. C’est le résultat central de Co-Design Bench, un benchmark construit à partir de demandes réelles formulées par des développeurs. Même GPT-6 Astra, meilleur modèle évalué, ne valide intégralement que 26,4 % des missions testées. Co-Design Bench

Cette différence entre progression partielle et livraison fonctionnelle oblige l’industrie à revoir ses indicateurs. Un modèle qui produit du code plausible ne suffit pas : l’agent doit comprendre le contexte, modifier le bon environnement, préserver l’existant et satisfaire simultanément plusieurs exigences. Les entreprises qui évaluent uniquement le modèle risquent donc de choisir un outil performant en démonstration, mais fragile dans un dépôt réel.

26,4 % de tâches entièrement terminées, malgré 69,9 % des critères satisfaits

Le benchmark Co-Design Bench mesure un écart rarement visible dans les présentations commerciales : réussir une partie d’une tâche n’équivaut pas à la livrer. Le meilleur endpoint évalué atteint en moyenne 69,9 % des critères d’acceptation, mais ne satisfait complètement que 26,4 % des 273 tâches du test. Co-Design Bench

Les chercheurs ont sélectionné ces tâches à partir de 37 463 requêtes dédupliquées issues de 26 314 sessions de développement réelles. Le corpus ne cherche donc pas à mesurer la capacité d’un modèle à résoudre des exercices artificiels isolés, mais son aptitude à modifier des applications existantes à partir de demandes parfois incomplètes ou multimodales. Co-Design Bench

La distinction entre les deux mesures est déterminante pour les équipes techniques :

• Le taux de critères validés mesure la proportion des exigences respectées.
• Le taux de tâches entièrement réussies exige que toutes les conditions soient satisfaites.
• Une interface correcte, mais connectée au mauvais flux de données, reste un échec opérationnel.
• Une modification fonctionnelle qui casse une autre partie du dépôt ne constitue pas une livraison complète.

À retenir : un agent peut produire une amélioration convaincante tout en laissant une tâche inutilisable. Pour l’entreprise, le taux de réussite complète est plus proche de la valeur réellement livrée que la moyenne des critères satisfaits.

GPT-6 Astra arrive en tête de cette évaluation, mais son résultat ne transforme pas le benchmark en validation générale de l’autonomie des agents. Il montre plutôt que même le meilleur système testé conserve un écart important entre compréhension partielle et exécution de bout en bout. Co-Design Bench

Les demandes réelles exposent les limites des démonstrations contrôlées

Les agents de code sont souvent présentés sur des tâches courtes, bien délimitées et accompagnées d’un environnement préparé. Co-Design Bench teste une situation plus proche du travail quotidien : l’agent doit réviser une application existante à partir d’une demande utilisateur, avec plusieurs contraintes qui peuvent se chevaucher. Co-Design Bench

Le benchmark comporte deux pistes. La première, Multimodal Editing, évalue des modifications localisées avec des entrées pouvant inclure une image, un fichier audio, une vidéo ou un document. La seconde, Repository Editing, porte sur des changements coordonnés à l’échelle d’un dépôt. Co-Design Bench

Cette organisation reproduit une difficulté fréquente des projets logiciels : le code n’est pas produit dans le vide. Une demande peut concerner l’apparence d’une page, le comportement d’un composant, la gestion d’un fichier importé et la compatibilité avec une architecture existante. L’agent doit alors relier plusieurs formes d’information au lieu de répondre à une instruction purement textuelle.

Les performances se dégradent lorsque le nombre de types de changements augmente. Le benchmark indique que les dix endpoints évalués obtiennent de moins bons résultats sur les modifications de dépôt qui combinent trois ou quatre catégories de changements que sur celles qui n’en combinent qu’une ou deux. Co-Design Bench

Ce résultat explique pourquoi une tâche peut sembler simple à un utilisateur tout en devenant complexe pour un agent. « Ajouter un tableau de bord » peut impliquer la structure des données, le rendu visuel, les routes, les tests, les permissions et les états d’erreur. Chaque modification prise séparément peut être correcte, mais une incohérence entre deux couches suffit à faire échouer la livraison.

Le dépôt impose une mémoire du contexte

Dans un projet existant, l’agent doit identifier les conventions locales avant d’écrire du code. Il doit repérer les fichiers pertinents, comprendre les dépendances, interpréter les tests et éviter de remplacer une solution déjà utilisée ailleurs. Cette phase de recherche consomme du temps et augmente le risque d’erreur, surtout lorsque les noms de fichiers ou les abstractions internes sont peu explicites.

Le benchmark oppose ainsi deux compétences souvent confondues : générer une implémentation et naviguer dans un système logiciel. La première peut être excellente sur une fonction isolée. La seconde exige une représentation fiable de l’ensemble du projet, régulièrement mise à jour pendant l’exécution.

Le résultat dépend autant du cadre d’exécution que du modèle

Le classement des modèles change selon l’environnement utilisé pour les évaluer. Le benchmark montre que l’identité du meilleur système ne suffit donc pas à déterminer quel agent sera le plus efficace dans une entreprise. Le modèle, le harness agentique, les outils disponibles et les règles d’évaluation forment un ensemble indissociable. Co-Design Bench

Un harness agentique désigne ici le cadre qui orchestre les interactions du modèle avec le terminal, le navigateur, les fichiers, les tests et les autres outils. Deux modèles identiques peuvent obtenir des résultats différents si l’un dispose d’une meilleure stratégie de recherche, d’un accès plus fiable aux tests ou d’une boucle de correction plus efficace.

La comparaison doit donc intégrer plusieurs dimensions :

• La capacité du modèle à raisonner sur le code et les exigences.
• La qualité de la navigation dans les fichiers et les dépendances.
• La fiabilité des outils d’exécution et de vérification.
• La gestion des erreurs après un premier résultat incorrect.
• La qualité des critères utilisés pour déclarer une tâche terminée.

Un benchmark publié par Snowflake illustre cette évolution vers des tests plus proches des dépôts professionnels. SnowPR comprend 65 tâches correspondant à de véritables pull requests examinées et fusionnées par des ingénieurs de l’entreprise. 62 tâches proviennent d’un monorepo et trois d’un dépôt Go consacré aux outils de développement. Snowflake

Snowflake compare notamment SnowPR à SWE Atlas, présenté comme un benchmark de 284 tâches couvrant 11 projets et plusieurs langages, dont Go, TypeScript, Python et C. Le mode de validation combine des contrôles automatiques et une évaluation par checklist. Snowflake

Ces tests ne mesurent pas exactement la même chose et leurs scores ne sont pas directement interchangeables. Leur point commun est ailleurs : ils déplacent l’évaluation de la génération de code vers la résolution de tâches contextualisées.

Pourquoi le même modèle change de rang

Un agent peut exceller sur des modifications localisées et perdre beaucoup d’efficacité lorsqu’il doit coordonner plusieurs fichiers. Un autre peut être moins performant en génération brute, mais mieux exploiter le terminal, relancer les tests et corriger ses erreurs. Le classement dépend alors du parcours complet imposé par l’environnement.

La conséquence est pratique : une entreprise ne devrait pas sélectionner un agent à partir d’un score unique publié dans un tableau comparatif. Elle doit reproduire des tâches représentatives de son propre système, avec ses langages, ses outils de compilation, ses règles de revue et ses données de test.

GPT-6 Astra illustre la différence entre puissance générale et fiabilité opérationnelle

GPT-6 Astra obtient 26,4 % de réussite complète dans Co-Design Bench, 41 % sur la piste multimodale et un peu moins de 18 % sur les tâches liées aux dépôts. Ces résultats montrent un écart marqué entre les modifications multimodales et les révisions de projets existants. Co-Design Bench

La piste multimodale reste difficile, mais elle présente un taux de réussite supérieur à celui des dépôts. Cela peut s’expliquer par la portée plus localisée de certaines modifications : l’agent reçoit un élément visuel ou documentaire et doit appliquer un changement ciblé. À l’inverse, une révision de dépôt exige souvent de préserver des interactions entre plusieurs composants.

La performance sur les dépôts est le chiffre le plus important pour les équipes qui envisagent un agent comme assistant de maintenance. Un taux inférieur à 18 % sur ce type de tâche indique qu’une grande partie des missions nécessite encore une vérification et une reprise humaines avant intégration. Co-Design Bench

Cela ne signifie pas que l’agent est inutile. Un système qui satisfait une majorité de critères en moyenne peut accélérer l’exploration, préparer une première implémentation, proposer des tests ou réduire le temps passé sur des modifications répétitives. Mais son apport doit être mesuré sur le temps économisé après revue, correction et validation, pas uniquement sur la quantité de code produite.

OpenAI rapporte par ailleurs que GPT-6 Astra atteint un taux moyen de réussite aux tests de 87,4 % sur 20 langages dans MultiLangBench, contre 26,8 % pour GPT-5.6 Sol. Le modèle dépasse 83 % dans 19 des 20 langages évalués, tandis que COBOL atteint 72 %. OpenAI

Ces résultats sur des langages multiples montrent une capacité élevée à produire du code compatible avec des tests. Ils ne contredisent pas Co-Design Bench : les deux évaluations portent sur des problèmes différents. Passer des tests sur un ensemble de programmes ne garantit pas qu’un agent saura modifier correctement une application réelle, respecter toutes les exigences d’une demande et préserver le comportement existant.

La réussite complète devient le nouvel indicateur à surveiller

L’industrie des agents de code s’est longtemps appuyée sur des métriques faciles à comparer : taux de tests réussis, score sur SWE-bench, nombre de problèmes résolus ou quantité de code générée. Ces indicateurs restent utiles, mais ils ne décrivent pas toujours le coût d’une intervention incomplète.

Une équipe de développement doit distinguer plusieurs niveaux de résultat :

• Code généré : l’agent a produit une modification.
• Critères satisfaits : une partie des exigences est respectée.
• Tests réussis : certains comportements attendus sont validés.
• Tâche terminée : toutes les exigences et contraintes sont satisfaites.
• Changement intégrable : la revue humaine accepte la modification sans reprise majeure.

Co-Design Bench rend visible la distance entre le deuxième et le quatrième niveau. Avec 69,9 % des critères satisfaits en moyenne, GPT-6 Astra peut donner une impression de progression élevée. Avec 26,4 % de tâches entièrement terminées, le résultat devient beaucoup plus exigeant pour une organisation qui cherche à déléguer une mission complète. Co-Design Bench

La réussite complète est particulièrement utile pour calculer le coût de supervision, c’est-à-dire le temps consacré à relire, corriger, tester et relancer l’agent. Un outil qui produit rapidement une première version mais multiplie les corrections peut rester moins rentable qu’un assistant plus lent et plus fiable.

Le coût réel ne se limite pas au prix de l’API

Le prix d’un modèle constitue seulement une composante du coût total. Une entreprise doit aussi prendre en compte la durée d’exécution, les appels d’outils, les environnements isolés, les tests lancés et le temps d’un développeur chargé de contrôler le résultat.

À grande échelle, une baisse du tarif par requête ne compense pas forcément un faible taux de livraison complète. Si chaque tâche exige plusieurs relances ou une correction manuelle importante, l’organisation paie la génération initiale et la supervision supplémentaire.

Cette logique favorise les évaluations internes fondées sur des unités de travail concrètes : une issue clôturée, une pull request acceptée, un bug corrigé sans régression ou une migration validée. Le nombre de tokens consommés et la longueur de la réponse deviennent alors secondaires.

Les entreprises doivent tester l’agent sur leurs propres dépôts

Le benchmark général permet de situer les tendances du secteur, mais la décision d’achat doit reposer sur un échantillon représentatif du système de l’entreprise. Les résultats de Co-Design Bench et de SnowPR montrent que la nature du dépôt, les langages et le cadre d’exécution modifient fortement les performances. Co-Design BenchSnowflake

Un protocole interne efficace peut inclure des tâches déjà clôturées, anonymisées puis rejouées par plusieurs agents. Chaque mission doit être évaluée selon des critères vérifiables : tests, absence de régression, respect des conventions, sécurité, lisibilité et acceptation par un développeur.

Les équipes peuvent également répartir les tâches par niveau de risque :

• Corrections locales avec tests existants.
• Ajout de tests et petites évolutions d’API.
• Refactorings touchant plusieurs modules.
• Modifications d’interface avec entrées multimodales.
• Changements de schéma, de permissions ou de logique métier.

Cette segmentation évite de généraliser le résultat d’un agent à partir d’un seul type de mission. Un outil peut être très rentable pour les corrections locales et inadapté aux changements de logique métier. La bonne question n’est pas « quel est le meilleur agent ? », mais « quel agent termine le plus sûrement quelles tâches dans notre environnement ? »

Les garde-fous déterminent le niveau de confiance

L’agent ne devrait pas disposer du même degré d’autonomie pour une modification cosmétique et pour un changement de sécurité. Les droits d’accès, la possibilité de fusionner directement une pull request et l’obligation de passer des tests doivent dépendre du risque de la tâche.

Un déploiement progressif peut suivre plusieurs étapes :

• Suggestions de code dans un environnement local.
• Création de branches isolées.
• Exécution obligatoire des tests et des contrôles statiques.
• Revue humaine avant toute fusion.
• Autorisation limitée pour les tâches répétitives à faible risque.

Cette approche ne cherche pas à masquer les limites des agents. Elle les transforme en paramètres de fonctionnement mesurables. Le taux de réussite complète, le nombre de corrections et le temps de revue peuvent ensuite être suivis par équipe et par catégorie de tâche.

Notre avis : les agents de code accélèrent déjà, mais ne livrent pas encore seuls

Les chiffres de Co-Design Bench imposent une conclusion nette : l’efficacité d’un agent de code ne se mesure pas à sa capacité à produire une démonstration convaincante. GPT-6 Astra satisfait 69,9 % des critères en moyenne, mais seulement 26,4 % des tâches entièrement, avec un résultat inférieur à 18 % sur les révisions de dépôts. Co-Design Bench

Les agents sont donc déjà pertinents comme accélérateurs de recherche, de prototypage, de tests et de corrections ciblées. Ils ne justifient pas encore une délégation générale des tâches de développement sans contrôle humain, surtout lorsque plusieurs composants d’un dépôt doivent évoluer ensemble.

Dans les six prochains mois, l’avantage compétitif devrait moins dépendre du modèle seul que de la qualité de l’intégration : accès au contexte, orchestration des outils, jeux de tests, isolation des branches et mesure du temps de supervision. Les entreprises qui construiront cette boucle d’évaluation auront une vision plus fiable de la productivité réelle que celles qui compareront uniquement des scores publics.

La question décisive devient alors la suivante : quel agent saura transformer une demande réelle en changement intégrable, sans laisser au développeur le dernier quart du travail à refaire ?