A-CODE-LLM Bench: Benchmark de codage agentique
Nous avons évalué les meilleurs grands modèles de langage (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 à la fois 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 le produit phare Opus. Les deux versions de Sonnet surpassent chaque 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 réservé à Anthropic : Grok 4.5 (0.732) bat toutes les variantes d'Opus. Le nouveau produit 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 bases (Sol Pro 0.543, Terra Pro 0.568 ; seule Luna Pro s'améliore, 0.603 contre 0.579).
- Les spécialistes du code n'ont pas remporté le benchmark de codage. GPT 5.3 Codex, la variante optimisée pour le code d’OpenAI, obtient 0.572, se classant au milieu du peloton 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 poids ouverts 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 place cinquième, devant tous les alias Opus et GPT.
- Inkling, le premier modèle de Thinking Machines, débute à 0.575, troisième parmi les poids ouverts. Son frontend à 0.747 bat tous les alias GPT 5.6 ; le backend à 0.501 plafonne son classement.
- Aucun modèle n'est fiable sur le backend : le plafond est 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), donc le backend reste le problème ouvert, et c'est lui qui détermine le classement. Claude Haiku 4.5 affiche un bon rendu (0.731), mais un backend à 0.277 le cantonne à 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 remonte ce score à 0.63–0.71, encore loin des 0.91 et plus de la lignée Sonnet.
Comparaison coût / réussite
- Les modèles au prix flagship sont les moins bons rapports 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 premier facture une prime élevée pour un gain minime : Sonnet 5 obtient 0.024 de plus que Sonnet 4.6 pour un coût par cellule 70 % plus élevé.
- Grok 4.5 est le nouveau meilleur rapport qualité-prix : 0.732, à 0.040 du vainqueur, pour 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 allant de 0.543 à 0.615, l'alias le moins cher surpassant le plus cher.
- Kimi K3 obtient sa sixième place à un prix intermédiaire : 1,47 $ par cellule, proche des 1,33 $ de Sonnet 4.6 mais avec un score 0.007 supérieur, et bien en dessous des 2,23 $ de Sonnet 5. Inkling coûte 1,64 $ par cellule au prix catalogue pour 0.575, au-dessus de Sonnet 4.6 pour un score inférieur.
Comparaison temps d'exécution / réussite
- Le meilleur score est parmi les plus lents. Sonnet 5 prend environ 30 minutes par tâche, soit 3x celui de Sonnet 4.6 pour 0.024 de plus ; Sonnet 4.6 offre 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, les deux variantes Qwen, GLM 5.1 base, et Deepseek V4 Pro, ont chacun tourné plus de 1 700 secondes par sur-itération pour des scores inférieurs à 0.45.
- Grok 4.3 a été rapide parce qu'il a abandonné 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 du tiers du temps de Sonnet 5, pour 0.732.
- Kimi K3 se situe à l'opposé : score de premier plan, pire vitesse. Il met en moyenne environ 55 minutes par tâche, le plus lent de tous, à peu près 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 pour accéder au haut du classement.
Appels d'outils par tâche
- Le nombre d'appels d'outils ne mesure ni la capacité ni l'effort comparables. Sonnet 5 a fait le plus d'appels (125) et a obtenu le meilleur score ; MiniMax M3 en a fait 108 pour un score moyen de 0.583 ; Grok 4.5 a atteint 0.732 avec 40 ; le faible volume d’OpenAI, de 16 à 36, vient du regroupement d'un fichier entier en un seul appel via apply_patch. Sol Pro et Terra Pro appellent un quart à un tiers d'outils en moins que leurs bases et obtiennent un score inférieur : plus de raisonnement, moins d'exécution. Ne classez pas les agents au volume d'outils.
- Deux chemins mènent au même score : Sonnet 5 itère beaucoup (125 appels), Sonnet 4.6 à peine (environ 50), 0.024 d'écart.
Performance des LLM sur une tâche réussie unique
Aucun modèle n'a passé toutes les étapes du benchmark complet ci-dessus. Pour comparer coût et vitesse sur une base égale, 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 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 » a été le plus cher ici : Gemini 3.5 Flash base a écrit 131 lignes pour la tâche triviale, soit deux à trois fois le reste, ce qui en fait la référence la plus chère, contrairement à son 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 et consommation de tokens
- La prévisibilité des coûts divise les modèles en deux. Les modèles adaptatifs ne dépensent que lorsque nécessaire (Opus 4.8 : 34s référence, 1 072s benchmark) ; les modèles à rythme fixe tournent lentement et coûtent cher même sur un travail trivial (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.
Que sont 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 constate, en continuant jusqu'à ce que la tâche soit terminée.
C'est important parce que les applications réelles ne se limitent 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 ajustements itératifs, ce que permet précisément l'architecture agentique.
Fonctionnement
Le modèle est placé dans un harnais avec accès à un shell, un système de fichiers et les sorties 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 fois. Dans les configurations ponctuelles, 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 le tir. Cependant, cette capacité seule ne suffit pas. Le modèle doit encore disposer d'un fort raisonnement pour implémenter correctement la logique métier, et c'est là que les écarts de performance se creusent vraiment.
Ajouter comme source préféréeMéthodologie du benchmark des LLM agentiques
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 tourné sur la CLI Claude Code avec l'abonnement Claude, et Inkling a fonctionné 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 de systèmes de réservation à des tableaux de bord interactifs. Ces tâches exigent des agents qu'ils 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 tourné sur Opencode 1.15.13 avec les paramètres par défaut de l’API, comme tous les modèles ici ; les chiffres de lancement d’OpenAI pour Sol utilisent des modes de calcul plus élevés.1 Quatre cellules Sol Pro et une cellule Terra Pro ont abouti à des échecs répétés de flux API silencieux plutôt qu'à des erreurs du modèle, et sont comptabilisées comme des échecs.
Kimi K3 et Inkling ont été ajoutés le 18 juillet avec les paramètres par défaut de l’API ; Inkling a fonctionné 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, soit 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é de ce montant dans le cadre d'une remise de lancement temporaire.2 Les deux modèles ont été exécutés avec un délai 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 le mur le plus court en cours de construction ; le temps d'exécution est rapporté séparément dans le graphique temporel. La capacité partagée en amont de Kimi K3 a renvoyé de fréquentes erreurs de limite de débit et de timeout pendant la fenêtre d'exécution ; les cellules concernées ont été réexécutées une fois avec le même délai, selon la même politique appliquée aux échecs de flux Sol Pro et Terra Pro ci-dessus.
Exécution et orchestration
Chaque agent et chaque tâche démarrent 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 la consommation de tokens en temps réel dans les catégories entrée, sortie et 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 heureux, la gestion des erreurs (400/403/409) et la cohérence des données.
Nous testons les résultats selon 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 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é en cas de dérive contractuelle (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 pré-vérifications, le rendu et l'authentification. Nous vérifions les étapes fonctionnelles telles que la soumission de connexion et le comportement après connexion pour garantir que l'application s'exécute sans plantage.
Le scoring UI répartit huit étapes en deux groupes. Les étapes d'infrastructure (pré-vérification backend, rendu frontend, formulaire de connexion visible, soumission de connexion, 2xx de connexion, absence de plantage runtime) mesurent si l'application fonctionne tout court. Les étapes de comportement (signal d'authentification après connexion, signal de comportement après connexion) évaluent si l'application remplit sa fonction une fois lancée.
ui_score = (behavior_passed / (behavior_passed + behavior_failed)) × (infra_passed / infra_total)
Les étapes de comportement bloquées sont exclues du dénominateur, de sorte qu'une cellule n'est pas doublement pénalisée lorsque l'application ne se charge pas.
Calcul des tokens
Les comptes de tokens sont extraits de la réponse de l’API LLM. Nous soustrayons les tokens d'entrée en cache des tokens d'entrée totaux 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 sur le frontend.
Exemple de tâche
Tâche 6 : Système de tickets de helpdesk
La tâche 6 porte 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 en fils de discussion dans 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 flux de statuts rigide qui empêche les transitions illégales et impose des actions spécifiques au rôle.
- Une isolation avancée des données où les demandes de ressources non autorisées renvoient 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 entre agents et clients.
- Un backend FastAPI combiné à un frontend réactif propulsé par 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 = aug,
howpublished = {\url{https://aimultiple.com/agentic-llm}},
note = {AIMultiple. Consulté le 12 Août 2026}
}Résultats et horodatages de 429 points de données. Téléchargez les données utilisées dans cet article sous forme de fichier ZIP contenant 2 fichiers CSV et un README.
Liens de référence
Les travaux de Cem ont été cités par des publications internationales de premier plan telles que Business Insider, Forbes, Washington Post, des entreprises mondiales comme Deloitte, HPE et des ONG comme le Forum économique mondial et des organisations supranationales comme la Commission européenne.
Tout au long de sa carrière, Cem a exercé en tant que consultant tech, acheteur tech et entrepreneur tech. Il a conseillé des entreprises sur leurs décisions technologiques chez McKinsey & Company et Altman Solon pendant plus d'une décennie. 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 tout en rendant compte au PDG. Il a également mené la croissance commerciale de l'entreprise deep tech Hypatos qui a atteint un chiffre d'affaires récurrent annuel à 7 chiffres et une valorisation à 9 chiffres à partir de 0 en 2 ans. Le travail de Cem chez Hypatos a été couvert par des publications technologiques de premier plan comme TechCrunch et Business Insider.
Cem intervient régulièrement lors de conférences technologiques internationales. Il est diplômé de la Bogazici University en tant qu'ingénieur informatique et détient un MBA de la Columbia Business School.
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.