Un classement élevé dans l’Open Agent Leaderboard ne suffit pas pour déployer un Agent : vous devez d’abord vérifier la combinaison Agent-modèle-version, reproduire quelques tâches représentatives, puis tester les permissions, la sécurité, la latence et la récupération après échec. Cette méthode est valable si vous choisissez un cadre d’exécution, comparez plusieurs Agents ou devez justifier une décision technique auprès de votre équipe.
Cet article s’adresse aux développeurs d’Agents qui veulent comprendre ce qui est réellement comparé, aux architectes qui contrôlent les tâches, les versions et les coûts, ainsi qu’aux responsables techniques qui ne souhaitent pas transformer un rang public en décision d’achat automatique.
Dernière mise à jour : 18 août 2026. Les informations ont été vérifiées à partir de la publication de recherche, du dépôt Exgentic, du classement public et du jeu de résultats associé.
Le bon objet d’évaluation
La première erreur consiste à lire l’Open Agent Leaderboard comme un palmarès de modèles de langage. Le résultat publié correspond plutôt à une configuration complète : un Agent particulier, un modèle donné, une version logicielle, un ensemble d’outils, une stratégie de planification et des paramètres d’exécution. La publication associée décrit 25 configurations évaluées, ce qui confirme qu’une comparaison isolant uniquement le modèle ne restitue pas l’objet réellement mesuré (détails des 25 configurations dans la publication).
L’Open Agent Leaderboard teste-t-il un modèle ou un Agent ? Il teste une combinaison des deux, avec le comportement produit par l’orchestrateur. Le modèle peut décider d’appeler un outil, mais c’est l’Agent qui détermine souvent quels outils sont visibles, comment leurs résultats sont injectés dans le contexte, quand une nouvelle tentative est lancée et ce qui se passe après une réponse invalide.
Pour interpréter une ligne du classement, relevez donc au minimum :
- le nom et la version de l’Agent ;
- le modèle utilisé et sa version au moment de l’évaluation ;
- les outils autorisés et la méthode de sélection des outils ;
- la politique de gestion du contexte, notamment lorsque l’historique devient long ;
- le traitement des erreurs de syntaxe, des appels interrompus et des résultats ambigus ;
- la définition exacte d’une réussite et le nombre de tentatives autorisées.
Cette lecture explique pourquoi deux systèmes reposant sur le même modèle peuvent produire des résultats différents. Un Agent qui filtre les outils de manière agressive peut éviter des appels inutiles, mais perdre une information indispensable. Un autre, plus permissif, peut réussir davantage de tâches tout en augmentant les appels, la durée d’exécution et les risques liés aux autorisations.
La source publique Exgentic et son dépôt d’exécution permettent de contrôler les paramètres déclarés, les scripts et les éléments nécessaires à une reproduction (données publiques et analyse du classement et code Exgentic avec les paramètres d’exécution). Il ne faut toutefois pas confondre la présence d’un paramètre dans le dépôt avec sa correspondance parfaite à votre infrastructure : réseau, secrets, versions de bibliothèques et limites d’outils peuvent modifier le comportement.
La pertinence des tâches
Un total proche ne signifie pas que deux candidats répondent au même besoin. Le bon candidat pour automatiser une correction de code n’est pas nécessairement celui qui convient à une recherche documentaire avec navigation, à une opération dans une interface graphique ou à un échange de service client.
Pour un produit de développement logiciel, examinez les tâches de modification de dépôt, de compréhension du code, de tests et de correction après échec. Le résultat de SWE-bench Verified constitue un repère connu, mais sa description officielle porte sur un ensemble de 500 problèmes validés par des humains ; ce chiffre décrit le périmètre de ce jeu de tâches, pas une garantie de réussite de votre dépôt (présentation officielle de SWE-bench Verified).
Pour un Agent de recherche, contrôlez plutôt la capacité à trouver une information difficile, à citer sa provenance, à distinguer une réponse incomplète d’une réponse certaine et à s’arrêter lorsque les sources se contredisent. BrowseComp a été conçu pour des recherches nécessitant plusieurs étapes et des informations moins directement accessibles ; son objectif est donc différent d’une simple question-réponse (description de BrowseComp et de sa conception).
Les applications de création audio, vidéo et design ajoutent d’autres contraintes. Un Agent peut savoir planifier une suite d’actions tout en échouant face à une fenêtre modale, à un fichier lourd, à un format propriétaire ou à une exportation qui demande une validation visuelle. Dans ces cas, un résultat de navigation textuelle ne suffit pas pour sélectionner un environnement d’automatisation d’interface.
Pour le service client, vérifiez les politiques d’escalade, la conservation du contexte, la capacité à ne pas inventer une information de compte et la séparation entre lecture et écriture. Le code officiel de τ-Bench est utile pour examiner la logique de tâches et les versions publiées, mais il ne remplace pas un scénario construit avec vos propres règles commerciales (dépôt officiel de τ-Bench).
Pourquoi un Agent bien classé peut-il échouer en production ? Parce que le classement mesure des tâches et une définition de réussite limitées. Votre environnement peut imposer une authentification supplémentaire, une réponse en moins de temps, une validation humaine obligatoire, un format de sortie strict ou une politique réseau absente de l’évaluation publique.
Une lecture par rôle
Le développeur doit suivre les trajectoires d’outils, pas seulement le score final. Une réussite obtenue après plusieurs appels superflus peut cacher un problème de conception de l’orchestrateur. À l’inverse, un échec isolé peut venir d’un outil mal exposé plutôt que d’une faiblesse fondamentale du modèle.
L’architecte doit relier chaque famille de tâches à une exigence système. Pour un Agent de recherche, la traçabilité et la fraîcheur des sources passent avant un classement global. Pour un Agent de code, la reproductibilité des modifications et l’exécution des tests comptent davantage qu’une réponse élégante. Pour un Agent d’interface, la gestion des états visuels et la reprise après interruption deviennent prioritaires.
Le responsable technique doit demander une vue par tâche, par version et par coût. Une ligne du classement qui mélange plusieurs appels de modèles, des reprises et des outils externes ne peut pas être comparée directement à une configuration qui comptabilise uniquement la réponse finale.
La grille de comparaison
Avant d’ouvrir un essai, remplissez cette grille avec les informations effectivement publiées. Une cellule « inconnue » n’est pas un détail éditorial : elle signale un risque de comparaison non équitable.
| Dimension | Candidat A | Candidat B | Décision à prendre |
|---|---|---|---|
| Agent et version | À relever dans le résultat | À relever dans le résultat | Écarter toute ligne sans version identifiable |
| Modèle et version | À vérifier séparément | À vérifier séparément | Comparer seulement des versions compatibles |
| Tâches pertinentes | Code, recherche, interface ou service client | Même périmètre | Donner priorité aux tâches proches du produit |
| Appels d’outils | Nombre et types publiés ou inconnus | Nombre et types publiés ou inconnus | Mesurer les appels inutiles pendant la reproduction |
| Gestion des erreurs | Reprise, arrêt ou comportement non documenté | Reprise, arrêt ou comportement non documenté | Exiger une trace exploitable |
| Coût annoncé | Périmètre à confirmer | Périmètre à confirmer | Inclure modèle, reprises et outils externes |
| Conditions de réussite | Tests, exactitude, validation humaine ou autre | Tests, exactitude, validation humaine ou autre | Ne jamais comparer des définitions différentes |
| Adaptation à la production | À tester | À tester | Le classement ne tranche pas cette colonne |
Cette grille transforme un classement public des Agents en outil de sélection. Elle vous oblige à séparer ce qui est observé de ce qui est supposé.
Le coût réel d’une réussite
Le coût affiché est souvent la partie la moins homogène de la comparaison. Demandez si le calcul inclut chaque appel au modèle, les sorties intermédiaires, les reprises automatiques, la lecture des résultats d’outils, les services externes et les opérations abandonnées. Un Agent qui réussit en une seule trajectoire courte n’a pas le même profil économique qu’un Agent qui obtient le même résultat après plusieurs corrections.
La granularité compte également. Un coût moyen par tâche peut masquer quelques cas très chers. Pour une équipe, vous devez conserver au moins la distribution des appels et identifier les tâches qui déclenchent des boucles. La question pertinente n’est pas « quel candidat est le moins cher sur le tableau ? », mais « quel budget maximal une tâche réussie peut-elle consommer lorsque le réseau ou l’outil échoue ? ».
Les résultats évoluent aussi lorsque le modèle, le cadre ou la politique de reprise change. La base publique des résultats est utile pour conserver la configuration et le contexte de publication, mais elle doit être consultée comme une série de clichés datés, non comme un classement permanent (jeu de résultats public de l’Open Agent Leaderboard).
Rappel de méthode : si la date du classement, la version du modèle ou le périmètre du coût n’est pas identifiable, notez « non comparable » plutôt que d’attribuer une précision artificielle au rang publié.
La reproduction contrôlée
Comment reproduire les résultats de l’Open Agent Leaderboard ? Vous ne devez pas commencer par reconstruire toute l’infrastructure. Reproduisez d’abord un petit échantillon de tâches, avec les mêmes versions et les mêmes règles, puis mesurez les écarts avant d’élargir.
Suivez cette séquence :
- Fixez la capture de référence. Enregistrez la date de consultation, la version du classement, l’identifiant de chaque tâche, le modèle, l’Agent et les paramètres visibles. Conservez aussi la définition de la réussite.
- Préparez un environnement isolé. Utilisez un compte de test, des données non sensibles, des clés limitées et un réseau dont les sorties sont contrôlables. Ne donnez pas d’accès de production à un Agent simplement parce qu’il apparaît en tête.
- Recréez les outils et leurs réponses. Vérifiez les schémas, les messages d’erreur, les délais et les formats retournés. Une différence minime dans une réponse d’outil peut changer la trajectoire.
- Lancez les tâches sans retouche manuelle. Enregistrez les appels, les arguments, les réponses, les reprises, le temps écoulé et la raison d’un arrêt. Si une intervention humaine est autorisée, marquez précisément son rôle.
- Comparez les états finaux et les trajectoires. Une réponse correcte ne suffit pas si l’Agent a appelé une ressource interdite, ignoré une règle ou produit un résultat impossible à auditer.
- Répétez les cas instables. Les sorties non déterministes et les variations de disponibilité des outils peuvent modifier le résultat. Indiquez les conditions de répétition au lieu de publier un chiffre présenté comme immuable.
- Ajoutez vos propres pannes. Coupez un outil, expirez une autorisation de test, renvoyez une donnée mal formée, ralentissez le réseau et interrompez l’exécution. Observez si l’Agent s’arrête proprement, réessaie dans une limite ou poursuit une action dangereuse.
- Consignez les écarts. Pour chaque différence avec le classement, cherchez d’abord une divergence de version, de tâche, de donnée, de coût ou de configuration avant de conclure à une supériorité technique.
Vous pouvez utiliser un environnement Mac distant lorsque les scénarios comportent une application graphique, un navigateur, de l’audio, de la vidéo ou une chaîne de design. Les contraintes de session doivent alors être documentées : accès VNC pour piloter un Mac à distance, résolution, presse-papiers, stockage temporaire et récupération après déconnexion.
Les contrôles absents du classement
Les évaluations publiques décrivent rarement toute la surface opérationnelle d’une entreprise. Avant de conclure, le plateau technique doit tester au moins les points suivants :
- Permissions : l’Agent peut-il lire, écrire, supprimer ou appeler un service au-delà de la tâche prévue ?
- Identifiants : les clés sont-elles séparées par environnement, renouvelées et absentes des journaux ?
- Concurrence : deux exécutions simultanées mélangent-elles leurs contextes ou leurs fichiers temporaires ?
- Journalisation : peut-on reconstruire la décision sans enregistrer de données confidentielles inutiles ?
- Réseau : les domaines autorisés, les téléchargements et les connexions sortantes sont-ils contrôlables ?
- Reprise : une coupure laisse-t-elle un état cohérent, ou l’Agent recommence-t-il une action déjà effectuée ?
- Validation : quelles opérations exigent une approbation humaine avant écriture, envoi ou publication ?
- Nettoyage : les artefacts, sessions et fichiers importés sont-ils supprimés après le test ?
Un Agent qui échoue immédiatement sur une tâche de classement peut être facile à diagnostiquer. Celui qui réussit tout en contournant une règle de permission est, lui, impropre à la production. La fiabilité doit donc être notée avec la sécurité et la gouvernance, et non ajoutée comme une remarque finale.
Les seuils de décision
Un classement d’Agents peut-il servir directement à choisir un cadre de développement ? Il peut réduire le nombre de candidats, mais il ne doit pas désigner seul le cadre retenu. Votre décision doit dépendre d’un essai qui reprend vos outils, vos données synthétiques, vos règles d’accès et vos critères d’arrêt.
Utilisez trois issues simples :
| Issue | Preuves minimales | Action recommandée |
|---|---|---|
| Entrée en essai | Tâches pertinentes, versions identifiables, trajectoires lisibles, coût calculable et absence de violation critique | Tester sur un environnement isolé avec une liste de pannes définie |
| Observation | Score intéressant mais coût, version, tâches ou reprise insuffisamment documentés | Attendre une donnée vérifiable ou reproduire avec des hypothèses explicitement consignées |
| Arrêt de l’évaluation | Permission excessive, fuite de secret, absence de journal exploitable, coût imprévisible ou échec systématique sur une tâche essentielle | Ne pas compenser par le rang ; chercher un autre candidat ou revoir le périmètre |
Le rang public est donc un filtre initial. La décision de pilote repose sur des preuves locales. La décision de production doit être validée par une procédure indépendante du classement, avec des critères de retour arrière et un propriétaire clairement nommé.
Pour présenter le résultat à une direction, évitez « le meilleur Agent est numéro un ». Préférez une formulation conditionnelle : « ce candidat est retenu pour l’essai de recherche parce que ses tâches pertinentes sont documentées ; son déploiement reste soumis à la vérification des permissions, du coût par trajectoire et de la reprise après panne ». Cette phrase sépare l’observation publique de la décision interne.
La fiche de lecture évolutive
Une fiche de lecture évite qu’une nouvelle publication efface les limites de l’ancienne. Conservez une entrée par capture avec :
- la date de consultation et la date annoncée du résultat ;
- l’Agent, sa version et le modèle associé ;
- les tâches incluses et celles qui ne le sont pas ;
- la définition de la réussite et le traitement des reprises ;
- le périmètre du coût, y compris les appels indirects lorsqu’ils sont connus ;
- les paramètres réseau, outils et données nécessaires à la reproduction ;
- les échecs observés et les hypothèses encore non vérifiées ;
- la décision prise : essai, observation ou arrêt.
Lorsque le classement ajoute un modèle, modifie sa méthode de notation ou publie un nouveau jeu de tâches, repartez de cette fiche. Ne remplacez pas silencieusement l’ancien résultat : conservez l’instantané historique et indiquez ce qui a changé. Le lecteur pourra alors comprendre pourquoi une recommandation évolue sans conclure que l’analyse précédente était nécessairement erronée.
Exgentic, le dépôt d’exécution et le jeu de résultats doivent être lus ensemble : la publication explique l’objet évalué, le code précise la mécanique déclarée et les données montrent la trace disponible. Aucun de ces éléments ne décrit à lui seul vos contraintes de production.
Le passage du classement au terrain
Dans la pratique, un classement public est plus utile pour sélectionner deux candidats que pour acheter immédiatement le premier. Faites-leur exécuter les mêmes tâches synthétiques, puis ajoutez une tâche représentative de votre application, une erreur d’outil, une expiration de permission et une interruption réseau. Comparez le résultat final, mais aussi la facilité d’audit, le coût des reprises, la capacité à s’arrêter et la propreté de l’état laissé derrière lui.
Pour structurer cette étape, commencez par le guide de choix d’une API de modèle pour un Agent de production si vous devez clarifier le rôle du modèle avant celui de l’orchestrateur. Lorsque l’évaluation implique une interface macOS ou une création audio-visuelle, documentez séparément la session distante et les accès, au lieu de mélanger performance du modèle et ergonomie de l’environnement.
Un poste local reste préférable lorsque vous avez besoin d’une charge stable sur une longue période, d’un périphérique physique spécifique ou d’un contrôle permanent des données. Une infrastructure distante peut être plus adaptée à un test temporaire, à une équipe distribuée ou à une comparaison isolée, à condition de vérifier la latence, les règles réseau et la conservation des journaux. Un environnement Mac distant peut alors fournir un terrain d’essai plus souple qu’un poste de développement partagé, mais il ne dispense pas de votre validation de sécurité ni de votre procédure d’acceptation.
Le choix opposé — se fier uniquement au classement, lancer l’Agent avec des identifiants réels et mesurer seulement la réponse finale — cumule trois défauts : il ignore les écarts entre versions, sous-estime les coûts de reprise et ne révèle pas les comportements dangereux lors d’une panne. Pour un besoin temporaire de calcul ou de test, un environnement Mac loué peut donc offrir une expérimentation plus contrôlable ; pour une charge durable et prévisible, l’achat d’une machine dédiée ou une autre architecture peut rester plus rationnel.
Avant de transformer un rang en contrat ou en déploiement, emportez deux candidats du classement dans votre propre jeu de tâches, remplissez leur fiche de version et faites-les passer par votre grille de permissions, de coûts et de récupération. Vous pourrez ensuite consulter les ressources de SSHMac sur les environnements Mac distants et l’accès aux sessions, sans confondre un bon résultat de référence avec une preuve de disponibilité en production.