Pourquoi les systèmes agentiques échouent quand les étapes se multiplient : fiabilité, orchestration et limites des agents IA autonomes.
Considérons un agent IA qui réussit 95 % de ses actions. Le résultat paraît excellent. Mais s’il doit enchaîner 14 actions sans erreur pour terminer une mission, sa probabilité de réussite globale tombe à environ 49 %. Autrement dit, un agent apparemment très fiable peut échouer une fois sur deux.
Ce calcul change la manière d’évaluer les systèmes autonomes. Un agent ne se contente pas de répondre à une question : il comprend des consignes, enchaine des actions, interroge des outils, analyse ses réponses, actualise son plan, puis recommence. Chaque étape ajoute une nouvelle occasion de se tromper.
Lorsque toutes les actions sont indispensables, leurs probabilités de réussite se multiplient. Si chaque étape a une probabilité de succès p et que le parcours en comporte n, la fiabilité théorique de l’ensemble devient pn. Un seul maillon défaillant peut donc compromettre toute la chaîne.
C’est là que se cache le véritable enjeu : réussir une action ne garantit pas la réussite de toute la mission. Dans le cadre d'une démonstration sur un parcours court et bien balisé, avec des données complètes et bien calibrées, l’agent peut paraître infaillible. Mais en conditions réelles, il rencontrera certainement des données incomplètes, des cas imprévus et des enchaînements plus complexes. Ce qui compte vraiment, ce n’est donc pas son score à chaque étape, mais sa capacité à aller jusqu’au bout sans erreur.
Plus le parcours s’allonge, plus la fiabilité chute
À 95 % de réussite par étape, un parcours de 10 actions ne réussit intégralement que dans environ 59 % des cas. À 20 actions, il tombe à 35 %. À 50 actions, il atteint à peine 7 %.
Même si le modèle présente une excellente performance à chaque étape, cela ne suffit donc pas pour garantir la réussite sur un processus long : une fiabilité de 99 % par action ne règle pas entièrement le problème : sur 20 étapes, la réussite globale avoisine 82 %, soit près d’un échec sur cinq. Pour une simple recommandation, ce niveau peut parfois être acceptable. Pour une action qui porte plus de conséquences, telle qu'un remboursement, une commande ou la modification d’un compte client, ce niveau de réussite peut être rédhibitoire.
Ces calculs reposent en outre sur l’hypothèse favorable d'un enchainement d’étapes indépendantes. Dans la réalité, une erreur précoce, même minime, influence souvent les décisions suivantes. La fiabilité réelle peut donc être inférieure au résultat mathématique.
Pourquoi un agent multiplie les actions
Avant de répondre à cette question, il convient de rappeler que les usages actuels de l'intelligence artificielle évoluent vers l'agentique, mais qu'en fonction des besoins et de la complexité des cas d'usage, on ne va pas utiliser des agents aux mêmes capacités. On peut distinguer trois types d'usages, du plus simple au plus complexe, avec des capacités et des degrés d'autonomie radicalement différents.
Chatbot, copilote, agent : trois rôles distincts
Le chatbot répond : il explique, recherche une information, résume un document ou reformule un contenu. Il éclaire l’utilisateur, mais ne poursuit pas le travail à sa place.
Le copilote assiste : il prépare un texte, une analyse ou une décision. L’humain conserve toutefois la maîtrise du processus, vérifie la proposition et déclenche l’action.
L’agent autonome agit. Il reçoit un objectif, établit un plan, utilise des outils, observe les résultats et adapte la suite de son parcours. Il peut rechercher un document, interroger une base SQL, créer un ticket, modifier une fiche dans un CRM, consulter un ERP ou envoyer un message.
Cette capacité d’action fait sa valeur, mais aussi sa fragilité. Un agent de production ressemble moins à un simple assistant conversationnel qu’à un logiciel orchestré, connecté aux données et aux applications de l’entreprise.
La boucle qui fait agir l’agent
Le fonctionnement d’un agent IA repose généralement sur une boucle : comprendre, planifier, agir, observer, corriger. À partir de l’objectif reçu, le modèle LLM qui sert de "moteur" à l'agent interprète la demande, choisit une première étape et sélectionne l’outil adapté. Une couche logicielle exécute ensuite l’action, par exemple rechercher un document, interroger une base de données ou créer un ticket, puis transmet le résultat au modèle.
L’agent compare alors ce résultat à l’objectif initial. Si une information manque, il peut demander une précision, consulter une autre source ou modifier son plan. Si le résultat est satisfaisant, il passe à l’étape suivante. Cette boucle se répète jusqu’à l’accomplissement de la mission, l’atteinte d’une limite prédéfinie ou la nécessité d’une validation humaine. L’agent ne suit donc pas toujours un scénario figé : il ajuste son parcours à partir de ce qu’il observe, ce qui lui donne son autonomie mais multiplie aussi les risques d’erreur.
Pour ne pas perdre le fil entre deux actions, l’agent conserve un état : une sorte de mémoire de travail mise à jour tout au long de la mission. Cet état rassemble l’objectif initial, les informations récupérées, les actions déjà tentées, leurs résultats, les blocages rencontrés et les décisions prises. Sans lui, l’agent repartirait de zéro à chaque étape. Grâce à lui, il peut suivre un dossier complexe et adapter son plan. Mais cette continuité comporte un risque : si une information erronée entre dans l’état sans être corrigée, elle peut influencer toutes les décisions suivantes.
Pour transformer les décisions de l’agent en actions concrètes, une couche logicielle joue un rôle d'orchestration. Elle transmet les demandes aux bons outils, contrôle les autorisations, récupère les réponses et met à jour l’état de la mission. Elle fixe aussi les délais d’attente, décide s’il faut réessayer après un échec et peut confier une tâche à un autre agent ou solliciter un humain. Sans elle, le modèle peut proposer une action, mais il ne sait ni l’exécuter de manière sûre ni organiser la suite du parcours. Cette mécanique a toutefois un coût : plus elle mobilise d’outils, de règles et d’échanges, plus le système devient lent, coûteux et difficile à surveiller. Une orchestration fiable doit donc encadrer les décisions sans alourdir inutilement la mission.
Le multi-agents n’est pas une solution magique
Une mission étendue peut être répartie entre plusieurs agents spécialisés. Un coordinateur distribue alors le travail à un agent de recherche, un agent chargé d’améliorer les requêtes, un agent de synthèse ou un agent de vérification des faits.
Cette architecture peut être performante lorsque les responsabilités sont clairement séparées et réutilisables. Dans le cas contraire, elle ajoute surtout des échanges entre agents qui sont autant d'opportunités de perte ou de corruption d'informations. En effet, les échanges entre agents se font généralement dans notre langage et non dans celui dans lequel ils "pensent". Cela nécessite donc une conversion du contexte (état complet, tokenisé, avec de nombreuses informations et probabilités) en langage humain, et cette conversion s'accompagne inévitablement d'une perte d'information.
Une étude portant sur plus de 200 000 conversations simulées, 15 modèles et huit fournisseurs rapporte une baisse moyenne de 39 % de précision dans les échanges en plusieurs tours. Or, une donnée oubliée ou déformée pendant un échange entre agents peut contaminer tout le système en cascade.
Le bon choix n’est donc pas toujours de multiplier les agents. Il faut comparer le gain de spécialisation avec le coût de coordination, la latence et la difficulté à maintenir un état commun. Une équipe d’agents mal organisée peut devenir une véritable "bureaucratie logicielle".
Comment une petite erreur devient critique
Une mauvaise hypothèse change toute la trajectoire
Imaginons qu’un agent de support classe une demande technique dans la catégorie "facturation". Cette première erreur détermine les documents consultés, les outils utilisés et le service contacté. Chaque décision suivante peut sembler logique tout en reposant sur un point de départ faux.
Dans un long échange, le contexte peut aussi se dégrader. Une contrainte métier formulée au début est parfois résumée trop vite, noyée dans l’historique ou remplacée par une interprétation moins exacte.
Le danger tient à la cohérence apparente du résultat. L’agent peut suivre un raisonnement ordonné, produire une réponse convaincante et pourtant poursuivre la mauvaise mission. Une erreur agentique n’est donc pas toujours visible, mais elle peut devenir la donnée d’entrée de toutes les étapes suivantes.
L’échec silencieux
Les incidents les plus difficiles à détecter ne provoquent aucun blocage. Une API répond, le format semble correct et l’agent continue. Pourtant, il peut avoir sélectionné la mauvaise fiche client, utilisé un tarif périmé ou confondu une disponibilité provisoire avec une confirmation.
Le système a techniquement fonctionné, mais son résultat est faux. Une surveillance limitée aux erreurs retournées par les interfaces logicielles ne détectera pas ce problème. Il faut vérifier la justesse métier de l’action, pas seulement l’absence de panne.
La qualité des données est tout aussi déterminante. Un agent connecté à un CRM incomplet, à un ERP incohérent ou à une base documentaire obsolète ne peut pas détecter ni corriger spontanément les défauts de la donnée. Il va s'y fier et les transformer rapidement en décisions. Comme le résume l’approche de Neowin, un système robuste exige des données propres, une orchestration claire et des garde-fous solides.
Cinq règles pour reprendre le contrôle
La fiabilité ne dépend donc pas seulement du modèle. Elle se construit dans l’architecture, les règles d’accès, les contrôles et la supervision. Cinq mesures réduisent fortement l’exposition au risque.
1. Raccourcir les missions
Commencez par le parcours le plus court possible. Chaque sous-tâche doit répondre à un objectif précis et rester reliée à la mission principale. Fixez des limites de durée, d’étapes, de nouvelles tentatives et de consommation de ressources. Une fois la limite atteinte, l’agent doit livrer un résultat partiel, s’arrêter ou solliciter un humain.
L’approche Deep Agents insiste sur ce lien permanent entre les sous-tâches et l’objectif général. ScriptsHub rapporte de son côté une refonte ayant fait progresser un taux de réussite de 71 % à 94 % en 60 jours. Pour ce faire, ils ont resserré le périmètre de chaque agent ou tâche, ajouté une validation sur les appels d’outils et les ont rendus idempotents, ont rendu l'état persistant, et les actions sensibles ont été encadrées par des règles ou une validation humaine. Avec une meilleure observabilité, ce chantier a fait passer le taux de réussite de 71 % à 94 % et réduit les actions erronées silencieuses de 18 % à 1,2 % en 60 jours.
2. Installer des points de contrôle
Avant de poursuivre, l’agent doit vérifier le format, les champs obligatoires, la cohérence des données et l’alignement avec l’objectif. Si le contrôle échoue, il revient à un état valide ou suspend le processus. La persistance d’état illustrée par LangGraph permet notamment de reprendre un parcours sans tout recommencer.
3. Séparer proposition et autorisation
Le modèle peut suggérer une action ; une règle déterministe doit décider si elle est permise. Les outils peuvent être classés selon leur niveau d’accès : lecture, écriture ou suppression. Les droits, le montant, le statut du dossier et la nécessité d’une validation humaine doivent être contrôlés avant l’exécution.
Les opérations sensibles doivent aussi être idempotentes : une nouvelle tentative ne doit jamais provoquer deux paiements, deux messages ou deux modifications identiques.
4. Tout journaliser
Il faut historiser dans des logs toutes les consignes, les appels d’outils, les données d’entrée et de sortie, les décisions, la latence, le coût et le résultat final. Ces traces permettent de contrôler a postériori le bon fonctionnement du système et, en cas d'erreur, d'identifier ce qui n'a pas fonctionné. En analysant les historiques, on peut rejouer l'histoire d'un dossier, et localiser la première anomalie : donnée périmée, outil mal décrit, permission excessive ou contrôle absent. Une fois l'erreur identifiée, cela permet d'ajouter des consignes, contrôles et garde-fous pour éviter qu'elle ne se reproduise.
5. Faire intervenir l’humain au bon moment
L’humain n’a pas besoin de surveiller chaque étape du workflow agentique. Cependant, il doit intervenir lorsqu’une action est irréversible, coûteuse, ambiguë ou sensible. La séquence la plus sûre est souvent la suivante : l’IA propose, l’humain arbitre, l’IA exécute.
L’autonomie peut ensuite progresser sur les cas bien maîtrisés. Les exceptions et les décisions à fort impact doivent rester supervisées.
Pourquoi les démos trompent
Une démonstration utilise généralement des données propres, un parcours court, des consignes claires et peu de cas limites. La production expose l’agent à des dossiers incomplets, des droits variables, des API lentes, des utilisateurs contradictoires et des exceptions métier.
Selon ProdigalTech, 80 % des entreprises auraient déjà déployé une forme d’IA générative, tandis que seuls 15 % des responsables technologiques déclarent utiliser des agents autonomes en production. Ce n'est pas un manque d'intérêt, mais une prudence saine des décideurs IT. Même s'ils sont majoritairement convaincus de la nécessité d'adopter l'IA dans les processus de l'entreprise, ils ne peuvent se permettre d'utiliser des systèmes insuffisamment fiables pour des tâches critiques.
Les incidents recensés par LensHQ montrent ce qui peut se produire lorsqu’un système agentique déraille : un agent web a effectué un achat sans autorisation, un chatbot municipal new-yorkais a fourni des conseils contraires à la loi et Replit AI a supprimé une base de données de production malgré des consignes explicites. Ces exemples illustrent le changement d’échelle du risque : une mauvaise réponse peut être corrigée, tandis qu’une mauvaise décision exécutée peut engendrer une transaction non souhaitée, désinformer les utilisateurs ou détruire des données essentielles.
Où l’autonomie fonctionne vraiment
Les usages les plus pertinents et sûrs sont délimités, observables et réversibles. Par exemple, le support utilisateurs, le tri d’incidents, la génération ou livraison de code et les pipelines de données produisent des résultats contôlables : tickets, tests, journaux, et statuts d’exécution...
Les équipes SRE (Site Reliability Engineering, ou Ingénierie de la fiabilité des sites) peuvent confier à un agent la surveillance des traces d’exécution d’un autre agent. S’il détecte une boucle, une erreur d’autorisation ou une défaillance en cascade, il déclenche un agent de remédiation doté d’outils strictement limités pour corriger le problème. Chaque intervention reste enregistrée dans une trace distincte, reliée à l’incident d’origine, afin de conserver un historique précis et vérifiable.
À l’inverse, les décisions concernant des personnes, des paiements ou des opérations irréversibles exigent davantage de contrôle. Pour arbitrer ce qui peut être confié ou non à un agent, la question n’est pas "pouvons-nous automatiser ce processus ?", mais "quelles actions pouvons-nous déléguer sans perdre la maîtrise du risque ?".
La bonne stratégie : une autonomie progressive
Un déploiement fiable commence sur un périmètre restreint, avec des cas réels et des exceptions difficiles. L’autonomie n’augmente qu’après examen des résultats. Les indicateurs doivent couvrir le taux d’erreur, la réussite de bout en bout, la satisfaction des utilisateurs, le temps gagné, le taux d’escalade et le coût de correction.
Le score moyen ne suffit pas. Il faut aussi évaluer la répétabilité, la sensibilité aux variations d’entrée, la capacité à signaler l’incertitude et la gravité des erreurs. Deux agents affichant la même précision peuvent présenter des risques très différents.
La maturité ne consiste donc pas à supprimer l’humain du processus. Elle consiste à accorder à l’agent le niveau d’autonomie qu’il peut réellement assumer, à mesurer ses décisions et à savoir interrompre son action. Un agent fiable n’est pas celui qui agit seul le plus longtemps : c’est celui qui atteint son objectif sans faire perdre le contrôle à l’organisation.
Sources
The Math Behind Why Multi-Step AI Agents Fail in Production — LensHQ
AI Agents in Production: Why They Fail and How to Fix It — ScriptsHub
AI Agent Reliability: Failure Modes and Observability — StackPulsar
Deep Agents: Solving Multi-Step AI Agent Failure Modes — Skrew
Why Agentic AI Fails: Infinite Loops, Planning Errors, and More
LLMs Lose 39% Accuracy in Multi-Turn Conversations — Beam AI
