Pourquoi les agents IA échouent sur les tâches longues, et comment les rendre fiables.
Les petits taux d'erreur se cumulent d'étape en étape. L'arithmétique des agents peu fiables, et les deux leviers de conception qui les rendent sûrs en production.
Publié le · 7 min de lecture
Un agent IA qui réussit parfaitement une tâche de trois étapes en démonstration peut s'effondrer sur une tâche de vingt étapes en production. Le modèle n'est pas devenu moins capable. La tâche est devenue plus longue, et les petits taux d'erreur se cumulent. Comprendre cette arithmétique est ce qu'une équipe peut faire de plus utile avant de confier un vrai travail à un agent.
L'arithmétique des tâches longues
Supposons que chaque étape d'une tâche, comme lire un document, appeler un outil ou décider de la suite, réussisse 95 % du temps. Cela paraît fiable. Mais une tâche ne réussit que si toutes ses étapes réussissent, donc les probabilités se multiplient. Sur vingt étapes, 0,95 multiplié vingt fois par lui-même donne environ 0,36. À peu près deux tâches sur trois contiennent au moins une erreur.
| Nombre d'étapes | 99 % de réussite par étape | 95 % de réussite par étape | 90 % de réussite par étape |
|---|---|---|---|
| 1 | 99 % | 95 % | 90 % |
| 2 | 98 % | 90 % | 81 % |
| 3 | 97 % | 86 % | 73 % |
| 4 | 96 % | 81 % | 66 % |
| 5 | 95 % | 77 % | 59 % |
| 6 | 94 % | 74 % | 53 % |
| 7 | 93 % | 70 % | 48 % |
| 8 | 92 % | 66 % | 43 % |
| 9 | 91 % | 63 % | 39 % |
| 10 | 90 % | 60 % | 35 % |
| 11 | 90 % | 57 % | 31 % |
| 12 | 89 % | 54 % | 28 % |
| 13 | 88 % | 51 % | 25 % |
| 14 | 87 % | 49 % | 23 % |
| 15 | 86 % | 46 % | 21 % |
| 16 | 85 % | 44 % | 19 % |
| 17 | 84 % | 42 % | 17 % |
| 18 | 83 % | 40 % | 15 % |
| 19 | 83 % | 38 % | 14 % |
| 20 | 82 % | 36 % | 12 % |
| 21 | 81 % | 34 % | 11 % |
| 22 | 80 % | 32 % | 10 % |
| 23 | 79 % | 31 % | 9 % |
| 24 | 79 % | 29 % | 8 % |
| 25 | 78 % | 28 % | 7 % |
| 26 | 77 % | 26 % | 6 % |
| 27 | 76 % | 25 % | 6 % |
| 28 | 75 % | 24 % | 5 % |
| 29 | 75 % | 23 % | 5 % |
| 30 | 74 % | 21 % | 4 % |
La courbe est impitoyable dans les deux sens. À 90 % par étape, une tâche de vingt étapes réussit environ une fois sur huit. À 99 % par étape, elle échoue encore presque une fois sur cinq. Même un très bon modèle, laissé seul sur une longue chaîne, produira un flux régulier de résultats faux.
Les systèmes réels ne sont pas tout à fait aussi simples. Certaines erreurs sont sans conséquence, certaines étapes sont bien plus faciles que d'autres, et un modèle capable remarque parfois ses propres erreurs et les corrige. Mais la tendance tient, et elle correspond à ce que constatent les équipes qui passent d'une démonstration aux volumes de production : les problèmes apparaissent dans la longue traîne des tâches qui demandent beaucoup d'étapes.
Deux leviers qui changent le résultat
L'arithmétique indique aussi la solution. La fiabilité dépend du nombre d'étapes confiées au modèle et de ce qui se passe quand l'une d'elles échoue. Cela donne deux leviers.
Confier moins d'étapes au modèle
Une grande partie de ce qu'un agent fait en boucle n'a pas besoin d'un modèle de langage. Récupérer un enregistrement, appeler une API avec des paramètres connus, mettre en forme un fichier ou écrire dans une base de données relèvent du code ordinaire : déterministe, testable et fiable en pratique à 100 %. Chaque étape déplacée du modèle vers le code raccourcit la chaîne.
Concrètement, cela signifie concevoir un workflow plutôt que confier un objectif ouvert à un agent. Le modèle traite les parties qui demandent du jugement ou du langage, comme lire un document non structuré, classer une demande ou rédiger une réponse. Le code s'occupe de tout le reste.
Contrôler chaque étape restante
Le second levier consiste à intercepter les erreurs avant qu'elles ne se propagent. Après chaque étape du modèle, on contrôle la sortie : validation par rapport à un schéma, rapprochement des chiffres avec la source, exécution des tests du code généré, ou relecture par un second modèle selon des critères explicites. Quand un contrôle échoue, on relance l'étape une fois, puis on escalade.
Les contrôles n'ont pas besoin d'être parfaits pour être utiles. Dans l'exemple chiffré ci-dessous, un contrôle qui détecte quatre erreurs sur cinq fait passer la fiabilité effective de chaque étape de 95 % à près de 99 %. Sur vingt étapes, la tâche passe de 36 % à 79 % de réussite.
Combinés, les deux leviers transforment un système qui se trompe la plupart du temps en un système qui a raison plus de neuf fois sur dix. Et les échecs restants ne sont plus silencieux : ils remontent à un contrôle, où une personne peut les examiner.
À quoi ressemble un workflow de production
Au final, un agent fiable ressemble moins à un assistant autonome qu'à un processus bien conçu comportant quelques étapes intelligentes. Voici la structure que nous utilisons pour le travail administratif riche en documents, comme le traitement des factures fournisseurs.
- CodeRécupérer la facture et la commande associéeAppels d'API classiques, aucune décision.
- ModèleExtraire les montants, dates et lignesSortie dans un schéma strict.
- ContrôleValider le schéma et rapprocher les totauxEn cas d'échec : une relance, puis escalade.
- ModèleExpliquer les écarts avec la commande
- HumainApprouver les écarts au-dessus d'un seuilLes cas courants passent sans intervention.
- CodeÉcrire dans l'ERP et journaliser chaque étape
Trois propriétés comptent plus que le détail des étapes.
- La sortie du modèle est toujours structurée. Un texte libre est difficile à contrôler. Un schéma strict, avec des champs obligatoires, des types et des valeurs autorisées, transforme « est-ce correct ? » en un test que le code peut exécuter.
- L'escalade fait partie de la conception. Une personne examine les cas que le système ne peut pas trancher : un contrôle en échec après une relance, un montant au-dessus d'un seuil, un fournisseur jamais vu. Les cas courants passent directement, et les équipes consacrent leur temps aux exceptions.
- Chaque étape est journalisée. Quand quelque chose se passe mal, il faut savoir quelle étape a échoué, avec quelle entrée, et ce que le modèle a renvoyé. Sans cette trace, un agent ne peut être ni débogué, ni audité, ni amélioré.
Mesurer la bonne chose
La qualité d'un agent est généralement mesurée par réponse ou par étape. Ce que vit l'entreprise, c'est le taux de réussite par tâche. Avant le déploiement, constituez un ensemble de tâches réelles dont le bon résultat est connu, et mesurez combien le système en mène correctement à terme et combien il en escalade. Suivez les deux dans le temps. Un taux d'escalade qui monte est souvent le premier signe que les données d'entrée ont changé.
Cette mesure sert aussi à décider. Si un nouveau modèle améliore la précision par étape, la mesure par tâche indique si cela compte vraiment. Si une étape échoue souvent, vous voyez s'il faut améliorer le prompt, ajouter un contrôle ou basculer cette étape dans le code.
Par où commencer
Choisissez un workflow répétitif, dont les bonnes réponses sont claires et qui prend aujourd'hui un temps réel, comme le tri des demandes entrantes, l'extraction de données depuis des documents ou le rapprochement d'enregistrements. Cartographiez ses étapes, décidez lesquelles ont besoin d'un modèle, et concevez les contrôles avant d'écrire le moindre prompt. Nos projets d'IA appliquée suivent cette approche, et vous pouvez nous décrire votre workflow pour savoir s'il s'y prête.