LangGraph gagne en tolérance aux pannes : réessais, timeouts et gestionnaires d’erreurs pour les agents de production

LangChain a publié un guide détaillé sur trois primitives de résilience intégrées de LangGraph — sans elles, tout agent de production inévitablement échoue là où le prototype fonctionnait comme une horloge.

Pourquoi les prototypes échouent en production

En conditions de laboratoire, un agent LangGraph semble fiable : les données d'entrée sont fixes, les APIs externes répondent rapidement, l'utilisateur est toujours disponible. En opération réelle, le tableau est différent. Les services externes se figent ou retournent 503 sous charge.

Les fournisseurs d'LLM à la demande maximale retardent les réponses de minutes. Dans les scénarios human-in-the-loop, une personne peut ne pas répondre pendant des heures. Chacun de ces cas, sans traitement spécial, se transforme en un agent figé ou échoué.

La solution classique — envelopper chaque appel dans try/except, écrire des timers, ajouter manuellement la logique de retry. Cela fonctionne, mais le code défensif se développe, se mélange avec la logique métier et devient lui-même une source d'erreurs. LangGraph propose une approche différente : trois primitives intégrées dans le moteur et fonctionnant de manière déclarative.

RetryPolicy : tentatives de retry automatiques **RetryPolicy**

configure les tentatives de retry automatiques avec backoff exponentiel. Paramètres configurables : nombre maximum de tentatives, délai initial, délai maximum et son coefficient de croissance entre les tentatives. La politique peut être définie précisément — pour un nœud spécifique appelant une API externe instable — ou appliquée à l'ensemble du graphe comme défaut global. La deuxième option est pratique quand toute interaction avec les services externes doit suivre des règles de récupération unifiées.

TimeoutPolicy : limites de temps **TimeoutPolicy** résout une tâche

différente — elle limite le temps qu'un nœud est autorisé à prendre. Deux types de limites sont pris en charge : `wall_clock_timeout` — temps écoulé maximal pour l'exécution du nœud du début à la fin `idle_timeout` — temps maximum d'inactivité. Particulièrement important dans les scénarios human-in-the-loop : si l'utilisateur n'a pas répondu en N minutes, l'agent doit continuer par une branche alternative ou se terminer avec une erreur Les deux limites peuvent être combinées dans une politique — celle qui arrive en premier se déclenchera Lorsque la limite est dépassée, le moteur lève automatiquement une exception * La politique est applicable à un nœud, un sous-graphe ou l'ensemble du graphe L'avantage clé des deux primitives — elles vivent à l'intérieur du moteur et voient le contexte complet de l'état du graphe.

Les décorateurs externes et les enveloppes ne peuvent pas le faire.

error_handler et le modèle SAGA **error_handler** — la troisième

primitive, qui se déclenche après que tous les retries soient épuisés. C'est le point de récupération final : annuler les actions déjà effectuées, envoyer des notifications, sauvegarder les diagnostics, placer l'agent dans un état sûr. Pour les agents multi-étapes avec de vrais effets secondaires — réservation de ressources, déduction de fonds, création d'enregistrements dans des systèmes externes — LangChain recommande le modèle SAGA.

L'idée : chaque étape de l'agent s'accompagne d'une opération de compensation qui annule son effet. Si l'étape N échoue après la fin réussie des étapes 1 à N-1, les opérations de compensation sont lancées dans l'ordre inverse — le système revient à un état cohérent. LangGraph vous permet d'intégrer SAGA directement dans le graphe : les compensations sont stockées à côté des nœuds, et error_handler exécute leur chaîne en cas d'échec.

"Avoir des politiques de résilience à l'intérieur du moteur, pas à

l'extérieur — c'est une différence fondamentale : la logique de récupération obtient le contexte complet de l'état du graphe," — blog LangChain.

Ce que cela signifie

LangGraph offre des outils matures pour faire passer les agents d'IA du prototype à l'opération dans le monde réel. Les retries, les timeouts et les transactions de compensation sont intégrés dans le moteur et ne nécessitent pas d'envelopper manuellement chaque nœud. Pour les équipes construisant des agents sous des charges de production, cela réduit le volume de code défensif et rend le comportement en cas d'échec prévisible et contrôlable.