Le choix entre ces paradigmes n’est pas simplement une pr\u00e9f\u00e9rence de repr\u00e9sentation graphique ; il influence directement l’architecture du syst\u00e8me, la gestion de la concurrence, la r\u00e9cup\u00e9ration d’erreurs et la maintenabilit\u00e9. Cette \u00e9tude de cas explore l’application pratique des deux approches au sein du cycle de vie d’une commande e-commerce moderne, d\u00e9montrant comment les sous-\u00e9tats s\u00e9quentiels et concurrents peuvent \u00eatre utilis\u00e9s pour construire des machines \u00e0 \u00e9tats r\u00e9silientes, \u00e9volutives et logiquement coh\u00e9rentes.<\/p>\n
![\"Orchestrating](\"https:\/\/blog.visual-paradigm.com\/wp-content\/uploads\/2026\/05\/img_6a0fd6eb638db.png\")
<\/p>\n
\n
Concepts fondamentaux<\/h2>\n
Avant de plonger dans l’\u00e9tude de cas, il est essentiel d’\u00e9tablir la distinction th\u00e9orique entre les deux architectures de sous-\u00e9tats.<\/p>\n
Sous-\u00e9tats s\u00e9quentiels (\u00e9tats OU)<\/h3>\n
Dans une configuration s\u00e9quentielle, un \u00e9tat compos\u00e9 ne peut occuper qu’un seul sous-\u00e9tat \u00e0 la foisun seul sous-\u00e9tat \u00e0 la fois<\/strong>. Les transitions suivent un chemin lin\u00e9aire pr\u00e9d\u00e9fini o\u00f9 chaque \u00e9tat doit \u00eatre termin\u00e9 avant que le suivant ne commence.<\/p>\n Condition logique :<\/strong>\u00a0\u00c9tat A\u00a0OU<\/strong>\u00a0\u00c9tat B.<\/p>\n<\/li>\n Utilis\u00e9 id\u00e9alement pour :<\/strong>\u00a0Flux de travail \u00e9tape par \u00e9tape, assistants, pipelines de validation et modes op\u00e9ratoires mutuellement exclusifs.<\/p>\n<\/li>\n<\/ul>\n Dans une configuration concurrente, un \u00e9tat compos\u00e9 est divis\u00e9 en plusieurs r\u00e9gions ind\u00e9pendantes. Lorsque l’\u00e9tat parent devient actif,toutes les r\u00e9gions sont activ\u00e9es simultan\u00e9ment<\/strong>, chacune maintenant son propre cycle de vie ind\u00e9pendant et ses transitions d’\u00e9tat.<\/p>\n Condition logique :<\/strong>\u00a0R\u00e9gion 1 (\u00c9tat A)\u00a0ET<\/strong>\u00a0R\u00e9gion 2 (\u00c9tat X).<\/p>\n<\/li>\n Meilleur usage pour :<\/strong>Ex\u00e9cution parall\u00e8le de processus, surveillance en arri\u00e8re-plan accompagnant l’interaction avec l’interface utilisateur, et coordination d\u00e9centralis\u00e9e des sous-syst\u00e8mes.<\/p>\n<\/li>\n<\/ul>\n Pour illustrer ces concepts en pratique, nous mod\u00e9liserons deux phases critiques du pipeline de traitement des commandes d’une plateforme e-commerce :\u00a0Traitement du paiement<\/strong>\u00a0et\u00a0Ex\u00e9cution de la commande<\/strong>. Chaque phase d\u00e9montre pourquoi une architecture de sous-\u00e9tat sp\u00e9cifique est le choix optimal.<\/p>\n Le traitement du paiement est intrins\u00e8quement lin\u00e9aire et d\u00e9pendant de l’\u00e9tat. L’autorisation doit pr\u00e9c\u00e9der la validation de la fraude, qui elle-m\u00eame doit pr\u00e9c\u00e9der la capture des fonds. Sauter des \u00e9tapes ou les ex\u00e9cuter en parall\u00e8le violerait la conformit\u00e9 financi\u00e8re et mettrait en danger l’int\u00e9grit\u00e9 de la transaction. Par cons\u00e9quent, une configuration s\u00e9quentielle (Or) est obligatoire.<\/p>\n\n
Sous-\u00e9tats concurrents (\u00e9tats ET)<\/h3>\n
\n
Comparaison structurelle<\/h3>\n
\n\n
\n \nFonctionnalit\u00e9<\/th>\n Sous-\u00e9tats s\u00e9quentiels<\/th>\n Sous-\u00e9tats concurrents<\/th>\n<\/tr>\n<\/thead>\n \n \u00c9tats actifs<\/strong><\/td>\n Exactement un sous-\u00e9tat est actif \u00e0 tout moment donn\u00e9.<\/td>\n Un sous-\u00e9tat dans\u00a0chaque<\/em>\u00a0r\u00e9gion parall\u00e8le est active simultan\u00e9ment.<\/td>\n<\/tr>\n \n Variables internes<\/strong><\/td>\n Contexte partag\u00e9, modifi\u00e9 de mani\u00e8re s\u00e9quentielle.<\/td>\n Souvent ind\u00e9pendants ; les modifications doivent \u00eatre s\u00e9curis\u00e9es par thread ou pilot\u00e9es par \u00e9v\u00e9nement.<\/td>\n<\/tr>\n \n Complexit\u00e9<\/strong><\/td>\n Faible \u00e0 moyenne ; facile \u00e0 suivre de mani\u00e8re lin\u00e9aire.<\/td>\n Plus \u00e9lev\u00e9e ; n\u00e9cessite le suivi de la synchronisation et des conditions de course potentielles.<\/td>\n<\/tr>\n \n Condition de sortie<\/strong><\/td>\n Atteindre un \u00e9tat final \u00e0 l’int\u00e9rieur, ou une transition externe explicite.<\/td>\n G\u00e9n\u00e9ralement n\u00e9cessite\u00a0tous<\/em>\u00a0r\u00e9gions pour atteindre leurs \u00e9tats finaux (fusion), ou une interruption externe.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
\n\u00c9tude de cas : Cycle de vie d’une commande e-commerce<\/h2>\n
Phase 1 : Sous-\u00e9tats s\u00e9quentiels dans le traitement du paiement<\/h3>\n
<\/p>\n
\n
\n