Publié le 24 septembre 2026 à 13:00 · Publication originale
Il crée son dossier, commande son ordinateur puis attend trois jours l'autorisation du responsable avant d'ouvrir ses accès.
Au deuxième jour, le serveur qui exécutait le processus tombe.
Que reste-t-il?
Dans une application classique, il faut enregistrer explicitement l'état: étapes terminées, données reçues, attente en cours, erreurs et opérations à reprendre.
L'exécution durable propose une autre architecture.
Temporal, projet open source spécialisé dans ce mécanisme, conserve une histoire ordonnée des événements produits par le processus.
Lorsqu'un worker disparaît, un autre peut récupérer cette histoire et rejouer le code afin de reconstruire son état.
Les opérations externes, appelées "Activities", ne sont pas simplement rejouées.
Si l'historique indique qu'une activité a déjà été exécutée et terminée, son résultat enregistré est réutilisé.
Le programme retrouve ainsi son état sans restaurer la mémoire vive de l'ancienne machine.
Cette propriété impose une contrainte inhabituelle: le code du workflow doit être déterministe.
Avec le même historique, il doit produire la même séquence de commandes.
Lire directement l'heure du système, générer un nombre réellement aléatoire ou appeler une API depuis cette partie du code pourrait produire un résultat différent pendant le rejeu.
Temporal fournit donc des primitives compatibles avec ce mécanisme et déplace les interactions non déterministes vers les Activities.
Un processus peut alors attendre une minute, trois jours ou plusieurs mois sans qu'un serveur reste bloqué pendant toute cette période.
L'état logique du travail survit à l'ordinateur qui l'avait commencé.
Pour des agents destinés à conduire des processus longs, cette propriété devient essentielle: leur mémoire opérationnelle ne peut dépendre de la durée de vie d'un processus informatique.
ULTRA®
L'exécution durable crée un problème surprenant lors d'une mise à jour logicielle.
Un workflow commencé lundi peut être encore actif lorsque son code est modifié vendredi.
Au prochain rejeu, la nouvelle version doit produire des commandes compatibles avec l'histoire créée par l'ancienne.
Ajouter, supprimer ou déplacer certaines opérations peut sinon provoquer une erreur de non-déterminisme.
Temporal propose donc des mécanismes de versionnement et permet de tester une nouvelle définition en rejouant d'anciens historiques avant son déploiement.
Le passé devient littéralement un test de compatibilité du nouveau code.
Autre détail: une Activity peut être relancée après un timeout ou un crash. Une opération externe doit donc rester idempotente lorsqu'elle possède des effets irréversibles.
Conseil: donner aux paiements, commandes ou créations de comptes une clé d'idempotence stable.
Une exécution peut être durable tout en produisant deux paiements si son effet externe ne l'est pas.