Temporal : rendre vos agents IA durables et résistants aux pannes
Les agents IA en production ont un défaut commun : ils sont fragiles. Un appel LLM qui échoue, un outil distant indisponible, un crash du processus, et c’est toute la chaîne qui s’effondre. La logique métier devient alors un labyrinthe de try / except, de retry maison et de jobs fantômes coincés à mi-parcours. Temporal propose une autre approche : transformer chaque exécution d’agent en workflow durable, dont l’état survit aux crashs, aux redéploiements et aux pannes réseau.
Temporal est un moteur d’orchestration open source (licence MIT, projet incubé par d’anciens ingénieurs Uber Cadence) qui sépare la logique d’orchestration (le workflow) des appels effectifs (les activités). Le moteur garde la trace exacte de chaque étape, ce qui permet de reprendre un agent là où il s’est arrêté, même plusieurs heures après.
Pourquoi un agent IA a besoin d’un moteur de workflow
Un agent qui appelle un LLM, lit un fichier, interroge une base, attend une validation humaine, puis relance un autre LLM, ressemble exactement à un workflow distribué de longue durée. Sans Temporal, on retrouve les mêmes problèmes que dans toute application distribuée : retries non idempotents, états perdus, pannes silencieuses, observabilité manquante.
Avec Temporal, on récupère gratuitement plusieurs propriétés clés :
- Persistance automatique : l’état du workflow est sauvegardé après chaque étape, sans code spécifique.
- Retry et timeout configurables : par activité, avec backoff exponentiel et politique précise.
- Reprise après crash : si le worker meurt, un autre reprend le workflow exactement où il en était.
- Workflows longs : un agent peut tourner pendant des jours, avec attente humaine ou signaux externes.
- Observabilité : interface web Temporal UI montre chaque étape, chaque retry, chaque erreur.
Le modèle Temporal en trois concepts
Workflow
Code déterministe qui décrit la suite des étapes. Il ne fait jamais d’appel réseau direct. Pour un agent IA, c’est l’équivalent du graphe d’exécution : prompt, choix d’outil, validation, boucle.
Activity
Code non-déterministe qui effectue les vrais appels : LLM, base de données, API tierces, MCP. C’est ici que l’on encapsule l’appel à Claude, Ollama ou vLLM.
Signal et query
Un workflow peut recevoir un signal externe (validation humaine, nouvelle instruction) ou répondre à une query (état courant). Idéal pour les agents semi-autonomes avec humain dans la boucle.
Un cas concret : agent de traitement documentaire
Imaginez un agent qui ingère un PDF, l’extrait avec Docling, vectorise avec pgvector, classifie avec un LLM local via Ollama, puis attend une validation humaine avant d’écrire dans un système métier. Sans orchestration, le moindre incident impose de tout relancer ou de gérer un état applicatif complexe.
Avec Temporal, chaque étape devient une activité retryable. La validation humaine devient un signal qui peut arriver dans la minute ou dans la semaine. Le workflow reste persisté, l’opérateur voit l’état exact dans Temporal UI, et si le worker tombe à l’étape 4, il reprend précisément là sans dupliquer les étapes 1 à 3.
Intégration avec l’écosystème agents IA
- LangGraph, Pydantic AI, DSPy : ces frameworks décrivent la logique d’agent, Temporal apporte la durabilité par-dessus. On encapsule chaque nœud dans une activité.
- MCP : chaque appel d’outil MCP devient une activité, avec retry idempotent et timeout dédié.
- Letta, Mem0 : la mémoire de l’agent est lue et écrite via activités, jamais dans le workflow lui-même.
- n8n : Temporal vise des workflows code-first plus exigeants en garanties de cohérence, n8n reste pertinent pour des automatisations visuelles plus simples.
Mise en route auto-hébergée
Le serveur Temporal se déploie en quelques commandes via Docker Compose ou Helm. Il s’appuie sur PostgreSQL, MySQL ou Cassandra pour la persistance, plus Elasticsearch ou OpenSearch en option pour la recherche d’historiques. Les SDK officiels existent pour Go, Java, Python, TypeScript, .NET et PHP, ce qui couvre la quasi-totalité des stacks.
Pour un POC, lancer temporal server start-dev suffit : un binaire unique, base SQLite intégrée, UI à l’adresse localhost:8233. Idéal pour valider l’intérêt avant de passer à un déploiement Kubernetes plus sérieux.
Points d’attention
- Déterminisme du workflow : pas d’appel réseau, pas d’aléatoire, pas de date système hors API Temporal. Tout doit passer par des activités.
- Versioning : les workflows en cours doivent rester compatibles avec leur ancien code. Temporal fournit une API patched pour gérer la migration.
- Coût opérationnel : un cluster Temporal en production demande de l’attention, monitoring inclus. Pour des cas légers, l’option managée Temporal Cloud peut faire gagner du temps.
En résumé
Temporal apporte aux agents IA ce que Kubernetes apporte aux conteneurs : un substrat de durabilité, de reprise et d’observabilité. C’est l’outil de choix quand un agent doit survivre à une panne, attendre un humain, ou enchaîner des dizaines d’étapes critiques sans perdre son état. Pour un projet d’agents en production, l’investissement initial est rapidement rentabilisé par la réduction du code défensif et des incidents silencieux.
