Les taux d'échec composés dans les agents multi-étapes sont brutaux — on a déjà établi ça. Un workflow de sept étapes à 95 % de fiabilité par étape atterrit à environ 70 % de bout en bout. Trois runs sur dix explosent. Mais voilà ce que personne ne corrige : quand l'étape quatre te renvoie un HTTP 500, qu'advient-il des trois étapes déjà exécutées ? Le message Slack déjà envoyé, la ligne en base déjà écrite, le ticket Jira déjà créé. Ton agent ne sait pas quelles étapes ont abouti. Il n'a aucun checkpoint — aucune position sauvegardée pour reprendre. Et il n'a aucune logique de compensation — aucun « annuler » automatique pour le travail à moitié fait.

Voir le taux d'échec, c'est l'étape un. Survivre à l'échec, c'est l'étape deux. Personne ne livre l'étape deux.

Le théâtre du recovery

Les trois principaux runtimes d'agents ont lancé des fonctionnalités de recovery en avril. Aucune ne résout réellement le recovery.

Les Managed Agents d'Anthropic (8 avril) utilisent un event log en append-only — un journal en écriture seule de tout ce que l'agent a fait. Crash ? Redémarrage, relecture du journal, on continue. Leur équipe d'ingénierie : « Rien dans le harness n'a besoin de survivre à un crash. » Ça sonne résilient. Mais il n'y a pas de dead-letter queue pour les tâches échouées, pas de garantie exactly-once assurant que chaque action s'exécute une et une seule fois, et aucun moyen de rollback les effets de bord déjà complétés.

La mise à jour du Agents SDK d'OpenAI (15 avril) a ajouté le snapshotting et la rehydration — sauvegarde et restauration de l'état de l'agent entre les redémarrages de conteneur. Sauf que ça persiste l'historique des messages, pas l'état d'exécution. Le modèle se souvient de ce qu'il a dit ; il ne trace pas ce qu'il a fait.

Google ADK (annoncé à Cloud Next, 22 avril) livre SequentialAgent, ParallelAgent, LoopAgent plus un ResumabilityConfig. Le détail qui tue : c'est l'appelant qui doit détecter l'interruption et relancer manuellement. Aucun recovery automatique.

Trois approches différentes de la durabilité. Les trois modélisent l'exécution comme des boucles d'inférence — « réfléchir → appeler un outil → observer → répéter. » Aucune ne la modélise comme une machine à états durable — un système qui trace exactement dans quel état il se trouve et quelles transitions sont valides, comme un distributeur automatique qui se souvient que tu as déjà inséré ta pièce même après une coupure de courant.

Les solutions qui existent déjà (hors IA)

Les workflow engines ont résolu l'exécution durable il y a dix ans. L'industrie de l'IA ne les a juste pas encore adoptées.

Temporal encapsule chaque étape dans une activity retryable et rejouable. Crash en plein workflow ? Temporal rejoue depuis la dernière activity complétée — pas depuis zéro. Voici à quoi ressemble une étape d'agent wrappée avec Temporal :

@activity.defn
async def file_jira_ticket(ctx: AgentContext) -> TicketResult:
    """Temporal retries this automatically on failure.
    If the agent crashes mid-workflow, it replays
    from the last completed activity — not from scratch."""
    return await ctx.tools.jira.create_issue(
        summary=ctx.draft.title,
        idempotency_key=ctx.run_id  # prevents duplicate tickets
    )

Cette idempotency_key — un identifiant unique qui garantit que la même requête ne s'exécute pas deux fois — c'est toute la différence entre « production-grade » et « démo impressionnante ».

Project Think de Cloudflare (15 avril) a pris une route complètement différente : des bases SQLite par agent, des checkpoints step.do(), et une hibernation à coût zéro. Chaque agent est une entité durable isolée avec son propre état persistant, pas un job dans un orchestrateur centralisé. Pour les équipes déjà sur Cloudflare Workers, c'est sans doute le chemin le plus propre — pas de workflow engine externe, pas de message broker, juste des durable objects avec du checkpointing intégré.

Restate se situe entre les deux : plus léger que Temporal, plus structuré que des durable objects bruts. Il fournit des garanties exactly-once avec un mécanisme de replay basé sur un journal, et a publié des patterns d'intégration directe avec Google ADK.

Le milieu inconfortable

Voici le problème que personne ne veut admettre : le fossé va dans les deux sens.

Les workflow engines ne parlent pas LLM. Ils ne comprennent pas les token budgets — combien de texte une IA peut traiter par appel. Ils ne gèrent pas le model fallback routing — basculer sur un modèle moins cher quand le coûteux atteint ses rate limits. Ils n'ont aucune notion de prompt versioning, de gestion de context window, ou d'évolution des schémas de tool-call. Brancher des agents sur Temporal signifie écrire une couche de traduction entre « workflow step » et « inference call » — et la maintenir à chaque changement d'API de ton fournisseur de modèle.

Les plateformes d'agents ne comprennent pas la durabilité. Elles traitent les tool calls comme des effets de bord éphémères de l'inférence, pas comme des transitions d'état nécessitant des garanties transactionnelles. Un LLM qui appelle un outil est philosophiquement différent d'une étape de workflow qui appelle une fonction : le LLM pourrait décider de rappeler le même outil, d'en appeler un autre, ou d'halluciner un outil qui n'existe pas. Les workflow engines supposent des définitions d'étapes déterministes. Les LLM sont par définition non-déterministes.

Aucun des deux camps n'a tort. Ils résolvent chacun une moitié du même problème.

Ce que ça signifie pour toi

Si ton agent modifie un état externe sur plus de trois étapes — envoie des emails, écrit en base, appelle des API tierces — tu as déjà besoin des garanties d'un workflow engine. Ta plateforme d'agents ne les fournit pas. Tu as trois options :

  1. Greffer Temporal/Restate toi-même. Vraie complexité d'intégration, mais durabilité éprouvée au combat. Ça vaut le coup si tu fais tourner des agents en production avec de vrais SLA.
  2. Passer full Cloudflare. Si tu es déjà sur Workers, Project Think te donne des agents durables sans l'overhead d'orchestration. Contrepartie : vendor lock-in.
  3. Accepter le taux d'échec et construire de l'outillage de réconciliation manuelle. Honnêtement, pour des outils internes avec des utilisateurs indulgents, c'est peut-être rationnel. Mais ne viens pas appeler ça « production-ready ».

La convergence est inévitable. Le premier fournisseur à livrer l'exécution en machine à états durable comme primitive par défaut des agents — pas en afterthought, pas en intégration tierce — possèdera la couche de fiabilité production au-dessus des trois runtimes. Temporal le sait ; leur intégration avec le SDK Agents d'OpenAI est un land grab. Cloudflare le sait ; Project Think est conçu pour faire des agents une feature de plateforme.

Ta démo en sept étapes marche toujours à merveille. La mettre en production, ça veut toujours dire choisir avec quel mode de défaillance tu peux vivre.