Pourquoi les agents échouent sur les tâches longues.
Un agent parfait sur 3 étapes peut s’effondrer sur 20. Voici l’arithmétique derrière ce problème, et les deux leviers que j’utilise pour le rendre fiable.
Par Nizar Oukhchi, Architecte solution
Publié le · 7 min de lecture
Vous construisez un agent IA. En démonstration, vous lui confiez une tâche de trois étapes, et il la réussit parfaitement.
Puis vous le mettez en production, vous lui donnez une tâche de vingt étapes, et tout s’effondre.
Que s’est-il passé ? Le modèle est-il devenu moins bon ?
Les petites erreurs se multiplient
Le modèle n’est pas devenu moins bon. La tâche est devenue plus longue.
Prenons un exemple. Disons que chaque étape d’une tâche, comme lire un document, appeler un outil ou décider de la suite, réussit 95 % du temps.
Ça paraît plutôt fiable, non ?
Sauf qu’une tâche ne réussit que si toutes ses étapes réussissent. Les probabilités se multiplient donc. Sur vingt étapes, cela fait 0,95 multiplié vingt fois par lui-même, soit environ 0,36.
À peu près deux tâches sur trois contiennent au moins une erreur.
Voici à quoi ressemble cette courbe :
| 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 % |
Et elle 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 donc un flux régulier de résultats faux.
Avant de confier un vrai travail à un agent, comprenez cette arithmétique. Je pense que c’est la chose la plus utile qu’une équipe puisse faire.
Je vais être honnête : 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 sa propre erreur et la corrige.
Mais la tendance tient. C’est 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
Bonne nouvelle : la même arithmétique indique comment s’en sortir.
La fiabilité dépend de deux choses :
- Le nombre d’étapes que vous laissez au modèle.
- Ce qui se passe quand l’une d’elles échoue.
Cela vous donne deux leviers.
Confier moins d’étapes au modèle
Voici une chose que l’on oublie facilement (moi le premier) : une grande partie de ce qu’un agent fait en boucle n’a pas du tout 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 ? Écrire dans une base de données ?
C’est du code ordinaire. Déterministe, testable, et fiable en pratique à 100 %.
Chaque étape que vous déplacez du modèle vers le code raccourcit la chaîne.
Concrètement, cela veut dire concevoir un workflow plutôt que confier un objectif ouvert à un agent. Le modèle traite les parties qui demandent vraiment 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.
Ne demandez au modèle que ce que lui seul sait faire.
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, contrôlez ce qu’il a produit. Vous pouvez :
- Valider la sortie par rapport à un schéma.
- Rapprocher les chiffres de la source.
- Exécuter les tests du code généré.
- Faire relire le résultat par un second modèle, selon des critères explicites.
Si un contrôle échoue, relancez l’étape une fois. S’il échoue encore, escaladez.
Faut-il que les contrôles soient parfaits ? Pas du tout.
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.
Voici ce que donnent les deux leviers, séparément et ensemble :
Combinés, ils transforment un système qui se trompe la plupart du temps en un système qui a raison plus de neuf fois sur dix.
Autre bénéfice : les échecs restants ne sont plus silencieux. Ils remontent à un contrôle, où une personne peut les examiner.
À quoi ça ressemble en production
Au final, un agent fiable ressemble moins à un assistant autonome qu’à un processus bien conçu, avec quelques étapes intelligentes.
Pardonnez-moi cette métaphore un peu facile, mais c’est un peu comme une cuisine. Le chef ne fait pas la vaisselle et ne compte pas les livraisons. Il cuisine, et tout le reste est organisé pour qu’il puisse bien le faire.
Voici la structure que nous utilisons chez Admeliora 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
Le détail des étapes compte moins que trois propriétés.
- 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 tâche, pas l’étape
Comment savoir si tout cela fonctionne ?
La qualité d’un agent est généralement mesurée par réponse ou par étape. Mais ce n’est pas ce que vit l’entreprise. Ce qu’elle vit, c’est le taux de réussite par tâche.
Avant le déploiement, voici ce que je ferais :
- Constituer un ensemble de tâches réelles dont le bon résultat est connu.
- Mesurer combien le système en mène correctement de bout en bout.
- Mesurer combien il en escalade.
- Suivre 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. Imaginons qu’un nouveau modèle sorte avec une meilleure précision par étape. Est-ce que ça compte vraiment ? La mesure par tâche vous le dit. Imaginons qu’une étape échoue souvent. Faut-il améliorer le prompt, ajouter un contrôle ou basculer cette étape dans le code ? Là encore, vous le voyez.
Si vous ne mesurez qu’une chose, mesurez des tâches entières.
Par où commencer
Choisissez un workflow. Il doit être répétitif, avoir des bonnes réponses claires et prendre aujourd’hui un temps réel. Le tri des demandes entrantes, l’extraction de données depuis des documents ou le rapprochement d’enregistrements sont de bons exemples.
Ensuite :
- Cartographiez ses étapes.
- Décidez lesquelles ont vraiment besoin d’un modèle.
- Concevez les contrôles avant d’écrire le moindre prompt.
C’est tout. C’est moins magique qu’un agent autonome, mais ça marche.
Nos projets d’IA appliquée suivent exactement cette approche. Si vous avez un workflow en tête, décrivez-le-nous et nous vous aiderons à voir s’il s’y prête.