Le choix d'un framework agent vient d'avoir un benchmark que tu peux citer

IBM Research et Hugging Face ont publié ce mois-ci l'Open Agent Leaderboard — le premier benchmark public qui évalue les frameworks agent à la fois sur le taux de succès et sur le coût par tâche. Pour tout CTO encore en train de choisir entre LangGraph, AutoGen, smolagents ou un harnais maison, le processus de sélection vient de changer : la réponse n'a plus besoin d'être "on aimait bien la doc" ou "notre dernier ingénieur le connaissait." La conclusion inconfortable, c'est que les frameworks que ton équipe considérait comme équivalents ne le sont pas — de manière mesurable — et que les écarts comptent vraiment à l'échelle de la production.

Ce qui a changé — et ce que le leaderboard mesure vraiment

L'Open Agent Leaderboard, publié par IBM Research en collaboration avec Hugging Face, évalue les frameworks agent open source sur un ensemble standardisé de tâches agentiques. La méthodologie note chaque framework sur le taux de succès (l'agent a-t-il atteint l'objectif ?), la précision des appels d'outils (a-t-il invoqué les bons outils dans le bon ordre ?), et le coût par tâche en USD — en fixant le modèle sous-jacent, de sorte que c'est le framework, et non le modèle, qui est la variable testée.

Le leaderboard est conçu pour être model-agnostic dans le harnais d'évaluation. Cela signifie que deux frameworks tournant sur le même modèle de base peuvent produire des taux de succès matériellement différents selon la façon dont ils structurent les prompts, gèrent l'état et traitent les tentatives de relance des appels d'outils. La métrique de coût par tâche capture la consommation de tokens sur l'ensemble de la boucle agent, pas seulement un seul appel d'inférence — ce qui correspond au chiffre qui apparaît réellement sur ta facture API en production.

La méthodologie distingue les configurations à agent unique des configurations multi-agents, et elle sépare les tâches à forte utilisation d'outils (opérations fichier, appels API, exécution de code) des tâches à fort raisonnement (planification multi-étapes, branchements conditionnels). Ces deux axes correspondent presque directement à la répartition des charges de travail réelles en entreprise : pipelines d'orchestration intensifs d'un côté, chaînes de raisonnement de type recherche de l'autre.

Pourquoi cela change le calcul autour du choix d'un framework agent

La plupart des équipes choisissent un framework agent comme elles choisissent un bundler JavaScript : en fonction de la dynamique de la communauté, d'un défenseur interne convaincant, ou d'un tutoriel qui s'avérait bon. C'était défendable en 2024, quand les frameworks étaient tous récents et qu'aucun benchmark n'existait. En 2026, s'engager sur un framework est une décision architecturale sur plusieurs années. La logique agent s'accumule. Les structures de prompt s'intègrent dans les outils. Migrer d'une couche d'orchestration vers une autre après 12 mois de production n'est pas un projet de week-end.

Le chiffre de coût par tâche est celui que la plupart des décideurs sous-estiment. Un framework qui coûte 40 % de plus par tâche à 10 000 tâches par mois, c'est une erreur d'arrondi. À 500 000 tâches par mois — ce que représente un déploiement interne réussi au bout de 18 mois — c'est un poste budgétaire qui remonte dans ta revue d'infrastructure. Le leaderboard te donne un moyen de modéliser ce chiffre avant de construire, pas après t'être déjà engagé.

Le deuxième élément sous-estimé, c'est la précision des appels d'outils dans les conditions d'échec. La plupart des démos de framework montrent le chemin nominal. L'évaluation du leaderboard inclut des tâches où les outils retournent des erreurs, des résultats partiels, ou nécessitent une logique de relance. Le taux de succès sur ces tâches prédit la fiabilité en production bien mieux que les performances sur des démos sans accroc. Si ta charge de travail dépend fortement des outils — et c'est le cas de la majorité des charges agent en entreprise — ce sous-score compte davantage que le chiffre de précision affiché en titre.

Parle à Domani AI de la construction de ceci →

Le réflexe du lundi matin : confronte tes exigences aux axes du leaderboard

Ne commence pas par lire le leaderboard en entier. Commence par noter trois contraintes issues de ton build réel, avant même de regarder les classements :

• Budget de latence : Quel est le temps maximum acceptable pour la complétion d'une tâche de bout en bout ? Les frameworks avec plus de boucles de relance et de réflexion obtiennent de meilleurs scores en précision, mais ajoutent du temps d'horloge réel.
• Surface d'outils : Combien d'outils distincts ton agent doit-il appeler, et à quelle fréquence ces outils retournent-ils des réponses non-200 ? Pondère le sous-score de précision des appels d'outils en conséquence.
• Volume mensuel de tâches à l'échelle 18 mois : Projette-toi, pas depuis où tu en es aujourd'hui. Utilise ce chiffre pour multiplier l'écart de coût par tâche entre tes deux frameworks candidats en tête.

Une fois que tu as ces trois chiffres, consulte les sous-scores du leaderboard pour ta configuration de tâches (agent unique vs. multi-agents, forte utilisation d'outils vs. fort raisonnement). Présélectionne les deux frameworks qui obtiennent les meilleurs scores sur tes critères pondérés. Ensuite, lance un spike de 48 heures : prends une vraie tâche de ton backlog, implémente-la dans les deux frameworks, et mesure la consommation réelle de tokens ainsi que le taux de succès sur ton outillage. Le leaderboard te donne la distribution a priori ; le spike te donne la mise à jour pour ton stack spécifique.

Si ton équipe n'a pas 48 heures pour lancer ce spike sans retirer quelqu'un d'un engagement de livraison, c'est en soi un signal : tu n'es pas dimensionné pour prendre cette décision architecturale en toute sécurité sans apport externe.

Ce que ça coûte d'agir maintenant plutôt que d'attendre que le leaderboard arrive à maturité

Agir maintenant, c'est s'engager sur un framework avant que le leaderboard couvre l'intégralité des frameworks que ton équipe pourrait envisager. L'Open Agent Leaderboard est en ligne, mais pas exhaustif — si ton framework préféré n'y figure pas encore, tu retombes sur une information partielle. Le compromis honnête : tu peux attendre 60 à 90 jours pour une couverture plus large, mais si tu as un build qui démarre en Q3, ce délai comprime ta fenêtre d'architecture.

Le risque le plus important est à l'opposé : attendre indéfiniment un benchmark parfait tout en continuant à laisser chaque ingénieur choisir le framework qu'il connaît. Cela produit un stack agent hétérogène, coûteux à opérer et presque impossible à auditer. Un choix de framework standardisé — même imparfait, pris avec les meilleures données disponibles — coûte moins cher sur 24 mois que trois frameworks tournant en parallèle parce que personne n'a tranché.

Le leaderboard ne prend pas la décision à ta place. Il supprime l'excuse de ne pas la prendre.