Gestion des erreurs dans les systèmes multi-agents : retries, fallbacks, circuit breakers

La gestion des erreurs dans les systèmes multi-agents regroupe tous les mécanismes qui empêchent la défaillance d'un seul agent de faire basculer tout le système : timeouts, retries avec backoff, agents de repli, circuit breakers et observabilité de bout en bout. L'objectif est la tolérance aux pannes : un sous-agent peut échouer sans que les erreurs se répercutent en cascade ou se propagent. Dans un système mono-agent, la gestion des erreurs est un problème largement résolu ; dès que plusieurs agents dotés de leurs propres fenêtres de contexte, outils et rôles collaborent, apparaissent des classes de défaillances qui n'existent tout simplement pas dans une boucle de tool use unique.

• Sépare le chemin de lecture et le chemin d'écriture : de nombreux agents peuvent lire et proposer en parallèle, mais un seul (ou une étape du pipeline) fait le commit. C'est le moyen le plus efficace contre la propagation des erreurs.
• Limite chaque tâche : un timeout, un plafond de tokens et un état failed explicite par sous-agent évitent les deadlocks et l'explosion des coûts.
• Vérifie avant de synthétiser : un agent Verifier-Judge intercepte les faits hallucinés avant que l'agent principal ne les écrive comme vérité dans la réponse.

Pourquoi la gestion des erreurs est différente dans les systèmes multi-agents

Un système multi-agents se compose de plusieurs agents basés sur des LLM (chacun avec son propre prompt, son propre rôle, son propre jeu d'outils et, dans le cas le plus strict, sa propre fenêtre de contexte) qui résolvent ensemble une tâche. C'est précisément cette répartition qui crée de nouvelles surfaces de défaillance. Il n'y a plus une trace unique, mais N trajectoires de sous-agents plus une synthèse. Les exécutions ne sont pas déterministes : la même entrée lance des sous-agents différents dans un ordre différent. Et le système peut présenter des comportements émergents qu'aucun agent n'a planifiés ainsi.

Le danger principal est la propagation des erreurs. Si un sous-agent hallucine un fait, l'agent principal l'intègre dans la réponse finale et les agents en aval agissent sur la base de ce fait erroné. Une erreur locale devient une mauvaise décision à l'échelle du système. La gestion des erreurs dans les systèmes multi-agents signifie donc deux choses : rendre chaque agent résistant aux pannes transitoires et empêcher que les erreurs se répandent le long de la chaîne d'agents.

Les huit classes de défaillances que les systèmes mono-agents n'ont pas

Le tableau suivant est notre propre synthèse des classes de défaillances qu'Anthropic, Cognition, Sierra, Salesforce et Microsoft ont décrites à partir de leurs systèmes en production. Quiconque met un système multi-agents en production doit les connaître.

Trois de ces classes (cascades, deadlock et fragmentation du contexte) sont les véritables moteurs de la propagation des erreurs. Les cinq autres l'amplifient ou la rendent invisible.

Empêcher la propagation des erreurs : séparer les chemins de lecture et d'écriture

La décision d'architecture la plus importante contre la propagation des erreurs n'est pas un outil, mais un principe. Cognition l'a formulé clairement dans « Don't Build Multi-Agents » (juin 2025) et dans la mise à jour « Multi-Agents: What's Actually Working » (avril 2026) : le fan-out multi-agents pour la lecture est robuste, le fan-out multi-agents pour l'écriture est fragile. La conséquence est la règle des single-threaded writes :

• Single-threaded writes : de nombreux agents lisent, recherchent et proposent, mais un seul agent ou une seule étape du pipeline fait le commit. Un agent lecteur défaillant ne fournit qu'une contribution partielle que l'agent principal peut écarter ou redemander.
• Écritures indépendantes avec réconciliation : chaque sous-agent livre un fragment, et l'agent principal les réconcilie dans la sortie finale (le modèle de l'agent de recherche d'Anthropic).
• Écritures concurrentes sur un état partagé : la spirale infernale. À éviter absolument.

L'observation de Cognition derrière tout cela : les « apparent disagreements » entre agents sont le plus souvent des symptômes de fragmentation du contexte, pas d'un véritable désaccord. Là où le couplage est fort, il faut partager les traces complètes des agents plutôt que de simples messages isolés. Pour la mémoire externe partagée (vector store, Postgres, SAP HANA), la même règle s'applique dans la plupart des systèmes en production : un seul rédacteur, de nombreux lecteurs.

Retries avec backoff, timeouts et circuit breakers

Au niveau de chaque appel d'agent ou d'outil, ce sont les modèles de résilience classiques, transposés du monde des microservices, qui s'appliquent :

• Retries avec backoff exponentiel : en cas d'erreur transitoire (rate limit, brève panne d'outil, timeout), l'appel est relancé avec des temps d'attente croissants, idéalement avec du jitter pour éviter les effets de thundering herd. Important : les retries ne servent que contre les erreurs transitoires, pas contre les erreurs sémantiques. Rappeler un agent qui hallucine produit la même hallucination.
• Timeouts sur chaque tâche : le protocole A2A définit un cycle de vie de tâche submitted → working → input-required → completed | failed | canceled. Un timeout sur chaque tâche et l'état explicite input-required constituent la contre-mesure documentée contre les resource deadlocks. Sans timeout, un agent en attente peut bloquer tout le système.
• Circuit breaker : si les erreurs d'un sous-agent ou d'un outil dépassent un seuil, le breaker s'ouvre et bloque les appels suivants pendant une fenêtre de temps. Cela stoppe l'explosion des coûts et laisse de la place pour un repli.
• Agents de repli et réponses dégradées : si un agent spécialisé tombe en panne, un agent de repli plus simple, un autre niveau de modèle ou une réponse volontairement réduite prend le relais. Mieux vaut une sortie honnêtement limitée qu'une mauvaise décision en cascade.

La discipline pratique en matière de tokens issue de la référence de l'agent de recherche d'Anthropic complète le dispositif : plafonner explicitement la dépense de tokens des sous-agents (pris en charge par Bedrock AgentCore, LangGraph et Claude Agent SDK), contraindre les sorties des sous-agents dans un schéma typé (Pydantic, JSON Schema, A2A Artifact) et les compresser avant de les renvoyer, ne jamais transmettre à l'agent principal la transcription complète d'un sous-agent. Un schéma typé est en même temps une frontière d'erreur : ce qui n'entre pas dans le schéma est rejeté au lieu d'être transmis.

Monitoring et observabilité : un prérequis, pas un simple ajout

Le debuggability collapse est la classe de défaillance la plus insidieuse : quand quelque chose tourne mal, aucune trace unique n'explique l'exécution. C'est pourquoi l'observabilité n'est optionnelle pour aucun système multi-agents en production. Les briques :

• Traçage distribué sur l'ensemble du maillage A2A, avec un identifiant de corrélation/trace continu dans chaque tâche A2A et chaque appel MCP. En 2026, OpenTelemetry est le standard transversal.
• Outils (état 2026) : LangSmith pour les traces LangGraph internes ; Galileo ou Arize Phoenix pour les traces multi-agents au-delà des frontières entre fournisseurs ; Pydantic Logfire dans les équipes très orientées Python ; Datadog/Splunk/Grafana pour la corrélation SIEM.
• Modèle Verifier-Judge : un agent juge distinct, souvent un modèle plus puissant que les workers, évalue chaque trajectoire selon une courte grille : tâche accomplie ? Réponse ancrée dans les sources ? Agents restés sur leur tâche ? Budget respecté ? C'est la réponse la plus légère et prête pour la production contre les défaillances en cascade.

Dans la zone DACH (Allemagne, Autriche, Suisse), l'observabilité est en outre une question de conformité. Dans ses orientations sur les risques TIC liés à l'utilisation de l'IA de décembre 2025, la BaFin recommande aux entreprises financières de journaliser tous les événements et activités pertinents des systèmes d'IA afin de les rendre traçables. Le fondement est DORA, dont le respect en Autriche est surveillé par la FMA. Dans sa communication sur la surveillance 08/2024, la FINMA constate que les résultats de l'IA ne peuvent souvent pas être retracés, expliqués ou reproduits. Pour un système d'agents, cela signifie : des traces de bout en bout de chaque appel d'agent, la reproductibilité (épingler les versions de modèles en production, consigner tous les prompts des sous-agents, les tool calls et les AgentCards) et un stockage d'audit en append-only. Les durées de conservation dépendent du secteur et du pays, et doivent être validées avec la conformité avant de mettre en place le stockage d'audit.

Exemple : Allianz Project Nemo

Project Nemo d'Allianz Australia, filiale de l'assureur munichois Allianz, est l'un des déploiements multi-agents les mieux documentés d'un groupe de la zone DACH et un cas d'école de gestion des erreurs. Sept agents spécialisés (Planner, Cyber, Coverage, Weather, Fraud, Payout, Audit) traitent les sinistres de denrées alimentaires avariées après des catastrophes naturelles. Le workflow complet à sept agents s'exécute en moins de cinq minutes.

Deux principes de gestion des erreurs y sont ancrés dans l'architecture même :

• Agent d'audit comme élément de la topologie : un agent dédié produit une synthèse complète de toutes les décisions des agents et de leurs justifications, soit une piste d'audit complète pour la conformité, le contrôle qualité et la vérification humaine. L'auditabilité est intégrée à la topologie des agents, et pas seulement ajoutée au pipeline de logging.
• Human-in-the-loop à l'étape critique : un gestionnaire de sinistres humain vérifie la synthèse d'audit et prend la décision finale de paiement. Une mauvaise décision propagée en cascade est interceptée au point le plus coûteux et irréversible, en tant que politique explicite.

Le résultat : une réduction de 80 % du temps de traitement et de règlement des sinistres éligibles inférieurs à 500 AUD, mise en production en moins de 100 jours (Australie, juillet 2025). La leçon pour la gestion des erreurs : des agents modulaires aux rôles clairs, un chemin d'audit dédié et un point de contrôle humain donnent un système rapide et maîtrisable.

Checklist pratique de gestion des erreurs

• Chemin d'écriture single-threaded ? Exactement un agent/une étape fait le commit ; les lecteurs font du fan-out, les rédacteurs non.
  
• Timeout sur chaque tâche ? Plus un état input-required explicite contre les deadlocks.
  
• Retries avec backoff + jitter uniquement pour les erreurs transitoires, pas pour les erreurs sémantiques.
  
• Circuit breaker par sous-agent/outil, avec seuil et fenêtre de réinitialisation.
  
• Agent de repli ou réponse dégradée défini pour chaque agent critique.
  
• Plafonds de tokens par sous-agent en place ; sorties contraintes dans un schéma typé et compressées.
  
• Agent Verifier-Judge qui vérifie les trajectoires avant la synthèse finale.
  
• Grounded retrieval + sources obligatoires contre les cascades d'hallucinations.
  
• Traces complètes partagées en cas de couplage fort ; contrats de décision explicites.
  
• ID de corrélation dans chaque tâche A2A et chaque appel MCP ; export OTel.
  
• Human-in-the-loop aux étapes irréversibles ou coûteuses.
  
• Versions de modèles épinglées, piste d'audit en append-only, conservation conforme au secteur.
  

Pour les agences et les décideurs B2B

Pour les agences marketing et les acteurs nativement IA, la gestion des erreurs est un critère de qualité produit, pas un détail d'arrière-plan : un pipeline de newsletter ou d'audit SEO avec des agents de recherche, de plan, de rédaction et de relecture tient ou s'effondre avec le Verifier-Judge et l'étape d'écriture single-threaded. Pour les décideurs B2B en Europe : exige de chaque pitch multi-agents, interne ou fournisseur, des réponses concrètes sur la stratégie de timeout, de repli, de vérification et de traçage. Un système sans observabilité de la classe de Galileo ou LangSmith ne peut pas être examiné en cas de demande d'un régulateur. Celui qui intègre la gestion des erreurs dans la topologie des agents dès le départ, selon le modèle Allianz Nemo avec agent d'audit et human-in-the-loop, livre des systèmes rapides qui restent en même temps auditables.