65 % une fois, 25 % à chaque fois : Microsoft a lancé 507 tâches d'agent vingt fois chacune
By Surya Pratap
27 août 2026
12 min de lecture
IA et technologie
27 août 2026
12 min de lecture
Le chiffre de la démo et celui du produitHover to exploreMicrosoft a publié la semaine dernière un benchmark au titre le moins ambigu qui soit : « One Success Isn't Reliability », une réussite n'est pas une fiabilité.
L'article (arXiv 2608.19741, 20 août 2026) présente Thinkingbox, un sandbox open source pour agents travaillant dans des workflows métier à état, accompagné d'un benchmark de 507 tâches. Les deux sont sur GitHub.
Le résultat principal tient en deux chiffres, du même modèle sur les mêmes tâches :
65,36 % de pass@1. 25,25 % de pass^20.
Juste du premier coup environ deux fois sur trois. Juste sur les vingt tentatives environ une fois sur quatre. Si vous avez déjà réussi une démo d'agent puis regardé la même chose déraper devant un client, cet écart est l'explication complète, et quelqu'un vient enfin de le mesurer.
La plupart des benchmarks d'agents notent la transcription. L'agent a-t-il appelé les bons outils ? A-t-il dit qu'il avait terminé ? Le message final a-t-il l'air correct ?
Thinkingbox note la base de données.
Comment se déroule vraiment une tâche Thinkingbox
Cinq éléments combinés, habituellement testés séparément
Puis il recommence l'ensemble vingt fois, en réinitialisant le backend entre les exécutions.
Cette conception est la contribution. Tout ce qu'il y a d'intéressant dans les résultats découle de ces deux choix : vérifier l'état, et répéter.
Les 507 tâches couvrent cinq domaines : retail et e-commerce (98 tâches), voyage et hôtellerie (104), assurance auto (100), informatique interne d'une néobanque (104) et support IT/RH en conseil (101).
Plus d'une douzaine de modèles, propriétaires et à poids ouverts, ont été passés. La répartition publiée :
Ce qu'il faut regarder, c'est le rapport, pas le classement. Sur tout le tableau, le pass^20 se situe entre un tiers et un dixième du pass@1. Quel que soit le chiffre de précision que vous avez vu cité pour un agent, celui que vivent vos utilisateurs à l'usage répété est nettement plus bas, et c'est le premier benchmark que je vois qui chiffre cette décote.
Voici le résultat que je mettrais sur une diapositive.
Le meilleur modèle a réussi au moins une fois sur environ neuf tâches sur dix. Il a réussi sur les vingt exécutions sur environ une tâche sur quatre.
Autrement dit, la population intéressante n'est ni celle des tâches fiables ni celle des tâches impossibles. Ce sont les 334 tâches — deux tiers du benchmark — dont l'issue variait d'un essai à l'autre.
Pourquoi c'est dans cette bande que meurt la crédibilité
Une tâche qui marche toujours est une fonctionnalité. Une tâche qui ne marche jamais est une limite connue que l'on contourne par conception. Une tâche qui marche la plupart du temps est celle que vous démontrerez avec succès, livrerez avec confiance, puis expliquerez à un client. Deux tiers des workflows métier réalistes sont dans cette bande pour le meilleur modèle disponible, ce qui veut dire que le résultat par défaut d'une démo est une démo qui marche et qui ne vous apprend presque rien.
Si vous vous êtes déjà demandé pourquoi les pilotes d'agents passent si mal en production, voilà une réponse mécanique. Les pilotes sont courts, supervisés et à petit effectif. Ils échantillonnent les bonnes exécutions.
Passons à la partie aux conséquences techniques les plus directes.
80,88 % des essais ratés se sont terminés proprement. La conversation s'est achevée normalement. Les appels d'outils modifiant l'état se sont exécutés et ont renvoyé un succès. Rien n'a levé d'erreur. L'état final était simplement faux.
La conclusion de l'article est nette : les signaux au niveau de la réponse et de l'appel d'outil ne sont pas de bons indicateurs de l'achèvement de la tâche de bout en bout.
Dans le détail, les modes d'échec dominants étaient :
Lisez ces deux points ensemble et une hypothèse répandue s'effondre. L'observabilité des agents, dans la plupart des équipes, consiste à tracer les appels d'outils et à inspecter les transcriptions. Face à cette distribution d'échecs, cela en attrape environ un sur cinq. Les quatre autres ressemblent exactement aux réussites — même sortie propre, mêmes appels valides — et la seule chose qui les distingue est l'état de la base de données à la fin.
C'est aussi la réponse honnête à l'enquête que nous avons traitée hier, où 85,5 % des ingénieurs déclaraient faire confiance à la production des agents. Évidemment qu'ils y croient. Quatre échecs sur cinq sont invisibles d'où ils se tiennent.
La réussite varie énormément selon le domaine : environ 52 % de réussite moyenne dans le retail, contre environ 23 % en assurance auto.
C'est plus du simple au double avec les mêmes modèles et le même harnais, et cela mérite d'être compris plutôt que moyenné. Les workflows du retail sont plutôt courts, tolérants et peu encadrés par des règles. Ceux de l'assurance sont longs, conditionnés par des politiques, et pleins d'étapes où une valeur fausse en amont empoisonne discrètement tout l'aval.
La traduction pratique pour un fondateur : le chiffre de votre domaine n'est pas le chiffre du titre. Si ce que vous automatisez ressemble à un processus de sinistres — multi-étapes, encadré par des règles, chargé en état — le message du benchmark est qu'il faut viser le bas de la fourchette, et le découvrir avant votre client.
Trois réserves, car un benchmark frappant invite à la surinterprétation.
Les modèles testés ne sont pas la frontière actuelle. Le tableau repose sur GPT-5.4 et la génération Claude 4.6. La frontière a bougé depuis : GPT-5.6 et Claude Opus 5 sont arrivés après ces travaux. Les chiffres absolus sont déjà historiques. Savoir si le rapport entre pass@1 et pass^20 s'améliore avec des modèles plus récents est la vraie question ouverte, et rien ici n'y répond.
La position au benchmark n'est pas un classement de capacité. Claude Opus 4.6 se situe sous Claude Sonnet 4.6 ici (37,91 % contre 58,45 % de pass@1), ce qui doit inciter à la prudence avant d'y voir un palmarès. L'adéquation au harnais, le format du prompt et les conventions d'appel d'outils déplacent ces chiffres. Tenez la forme du résultat pour solide et l'ordre pour propre à ce montage.
C'est une simulation. Des backends isolés et un utilisateur simulé valent infiniment mieux que des cas de test statiques, et ce n'est toujours pas votre système de production avec vos données et vos utilisateurs. Le sens de l'erreur est inconnu : les workflows réels pourraient être plus faciles parce que les utilisateurs précisent, ou plus durs parce que le réel est plus sale qu'un simulateur.
La troisième carte offre le meilleur rendement. Ce n'est pas un problème de modèle et cela ne demande pas un meilleur prompt. Si un appel d'outil échoue et que votre orchestration laisse l'agent continuer, vous avez construit une machine à produire des réponses fausses avec assurance, et le benchmark dit que cela explique les trois quarts de ce qui déraille.
Microsoft a construit le benchmark d'agents qui note ce qui compte — ce qui a changé dans le système — puis a tout relancé vingt fois pour voir si cela tenait. Les deux choix paraissent évidents après coup et aucun n'était la norme.
Les résultats : le meilleur modèle disponible à l'époque avait juste du premier coup 65,36 % du temps, et juste à chaque fois 25,25 % du temps. Deux tiers des tâches clignotaient d'une exécution à l'autre. Quatre échecs sur cinq se terminaient proprement, avec des appels valides, et passeraient pour des réussites dans n'importe quelle supervision fondée sur les transcriptions que vous avez déployée.
Rien de tout cela ne signifie que les agents ne marchent pas. Cela signifie qu'une démo n'est pas une preuve, que la précision à un seul essai était la mauvaise métrique à citer, et que l'observabilité construite par la plupart des équipes ne peut pas voir les échecs qui se produisent réellement.
Le correctif n'a rien d'exotique. Lancez-le vingt fois. Vérifiez la base. Arrêtez l'agent quand un outil dit non.
Sources : arXiv 2608.19741, « One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows » · microsoft/thinkingbox sur GitHub · Les notes par modèle, la ventilation des 507 tâches, le chiffre de 80,88 % de terminaison propre et les moyennes par domaine sont ceux publiés dans l'article et son analyse d'accompagnement ; les réserves de la section 6 sont les miennes.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
