Les 14 modes de défaillance des agents IA

En bref

En 2025, une équipe de l’UC Berkeley a analysé 1 642 traces d’exécution de systèmes multi-agents LLM et en a extrait une taxonomie structurée : MAST (Multi-Agent System Failure Taxonomy). Elle recense 14 modes de défaillance regroupés en trois catégories — conception système, désalignement inter-agents, et vérification des tâches. Ces modes ne sont pas des cas limites rares : ils se produisent régulièrement en production, jusqu’à entraîner des coûts opérationnels non anticipés (ZenML documente un cas à 47 000 USD en onze jours). Comprendre cette taxonomie, c’est disposer d’un vocabulaire commun pour diagnostiquer, corriger et prévenir les pannes de vos agents.

La taxonomie MAST — une classification systématique

Un système multi-agents LLM (MAS) est un ensemble de modèles de langage autonomes qui collaborent pour accomplir une tâche : un agent planifie, un autre exécute du code, un troisième vérifie les résultats. Ce type d’architecture est de plus en plus courant dans les applications d’automatisation, mais les mécanismes de défaillance qui lui sont propres restaient mal documentés.

Cemri, Pan, Yang et al. (2025) comblent ce gap avec MAST. La méthode repose sur la Grounded Theory : les chercheurs ont annoté 150 traces d’exécution sans catégories prédéfinies, en laissant les patterns émerger des données. L’accord inter-annotateurs atteint kappa = 0.88 (indice de Cohen), considéré comme un accord fort en sciences de l’information. Le corpus final — MAST-Data — contient 1 642 traces annotées, issues de sept frameworks open-source (MetaGPT, ChatDev, HyperAgent, OpenManus, AppWorld, Magentic, AG2) sur des tâches de codage, de mathématiques et d’agents généraux.

La taxonomie identifie 14 modes de défaillance, répartis en trois catégories :

Pour rendre cette taxonomie opérationnelle à grande échelle, les auteurs ont développé un pipeline d’annotation automatique (LLM-as-a-Judge) qui atteint 94 % de précision et kappa = 0.77 par rapport aux annotations humaines expertes. MAST, MAST-Data et l’annotateur sont publiés en open source sur GitHub.

En clair : pensez à MAST comme à la nomenclature médicale des pannes d’agents. Avant elle, on disait “ça marche pas” — comme un médecin qui dirait “il est malade”. Avec elle, on peut nommer précisément FM-1.1 (l’agent ignore les contraintes), FM-2.6 (raisonnement correct mais action divergente), FM-3.3 (vérification incorrecte). Le diagnostic devient possible, donc le traitement aussi.

Un résultat important : l’analyse comparative sur quatre modèles (GPT-4, Claude 3, Qwen2.5, CodeLlama) montre que les variations de performance existent mais ne suivent pas une logique simple de taille. Sur MetaGPT avec des tâches de programmation, GPT-4o génère 39 % moins d’erreurs de type FC1 que Claude 3.7 Sonnet dans les traces analysées. Plus généralement, les auteurs concluent que ces défaillances sont indicatives de défauts de conception fondamentaux dans les architectures MAS, et pas seulement d’artefacts propres aux frameworks testés.

Catégorie 1 : problèmes de conception système (41,8 %)

La première catégorie regroupe les défaillances dont la cause racine se situe dans la façon dont le système et ses agents sont conçus : les spécifications de tâche, les rôles, la gestion du contexte. Elle représente plus de 40 % des défaillances observées, ce qui en fait la source de problèmes la plus fréquente.

FM-1.1 — Non-respect des spécifications de tâche (15,7 %)

C’est le mode de défaillance le plus fréquent, toutes catégories confondues. Un agent reçoit une tâche avec des contraintes explicites — format de sortie, périmètre fonctionnel, limites — et les ignore partiellement ou totalement. Le résultat est produit, mais il ne correspond pas à ce qui était demandé.

Exemple concret : un agent chargé de générer un rapport CSV avec des colonnes précisément nommées produit un fichier JSON. La tâche est “terminée” du point de vue de l’agent, mais le résultat est inutilisable.

Ce mode pointe vers un problème de spécification ou de transmission des contraintes. La question diagnostique est : le prompt de tâche est-il suffisamment précis pour qu’un lecteur humain ne puisse pas l’interpréter autrement ?

FM-1.2 — Non-respect des spécifications de rôle (11,8 %)

Chaque agent dans un MAS se voit attribuer un rôle : planificateur, exécuteur, vérificateur, etc. Ce mode de défaillance survient quand un agent déborde de son rôle assigné — par exemple, un agent “planificateur” qui commence à exécuter directement des actions au lieu de déléguer, ou un agent “vérificateur” qui modifie le résultat au lieu de simplement l’évaluer.

Le problème est souvent subtil : l’agent produit quelque chose d’utile, mais dans un registre qui n’est pas le sien. Cela crée des conflits de responsabilité entre agents et rend le débogage difficile, car on ne sait plus quel agent est responsable de quelle décision.

La question diagnostique : les instructions de rôle de chaque agent définissent-elles explicitement ce que l’agent ne doit pas faire ?

FM-1.3 — Répétition d’étapes (13,2 %)

Un agent réexécute une étape déjà complétée, sans raison valable. Ce mode est particulièrement coûteux en tokens et en temps, et peut masquer une absence de mémoire de travail correctement implémentée. Il apparaît fréquemment en combinaison avec d’autres modes : HyperAgent souffre notamment de FM-1.3 combiné à FM-3.3 (vérification incorrecte), créant une boucle où l’agent vérifie mal, échoue, et recommence indéfiniment.

La question diagnostique : votre système maintient-il un registre explicite des étapes complétées, accessible à l’agent avant qu’il planifie la prochaine action ?

FM-1.4 — Perte d’historique de conversation (1,5 %)

Ce mode survient quand la fenêtre de contexte est tronquée de façon inattendue : l’agent revient à un état conversationnel antérieur, comme si les échanges récents n’avaient pas eu lieu. Sa fréquence brute est faible dans le corpus MAST, mais son impact peut être sévère : les décisions prises avant la troncature sont invisibles pour l’agent, qui peut reprendre une sous-tâche déjà résolue ou contredire des décisions validées.

L’analyse ZenML (2025) précise que le “context rot” — la dégradation progressive de la cohérence contextuelle — commence entre 50 000 et 150 000 tokens dans les fenêtres contextuelles, indépendamment des limites théoriques déclarées par les fournisseurs.

La question diagnostique : votre système dispose-t-il d’un mécanisme de compression ou de résumé de l’historique avant d’atteindre les limites de contexte ?

FM-1.5 — Méconnaissance des conditions de terminaison (1,9 %)

Un agent incapable de reconnaître quand une tâche est réellement terminée. Il continue à produire des outputs, à appeler des outils, à solliciter d’autres agents — même quand l’objectif est atteint. Ce mode peut générer des boucles infinies, avec les coûts associés. Le cas documenté par ZenML (deux agents en boucle récursive pendant onze jours) illustre ce que peut coûter l’absence de critère de terminaison explicite.

La question diagnostique : chaque tâche dans votre système dispose-t-elle d’un critère de succès vérifiable par l’agent lui-même, sans intervention humaine ?

Catégorie 2 : désalignement inter-agents (36,9 %)

La deuxième catégorie concerne les défaillances qui émergent de l’interaction entre agents. Un agent seul peut fonctionner correctement — c’est dans la collaboration que les problèmes apparaissent. Cette catégorie couvre six modes distincts.

FM-2.1 — Réinitialisation de conversation

Une conversation entre agents est réinitialisée de façon non intentionnelle : le contexte de collaboration établi est perdu. Les agents reprennent leur échange depuis un état antérieur, potentiellement avec des contradictions par rapport aux décisions déjà prises. Ce mode est particulièrement insidieux car il peut passer inaperçu si le résultat final est superficiellement correct.

FM-2.2 — Absence de demande de clarification

Un agent reçoit une instruction ambiguë et, au lieu de demander des précisions, choisit une interprétation — souvent sans signaler qu’une ambiguïté existe. La décision silencieuse se propage à l’ensemble du pipeline. Ce mode est documenté dans l’analyse qualitative de Abdin et al. (2024) sous le terme “premature action without grounding” : l’agent agit avant d’avoir ancré suffisamment sa compréhension de la tâche.

La question diagnostique : vos agents sont-ils explicitement instruits de signaler et de bloquer en cas d’ambiguïté, plutôt que de choisir par défaut ?

FM-2.3 — Déraillement de tâche (7,4 %)

Un agent dévie de l’objectif initial. Il produit des actions non pertinentes, voire contre-productives, qui n’ont plus de lien avec la tâche assignée. Ce mode diffère du FM-1.1 (non-respect des spécifications) en ce qu’il émerge dynamiquement au cours de l’exécution — souvent déclenché par un contexte mal géré ou par les outputs d’autres agents. L’agent n’ignore pas les contraintes initiales ; il les perd de vue progressivement.

FM-2.4 — Rétention d’information (0,85 %)

Un agent possède une information pertinente pour les autres agents, mais ne la partage pas. Cela peut survenir faute de mécanisme de partage explicite, ou parce que l’agent évalue incorrectement la pertinence de l’information pour ses voisins. La rétention d’information est difficile à détecter : ce qui n’est pas transmis n’apparaît pas dans les traces.

La question diagnostique : votre architecture définit-elle explicitement quelles informations chaque agent doit remonter à l’orchestrateur ou aux autres agents ?

FM-2.5 — Ignorance des inputs des autres agents (1,9 %)

Un agent reçoit des contributions ou recommandations d’un autre agent et ne les prend pas en compte dans sa décision. Ce mode peut produire des résultats cohérents en apparence, mais qui ignorent des contraintes ou des connaissances apportées par le reste du système. Il est particulièrement problématique dans les architectures où un agent spécialisé (expert domaine) est censé enrichir les décisions d’un agent généraliste.

FM-2.6 — Divergence raisonnement-action (13,2 %)

Ce mode est le deuxième plus fréquent dans FC2. Un agent exprime un raisonnement correct — il identifie le bon plan, la bonne décision — mais son action effective ne correspond pas à ce raisonnement. Le modèle “dit” une chose et “fait” une autre. Ce décalage est particulièrement difficile à diagnostiquer car les traces de raisonnement (chain-of-thought) semblent correctes, masquant la défaillance réelle.

Abdin et al. (2024) documentent un phénomène connexe : la “over-helpfulness”, où un agent substitue des entités manquantes (valeurs par défaut, paramètres inventés) sans signaler l’approximation, produisant une action superficiellement valide mais incorrecte sur le fond.

La question diagnostique : votre système vérifie-t-il que les actions effectivement exécutées correspondent aux intentions exprimées dans la trace de raisonnement ?

Catégorie 3 : vérification et terminaison (21,3 %)

La troisième catégorie regroupe les défaillances liées à l’évaluation de la qualité et à la clôture des tâches. Ces modes surviennent en fin de pipeline — ou précisément parce que la fin du pipeline est mal gérée.

FM-3.1 — Terminaison prématurée

Un agent arrête l’exécution avant que la tâche soit réellement complète. Il déclare succès — ou simplement cesse d’agir — alors que des étapes nécessaires restent à accomplir. Le framework AppWorld est particulièrement touché par ce mode dans les traces MAST, probablement en raison de sa topologie en étoile sans workflow prédéfini : sans structure explicite indiquant les étapes restantes, l’agent n’a pas de référence pour évaluer sa progression.

Ce mode est l’opposé de FM-1.5 (incapacité à s’arrêter) : le problème est ici de s’arrêter trop tôt plutôt que trop tard.

FM-3.2 — Vérification absente ou incomplète

Aucun mécanisme ne garantit l’exactitude, la complétude et la fiabilité du résultat produit. L’agent termine la tâche et transmet le résultat sans validation. MAST montre que les frameworks disposant de vérificateurs explicites (MetaGPT, ChatDev) génèrent moins de défaillances totales que ceux qui n’en ont pas. Mais la présence d’un vérificateur n’t est pas suffisante : les auteurs documentent un cas où ChatDev génère un programme qui passe les vérifications superficielles mais contient des bugs runtime, parce que le vérificateur ne valide pas contre les règles réelles du jeu.

La question diagnostique : vos critères de vérification sont-ils alignés avec les contraintes réelles de la tâche, ou seulement avec des heuristiques de surface (syntaxe correcte, format valide) ?

FM-3.3 — Vérification incorrecte

Le mécanisme de vérification existe, mais il valide à tort un résultat incorrect. C’est le mode le plus difficile à détecter : le système signale un succès, les logs indiquent que les vérifications ont passé, et pourtant le résultat est faux. HyperAgent souffre particulièrement de ce mode en combinaison avec FM-1.3 : l’agent vérifie incorrectement, conclut à tort que le résultat est mauvais, et répète l’étape — créant une boucle.

IBM Research et UC Berkeley ont appliqué MAST à IT-Bench (NeurIPS 2025), un benchmark de tâches d’automatisation IT réelles. Résultat : les agents résolvent seulement 11,4 % des scénarios SRE (Site Reliability Engineering), 25,2 % des scénarios CISO et 25,8 % des scénarios FinOps. Ces chiffres illustrent concrètement l’impact cumulé des modes FC3 en conditions proches du réel.

La checklist du praticien

Les 14 modes MAST se traduisent en questions opérationnelles. Voici une checklist diagnostique à parcourir avant de déployer un système multi-agents, ou au moment de diagnostiquer une panne.

Conception de la tâche (FC1)

• Les contraintes de chaque tâche sont-elles formulées de façon non ambiguë, avec des exemples positifs et négatifs si nécessaire ? (FM-1.1)
• Les instructions de rôle de chaque agent définissent-elles explicitement les responsabilités et les limites — ce que l’agent ne doit pas faire ? (FM-1.2)
• Le système maintient-il un registre explicite des étapes complétées, visible par chaque agent avant de planifier la suite ? (FM-1.3)
• Existe-t-il un mécanisme de résumé ou de compression du contexte avant d’atteindre les limites de la fenêtre ? (FM-1.4)
• Chaque tâche dispose-t-elle d’un critère de succès vérifiable par l’agent lui-même, sans intervention humaine ? (FM-1.5)

Collaboration entre agents (FC2)

• Les agents sont-ils instruits de bloquer et de signaler en cas d’ambiguïté, plutôt que de choisir une interprétation par défaut ? (FM-2.2)
• L’architecture définit-elle explicitement quelles informations chaque agent doit transmettre aux autres ? (FM-2.4)
• Un mécanisme vérifie-t-il que les actions effectivement exécutées correspondent au raisonnement exprimé dans les traces ? (FM-2.6)
• Les agents spécialisés disposent-ils d’un canal de communication structuré pour que leurs contributions soient prises en compte ? (FM-2.5)

Vérification et clôture (FC3)

• Chaque tâche dispose-t-elle d’une définition explicite de la complétude, accessible à l’agent en cours d’exécution ? (FM-3.1)
• Les critères de vérification sont-ils alignés avec les contraintes réelles de la tâche, pas uniquement avec des heuristiques de surface ? (FM-3.2)
• Le système dispose-t-il de tests de régression sur des cas où la vérification pourrait conclure à tort à un succès ? (FM-3.3)

Limites à conserver en tête

MAST est construit sur sept frameworks open-source. Sa représentativité sur des systèmes enterprise propriétaires reste à établir. Les interventions documentées — prompt engineering, ajout de vérificateurs — améliorent les performances de 14 à 15,6 % selon les études, mais restent insuffisantes pour un déploiement en production sans supervision. La taxonomie elle-même pourrait évoluer avec les nouvelles architectures (raisonnement étendu, mémoire persistante, outils multimodaux). Enfin, MAST identifie les catégories de défaillance, mais pas toujours l’agent responsable dans un système distribué — un problème d’attribution causale que la recherche adresse séparément (arXiv:2603.25001).

En clair : la checklist MAST est un outil de prévention, pas une garantie. Sur les 14 modes, deux dominent : FM-1.1 (15,7%) et FM-2.6 (13,2%). Si votre prompt et votre architecture résolvent ces deux-là, vous traitez près de 30% des défaillances structurelles. Le reste est un travail d’incrémental — couvrir progressivement les modes qui apparaissent sur votre domaine spécifique. Aucune équipe ne livre un système sans 14/14, mais 8-10/14 est déjà significativement plus stable que la moyenne du secteur.

Ce qu’il faut retenir

• 14 modes, 3 catégories. MAST est la première taxonomie systématique des défaillances des systèmes multi-agents LLM, construite sur 1 642 traces annotées avec kappa = 0.88. Elle couvre la conception système (41,8 %), le désalignement inter-agents (36,9 %) et la vérification des tâches (21,3 %).
• Les problèmes de conception dominent. FM-1.1 (non-respect des spécifications de tâche, 15,7 %) et FM-2.6 (divergence raisonnement-action, 13,2 %) sont les modes les plus fréquents. Ce sont des problèmes d’architecture et de spécification, pas des bugs de modèle.
• La vérification n’est pas une garantie. Les frameworks avec vérificateurs explicites performent mieux en moyenne, mais FM-3.3 montre qu’un vérificateur peut valider un résultat incorrect. La qualité des critères de vérification importe autant que leur présence.
• Les interventions actuelles ne suffisent pas. Le prompt engineering et l’ajout de vérificateurs améliorent les performances de 14 à 15,6 % dans les études disponibles, mais les taux de réussite en conditions réelles restent bas (11,4 % sur les tâches SRE dans IT-Bench).
• MAST est un outil de diagnostic, pas une garantie. La taxonomie permet de nommer et d’anticiper les défaillances. Elle ne résout pas la question plus large : à quel seuil de performance un système multi-agents est-il acceptable pour un déploiement autonome en production ?