Dans cet article
La réponse directe : une démonstration réussie ne prouve rien de la fiabilité d'un agent d'IA, car la bonne question n'est pas de savoir s'il a accompli la tâche une fois, mais s'il l'accomplit correctement chaque fois. Dans une étude que Microsoft a publiée le 20 août 2026, le modèle le plus puissant a obtenu 65,36 % lorsque chaque tâche était exécutée une seule fois, mais n'a réussi les vingt tentatives que sur 25,25 % des tâches. Cet écart est précisément la distance entre un agent qui vous impressionne en réunion et un agent auquel vous pouvez confier les données de vos clients.
Ce que Microsoft a réellement construit
L'outil s'appelle Thinkingbox, un environnement de test open source publié sous licence MIT sur GitHub. L'idée est simple et habile : au lieu de câbler les outils directement dans l'agent, vous les définissez comme des serveurs compatibles MCP, vous exécutez l'agent dans une session isolée avec sa propre base de données, et vous enregistrez la trace complète d'exécution.
Le point essentiel tient à sa façon de noter. Le cadre ne lit pas ce que l'agent a dit avoir fait ; il inspecte ce qui a réellement changé dans la base de données une fois la tâche terminée. Cette distinction n'est pas un détail technique. Les agents sont très doués pour rédiger un résumé convaincant d'un travail qui n'a jamais eu lieu, et toute évaluation fondée sur la transcription de la conversation mesure la qualité de la prose, non celle de l'exécution.
Sur cet environnement, l'équipe a construit un banc d'essai appelé Thinkingbox-bench, contenant 507 flux de travail soumis à des règles, répartis sur cinq domaines : le commerce de détail et la vente en ligne, le voyage et l'hôtellerie, l'assurance automobile, le support informatique interne d'une néobanque, et le support informatique et des ressources humaines d'un cabinet de conseil. Chaque tâche a été exécutée vingt fois sur douze modèles, propriétaires comme à poids ouverts.
Pourquoi ce chiffre compte pour un dirigeant
Imaginez que vous confiiez à un agent le traitement des demandes de retour dans votre boutique. Un taux de réussite de 65 % paraît acceptable sur le papier. Sur le plan opérationnel, cela signifie qu'un tiers des demandes aboutit à un résultat erroné : un remboursement émis deux fois, une commande clôturée sans réintégration du stock, ou une dérogation accordée à un client auquel votre politique ne l'autorise pas.
Pire, les échecs de cette étude n'étaient pas des plantages évidents. L'article décrit explicitement nombre d'échecs comme se terminant proprement, avec des étapes qui paraissaient valides, alors que l'état final du système restait erroné. Aucun message d'erreur, aucun arrêt, rien qui s'allume sur un tableau de bord de surveillance. Juste un journal qui se lit normalement et des données devenues silencieusement incorrectes.
Un échec qui arrête le système est agaçant mais visible. Un échec qui termine le parcours et laisse vos données erronées est celui qui vous coûte réellement, parce que vous le découvrez un mois plus tard, au moment du rapprochement.
Cela explique aussi une source courante de déception. Le pilote réussit parce qu'il a exécuté la tâche une fois sur des données propres. L'exploitation réelle, c'est la même tâche des milliers de fois sur un état accumulé et désordonné, et c'est exactement là qu'apparaît la différence entre 65 % et 25 %.
Ce qu'il faut faire avant d'adopter un agent
- Exigez des exécutions répétées, pas une démonstration unique. Faites de votre critère d'acceptation vingt exécutions consécutives de la même tâche sur les mêmes données. Un fournisseur qui refuse vous dit quelque chose.
- Mesurez l'état des données, pas le texte de la réponse. Définissez à l'avance à quoi l'enregistrement dans votre base de données doit ressembler après la tâche, et comparez la réalité à cette définition. Ne vous contentez pas de lire le résumé de l'agent.
- Testez les règles, pas seulement les tâches faciles. L'essentiel de votre travail n'est pas libre ; il est contraint par des règles : délais de retour, plafonds de crédit, dérogations pour les clients prioritaires. Un agent qui réussit sans contraintes peut s'écrouler à la première condition réelle.
- Construisez le jeu de tests à partir de vos propres cas. Prenez vingt cas réels des derniers mois, y compris les cas bizarres qui ont dérouté vos équipes, et transformez-les en une série fixe que vous exécutez sur tout modèle avant de l'adopter et après chaque mise à jour.
- Accordez l'autorité par étapes. Commencez par un agent qui propose sans exécuter, puis laissez-le réaliser des opérations à faible impact, puis élargissez son périmètre à mesure qu'un véritable historique de mesures s'accumule. L'autorité doit se gagner avec des données, pas avec des impressions.
Comment nous traitons cela chez Origami
Quand nous construisons un système qui comprend un agent d'IA, nous traitons l'agent comme n'importe quel autre composant logiciel : il reçoit une série de tests automatisés, des contrôles de vérification qui inspectent l'état de la base de données après chaque opération, et un point de transfert clair vers un humain dès qu'un seuil de confiance est franchi. Le modèle lui-même reste un réglage interchangeable plutôt qu'un élément soudé au code, car le meilleur modèle d'aujourd'hui n'est peut-être pas le meilleur dans trois mois.
La conclusion à retenir de cette étude n'est pas que les agents sont inutilisables. C'est que l'étalon avec lequel nous les jugions était le mauvais. Les agents sont aujourd'hui des outils puissants dans un périmètre bien défini et mesuré en continu, et très faibles quand un processus sensible leur est confié sur la foi d'une démonstration convaincante. La différence n'est pas dans le modèle ; elle est dans la discipline d'ingénierie qui l'entoure.
Sources
- Article de recherche : One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — arXiv (publié le 20 août 2026)
- Dépôt open source : microsoft/thinkingbox sur GitHub
Questions fréquentes
Quelle est la différence entre un agent d'IA qui réussit une fois et un agent fiable ?
Réussir une fois signifie que l'agent est capable de trouver un chemin correct dans la tâche. La fiabilité signifie qu'il trouve le chemin correct à chaque exécution. Dans l'étude de Microsoft, le meilleur modèle a réussi une fois sur 65,36 % des tâches mais n'a franchi les vingt tentatives que sur 25,25 %, et c'est cet écart qui détermine s'il convient à de vraies opérations.
Comment tester un agent d'IA avant de le relier aux systèmes de mon entreprise ?
Exécutez la même tâche vingt fois de suite sur les mêmes données, inspectez l'état de la base de données après chaque exécution au lieu de vous contenter de lire la réponse de l'agent, et utilisez des cas réels tirés de vos propres dossiers, comprenant des cas limites et des contraintes de politique interne, plutôt que des exemples idéaux simplifiés.
Cela veut-il dire qu'utiliser des agents d'IA en entreprise n'est pas sûr ?
Non, mais cela veut dire que l'étendue de leur autorité devrait s'élargir par la mesure plutôt que par l'impression. Commencez par un agent qui propose sans exécuter, puis autorisez-le à réaliser des opérations à faible impact, et élargissez ses autorisations progressivement à mesure que des résultats de tests répétés prouvent sa constance.
Quel est le type d'échec d'un agent d'IA le plus dangereux pour une entreprise ?
Les échecs silencieux, qui se terminent proprement sans message d'erreur mais laissent des données incorrectes, comme clôturer une commande sans réintégrer le stock. L'article de recherche indique que nombre d'échecs étaient de cette nature, et c'est pourquoi vous devez inspecter l'état des données plutôt que surveiller seulement les plantages.
Suivez Origami sur Google
Ajoutez Origami à vos sources préférées : nos articles apparaîtront en premier pour vous dans la recherche Google et les actualités à la une.
