Chaque équipe qui livre un système à base d'agents IA finit par poser la même question, généralement vers le troisième mois : « est-ce qu'il nous faut Temporal / Inngest / Restate, ou est-ce qu'on peut juste ajouter des retries ? »
La réponse est presque toujours : « il vous faut l'orchestrateur durable, mais pour une raison qui n'est pas “les retries”. »
Ce que les retries résolvent vraiment
Les retries sont le bon outil quand une panne transitoire est observée par le même processus qui a émis l'appel. Coupure réseau, réponse de rate-limit, un service en aval capricieux — l'appelant a le résultat raté en main, sait ce qu'il essayait de faire, et peut simplement réessayer.
Pour cela il vous faut : une politique de retry avec backoff exponentiel, un plafond de tentatives, et de l'idempotence côté récepteur. C'est une lib, pas un système. p-retry, tenacity, tokio-retry — choisissez-en une et passez à la suite.
Ce que l'exécution durable résout vraiment
L'exécution durable est le bon outil quand le processus lui-même peut mourir entre les étapes. Crash, déploiement, k8s qui évince le pod, un appel LLM de 30 minutes qui dépasse votre timeout de requête — la question n'est pas « peut-on réessayer » mais « où en étions-nous quand la lumière s'est éteinte, et comment reprendre sans refaire les parties qui avaient déjà réussi ? »
C'est un problème fondamentalement différent. Il faut :
- Un état d'étape persistant — un journal des étapes terminées, avec leurs résultats.
- Un historique rejouable — quand le processus reprend, il parcourt le journal, saute les étapes finies, et continue à partir de la première inachevée.
- Des bornes d'étape déterministes — du code structuré pour que l'orchestrateur identifie sans ambiguïté les étapes à travers les rejeux.
Vous pouvez écrire ça à partir de zéro. Des gens le font. C'est six mois à déboguer des race conditions avant de réaliser que vous avez construit une moins bonne version de Temporal.
La vraie décision
Si votre système à base d'agents IA a :
- Des tool calls qui prennent plus de quelques secondes individuellement,
- Des workflows avec plus de ~3 étapes séquentielles,
- Un handoff ou un human-in-the-loop quelque part au milieu,
- Des SLAs qui ne tolèrent pas qu'un redémarrage de déploiement provoque un échec visible par l'utilisateur,
…il vous faut un orchestrateur durable. Pas « vous voudrez peut-être en avoir un pour le confort ». Il vous en faut un, et l'ajouter plus tard sera bien plus coûteux que de commencer avec.
Si votre système est court, synchrone et stateless (un prompt, une réponse, terminé en 5 secondes), les retries suffisent. Ne sur-ingénierez pas.
Ce que nous livrons
En pratique, notre choix par défaut est Temporal ou Restate (selon la stack du langage), avec du code de workflow structuré pour que chaque appel LLM, chaque tool invocation et chaque approbation soit une étape séparée. Le coût : une certaine courbe d'apprentissage et un runtime à opérer. Le bénéfice : « que se passe-t-il quand ce processus crashe en plein workflow » cesse d'être une question à laquelle nous devons répondre pour chaque nouvelle feature — l'orchestrateur y répond une fois pour toutes.
Les retries résolvent « cet appel a échoué ». L'exécution durable résout « ce workflow doit survivre aux pannes de ce qui le fait tourner ». Ce ne sont pas des alternatives — la plupart des systèmes en production ont besoin des deux, et c'est le second que l'on sous-estime.