A-CODE-LLM Bench: Benchmark de Codage Agentique

Nous avons évalué les meilleurs Large Language Models (LLMs) sur 10 tâches de développement logiciel à l'aide d'un outil CLI agentique. Nous avons exécuté environ 3,500 étapes de validation automatisées par modèle sur les couches API et UI.

Résultats du benchmark A-CODE-LLM

Chaque alias a été exécuté 3 fois sur 10 tâches (30 échantillons par alias, 400 cellules par itération pour 40 alias). Voir plus de détails sur la méthodologie.

• Sonnet milieu de gamme bat l'Opus phare. Les deux versions de Sonnet surpassent tous les Opus, y compris Opus 4.8 (0.702). Le niveau le plus cher d'Anthropic n'est pas son meilleur codeur.
• Le sommet n'est plus exclusivement Anthropic : Grok 4.5 (0.732) bat toutes les variantes d'Opus. Le nouveau modèle phare d'OpenAI, GPT 5.6 Sol, affiche le meilleur score de l'entreprise (0.615), toujours 0.157 en dessous de Sonnet 5, et ses variantes pro à calcul plus élevé se situent pour la plupart en dessous de leurs propres versions de base (Sol Pro 0.543, Terra Pro 0.568 ; seul Luna Pro s'améliore, 0.603 vs 0.579).
• Les spécialistes du code n'ont pas remporté le benchmark de codage. GPT 5.3 Codex, la variante d'OpenAI optimisée pour le code, obtient 0.572, au milieu du classement et en dessous du modèle généraliste d'OpenAI, GPT 5.4 Mini (0.594). Kimi K2.7 Code de Moonshot est le spécialiste le plus performant avec 0.611.
• Kimi K3, un modèle généraliste, prend la tête des modèles open-weights devant le spécialiste code de Moonshot : 0.725, sixième au classement général, 0.114 au-dessus de K2.7 Code. Son score backend de 0.632 le classe cinquième, devant tous les alias d'Opus et de GPT.
• Inkling, le premier modèle de Thinking Machines, fait ses débuts à 0.575, troisième parmi les modèles open-weights. Son score frontend de 0.747 bat tous les alias de GPT 5.6 ; le score backend de 0.501 limite son classement.
• Aucun modèle n'est fiable sur le backend : le plafond est de 0.701 (Sonnet 5), donc même le vainqueur échoue à environ un tiers des vérifications de logique métier et de contrat. Grok 4.5 s'en approche le plus parmi les ajouts de juillet avec 0.663. Le frontend est presque résolu chez les leaders (0.79 à 0.96), le backend est donc le problème ouvert, et c'est lui qui détermine le classement. Claude Haiku 4.5 s'affiche correctement (0.731), mais un backend à 0.277 le maintient à 0.413.
• Le point faible de GPT est le frontend. GPT 5.4 et 5.5 égalent Opus 4.8 sur le backend (environ 0.6) mais obtiennent 0.53 à 0.55 sur le frontend ; la famille GPT 5.6 fait monter cela à 0.63-0.71, toujours bien en dessous des 0.91 et plus de la lignée Sonnet.

Comparaison coût & réussite

• Les modèles au prix flagship offrent le pire rapport qualité-prix. Opus 4.7 est le plus cher ($3.08/cellule) et obtient 0.610, en dessous de Sonnet 4.6 à $1.33.
• Le meilleur facture une forte prime pour un gain minime : Sonnet 5 obtient 0.024 de plus que Sonnet 4.6 pour un coût par cellule supérieur de 70%.
• Grok 4.5 est le nouveau meilleur rapport qualité-prix : 0.732, à 0.040 du vainqueur, à $0.46 par cellule, contre $2.23 pour Sonnet 5. Dans la famille GPT 5.6, le prix n'achète rien : de $0.18 (Luna) à $2.76 (Sol Pro) par cellule pour des scores entre 0.543 et 0.615, l'alias le moins cher surpassant le plus cher.
• Kimi K3 obtient son score de sixième place à un prix intermédiaire : $1.47 par cellule, proche des $1.33 de Sonnet 4.6 mais avec un score supérieur de 0.007, et bien en dessous des $2.23 de Sonnet 5. Inkling coûte $1.64 par cellule au prix catalogue pour 0.575, plus cher que Sonnet 4.6 pour un score inférieur.

Comparaison temps de réalisation & réussite

• Le meilleur score est parmi les plus lents. Sonnet 5 prend environ 30 minutes par tâche, soit 3x plus que Sonnet 4.6 pour 0.024 de plus ; Sonnet 4.6 donne presque le même score en un tiers du temps.
• Une longue exécution signale généralement un modèle bloqué, pas un modèle minutieux : les moins bons scores, les deux variantes Qwen, GLM 5.1 base et Deepseek V4 Pro, ont chacun dépassé 1,700 secondes à cause de la sur-itération pour des scores inférieurs à 0.45.
• Grok 4.3 était rapide parce qu'il abandonnait tôt : 142 secondes et 18 appels d'outils pour 0.431. Grok 4.5 conserve la vitesse et cesse d'abandonner : environ 9 minutes par tâche, moins d'un tiers du temps de Sonnet 5, pour 0.732.
• Kimi K3 se situe à l'opposé : score de premier plan, pire vitesse. Il prend en moyenne environ 55 minutes par tâche, le plus lent du lot et environ le double de Sonnet 5, pour une sixième place à 0.725. Sa précision est réelle, mais c'est la voie la moins pratique vers le premier plan.

Appels d'outils par tâche

• Le nombre d'appels d'outils ne mesure ni la capacité ni l'effort que l'on peut comparer. Sonnet 5 a effectué le plus d'appels (125) et a obtenu le meilleur score ; MiniMax M3 en a effectué 108 pour un score moyen de 0.583 ; Grok 4.5 a atteint 0.732 avec 40 appels ; les chiffres bas d'OpenAI, 16 à 36, proviennent de apply_patch qui regroupe un fichier entier en un seul appel. Sol Pro et Terra Pro appellent un quart à un tiers d'outils en moins que leurs versions de base et obtiennent un score inférieur : plus de raisonnement, moins d'exécution. Ne classez pas les agents par volume d'outils.
• Deux chemins mènent au même score : Sonnet 5 itère lourdement (125 appels), Sonnet 4.6 à peine (environ 50), 0.024 d'écart.

Performance des LLM sur une tâche unique réussie

Aucun modèle n'a réussi chaque étape du benchmark complet ci-dessus. Pour comparer le coût et la vitesse sur un pied d'égalité, nous avons exécuté une tâche de référence simple que chaque modèle peut accomplir : quatre endpoints CRUD, validation de base, sans authentification ni base de données.

Comparaison coût & lignes de code

• Les tâches simples ne peuvent pas classer les modèles, les évaluations jouets sont donc trompeuses. Sur la référence que chaque modèle réussit, le code converge vers 40 à 64 lignes, et le coût tombe à quelques centimes ; les différences n'apparaissent que sur des travaux longs et multi-fichiers.
• Le niveau « rapide et léger » était le plus cher ici : Gemini 3.5 Flash base a écrit 131 lignes pour la tâche triviale, deux à trois fois plus que les autres, ce qui en fait la référence la plus chère, à l'encontre de son propre positionnement.
• L'itération lourde de Sonnet 5 est dictée par la tâche, pas une habitude : 9 appels et $0.09 ici contre 125 appels sur le benchmark.

Voir plus de détails dans l'article sur la tarification des LLM.

Temps d'exécution & utilisation de tokens

• La prévisibilité des coûts divise les modèles en deux. Les modèles adaptatifs ne dépensent que lorsque c'est nécessaire (Opus 4.8 : 34s en référence, 1,072s sur le benchmark) ; les modèles à rythme fixe sont lents et coûteux même sur des travaux triviaux (MiniMax M3 : 475 vs 1,684s).
• La longueur de sortie est un trait fixe du modèle, variant de près de 10x pour la même tâche (787 à 7,508 tokens), ce qui alimente directement le coût.

Qu'est-ce que les systèmes LLM agentiques ?

Construire un logiciel est itératif : écrire du code, l'exécuter, lire les erreurs, les corriger, recommencer. Les systèmes d'IA agentique permettent aux LLM de suivre ce même cycle. Le modèle opère dans un environnement de développement où il peut écrire des fichiers, exécuter des commandes, lire les sorties et apporter des modifications en fonction de ce qu'il voit, jusqu'à ce que la tâche soit terminée.

C'est important parce que les vraies applications ne sont pas des fichiers uniques. Elles ont des backends avec des routes et des modèles de base de données, des frontends avec des composants et des appels API, des fichiers de configuration, des dépendances et des tests. Faire fonctionner tout cela ensemble nécessite des tests et des améliorations itératives, ce que permet précisément l'architecture agentique.

Comment ça fonctionne

Le modèle se trouve dans un harnais avec accès à un shell, un système de fichiers et la sortie d'exécution. Lorsqu'on lui demande de construire une application, il écrit des fichiers de manière incrémentale. Après chaque étape, le harnais montre au modèle ce qui s'est passé : le serveur a-t-il démarré, les tests ont-ils réussi, le linter a-t-il signalé des erreurs ? Sur la base de ce retour, le modèle décide quoi écrire ou corriger ensuite.

Cela diffère fondamentalement de la génération en une seule passe. Dans les configurations one-shot, le modèle génère une base de code entière à l'aveugle, sans aucun moyen de vérifier si elle fonctionne. Dans les systèmes LLM agentiques, le modèle voit les conséquences de chaque action et corrige sa trajectoire. Cependant, cette capacité seule ne suffit pas. Le modèle a encore besoin d'un raisonnement solide pour implémenter correctement la logique métier, et c'est là que les différences de performance émergent vraiment.

Découvrez davantage de nos benchmarks et analyses basées sur les données dans la recherche Google.

Ajouter comme source préférée

Méthodologie du benchmark LLM agentique

Nous avons utilisé Opencode comme harnais d'agent pour tous les modèles et les avons connectés via OpenRouter, à deux exceptions près : Claude Fable 5 a été exécuté sur le CLI Claude Code avec l'abonnement Claude, et Inkling a été exécuté via l'API compatible OpenAI de Thinking Machines car le modèle n'est pas disponible sur OpenRouter. Chaque cellule a été exécutée 3 fois pour mesurer la variance par cellule et stabiliser le classement. Nous avons évalué leur capacité à travailler de manière autonome sur 10 tâches de développement logiciel (T-1 à T-10), allant des systèmes de réservation aux tableaux de bord interactifs. Ces tâches exigent que les agents gèrent des projets multi-fichiers et livrent des produits fonctionnels. Les sept alias ajoutés en juillet 2026 (Grok 4.5 et la famille GPT 5.6 : Sol, Terra, Luna, chacun en mode base et pro) ont été exécutés sur Opencode 1.15.13 avec les paramètres API par défaut, comme tous les modèles ici ; les chiffres de lancement d'OpenAI pour Sol utilisent des modes de calcul plus élevés.¹ Quatre cellules Sol Pro et une cellule Terra Pro se sont terminées par des échecs silencieux répétés du flux API plutôt que par des erreurs du modèle et sont comptées comme des échecs.

Kimi K3 et Inkling ont été ajoutés le 18 juillet avec les paramètres API par défaut ; Inkling a été exécuté avec son effort de réflexion par défaut de 0.9. La colonne de coût d'Inkling utilise les prix catalogue de Thinking Machines de $3.74 par million de tokens d'entrée et $9.36 par million de tokens de sortie ; le fournisseur a facturé environ la moitié dans le cadre d'une réduction de lancement temporaire.² Les deux modèles ont été exécutés avec une limite de 150 minutes par cellule au lieu des 45 minutes précédentes, car le flux de tokens de Kimi K3 est suffisamment lent pour atteindre la limite plus courte en cours de construction ; le temps d'exécution est rapporté séparément dans le graphique de temps. La capacité partagée en amont de Kimi K3 a retourné de fréquentes erreurs de limite de débit et de timeout pendant la fenêtre d'exécution ; les cellules affectées ont été réexécutées une fois avec la même limite, la même politique étant appliquée aux échecs de flux de Sol Pro et Terra Pro ci-dessus.

Exécution et orchestration

Chaque agent et chaque tâche démarre dans un environnement propre. Les instructions sont fournies sous forme de fichier TASK.md, et nous utilisons un chien de garde de 20 minutes pour les scripts de lancement. Pendant cette phase, nous enregistrons les codes de sortie, le temps d'exécution et si les fichiers backend et frontend ont été créés. Nous suivons également l'utilisation des tokens en temps réel dans les catégories d'entrée, de sortie et de cache.

Validation backend : Nous déployons les projets générés dans des environnements isolés pour les tester par rapport à un contrat YAML canonique. La validation couvre les scénarios de chemin nominal, la gestion des erreurs (400/403/409) et la cohérence des données.

Nous testons les résultats en deux modes :

Le mode adaptatif valide la fonctionnalité même avec des noms de route différents, tandis que le mode strict exige une conformité exacte au contrat.

Le score global du backend est calculé par cellule comme suit :

backend_overall = has_backend × (0.7 × adaptive_pass_rate + 0.3 × strict_pass_rate)

où has_backend vaut 1 si la cellule a produit un projet backend, 0 sinon. Le mode adaptatif a un poids plus élevé car il mesure la correction comportementale ; le mode strict ajoute une pénalité pour les dérives contractuelles (routes renommées, codes de statut substitués, champs de réponse restructurés).

Tests UI et scénarios utilisateur

Nous utilisons l'automatisation de navigateur pour simuler des flux utilisateur réels, y compris les preflights, le rendu et l'authentification. Nous vérifions les étapes fonctionnelles telles que la soumission de connexion et le comportement post-connexion pour garantir que l'application s'exécute sans plantage.

La notation UI divise huit étapes en deux groupes. Les étapes d'infrastructure (preflight backend, rendu frontend, formulaire de connexion visible, soumission de connexion, connexion 2xx, pas de crash d'exécution) mesurent si l'application fonctionne tout court. Les étapes de comportement (signal d'authentification post-connexion, signal de comportement post-connexion) évaluent si l'application remplit sa fonction prévue une fois qu'elle est opérationnelle.

ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)

Les étapes de comportement bloquées sont exclues du dénominateur de comportement, afin qu'une cellule ne soit pas doublement pénalisée lorsque l'application ne parvient pas à se charger.

Calcul des tokens

Le nombre de tokens est extrait de la réponse API du LLM. Nous soustrayons les tokens d'entrée en cache du total des tokens d'entrée pour obtenir l'entrée effective, qui reflète uniquement les tokens nouvellement traités. Les tokens de sortie ne sont jamais mis en cache, ils restent donc inchangés.

Agrégation finale

Le score final du benchmark est calculé en combinant les résultats des phases précédentes : Final Score = (0.7 × backend_overall) + (0.3 × ui_score) Nous attribuons un poids plus élevé au backend car les échecs de logique au niveau de l'API invalident souvent tout succès dans le frontend.

Exemple de tâche

Tâche 6 : Système de tickets de helpdesk

La tâche 6 se concentre sur le développement d'un écosystème complexe de support client. L'objectif principal est de construire une plateforme qui assure la médiation de la communication entre les clients et les agents de support tout en appliquant strictement les règles métier et les limites de sécurité. Cette tâche évalue la capacité d'un agent à gérer des machines d'état multi-utilisateurs, l'isolation des données et la communication par fils au sein d'un environnement full-stack.

La tâche exigeait la construction d'un système de helpdesk comprenant :

• Des permissions distinctes pour les Clients (émission/réponse) et les Agents (gestion/résolution).
• Un workflow de statut rigide qui empêche les transitions illégales et applique des actions spécifiques au rôle.
• Une isolation avancée des données où les demandes de ressources non autorisées retournent 404 au lieu de 403 pour protéger l'intégrité du système.
• Un système de réponse chronologique pour une interaction fluide agent-client.
• Un backend FastAPI combiné à un frontend réactif basé sur Vite (React/Vue/Svelte).
• Une configuration reproductible via des commandes shell spécifiques pour une activation immédiate du système.

Vous pouvez consulter la documentation de la Tâche 6 sur GitHub.

Citez ce benchmark

Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.

@misc{kalelioglu2026,
  author = {Kalelioğlu, Berk and Dilmegani, Cem},
  title  = {{A-CODE-LLM Bench: Benchmark de Codage Agentique}},
  year   = {2026},
  month  = jul,
  howpublished    = {\url{https://aimultiple.com/agentic-llm}},
  note   = {AIMultiple. Consulté le 23 Juillet 2026}
}

Liens de référence

1.

GPT-5.6: Frontier intelligence that scales with your ambition | OpenAI

2.

Inkling: Our Open-Weights Model - Thinking Machines Lab

Berk Kalelioğlu

Chercheur en IA

Suivre

Berk est chercheur en IA chez AIMultiple, se concentrant sur les systèmes d'IA agentique et les language models.

Voir le profil complet

Examiné techniquement par

Cem Dilmegani

Analyste principal

Suivre

Cem est analyste principal chez AIMultiple depuis 2017. AIMultiple informe chaque mois des centaines de milliers d'entreprises (selon similarWeb), dont 55 % des entreprises du classement Fortune 500. Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes et le Washington Post, ainsi que par des entreprises mondiales comme Deloitte et HPE, des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne. Vous trouverez d'autres entreprises et ressources réputées ayant fait référence à AIMultiple. Tout au long de sa carrière, Cem a exercé les fonctions de consultant, d'acheteur et d'entrepreneur dans le secteur des technologies. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus de dix ans. Il a également publié un rapport McKinsey sur la numérisation. Il a dirigé la stratégie technologique et les achats d'un opérateur télécom, sous la responsabilité directe du PDG. Il a également piloté la croissance commerciale de la société de deep tech Hypatos, qui a atteint un chiffre d'affaires annuel récurrent à sept chiffres et une valorisation à neuf chiffres en seulement deux ans. Les travaux de Cem chez Hypatos ont été présentés dans des publications technologiques de référence telles que TechCrunch et Business Insider. Cem intervient régulièrement lors de conférences internationales sur les technologies. Diplômé en génie informatique de l'université de Bogazici, il est également titulaire d'un MBA de la Columbia Business School.

Voir le profil complet

Soyez le premier à commenter

Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.

Nom

Adresse email

Commentaire

0/450

Publier un commentaire