Votre pilote a tourné sur le cas standard
Votre entreprise, elle, tourne sur les exceptions — et quelqu'un a déjà mesuré l'écart
- Un processus de vingt étapes fiables à 95 % chacune est juste, de bout en bout, 36 % du temps. Une exploitation d'entreprise a besoin de moins de 1 à 5 % d'échec. Cet écart, c'est le fossé entre le pilote et la production.
- Les agents qui réussissent une fois savent rarement recommencer : τ-bench mesure un pass^8 sous 25 % dans le commerce, et CRMArena-Pro passe de ~58 % en un tour à ~35 % en plusieurs.
- La preuve la plus nette est à l'échelle d'un pays : après dix ans d'obligations, l'assurance santé américaine a porté la vérification d'éligibilité à 96-99 % et la transmission des demandes à 98 % — mais l'accord préalable reste à 31-37 %. Les incitations n'ont pas déplacé la couche de jugement.
- Le travail réel est surtout de l'exception : 18,4 % des factures, seulement 12 % des dossiers d'assurance vie éligibles à une décision automatisée (et 83 % de ceux-là passent quand même par un humain), et des journaux de processus réels montrant jusqu'à 80 % de traces uniques.
- Air Canada a perdu devant un tribunal pour un agent conversationnel qui avait la bonne forme de la règle et la mauvaise condition de délai. Dommages : 650,88 $. C'est le montant qui fait la démonstration.
- Limite assumée : aucune étude ne relie la conception amont du traitement des exceptions au succès en production. Nous le disons plutôt que de revendiquer la preuve que nous aimerions avoir.
Votre pilote a marché. Il a traité les cas que vous lui avez donnés, la démonstration est passée, et tout le monde dans la salle a trouvé ça impressionnant. Six mois plus tard, c'est toujours un pilote.
Les explications habituelles sont la résistance au changement, la qualité des données, ou le modèle. Parfois c'est effectivement la réponse. Le plus souvent, le pilote a tourné sur le cas standard quand l'entreprise tourne sur les exceptions, et personne n'a mesuré l'écart avant de s'engager.
Ce n'est pas une affirmation molle sur la maturité organisationnelle. C'est de l'arithmétique, et ça a été mesuré à l'échelle d'un pays.
Le calcul que personne ne fait à voix haute
Prenez un processus de vingt étapes. Supposez chaque étape juste 95 % du temps — un chiffre dont la plupart des équipes se contenteraient volontiers.
De bout en bout, ce processus est correct 36 % du temps.
À 99 % par étape, c'est 82 %. À 99,5 %, 90 %. Une exploitation d'entreprise demande typiquement moins de 1 à 5 % d'échec, ce qui suppose une fiabilité par étape dans les neuf virgule quelque chose. La distance entre « impressionnant en démonstration » et « sûr en production » n'est pas un déficit d'enthousiasme. C'est plusieurs ordres de grandeur de fiabilité par étape, et elle se creuse en silence parce que personne ne voit jamais le chiffre à vingt étapes.
Les mesures disponibles disent que c'est exactement là que les systèmes cassent :
- Les agents qui réussissent une fois savent rarement recommencer. τ-bench (Sierra AI et Princeton, arXiv:2406.12045) note les agents sur l'état final d'une base de données plutôt que sur une grille, et introduit le pass^k — la probabilité de réussir k fois d'affilée. Verbatim : « même les agents d'appel de fonctions les plus avancés (comme gpt-4o) réussissent moins de 50 % des tâches, et sont très inconstants (pass^8 < 25 % dans le commerce). »
- C'est le multi-tour qui fait tomber. CRMArena-Pro (Salesforce AI Research, arXiv:2505.18878), construit sur 4 280 instances de tâches validées par des experts dans une organisation Salesforce réelle, mesure environ 58 % de réussite en un seul tour et près de 35 % en plusieurs. Notez qui publie : une recherche peu flatteuse pour la catégorie que vend son propre employeur.
- L'horizon annoncé est un pile ou face. METR (arXiv:2503.14499) a mesuré la durée de tâche qu'un modèle sait mener à bien, et trouve que l'horizon à 80 % de fiabilité est environ cinq fois plus court que celui à 50 %. Tous les titres « l'IA sait maintenant faire des tâches de plusieurs heures » citent le seuil pile ou face, pas celui qu'une direction des opérations signerait.
Lisez ça en regard de GDPval (OpenAI, arXiv:2510.04374), où des livrables produits en un coup et notés à l'aveugle par des professionnels d'environ quatorze ans d'expérience atteignent une qualité proche de l'expert. Les deux résultats sont vrais, et ensemble ils tiennent tout le schéma en deux phrases : un artefact, un coup, noté sur la qualité — c'est la démonstration. Une exécution répétée, multi-étapes, contre un état — c'est la production. Les modèles sont forts sur la première et faibles sur la seconde.
Quelle part du travail réel est de l'exception
Voici la partie qui décide si un processus vaut la peine d'être automatisé, et que presque personne ne mesure avant de commencer.
L'assurance santé, au volume de transactions d'un pays. L'indice CAQH rapporte les comptages annuels réels de transactions entre assureurs, soignants et chambres de compensation — des milliards, pas un sondage. Après une décennie d'obligations, d'incitations financières et de normalisation, les transactions mécaniques sont allées presque au bout : vérification d'éligibilité 96-99 % entièrement électronique, transmission des demandes 98 %. Celle qui demande du jugement n'a pas bougé. L'accord préalable reste à 31-37 %, l'un des plus bas de l'indice, avec environ trois points gagnés par an.
Même secteur, mêmes obligations, même argent, même décennie. Travail mécanique : 98 %. Travail de jugement : un tiers. C'est l'expérience naturelle la plus propre dont on dispose sur l'endroit où l'automatisation s'arrête, et la variable n'est ni la technologie ni la bonne volonté. C'est la présence d'un jugement dans l'étape.
La comptabilité fournisseurs. State of ePayables 2025 d'Ardent Partners (n=204) trouve 18,4 % de factures en exception et seulement 35,4 % de traitement direct. Les meilleures organisations tournent à 11,1 % d'exceptions contre 20,9 % pour les autres — mieux, pas résolu. La phrase à retenir est celle du rapport lui-même : « le même problème d'exceptions devra être résolu à nouveau (et encore). » Les répondants d'une enquête sur l'automatisation des paiements sont plus automatisés que le terrain : traitez 18,4 % comme un plancher.
La tarification en assurance vie. L'enquête américaine 2024 de Gen Re sur la souscription accélérée trouve que seulement 12 % des dossiers sont éligibles à une décision entièrement automatisée — et que 83 % de ceux-là passent quand même par un souscripteur humain. À l'intérieur même de la population facile et pré-qualifiée, cinq cas sur six touchent une personne.
Et la forme des données de processus réelles. Une analyse de 98 journaux d'événements publics (TU Munich, BPM 2025) trouve des processus réels comportant jusqu'à 22 632 variantes distinctes. Dans le journal Sepsis Cases, très utilisé, 1 050 traces produisent 845 variantes — soit environ 80 % de traces uniques. Quatre cas réels sur cinq suivent un chemin qu'aucun autre ne suit. Un pilote construit sur le chemin le plus fréquent n'a pas vu le processus.
Ce que ça coûte quand ça tourne mal
Moffatt c. Air Canada, 2024 BCCRT 149, est l'exemple documenté le plus net qui existe, et il est petit à dessein. L'agent conversationnel d'Air Canada a indiqué à un passager que les tarifs deuil pouvaient être réclamés rétroactivement sous 90 jours. La règle réelle dit le contraire. Air Canada a soutenu devant le tribunal que l'agent était « une entité juridique distincte, responsable de ses propres actes ». Réponse du tribunal : « Voilà une thèse remarquable… Peu importe que l'information provienne d'une page statique ou d'un agent conversationnel. » Déclaration inexacte par négligence. Dommages : 650,88 $.
Le système avait la forme générale de la règle juste et la condition de délai de l'exception fausse. C'est ça, le mode de défaillance. Pas une invention grossière que n'importe qui repérerait — une réponse plausible sur une dérogation rare, servie avec exactement la même assurance que les réponses correctes.
Un second exemple, rapporté cette fois par l'équipe qui a construit le système. AJ Asver, qui dirige Grep (anciennement Parcha Labs), a publié dix leçons tirées de trois ans d'agents en production pour des établissements de paiement et de courtage. L'une d'elles est un défaut de décembre 2024 dans leur chaîne de vérification d'entreprise, qui cherche ce qui se dit de mauvais sur une société avant d'entrer en relation avec elle. Ses mots : « l'implémentation contenait une condition fausse. Elle ne lançait Google Search que si Google News ne renvoyait aucun résultat. » Et la conséquence : « si Google News trouvait un seul résultat maigre ou hors sujet, la recherche large n'avait jamais lieu, ce qui pouvait exclure des articles de presse négatifs importants. » Les dossiers ne revenaient pas vides. Ils revenaient propres. « L'erreur nous a coûté cinq chiffres en remboursements », plus des milliers de dossiers à repasser.
Cette condition est l'argument entier, en une ligne de code. Une question de jugement — ce que j'ai trouvé suffit-il ? — écrite comme un test mécanique — ai-je trouvé zéro résultat ? Les deux se ressemblent, une seule est vraie. Le système était capable de voir que sa moisson était maigre ; la règle lui interdisait d'y retourner. Le résumé que le même auteur fait de la distance qu'il a dû parcourir : « une démo qui marche représente environ 10 % de l'effort. Prévoyez les 90 % restants pour la régularité, la reprise, l'évaluation et le volume. » À prendre comme un témoignage et non comme une mesure — c'est un éditeur qui écrit sur son propre produit — recevable parce qu'il va contre son intérêt.
Ce qu'il faut en faire — et ce que personne ne peut encore prouver
Le principe de conception qui en découle n'est pas « mettre un humain dans la boucle » comme slogan. C'est une question sur les cas qui ont le droit d'être tranchés sans personne, à répondre avant la construction et non après.
Trois questions à poser sur un processus réel :
- Quelle part du volume est de l'exception ? Pas estimée — comptée, dans les journaux. Si personne ne sait produire le chiffre, c'est déjà le premier constat.
- Qu'arrive-t-il à l'exception quand le cas standard est automatisé ? Retirer les 70 % de routine ne laisse pas les 30 % restants inchangés. Ça retire le travail courant qui entretenait la compétence des gens sur le domaine, et il ne reste plus que la file des exceptions.
- Combien de travail humain subsiste après le passage du système ? Si un senior doit reconstruire tout le dossier avant de valider ce que le système a produit, presque rien n'a disparu. C'est la mesure qui sépare un gain de productivité d'un théâtre de productivité, et elle n'est presque jamais prise.
Maintenant la partie honnête. La conclusion évidente de tout ceci serait que concevoir le chemin d'escalade en amont est ce qui sépare les déploiements qui marchent de ceux qui calent. Nous aimerions l'affirmer. Nous ne le pouvons pas : aucune étude ne relie la conception amont des exceptions au succès en production. Ce qui existe est une littérature de laboratoire sur l'apprentissage de la délégation, montrant qu'un passage de relais bien conçu peut battre l'humain comme le modèle pris séparément — dans une démonstration, un hybride assisté par preuves atteint 91,3 % contre 87,7 % pour le modèle seul. Cette littérature porte aussi deux constats qui coupent court à l'optimisme facile : la façon d'accompagner un humain traitant une file de cas délégués à faible confiance est très peu étudiée, et à mesure que les relecteurs progressent avec la pratique, certaines formes d'assistance cessent d'aider pour commencer à nuire.
Un principe de ces travaux survit au contact du terrain, et il vaut d'être emporté : router sur le rayon d'impact et la réversibilité, pas sur la confiance du modèle. La confiance verbalisée est un signal faible. « Quelle gravité si c'est faux, et peut-on revenir en arrière ? » est une question à laquelle l'entreprise répond sans l'aide du modèle.
Le cabinet qui disait déjà ça en 2016
Il existe un précédent utile, tiré de la vague d'automatisation précédente. Les recommandations RPA d'EY en 2016 — écrites par un cabinet qui vendait des déploiements RPA — disaient : « Automatiser 70 % d'un processus, la part de plus faible valeur, et laisser les 30 % de forte valeur aux humains est un bon objectif initial. »
Le premier fournisseur de la vague d'automatisation précédente recommandait d'en laisser environ un tiers aux personnes, comme objectif de conception, dès le premier jour. La vague qui a suivi a produit ce constat de Deloitte en 2018 : seules 3 % des organisations avaient dépassé les 50 robots, 33 % en étaient encore au pilote, et « la standardisation des processus est le premier obstacle à tous les stades. »
La technologie est bien meilleure aujourd'hui. La distribution du travail réel, elle, n'a pas changé.
La version en une ligne
Votre pilote a prouvé qu'une démonstration passe. Il n'a pas prouvé que votre processus tient. Ce sont deux affirmations différentes, et seule la seconde a un budget attaché.
Si vous avez un processus où l'IA devrait rapporter et ne rapporte pas, la première chose à mesurer n'est pas le modèle. C'est la part de votre volume qui n'a jamais ressemblé à la démonstration.
C'est de l'arithmétique, pas une étude : 0,95 à la puissance 20 vaut 0,358. Un processus de vingt étapes dont chacune est juste 95 % du temps aboutit correctement environ 36 % du temps. À 99 % par étape, c'est 82 % ; à 99,5 %, 90 %. Si nous l'énonçons, c'est parce que la fiabilité par étape est ce qu'on démontre en pilote, et la fiabilité de bout en bout ce que l'entreprise vit réellement. Personne ne calcule le second chiffre à voix haute.
Parce que c'est une expérience naturelle à l'échelle d'un pays, établie sur des comptages réels de transactions annuelles et non sur un sondage. L'indice CAQH montre qu'une décennie d'obligations, d'incitations financières et de normalisation a porté les transactions mécaniques à 96-99 % de traitement électronique, tandis que l'accord préalable — celui qui exige un jugement — restait à 31-37 %. Même secteur, mêmes incitations, même décennie. La variable qui prédit le résultat est la présence ou non d'un jugement dans l'étape. Un piège à connaître : « entièrement électronique » mesure le canal, pas l'absence d'intervention humaine.
Non — presque tout en comporte. L'argument est que le taux d'exception doit être compté dans les journaux avant la construction, pas découvert après, et que la vraie question de conception est : quels cas peuvent être tranchés sans personne ? EY, qui vendait des déploiements RPA en 2016, recommandait d'automatiser les 70 % de plus faible valeur et de laisser 30 % aux humains comme objectif initial. C'est une posture de départ raisonnable, et elle a été écrite par le fournisseur.
En routant sur le rayon d'impact et la réversibilité, pas sur la confiance du modèle. La confiance verbalisée est un signal faible, et l'entreprise sait répondre sans le modèle à « quelle gravité si c'est faux, et peut-on revenir en arrière ? ». Rédiger une note interne et modifier un contrat client peuvent tourner sur le même modèle tout en justifiant des niveaux d'autonomie entièrement différents.
Pas à l'échelle d'un déploiement, et nous pensons que le dire vaut mieux que de prétendre le contraire. Aucune étude ne relie la conception amont des exceptions au succès en production. Ce qui existe est une littérature de laboratoire sur l'apprentissage de la délégation, montrant qu'un passage de relais bien conçu peut battre chacune des deux parties prise seule — une démonstration atteint 91,3 % pour un hybride assisté par preuves contre 87,7 % pour le modèle seul. Cette même littérature constate que l'accompagnement d'un humain traitant une file de cas délégués à faible confiance est très peu étudié, et que certaines formes d'assistance cessent d'aider pour commencer à nuire à mesure que les relecteurs progressent.
Apportez un travail que vos équipes font encore à la main.
Vingt minutes : si c'est faisable chez vous, et par où ça commence →Pas encore prêt à en parler ? Lisez comment nous reprenons un travail fait à la main — rien à payer, rien à engager.