Saga vs Process Manager : la confusion qui casse les workflows

Le virement est bloqué à l'étape 2 sur 4. Le débit a eu lieu, le crédit n'a pas encore été exécuté, et le processus a crashé entre les deux.

Le lendemain matin, l'équipe ouvre les logs et constate qu'il n'y a aucun état sauvegardé, aucun mécanisme de reprise, aucune compensation automatique. Le workflow qu'on appelait « notre saga » n'était pas une saga, c'était une séquence d'appels asynchrones sans état ni garantie.

La plupart des « sagas » en code métier sont en réalité des process managers. La confusion dépasse la sémantique, parce qu'elle a des conséquences sur la reprise d'erreur, la durabilité et la testabilité.

La saga originelle : transaction longue avec compensation

Garcia-Molina et Salem ont formalisé le concept en 1987 dans un papier ACM sur les transactions longue durée. Une saga y est une séquence de transactions locales, chacune dotée d'une transaction compensatoire qui peut l'annuler.

Saga de virement :
  T1: débiter compte source    → compensation : créditer compte source
  T2: créditer compte cible    → compensation : débiter compte cible

Si T2 échoue :
  Exécuter compensation de T1 → le débit est annulé

La saga originelle est stateless au sens du workflow. Elle décrit un contrat de compensation et n'orchestre rien ; elle ne sait pas « où on en est » dans le processus, seulement que si Ti échoue, les compensations C1...C(i-1) doivent être exécutées dans l'ordre inverse.

Le Process Manager : workflow stateful

Ce que la plupart des équipes appellent « saga » est en réalité un Process Manager, au sens des patterns d'intégration. La distinction est précise :