— 16 mai 2026 · 9 min de lecture

Saga vs CQRS appliqués aux flux EDI

Saga et CQRS sont des patterns nés dans le monde des microservices distribués (Hector Garcia-Molina & Kenneth Salem, 1987 ; Greg Young, 2010). Ils s'appliquent avec une remarquable précision à des flux EDI réels — saga pour orchestrer une commande complète, CQRS pour exposer un read-model du statut des partenaires.

Pourquoi ces patterns dans un contexte EDI ?

Un flux EDI complet — disons une commande B2B — n'est jamais une transaction atomique. Une ORDERS envoyée à un fournisseur génère, dans les jours ou semaines qui suivent, une ORDRSP (accusé métier), une ou plusieurs DESADV (avis d'expédition), une RECADV (avis de réception), et finalement une INVOIC (facture). Chaque étape vit dans un système différent — ERP acheteur, ERP fournisseur, WMS, TMS, plateforme de facturation — sans transaction ACID globale. Le besoin : une coordination métier qui sait passer par tous ces états sans verrou distribué, et qui sait revenir en arrière (ou compenser) en cas d'incident.

Ce besoin est précisément celui que Garcia-Molina et Salem ont nommé saga en 1987 dans leur papier « Sagas » au SIGMOD : une séquence de transactions locales, chacune compensable individuellement. Les flux EDI étaient des sagas avant la lettre — la lettre est juste arrivée 25 ans après la pratique.

Une saga EDI concrète

Prenons un cas type : un retailer européen passe une commande de 200 palettes de produits frais à un fournisseur. La saga vue de l'acheteur a typiquement l'allure suivante :

1. État : ORDERED. L'ERP acheteur émet une ORDERS EDIFACT vers le fournisseur. Aucune compensation possible tant que le fournisseur n'a pas répondu — l'événement métier reste réversible.
2. État : ACK_RECEIVED. Le fournisseur retourne une CONTRL syntaxique puis une APERAK ou une ORDRSP métier. Si ORDRSP positif (segment BGM+231 ou BGM+233), la saga passe à CONFIRMED. Si négatif, la saga déclenche une compensation : notification au procurement, recherche d'un fournisseur alternatif, ou abandon.
3. État : SHIPPED. Le fournisseur émet une DESADV par camion expédié. Cet état est atteint progressivement (200 palettes peuvent partir en 3 camions sur 5 jours). La saga doit gérer le fan-out — c'est typiquement où elle se complique.
4. État : RECEIVED. Le WMS du retailer émet une RECADV au fournisseur, avec écarts éventuels (manquants, casses). Les écarts importants déclenchent une compensation : REQOTE de retour, débit de prix, ou litige.
5. État : INVOICED. Le fournisseur émet une INVOIC qui doit matcher la commande (3-way matching ORDERS / DESADV / INVOIC). Désaccord → compensation par avoir ou contestation. Accord → bon à payer.
6. État : PAID. Le débit bancaire émet une REMADV au fournisseur. La saga se termine ici, plusieurs semaines après l'ORDERS initiale.

Cette saga, vue depuis le process manager (pattern EIP 312, Hohpe & Woolf 2003), est typiquement implémentée par un automate fini persistant — Camunda, Temporal, ou un microservice maison sur Kafka avec un state machine. L'identifiant de la saga est presque toujours le numéro de bon de commande (segment RFF+ON en EDIFACT) qui sert de correlation identifier.

CQRS pour le statut des partenaires

CQRS (Command Query Responsibility Segregation), théorisé par Greg Young à partir de 2010 sur la base des travaux de Bertrand Meyer, sépare explicitement les opérations de modification (commandes) des opérations de lecture (requêtes). L'idée force : optimiser indépendamment les deux chemins, parce qu'ils ont des contraintes différentes — la commande est transactionnelle et rare, la requête est éventuellement-consistante et fréquente.

Sur un hub EDI multi-partenaires, CQRS s'applique très naturellement à la question : « quel est le statut courant de mes 4 000 partenaires EDI ? » Le statut est dérivé d'événements émis par les flux saga ci-dessus : dernier message reçu, dernier acquittement, taux d'erreur sur les 30 derniers jours, latence moyenne d'acquittement.

• Côté commande (write model) : chaque saga EDI émet des événements ORDER_SHIPPED, INVOICE_RECEIVED, CONTRL_LATE, VALIDATION_FAILED sur un bus Kafka ou NATS. Le write model est optimisé pour la cohérence transactionnelle au sein d'une saga, pas pour les requêtes croisées.
• Côté requête (read model) : un consommateur projette ces événements dans une base de lecture dénormalisée — typiquement PostgreSQL avec des index GIN, ou ElasticSearch. La table partner_status contient une ligne par partenaire avec ses indicateurs courants. Une dashboarding interrogée par les chefs de produit ou le support se base exclusivement sur cette projection.
• Cohérence éventuelle : il y a un délai entre l'événement et la projection — typiquement quelques secondes. Pour le dashboard, c'est acceptable. Pour les décisions opérationnelles critiques (suspendre un partenaire en raison d'erreurs systémiques), on requête le write model directement.

Combiner saga et CQRS

Saga et CQRS ne sont pas concurrents — ils sont complémentaires. La saga orchestre l'écriture distribuée ; CQRS expose une lecture optimisée sur les états dérivés.

Dans un hub EDI moderne, l'architecture cible ressemble typiquement à ceci :

• Process Manager (Camunda, Temporal) qui pilote N sagas en cours, une par flux ORDERS-INVOIC.
• Bus d'événements (Kafka) où chaque transition de saga émet un événement immuable, partitionné par identifiant partenaire pour garantir l'ordre par-partenaire.
• Plusieurs projections en parallèle : une projection « dashboard opérationnel », une projection « facturation interne » (combien d'INVOIC sont en attente de bon à payer ?), une projection « SLA partenaire » (qui dépasse le seuil contractuel d'acquittement ?).
• Audit log immuable : le bus Kafka lui-même sert d'event store, replay possible à tout moment pour reconstruire une projection ou auditer un flux.

Quand ces patterns ne s'imposent pas

Saga et CQRS apportent une complexité non-négligeable. Ils ne se justifient pas sur les cas suivants :

• Flux EDI très simples : un seul partenaire, une seule transaction (par exemple uniquement des factures INVOIC entrantes). Un pipeline ETL classique avec idempotence (EIP idempotency) suffit.
• Volume faible : pour moins de quelques dizaines de messages par jour, l'overhead d'un process manager n'est pas amorti.
• Pas de requête analytique récurrente : si personne ne consulte de dashboard partenaire ou de SLA, CQRS est superflu.
• Équipe sans expérience event-driven : l'investissement formation et outillage est conséquent. Une implémentation maladroite peut être pire qu'un batch classique.

Deux outils, un même corpus de problèmes

Saga et CQRS sont des patterns d'architecture distribuée qui trouvent dans l'EDI un terrain particulièrement fertile, parce que les flux EDI sont natifs distribués, multi-acteurs et multi-temps. Pour un hub EDI moderne, leur combinaison apporte trois choses simultanément : orchestration robuste des flux complexes, projection rapide pour les besoins de lecture, et audit trail by-design. Pour creuser, voir les pages Process Manager (EIP 312) et Correlation Identifier (EIP 163), qui sont les briques élémentaires d'une saga EDI bien construite.