Un processus réparti peut fonctionner en démonstration et devenir incompréhensible au premier incident. Le risque apparaît lorsque cinq services ont réagi, que deux attendent encore et qu’aucune équipe ne sait dire si la commande client est terminée. Le débat « orchestration ou chorégraphie » cache alors une question plus concrète : qui possède la progression et la reprise ?
Le vrai enjeu n’est pas de choisir une architecture réputée moderne. Il est de rendre les invariants, les délais, les échecs et les responsabilités explicites. L’orchestration centralise une décision de processus ; la chorégraphie distribue les réactions. Chacune déplace le couplage et le coût d’exploitation, sans les supprimer.
Ce guide s’adresse aux architectes, responsables produit, développeurs, SRE et équipes métier qui font collaborer plusieurs services ou applications. Il fournit des critères, un cas comparé, des erreurs fréquentes, des seuils locaux et un plan de mise en œuvre qui ne présume pas qu’un modèle convient partout.
Pour inscrire ce choix dans une application durable, une démarche de développement web sur mesure permet d’aligner le découpage technique avec le parcours, les preuves et le run.
Clarifier orchestration et chorégraphie sans caricature
L’orchestrateur connaît la progression
Dans une orchestration, un composant porte l’état du processus et demande aux participants d’exécuter des actions. Il sait qu’après réservation du stock vient le paiement, puis l’expédition, ou qu’une compensation doit être déclenchée. Les services restent propriétaires de leur domaine ; l’orchestrateur possède l’enchaînement transverse.
Il ne doit pas devenir un moteur qui lit directement toutes les bases et reproduit chaque règle locale. Il envoie des commandes, reçoit des résultats et décide de la suite selon un contrat. La frontière est importante : coordonner n’est pas absorber le métier des participants.
La chorégraphie distribue les réactions
Dans une chorégraphie, un service publie un événement décrivant un fait. Les autres réagissent sans qu’un chef central leur prescrive tout le scénario. Le service commande publie « CommandeConfirmée » ; facturation, fidélité et notification peuvent alors avancer de manière autonome.
Cette autonomie n’implique pas l’absence de gouvernance. Les événements sont des contrats partagés, leur sens doit rester stable et la chaîne globale doit être observable. Contre-intuitivement, retirer le coordinateur peut augmenter le couplage cognitif : comprendre un parcours exige alors de suivre de nombreux abonnements répartis.
Partir du processus métier et de ses invariants
Avant de dessiner les flèches, décrivez le résultat, les états intermédiaires et les règles qui ne doivent jamais être violées. Une commande peut-elle rester payée sans stock ? Pendant combien de temps ? Qui décide qu’elle est abandonnée ? Quelle donnée fait foi ? Ces réponses révèlent si une vision centrale du processus est nécessaire.
Un processus court, avec une seule équipe et une transaction locale, n’a peut-être besoin ni de saga ni de broker. Le découper en événements augmente le nombre de pannes possibles. Si la cohérence immédiate est indispensable et si les données peuvent vivre ensemble, alors une transaction simple reste souvent le meilleur choix.
À l’inverse, un parcours long qui attend une validation humaine, un paiement externe ou une livraison ne peut pas conserver une transaction ouverte. Il doit représenter l’attente et la compensation. L’architecture choisie dépend alors du nombre de participants, de leur autonomie, du besoin de visibilité et de la fréquence des changements.
Un premier signal faible est un statut global recalculé différemment par plusieurs écrans. Un second signal faible est un incident dont le diagnostic exige de réunir trois équipes devant des logs sans identifiant commun. Ils indiquent que la propriété du processus est floue.
Comprendre les forces et les limites de l’orchestration
Gagner une vue explicite du parcours
L’orchestration convient lorsque l’ordre est important, que les délais et compensations sont nombreux ou qu’un propriétaire métier doit voir l’état global. Le modèle peut afficher où se trouve chaque instance, quelle échéance approche et quelle action est autorisée. La reprise est guidée par un état durable plutôt que par une reconstruction des événements.
Elle simplifie aussi l’évolution d’un parcours coordonné par une équipe. Ajouter une étape conditionnelle se lit dans un flux central, alors qu’une chorégraphie peut demander de modifier plusieurs réactions. Les tests de scénarios et les timers sont plus directs lorsque le coordinateur porte la décision.
Éviter le coordinateur omniscient
Le coût caché apparaît lorsque l’orchestrateur connaît les tables, les règles et les erreurs internes de tous les services. Il devient un monolithe distribué et chaque équipe attend son évolution. Le contrat doit rester au niveau des capacités : réserver, facturer, notifier, obtenir un verdict. Le participant traduit ses erreurs techniques en résultats de domaine compréhensibles.
L’orchestrateur est une dépendance critique. Il exige stockage d’état, haute disponibilité, versionnement des instances et stratégie de déploiement. Une nouvelle version du workflow ne doit pas rendre illisibles les instances commencées sous l’ancienne. Si le produit change souvent, alors cette coexistence se conçoit dès le départ.
Comprendre les forces et les limites de la chorégraphie
Préserver l’autonomie des domaines
La chorégraphie convient lorsque les réactions sont indépendantes, que l’émetteur n’a pas à attendre leur résultat et que chaque équipe possède clairement son service. Ajouter un consommateur analytique ou une notification ne change pas le producteur. Un événement factuel peut ainsi devenir une capacité d’intégration stable.
Elle supporte bien la propagation d’un fait : client créé, catalogue publié, facture acquittée. Chaque consommateur traite à son rythme et reste idempotent. Si l’un tombe, les autres continuent. Le producteur ne doit toutefois pas considérer que tous les effets ont réussi simplement parce qu’il a publié.
Maîtriser la chaîne invisible
Lorsque A déclenche B, qui déclenche C, qui publie un événement auquel D répond, une modification locale peut casser un résultat global que personne ne possède. Les dépendances existent toujours, mais elles ne figurent plus dans un appel direct. Un catalogue d’événements, des owners et des tests de contrat rendent cette topologie visible.
La chorégraphie est moins adaptée à une séquence avec nombreuses conditions, délais et compensations coordonnées. Chaque service doit connaître une part du scénario, et les événements de correction prolifèrent. Si le métier demande « où est mon dossier et que manque-t-il ? », alors une projection globale ou un coordinateur devient nécessaire.
Assumer une architecture hybride plutôt qu’un choix idéologique
Un SI réel combine souvent les deux. Un orchestrateur peut piloter le cœur d’une commande — réservation, paiement, compensation — puis publier « CommandeFinalisée ». Des services de notification, analytique et fidélité réagissent par chorégraphie. La frontière suit la différence entre effets nécessaires au résultat et effets secondaires autonomes.
Un domaine peut aussi orchestrer son processus interne tout en échangeant des événements avec les autres domaines. Cette combinaison limite la connaissance transverse. L’orchestrateur ne coordonne que les participants indispensables ; les autres consomment un fait stable sans influencer son achèvement.
Le modèle hybride ne dispense pas de nommer une source de vérité. Pour chaque étape, le produit sait qui peut répondre et qui peut relancer. Si plusieurs composants se croient propriétaires de la même transition, alors l’hybridation devient une duplication, pas un compromis.
Distinguer commandes, événements et réponses
Dire qui attend quoi
Une commande exprime une intention adressée à un responsable : « RéserverStock ». Elle peut être acceptée ou refusée. Un événement décrit un fait passé : « StockRéservé ». Il n’ordonne pas aux consommateurs de se comporter d’une façon cachée. Nommer un événement « FaitesLaFacture » transforme une commande en diffusion ambiguë.
Le contrat porte identifiant, corrélation, causalité, version et date. Les consommateurs ne déduisent pas l’ordre global de l’heure système. Une réponse distingue résultat fonctionnel, indisponibilité technique et délai dépassé. L’orchestrateur peut alors décider sans connaître l’exception interne du participant.
Faire évoluer sans synchroniser tous les déploiements
Les champs ajoutés sont optionnels ou possèdent une valeur définie. Un changement de sens produit un nouveau type ou une nouvelle version. Les producteurs testent leurs contrats, les consommateurs tolèrent les champs inconnus et les propriétaires connaissent les abonnements. Un schéma valide ne garantit pas le sens ; des exemples métier complètent la compatibilité syntaxique.
Les messages peuvent être livrés plusieurs fois ou hors ordre. Chaque participant définit son idempotence et ses versions attendues. Cette discipline est nécessaire dans les deux modèles : l’orchestrateur n’annule pas les réalités du réseau, et la chorégraphie ne les absorbe pas automatiquement.
Modéliser échecs, délais et compensations
Une saga ne fournit pas une transaction ACID distribuée. Elle enchaîne des transactions locales et, lorsque nécessaire, des compensations. Compenser n’est pas remonter le temps : rembourser un paiement peut laisser des frais, annuler une réservation peut échouer, retirer un email déjà lu est impossible. Le métier doit accepter ces états.
L’orchestration rend la politique visible : après tel délai, relancer ; après tel refus, compenser ; après telle incertitude, demander une intervention. En chorégraphie, les participants publient leurs résultats et un autre composant peut construire une projection ou déclencher une correction. Dans les deux cas, une échéance et un owner sont indispensables.
Les retries ciblent les erreurs transitoires et conservent l’idempotence. Les refus permanents ne doivent pas tourner en boucle. Une file d’échec sans procédure est une perte différée. Le runbook décrit les droits de rejeu, la prévisualisation, l’impact et la preuve de convergence.
Par exemple, si le paiement réussit mais que la réservation expire, alors le processus peut tenter une nouvelle réservation pendant un délai décidé, puis rembourser et informer. Le client doit voir un état honnête pendant cette incertitude. Le choix technique est subordonné à cette politique métier.
Rendre la progression visible et exploitable
Observer une instance, pas seulement des services
Un identifiant de corrélation traverse commandes, événements, logs et traces. Une projection durable montre l’état de l’instance, la dernière transition, l’échéance et la cause d’un blocage. Dans une orchestration, cette vue peut provenir du moteur. Dans une chorégraphie, elle est souvent reconstruite à partir des événements ; sa fraîcheur et ses trous doivent être visibles.
Les métriques techniques — latence, erreurs, backlog — se relient à un résultat : commandes en attente de paiement, dossiers sans validation, compensations non terminées. Une alerte nomme l’impact et l’équipe responsable. Le taux global de messages consommés ne prouve pas que le parcours converge.
Exercer la reprise avec les mêmes outils que la production
Les entrées sont l’identifiant, l’état attendu, la version et les événements corrélés ; les sorties sont le verdict et la prochaine action. Les responsabilités séparent owner du processus et owners de domaines. L’instrumentation mesure âge et convergence, le monitoring alerte, la journalisation garde les décisions, et le rollback passe par une compensation ou un repli versionné.
Les dépendances, seuils, contrats, idempotence et délais figurent dans le runbook. Un support autorisé peut reprendre une étape sans modifier une base ni republier un événement artisanal. La traçabilité conserve l’opérateur, le motif et le résultat. Cette mise en œuvre compte davantage que le diagramme initial.
Cas concret : coordonner une commande B2B
Comparer les deux modèles sur le même parcours
Cas concret. Une commande B2B doit vérifier le crédit, réserver un stock, obtenir un paiement puis lancer la préparation. L’analytique et la notification commerciale sont utiles mais ne conditionnent pas le résultat. Les équipes crédit, stock et paiement ont des cycles de livraison distincts.
En chorégraphie pure, chaque résultat déclenche le suivant. Le flux nominal paraît élégant, mais la politique devient difficile à localiser : qui attend le crédit, qui décide d’expirer la réservation et qui rembourse ? Une nouvelle condition de paiement touche plusieurs consommateurs. Le statut client est une projection qui peut prendre du retard.
En orchestration pure, le coordinateur demande chaque capacité et porte les timers. Le parcours et les compensations sont lisibles, mais il risque de recopier les règles de crédit et de stock. La conception correcte lui fait seulement interpréter « accepté », « refusé » ou « indéterminé » et laisse chaque domaine décider comment obtenir ce verdict.
Décider avec des seuils et une panne jouée
Le choix retenu est hybride : orchestration pour les quatre étapes nécessaires, événement « CommandeConfirmée » pour analytique et notification. Sur un pilote local, l’équipe exige que 99 % des commandes nominales convergent en moins de cinq minutes et qu’aucune compensation ne reste sans owner plus de trente minutes. Ces seuils sont qualifiés par le volume, les contrats aval et la promesse de ce produit ; ils ne sont pas universels.
Un scénario de recette coupe le paiement après autorisation mais avant réponse. L’idempotence retrouve l’autorisation, l’orchestrateur reprend sans second débit et la projection client conserve un état « confirmation en cours ». Cette preuve décide le go, pas seulement le taux de tests unitaires.
Dans quels cas chaque modèle convient-il ?
L’orchestration favorise les processus longs, conditionnels, soumis à délais ou compensations, avec besoin de suivi central. Elle convient lorsque l’équipe propriétaire peut assumer le moteur et que la séquence constitue une capacité produit. La chorégraphie favorise les faits largement diffusés et les réactions réellement autonomes.
Une petite équipe sur un monolithe modulaire peut garder une coordination en code et des événements internes, sans déployer immédiatement un système distribué. Une organisation avec domaines autonomes peut utiliser un broker, mais doit financer contrats, catalogue et observabilité. Le nombre de services n’est pas à lui seul un critère.
Si une obligation transverse doit être accomplie avant d’annoncer le succès, alors un propriétaire de progression est généralement nécessaire. En revanche, si un consommateur peut échouer sans invalider le fait émis, la chorégraphie lui donne une autonomie utile.
Erreurs fréquentes dans le choix et la mise en œuvre
- Choisir par mode : « événementiel » devient un objectif sans contrainte métier explicite.
- Cacher des commandes en événements : l’émetteur attend un effet mais aucun consommateur n’en est responsable.
- Créer un orchestrateur omniscient : il reproduit les règles et les données de tous les domaines.
- Ignorer les compensations imparfaites : le diagramme suppose qu’une annulation efface tout effet réel.
- Confondre publication et succès : l’interface confirme un résultat alors que les réactions restent inconnues.
- Oublier les instances anciennes : un déploiement modifie le workflow sans stratégie de version.
Ces erreurs augmentent le coût complet et le temps de diagnostic. La correction consiste à rendre visible la responsabilité, le résultat attendu et les fenêtres d’incertitude, puis à choisir le minimum de coordination nécessaire.
Matrice de décision entre orchestration, chorégraphie et hybride
Évaluez chaque processus, pas le SI entier. Plus les étapes sont conditionnelles, les compensations coordonnées et la visibilité globale importantes, plus l’orchestration est pertinente. Plus les réactions sont facultatives, indépendantes et possédées par des domaines autonomes, plus la chorégraphie est naturelle.
- D’abord, écrire le résultat, les invariants, les délais et les états d’incertitude.
- Ensuite, nommer le propriétaire de chaque capacité et celui de la progression globale.
- Puis, comparer évolution, observabilité, compensation et coût complet de run.
- Enfin, isoler les effets nécessaires des réactions autonomes et tester un modèle hybride.
Si personne n’a besoin de connaître l’achèvement global, alors un orchestrateur est probablement superflu. Si le client attend un résultat composé et qu’aucun service ne peut l’expliquer, alors la chorégraphie pure est probablement insuffisante.
Plan d’action pour mettre en œuvre le modèle retenu
D’abord, modéliser un seul parcours
Choisissez un processus avec douleur mesurée. Cartographiez résultat, états, participants, événements, commandes, délais et compensations. Désignez la source de vérité et l’owner de reprise. Ne changez pas encore le découpage : cette carte doit être validée par le métier et le support.
Ensuite, fermer les contrats et l’idempotence
Versionnez messages et résultats, définissez corrélation et causalité, puis testez les livraisons répétées et hors ordre. Pour une orchestration, persistez l’état et la version du workflow. Pour une chorégraphie, inventoriez les abonnements et construisez la projection de suivi.
Puis, provoquer les pannes
Coupez chaque participant avant et après son effet, dépassez les délais et rendez une compensation indisponible. Vérifiez que l’utilisateur voit un état honnête et que le support peut agir avec le runbook. Mesurez temps de convergence, reprises manuelles et incidents sans owner.
Enfin, étendre sous condition
Ouvrez un volume borné, comparez les seuils au contexte réel et surveillez le coût caché de coordination. Étendez si le parcours converge et reste explicable. Le rollback conserve les instances déjà lancées et leur version ; il ne se limite pas à redéployer l’ancien code.
La revue fait suivre une instance nominale et une instance compensée par une personne qui n’a pas développé le flux. Elle confirme que le propriétaire global et les domaines arrivent au même verdict. Une extension attend si la progression dépend encore d’un log local, si une ancienne instance ne survit pas au déploiement ou si une compensation n’a pas d’échéance.
- Chaque commande et chaque événement ont un sens, une version et un owner.
- La progression globale reste visible pendant une panne et un redéploiement.
- Les délais, compensations et reprises sont testés avec les outils du run.
Références officielles et guides complémentaires
Le catalogue officiel Microsoft décrit le patron de chorégraphie et ses compromis. Le patron Saga rappelle le rôle des transactions locales et compensations dans un processus distribué.
La documentation Symfony Messenger fournit les mécanismes de messages, handlers, retries et transports. Elle n’impose pas le propriétaire métier : ce choix appartient à l’architecture du produit.
Pour les preuves internes, utilisez le guide d’observabilité d’un workflow métier, le test des workflows à exceptions et le guide de monitoring applicatif.
Conclusion : choisir où vit la responsabilité du processus
L’orchestration et la chorégraphie ne suppriment ni le couplage ni les pannes. Elles placent différemment la connaissance de la progression, la décision et la reprise.
Le bon choix part du résultat métier, des invariants et des responsabilités. Un coordinateur sert les séquences complexes ; des événements servent les réactions autonomes. Un modèle hybride est souvent plus fidèle à cette frontière.
La décision devient solide lorsqu’un incident est traçable, une compensation est exercée, une ancienne instance reste lisible et le support sait dire ce qui manque. Ces preuves comptent davantage que la pureté du diagramme.
Dawap peut vous accompagner pour concevoir et éprouver cette architecture avec une application web sur mesure alignée sur son exploitation.
