Analyse comparative des LLM d'Agentic : Comparaison des 13 meilleurs LLM
Nous avons évalué les performances de 13 LLM sur 10 tâches de développement logiciel à l'aide d'un outil CLI agentic . Nous avons exécuté environ 300 étapes de validation automatisées par modèle afin de mesurer les performances des couches API et UI.
Résultats de référence Agentic LLM
Comparaison des taux de réussite
Claude 4.5 Sonnet et GPT-5.2 ont obtenu les meilleurs scores globaux, avec des résultats très cohérents tant au niveau de la logique API que de l'intégration de l'interface utilisateur. Gemini 3.1 Pro Preview et GPT-5.2 Codex ont suivi, avec une logique backend fonctionnelle mais un rendu frontend moins performant.
Claude Sonnet 4.5
Parmi tous les modèles testés, Claude Sonnet 4.5 a obtenu le meilleur taux d'interface utilisateur, produisant systématiquement des interfaces fonctionnelles avec une logique backend opérationnelle. Il a implémenté avec succès les opérations CRUD, la validation des entrées, la collecte de ressources, les workflows multi-étapes et les cycles de vie à plusieurs phases. Cependant, certaines tâches, bien que correctement configurées pour l'authentification, ne prenaient pas en charge la création de ressources, l'application des contraintes ou le contrôle d'accès basé sur les rôles dans les points de terminaison spécifiques au domaine.
Aperçu de Gemini 3.1 Pro
Code backend techniquement précis, mais infrastructure fragile. Authentification et vérification des étapes de base réussies pour certaines tâches, mais échec général sur :
- Initialisation du frontend
- Validation stricte du schéma
- Contraintes de validation basées sur le temps
- transitions d'état complexes
- Création de ressources en cascade
GPT-5.2
La plupart des tâches gérées par GPT-5.2 se caractérisaient par des backends fonctionnels et des frontends opérationnels, avec d'excellentes performances en matière de CRUD, de validation des entrées, de contrôle d'accès basé sur les rôles et de workflows multi-étapes. Ses points faibles :
- Logique de la machine à états : authentification et liste des ressources implémentées, mais transitions de statut d’administrateur et application irréversible des états ignorées.
- Application des rôles ou création de ressources limitée dans certaines tâches
GPT-5.2 Codex
Les flux de base tels que l'enregistrement, le recensement des ressources et la gestion des collections étaient bien gérés par le Codex GPT-5.2. Ses principales faiblesses :
- Points de terminaison de récupération des détails manquants
- Aucune transition d'état d'administration
- La moitié de ses interfaces ont planté avec des erreurs d'exécution (5 sur 10).
Comparé à GPT-5.2, Codex a généré des backends plus fiables mais des frontends nettement moins stables.
Exemple de journalisation :
Gemini 3 Pro
Pour les tâches simples à rôle unique, Gemini 3 Pro implémentait correctement les opérations CRUD, la recherche, le contrôle d'accès basé sur les rôles et la récupération des données. Les applications à rôles multiples constituaient son point faible.
- Le contrôle d'intégrité et l'authentification ont réussi, mais la création des ressources, la gestion des associations, l'application des rôles et les flux de travail d'administration ont échoué.
- Échec à 13 des 16 étapes de deux tâches à rôles multiples
- L'affichage des interfaces a échoué dans 4 tâches
Claude Sonnet 4.6
Avec deux défaillances totales du backend et des scores d'API faibles pour la plupart des tâches, Claude Sonnet 4.6 a affiché des performances inconstantes. Une exception : un score d'API de 0,92 a été obtenu pour une tâche unique avec des fonctionnalités CRUD, d'authentification, de gestion des rôles et des ressources quasi complètes (échec uniquement lors de la suppression). Pour les autres tâches, la structure du projet et les couches d'authentification fonctionnelles ont été générées, mais la logique métier spécifique au domaine est restée inachevée. Implémentations manquantes :
- Création, inventaire et récupération des ressources
- Transitions d'état, application des rôles, validation des entrées
- Flux de travail du domaine : panier/paiement, gestion des billets, rendez-vous, sondages, confirmation de présence aux événements, suivi des transactions
Claude Opus 4.6
Claude Opus 4.6 a permis d'obtenir des interfaces utilisateur quasi complètes, mais avec une logique backend minimale. Le système a passé avec succès les tests de santé, d'inscription et de connexion, mais a généralement échoué aux étapes suivantes :
- Création de ressources
- transitions d'état
- accès basé sur les rôles
- Validation des entrées
- Flux de travail d'administration
Exemple de journalisation :
Kimi K2.5
Des implémentations complètes pour certains types de tâches contrastent avec des backends défaillants pour d'autres, suggérant que Kimi K2.5 gère les tâches CRUD plus simples mais a du mal avec les applications complexes à rôles multiples ou à étapes multiples.
GLM 4.7
Les performances globales de GLM 4.7 ont été mitigées. Les tâches ayant obtenu les meilleurs scores présentaient des interfaces partiellement chargées, et les points de terminaison d'authentification renvoyaient des codes d'état incorrects. La plupart des tâches présentaient des erreurs dans le code du serveur ou de l'interface.
Grok 4
Le code backend minimal issu de Grok 4 se limitait généralement à la vérification de l'état et à l'authentification. Il réussissait une tâche à la perfection, mais échouait sur les autres points suivants :
- Liste des services
- Création de ressources
- Opérations administratives
- transitions d'état
Devstral 2 2512
Devstral a généré une partie de la logique backend, mais aucun code frontend valide n'est apparu dans aucune tâche en raison de fichiers manquants ou de références de modules cassées.
Qwen3 Coder Suivant
Le code backend qui n'a pas pu s'exécuter a caractérisé la plupart des tâches tentées par Qwen3 Coder Next. Là où les backends ont commencé, les frontends ont échoué en raison de points d'entrée manquants ou de composants défectueux.
Aperçu de Trinity Large
Avec les scores les plus bas, Trinity Large Preview a généré des structures de projet comportant des erreurs empêchant l'exécution des applications. La plupart des backends ne disposaient pas d'implémentations de routes fonctionnelles et les frontends présentaient des composants manquants ou défectueux.
Comparaison des coûts et des résultats
Claude Opus 4.6 était le modèle le plus cher par série, mais se classait en milieu de tableau. Devstral, quant à lui, avait un coût similaire à celui de Claude 4.5 Sonnet, mais un score nettement inférieur. Les modèles GPT-5.2 et GPT-5.2 Codex ont obtenu d'excellents scores pour un coût relativement faible.
Jetons d'achèvement et temps d'achèvement de la tâche
Devstral a consommé une grande quantité de jetons dans tous les modèles, mais n'a produit aucun frontend fonctionnel, ce qui signifie qu'une grande partie de sa production était du code non fonctionnel ou redondant.
Kimi K2.5 et GLM 4.7 ont eu les latences les plus élevées, passant beaucoup plus de temps par tâche sans amélioration correspondante des résultats.
Grok-4 s'est avéré tout aussi lent malgré la génération d'un nombre relativement faible de jetons, ce qui indique de longues pauses entre les générations plutôt qu'une production importante. À l'inverse, Gemini 3 Pro Preview et GPT-5.2 Codex ont accompli les tâches rapidement avec une utilisation modérée de jetons, se classant tous deux dans la première moitié du classement général.
performance LLM sur une tâche unique réussie
Après avoir effectué notre test de performance sur 10 tâches, nous avons constaté qu'aucune tâche n'était réussie par tous les LLM et que de nombreuses étapes présentaient des échecs. Nous avons donc souhaité observer les performances en termes de jetons et de latence sur une tâche que tous les LLM pourraient facilement réussir.
À cette fin, nous avons conçu une tâche de base minimale : une API Notes simple en mémoire avec quatre points de terminaison CRUD, une validation basique, sans authentification ni base de données. Tous les étudiants en LLM ont réussi cette tâche avec un taux de réussite de 100 %, confirmant ainsi que tous les modèles peuvent gérer la génération d’API simples une fois la complexité éliminée.
Cela nous a permis de comparer leur utilisation des jetons, leur coût et leur latence sur une seule tâche réussie.
Comparaison des coûts et des lignes de code
Dans le benchmark complet, Claude 4.5 Sonnet était le modèle le mieux noté à un coût moyen de 0,29 $ par tâche ; ici, il a complété la base de référence pour seulement 0,012 $, égalant les modèles les moins chers.
Les logiciels Qwen3 Coder (0,012 $) et Trinity (gratuit), respectivement dernier et avant-dernier du test de performance complet, offraient des prix compétitifs par rapport aux modèles Sonnet les plus performants. Ainsi, pour une tâche réalisable par tous, l'écart de coût entre les logiciels les plus performants et les moins performants s'estompe considérablement, à l'exception d'Opus qui reste cher quelle que soit la difficulté de la tâche.
La version d'essai de Gemini 3.1 Pro, proposée à 0,016 $, a démontré un prix compétitif pour cette tâche de base, malgré un coût légèrement supérieur à celui des modèles les plus abordables. Elle se positionne ainsi avantageusement parmi les solutions de milieu de gamme, affichant un rapport qualité-prix satisfaisant pour des tâches moins complexes.
Devstral 2 2512 a affiché la réduction de coût la plus spectaculaire, passant de 0,31 $ par tâche à 0,021 $. Comme il n'a obtenu qu'un score de 0,07 dans l'ensemble du benchmark, cela révèle un aspect important de la tarification LLM : les coûts élevés ne reflètent pas toujours des tarifs par jeton élevés, ils peuvent résulter de tentatives de reconnexion infructueuses répétées plutôt que de la structure de tarification de base du modèle.
Claude Opus 4.6 est resté le plus cher à 0,086 $, conformément à sa moyenne de 1,17 $ dans l'ensemble du benchmark, confirmant que sa tarification par jeton le rend coûteux quelle que soit la difficulté de la tâche.
Grok-4 a généré le moins de lignes de code, ce qui correspond à sa faible utilisation de jetons dans le benchmark complet. Codex et GPT-5.2 présentaient des coûts similaires, mais GPT-5.2 était plus rapide et plus efficace. Ceci est conforme au benchmark complet où GPT-5.2 a obtenu un meilleur score pour un coût identique, démontrant ainsi qu'il parvient plus directement aux solutions.
Comparaison des jetons d'achèvement et de l'achèvement des tâches
Kimi K2.5 a mis 135 secondes pour une tâche que la plupart des modèles ont terminée en moins de 30 secondes, confirmant que la latence élevée observée dans le benchmark complet est une contrainte au niveau du modèle, et non due à la complexité de la tâche.
GLM 4.7, le modèle le plus lent de l'ensemble du benchmark, a terminé cette tâche en 24 secondes, une réduction de 25 fois, suggérant que sa latence est proportionnelle à la difficulté.
Qwen3 Coder a réalisé le meilleur temps (10 secondes) malgré sa dernière place au classement général. GPT-5.2 a utilisé moins de jetons que GPT-5.2 Codex et a terminé plus rapidement, conformément au classement général où GPT-5.2 a obtenu un meilleur score tout en étant plus concis.
Que sont les systèmes LLM agentsifs ?
Le développement logiciel est un processus itératif : écrire le code, l’exécuter, identifier les erreurs, les corriger, et recommencer. Les systèmes d’IA agentiques permettent aux modèles de langage (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 résultats et apporter des modifications en fonction de ce qu’il observe, et ce jusqu’à la fin de la tâche.
C'est important car les applications réelles ne se résument pas à un seul fichier. Elles comportent un backend avec des routes et des modèles de base de données, un frontend avec des composants et des appels d'API, des fichiers de configuration, des dépendances et des tests. Faire interagir ces éléments nécessite des tests et des améliorations itératifs, ce que permet précisément l'architecture agentique.
Comment ça marche
Le modèle est intégré à un environnement d'exécution lui donnant accès à un shell, au système de fichiers et à la sortie d'exécution. Lorsqu'on lui demande de compiler une application, il écrit les fichiers de manière incrémentale. Après chaque étape, l'environnement d'exécution indique au modèle le déroulement des opérations : le serveur a-t-il démarré ? Les tests ont-ils réussi ? L'analyseur de code a-t-il détecté des erreurs ? En fonction de ces informations, le modèle décide des prochaines étapes d'écriture ou de correction.
Cela diffère fondamentalement de la génération en une seule étape. Dans ce dernier cas, le modèle génère l'intégralité du code source à l'aveugle, sans possibilité de vérifier son bon fonctionnement. Dans les systèmes LLM multi-agents, le modèle observe les conséquences de chaque action et corrige le tir. Toutefois, cette capacité seule ne suffit pas. Le modèle a toujours besoin d'un raisonnement solide pour implémenter correctement la logique métier, et c'est là que les différences de performance apparaissent réellement.
Méthodologie de référence Agentic LLM
Nous avons utilisé Aider pour tous les agents et les avons connectés aux modèles via OpenRouter. 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 simples à des tableaux de bord interactifs complexes. Ces tâches exigent des agents qu'ils gèrent des projets multi-fichiers et livrent des produits fonctionnels.
Exécution et orchestration
Chaque agent et chaque tâche démarre dans un environnement vierge. Les instructions sont fournies dans un fichier TASK.md, et nous utilisons un système de surveillance (battement de cœur) toutes les 20 minutes pour les scripts de lancement. Durant cette phase, nous enregistrons les codes de sortie, le temps d'exécution et la création des fichiers backend et frontend. Nous suivons également en temps réel l'utilisation des jetons pour les entrées, les sorties et les données mises en cache.
Validation côté serveur : Nous déployons les projets générés dans des environnements isolés afin de les tester par rapport à un contrat YAML standard. La validation couvre les scénarios nominaux, 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 le respect exact du contrat.
Le score global du backend est calculé comme suit : backend_overall = (ready_tasks / total_tasks) × Moyenne (taux de réussite adaptatif + strict)
Tests d'interface utilisateur et de scénarios utilisateurs
Nous utilisons l'automatisation du navigateur pour simuler les parcours utilisateurs réels, y compris les requêtes préliminaires, le rendu et l'authentification. Nous vérifions les étapes fonctionnelles telles que la soumission du formulaire de connexion et le comportement post-connexion afin de garantir le bon fonctionnement de l'application.
Les performances de l'interface utilisateur sont mesurées par le taux de réussite des étapes : step_pass_rate = passed / (passed + failed + blocked)
Calcul des jetons
Le nombre de jetons est extrait de la réponse de l'API LLM. Nous soustrayons les jetons d'entrée mis en cache du nombre total de jetons d'entrée pour obtenir l'entrée effective, qui ne reflète que les jetons nouvellement traités. Les jetons de sortie ne sont jamais mis en cache et restent donc inchangés.
Agrégation finale
Le score de référence final est calculé en combinant les résultats des phases précédentes : Score final = (0,7 × backend_overall) + (0,3 × ui_overall) Nous attribuons un poids plus élevé au backend car les échecs logiques au niveau de l'API invalident souvent tout succès dans le frontend.
Exemple de tâche
Tâche 6 : Système de gestion des tickets d'assistance
La tâche 6 porte sur le développement d'un écosystème complexe de support client. Son objectif principal est de concevoir une plateforme qui assure la communication entre les clients et les agents de support, tout en garantissant le respect des règles métier et des normes de sécurité. Cette tâche évalue la capacité d'un agent à gérer des machines à états multi-utilisateurs, l'isolation des données et la communication multithread dans un environnement full-stack.
La tâche consistait à construire un système de support technique comprenant :
- Autorisations distinctes pour les clients (émission/réponse) et les agents (gestion/résolution).
- Un flux de travail de statut rigide qui empêche les transitions illégales et impose des actions spécifiques aux rôles.
- Isolation avancée des données où les requêtes de ressources non autorisées renvoient un code 404 au lieu d'un code 403 afin de protéger l'intégrité du système.
- Un système de réponse chronologique pour une interaction agent-client fluide.
- Un backend FastAPI combiné à un frontend réactif basé sur Vite (React/Vue/Svelte).
- Configuration reproductible via des commandes shell spécifiques pour une activation système immédiate.
Vous pouvez consulter la documentation de la tâche 6 sur GitHub .
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires.