State Machine (cycle de vie partenaire EDI)

Variante du pattern State Machine, appliquée au cycle de vie technique d'un partenaire EDI plutôt qu'au cycle d'un message individuel. Le pattern qui structure l'onboarding et l'opération partenaire dans un hub multi-tenant.

Problème

Sans état explicite du cycle partenaire, on ne sait pas répondre : « Où en est le partenaire Acme dans son onboarding ? », « Combien de partenaires sont en attente de certificate ? », « Qui est en production active depuis moins d'un mois ? ». L'information est éparpillée entre Salesforce, Confluence, un Excel et la tête de quelques personnes. Les dérives passent inaperçues — un partenaire stalle 3 mois sans qu'on le détecte. La direction n'a pas de vision pilotage.

Forces

• Le cycle partenaire est long : 2-6 semaines d'onboarding, puis années en production.
• Les transitions doivent être contrôlées : un partenaire ne passe pas en production sans avoir passé les tests.
• L'auditabilité est exigée : prouver qui a validé telle étape, quand, sur quelle base.
• Les états d'erreur sont des états réels : stalled, suspended, offboarding ne sont pas des exceptions, ce sont des états dans lesquels un partenaire peut rester des semaines.
• L'aspect temporel : certaines transitions doivent intervenir dans un délai (SLA onboarding 30 jours).

Solution

Modéliser le cycle partenaire comme une machine à états explicite persistée. Chaque partenaire a une rangée DB avec { partnerId, state, history: [{state, at, by, reason}], lastActivityAt }. Les transitions sont gardées (préconditions vérifiées), les actions sont déclenchées par les transitions (notification, ticket créé, dashboard mis à jour). Un dashboard ops affiche la répartition par état, par âge, par owner. Les états Stalled, Suspended sont surveillés par un timer : pas d'activité depuis 14 jours → transition automatique vers Stalled, ticket d'investigation créé.

Cycle de vie partenaire EDI :

   [Prospect]               ─ contact commercial initié
       │
   discovery ok
       ▼
   [Scoped]                 ─ TPA en cours, périmètre défini
       │
   specs received
       ▼
   [SpecsReceived]          ─ Implementation Guide reçu
       │
   mapping drafted
       ▼
   [MappingDrafted]         ─ mappings v1 en revue interne
       │
   certs exchanged
       ▼
   [CertsExchanged]         ─ X.509 reçus et installés
       │
   gateway configured
       ▼
   [Configured]             ─ AS2/AS4 prêt à émettre/recevoir
       │
   tests passed
       ▼
   [Tested]                 ─ tests bilatéraux validés
       │
   pilot started
       ▼
   [PilotActive]            ─ 10% du volume cible
       │
   ramp ok
       ▼
   [ProductionActive]       ─ régime de croisière
       │
       │  (offboarding)
       ▼
   [Archived]               ─ flux clos, données conservées 10 ans

   États d'erreur :
   - [Stalled]              ← inactivité prolongée (à relancer)
   - [Offboarding]          ← arrêt programmé
   - [Suspended]            ← contestation contractuelle

Implémentation EDI

Cas concret : hub EDI multi-tenant avec 200 partenaires actifs et 30 en onboarding. Le partner master a un partner_state typé enum avec les états ci-dessus. À chaque action du playbook d'onboarding, l'état transitionne : réception spec → SpecsReceived, mappings drafted → MappingDrafted, etc. Le workflow engine (Camunda 8 ou Temporal) exécute les transitions, génère les tâches humaines (revue, validation), et déclenche les notifications. Le dashboard ops affiche en temps réel : « 30 prospects, 12 en SpecsReceived, 5 stallés depuis > 30 jours, 200 ProductionActive, 3 Suspended pour litige contractuel ». Le PSM (Partner Success Manager) voit son portfolio. Le directeur EDI voit le throughput d'onboarding (en moyenne 8 partenaires/mois passent du Prospect à ProductionActive). Outils : Camunda 8 BPMN, Temporal Workflow, Spring State Machine, Akka FSM.

Anti-patterns

• État partenaire dans un Excel : pas de contrainte transactionnelle, divergence garantie, audit impossible.
• État implicite dans plusieurs systèmes : Salesforce dit « Prospect », Jira dit « Active », le hub dit « Tested » — divergence sans détection.
• Transitions non gardées : un partenaire passe en ProductionActive sans test = incident garanti au premier flux.
• Pas de timers : les partenaires stallés ne sont jamais détectés, le pipeline s'engorge silencieusement.
• Trop d'états microscopiques : 40 sub-états d'onboarding ingérables et sans valeur métier.

Patterns liés

• State Machine (message EDI) — variante pour le cycle de vie d'un message individuel.
• Process Manager — pattern parent EIP, état explicite de processus longs.
• Process Engine — runtime BPMN/workflow qui exécute la state machine.
• Temporal Workflow — implémentation moderne en code.
• Step Functions — implémentation managée AWS.

Sources

• Hopcroft J.E., Ullman J.D. — Introduction to Automata Theory, Languages, and Computation, Addison-Wesley, 1979. Le fondement formel des machines à états.
• Harel D. — Statecharts: A Visual Formalism for Complex Systems, Science of Computer Programming, 1987. L'extension hiérarchique du modèle FSM, intégrée à UML.
• Camunda — BPMN State Machine. Documentation et best practices. docs.camunda.io — State Machine
• Spring State Machine. Implémentation Java légère. spring.io — Statemachine
• Hohpe G., Woolf B. — Enterprise Integration Patterns, Addison-Wesley 2003. Process Manager (§312) — pattern parent.
• UML State Machine spec (OMG). La spécification formelle UML, support visuel des state machines. omg.org — UML