Une validation vendeur commence par trois conditions dans un service. Six mois plus tard, elle attend un document, relance la conformité, expire après dix jours, suspend une offre, ouvre une tâche support et reprend lorsque le prestataire KYC répond. Chaque ajout paraît local, mais personne ne sait plus quel chemin est actif.
Le problème inverse existe aussi : une équipe installe un workflow engine pour quatre transitions synchrones. Le code métier se disperse alors entre diagrammes, workers, variables de processus et adaptateurs. Le moteur est visible, mais la décision devient plus difficile à tester et à modifier.
Contre-intuitivement, le meilleur choix n’est ni « tout en code » ni « tout dans le moteur ». La vraie question porte sur la nature de la coordination : durée, frontières système, décisions humaines, reprises, versions en cours et besoin d’exploitation.
La méthode permet de décider dans le cadre d’un back-office opérateur marketplace relié à notre expertise en création de marketplace. Elle protège une règle essentielle : l’orchestrateur coordonne le travail, tandis que le domaine reste propriétaire de la vérité métier.
Dans quels cas le code métier atteint ses limites d’orchestration
Le code applicatif convient lorsque la décision est courte, locale et atomique. Il commence à souffrir quand le processus survit à une requête, traverse plusieurs équipes ou doit expliquer une attente de plusieurs jours.
Repérer la coordination cachée
Les cron jobs relancent des dossiers, les statuts techniques servent de rappels et le support corrige directement la base. Un signal faible apparaît lorsque l’ordre des étapes n’existe que dans la tête de deux développeurs.
Un second signal apparaît quand chaque nouvelle règle ajoute un scheduler, une colonne et un script de reprise. Au départ le coût reste invisible ; après quelques sprints, personne ne sait plus quel chemin constitue le fonctionnement nominal.
Refuser l’outil quand le problème reste local
Une commande qui valide un invariant puis persiste un nouvel état ne devient pas meilleure parce qu’elle traverse un moteur. Le domaine et sa transaction suffisent lorsque l’exécution est brève, déterministe et facile à rejouer.
Cas concret : publier une offre après contrôle de prix et stock peut rester un service métier. En revanche, qualifier un vendeur avec documents, revue humaine, échéances et prestataire externe crée une orchestration durable.
Séparer l’état métier de l’orchestration du processus
Une machine à états répond à « quelle transition cet objet peut-il accepter ? ». Un orchestrateur répond à « quelle étape doit être tentée ensuite, avec quelle attente et quelle reprise ? ». Les deux notions se croisent sans se remplacer.
Laisser les invariants dans le domaine
La commande décide si un remboursement est autorisé ; le moteur ne fait que demander cette opération au bon moment. Le vendeur décide si son dossier peut devenir actif ; le processus organise collecte, contrôle et notification.
Les montants, droits, versions et transitions légales restent vérifiés par les services métier. Une variable BPMN ou un contexte de workflow ne devient jamais la source de vérité par commodité.
Donner à l’orchestration ses propres responsabilités
Le moteur porte ordre, parallélisme, temporisation, retry, corrélation, tâche humaine et compensation. Il expose pourquoi une instance attend et quelle action peut la débloquer sans inventer la décision métier.
Cette frontière évite qu’un diagramme modifiable change silencieusement une règle financière. Chaque activité appelle un contrat versionné dont le résultat est accepté ou refusé par le domaine.
Évaluer la durée du processus et le nombre de frontières traversées
La durée seule ne suffit pas. Un traitement long mais calculatoire peut rester un job ; un processus court qui attend trois systèmes et une personne peut justifier une orchestration durable.
Compter les points d’attente persistants
Un point d’attente survit au redémarrage : webhook KYC, confirmation PSP, document vendeur, validation finance ou délai de rétractation. Chacun exige identité de corrélation, échéance et comportement en cas d’absence.
Lorsque ces attentes se multiplient, le code construit implicitement un moteur avec tables de statut, schedulers et reprises. Un produit dédié peut alors réduire la plomberie, à condition que son modèle corresponde aux besoins.
Mesurer l’entropie des frontières
ERP, PSP, KYC, transporteur et outil support ne partagent ni disponibilité ni sémantique. Chaque frontière ajoute doublon, retard, ordre différent et réponse incertaine.
Une grille compte systèmes, événements asynchrones, délais, branches parallèles et owners. Au-delà de deux attentes durables et trois frontières, un pilote d’orchestration devient généralement plus utile qu’une nouvelle couche de conditions.
Modéliser les décisions humaines sans les réduire à un statut
Les opérations marketplace comprennent revue documentaire, modération, contrôle fraude, arbitrage litige et validation de paiement. Une tâche humaine possède plus qu’un état « à faire ».
Définir assignation, preuve et échéance
La tâche indique compétence requise, pool, priorité, date cible, données visibles et résultat attendu. Prise en charge, délégation, escalade et expiration sont des événements, pas des mises à jour libres.
Le back-office montre le motif de la demande et les conséquences de chaque choix. Il interdit une validation si le dossier a changé depuis son ouverture ou si le décideur ne possède plus l’autorité requise.
Garder l’humain hors du langage technique
Une personne valide un risque vendeur, pas un token ou une transition 42. Le moteur traduit le résultat métier vers la suite du processus, avec motif structuré et commentaire proportionné.
Si une étape exige une correction manuelle de variable, le modèle n’est pas exploitable. Les opérations doivent disposer d’actions bornées : demander une pièce, refuser, approuver, réassigner ou escalader.
Gérer attentes, timers et événements externes sans polling opaque
Une orchestration durable doit dormir sans occuper un worker, puis reprendre sur un événement corrélé. Le polling permanent crée charge, latence et doublons sans clarifier l’état.
Corréler l’événement à la bonne instance
Chaque attente possède identifiant métier, type d’événement, version attendue et fenêtre d’acceptation. Un webhook tardif enrichit l’historique mais ne réveille pas automatiquement une instance déjà compensée.
Déduplication et ordre sont testés aux frontières. Le moteur peut mémoriser l’attente ; le service métier décide si le fait reçu reste valable pour l’objet courant.
Traiter le temps comme un événement
Relance à J+2, expiration à J+10 et escalade quatre heures avant un cut-off deviennent des timers nommés. Chacun possède fuseau, calendrier, règle de replanification et action en retard.
Un changement de délai ne doit pas réécrire silencieusement les instances existantes. La politique précise si elles gardent l’ancienne échéance, migrent ou passent par une décision opérateur.
Traiter échec, retry, reprise et compensation comme quatre décisions
Relancer une activité n’annule pas ses effets précédents. Un appel PSP, une notification vendeur ou une réservation de stock peut avoir réussi malgré un timeout local.
Définir la sémantique de chaque activité
L’activité décrit idempotence, timeout, retry, backoff, preuve d’effet et erreur terminale. Une lecture peut être retentée ; une écriture incertaine demande d’abord une vérification avant tout nouvel envoi.
Le moteur stocke tentative et résultat technique. Le domaine conserve la conséquence opposable : paiement capturé, stock réservé, vendeur suspendu ou remboursement accepté.
Compenser sans prétendre remonter le temps
Annuler une réservation ajoute une libération ; rembourser ajoute un mouvement financier. L’historique initial reste présent afin d’expliquer la chronologie et de rapprocher les systèmes.
La compensation possède owner, conditions, limite et preuve finale. Si elle échoue, l’instance passe en incident exploitable plutôt que dans une boucle de retry infinie.
Rendre le processus visible sans exposer toute la plomberie
La visibilité est un avantage majeur d’un moteur, mais un diagramme coloré n’est pas encore un outil de run. L’écran doit répondre à une question opérationnelle.
Construire une chronologie métier
Le support recherche par vendeur, commande, paiement ou litige. Il voit étape courante, attente, échéance, tentatives, décision humaine et conséquences confirmées, avec des libellés compréhensibles.
Les identifiants techniques restent disponibles pour le diagnostic, mais ne remplacent pas le motif. « Worker failed » devient « vérification KYC indisponible, prochaine tentative à 14 h 20 ».
Borner les actions de reprise
Retry, saut, annulation, réassignation et compensation ont des préconditions et des droits distincts. Une reprise manuelle crée un événement auditable et rejoue les mêmes invariants que le chemin automatique.
Le tableau de bord distingue attente normale, incident, SLA menacé et dette de traitement. Il évite de classer chaque instance longue comme panne ou chaque succès technique comme résultat métier.
Comparer les modèles de test avant de choisir la technologie
Le workflow le plus lisible en démonstration peut devenir pénible à valider. La testabilité porte sur règles, parcours, temps, erreurs et compatibilité des versions.
Tester le domaine indépendamment
Les invariants restent des tests unitaires rapides : montant, autorisation, transition et calcul. Ils ne démarrent pas un cluster d’orchestration et n’utilisent pas le diagramme comme oracle.
Les activités sont testées sur leurs contrats, y compris idempotence et erreurs. L’orchestrateur utilise des doubles contrôlés pour parcourir branche nominale, refus, timeout et compensation.
Accélérer le temps et injecter les événements
Un test doit avancer de dix jours sans attendre dix jours, livrer un webhook avant ou après le timer et vérifier l’état final. Le moteur choisi doit fournir une horloge contrôlable et un historique déterministe.
La suite rejoue des instances anciennes contre une nouvelle version lorsque la plateforme le permet. Une migration qui ne peut être éprouvée sur l’historique reste un risque de production.
Faire évoluer les définitions avec des instances encore en cours
Un onboarding vendeur peut durer plusieurs semaines. Une nouvelle release arrive donc pendant que des milliers d’instances exécutent une définition antérieure.
Choisir une stratégie de compatibilité
Les instances peuvent terminer sur leur version, migrer à un point sûr ou suivre une nouvelle branche compatible. La décision dépend des données disponibles, du risque et de la durée résiduelle.
Chaque définition porte version et date. Les activités restent compatibles assez longtemps pour servir les anciennes instances ; leur retrait exige une preuve d’usage nul.
Éviter la migration magique
Ajouter une étape obligatoire au milieu d’une instance déjà passée crée une ambiguïté. La migration calcule position, données manquantes et effets déjà produits, puis choisit continuer, compléter ou compenser.
Un lot pilote migre quelques instances représentatives avec dry-run, rapport et rollback. Les cas impossibles restent sur l’ancienne version ou passent dans une file de décision humaine.
Calculer le coût complet du workflow engine
La licence n’est qu’une ligne. Le coût comprend exploitation, montée en compétence, stockage d’historique, observabilité, migration, disponibilité et dépendance au modèle de l’éditeur.
Mesurer ce que le moteur remplace vraiment
Timers durables, retries, tâches humaines, journal, console et corrélation ont une valeur lorsqu’ils suppriment du code et du toil existants. Ils coûtent cher s’ils dupliquent des capacités déjà fiables.
Le business case compare construction interne, coût de plateforme, incidents évités, temps support, délai de modification et charge d’astreinte. Une promesse de low-code sans ces données reste décorative.
Inclure le coût de sortie
Définitions, historiques, variables, tâches et incidents doivent pouvoir être exportés sous une forme intelligible. Les activités métier restent derrière des contrats indépendants de l’outil.
Un pilote documente comment reprendre une instance ailleurs ou la terminer sans moteur. Cette réversibilité réduit le verrouillage et améliore aussi les plans de continuité.
Gouverner droits, données et responsabilités du moteur
L’orchestrateur voit des processus transverses et peut déclencher des actions sensibles. Son back-office ne doit pas devenir un accès administrateur universel à la marketplace.
Appliquer le moindre privilège par activité
Chaque worker possède une identité, des scopes et un tenant explicite. Il reçoit seulement les données nécessaires à l’activité et n’utilise pas un secret partagé par tous les processus.
Les variables sensibles sont minimisées, chiffrées ou référencées. Droits d’affichage, action manuelle et export d’historique suivent des politiques séparées avec journal d’accès.
Attribuer définition, activité et run
Le process owner approuve le parcours ; chaque domaine possède ses activités ; la plateforme garantit disponibilité et outillage ; les opérations traitent les incidents selon un runbook commun.
Une modification de diagramme passe revue, test et déploiement comme du code. Le modeler ne contourne ni séparation des tâches ni politique de release.
Construire une architecture hybride au lieu d’opposer deux camps
Le choix se fait par type de coordination. Une marketplace peut combiner services métier, machine à états locale, file de messages et orchestration durable sans créer quatre vérités concurrentes.
Utiliser chaque mécanisme à sa bonne échelle
Le code porte calculs et invariants. La machine à états protège le cycle d’un agrégat. La messagerie transporte les faits. Le workflow engine coordonne attentes longues, acteurs et compensations.
L’architecture de machine à états marketplace approfondit les transitions d’un objet. L’orchestration décrite ici commence lorsque plusieurs objets, systèmes ou personnes doivent avancer ensemble.
Définir une enveloppe de processus
L’instance garde processId, businessKey, version, état de coordination et références. Elle ne copie pas tout le vendeur ou la commande dans ses variables.
Les activités lisent la vérité depuis le domaine, envoient une commande idempotente et enregistrent le résultat. Le moteur peut être reconstruit ou remplacé sans devenir le référentiel commercial.
Matrice de décision : code, machine à états ou workflow engine
La décision doit être comparable et contestable. Une matrice courte vaut mieux qu’une préférence d’architecture transformée en standard universel.
Noter la coordination réelle
Chaque candidat reçoit durée, frontières, tâches humaines, timers, parallélisme, compensations, versions en cours, visibilité support, débit et sensibilité des données.
Les critères sont pondérés selon le processus. Une validation vendeur privilégie humains et délais ; un flux de calcul de commission privilégie débit, déterminisme et audit financier.
Appliquer une règle de décision explicite
Si le processus est local, synchrone et sans attente durable, alors le code reste prioritaire. S’il protège surtout le cycle d’un objet, une machine à états suffit. S’il coordonne plusieurs frontières pendant des heures ou jours, le moteur devient candidat.
Si aucun choix ne gagne clairement, le pilote porte uniquement l’enveloppe de coordination la plus risquée. Le domaine reste inchangé et fournit le point de comparaison.
| Besoin dominant | Choix initial | Signal de réévaluation |
|---|---|---|
| Décision locale et atomique | Code métier | Attentes persistantes dispersées |
| Cycle d’un agrégat | Machine à états | Coordination multi-objets |
| Humains, timers et compensations | Workflow engine | Coût plateforme supérieur au toil retiré |
| Contraintes mixtes | Architecture hybride | Responsabilités ou vérités dupliquées |
Piloter l’orchestration sans réécrire toute la marketplace
Le pilote choisit un processus douloureux mais borné, avec historique disponible et résultat observable. Il ne commence ni par le checkout critique ni par un parcours trop simple pour démontrer la valeur.
Encapsuler un parcours existant
L’onboarding vendeur ou le traitement d’un litige convient si ses activités disposent déjà d’API. Le moteur coordonne une cohorte tandis que le chemin actuel reste disponible pour comparaison et rollback.
Les entrées, sorties, responsabilités, dépendances, seuils et monitoring sont écrits avant la première instance. Le pilote mesure délai, reprises, tickets, changements manuels et temps de diagnostic.
Chaque activité nomme son owner, son contrat d’entrée, sa sortie, sa politique de retry et son repli. Le runbook relie ensuite incident, dépendance, rollback et preuve métier afin qu’une reprise reste exécutable sans correction directe des variables.
Fixer les critères d’arrêt et d’extension
Une amélioration visuelle sans baisse du toil ne suffit pas. L’extension exige parcours expliqués, timers fiables, erreurs reprises sans SQL, tests reproductibles et coût d’exploitation accepté.
Si le moteur complexifie les changements ordinaires, le pilote revient au code ou réduit son périmètre. Cette sortie prévue protège l’équipe contre un engagement technologique fondé sur la démonstration seule.
Plan d’action : décider et livrer l’orchestration en six semaines
La démarche part d’un processus réel et compare les options sur les mêmes scénarios. Elle ne choisit aucune plateforme avant d’avoir posé les frontières et les preuves attendues.
Semaines 1 et 2 : parcours et critères
La première semaine reconstruit nominal, exceptions, tâches, timers, compensations et actions support. Chaque étape reçoit décision métier, système propriétaire et preuve de sortie.
La deuxième semaine mesure durée, frontières, volumes, incidents, toil et coût actuel. La matrice compare code, machine à états et moteur sur des critères pondérés.
Semaines 3 et 4 : contrats et prototype
La troisième semaine définit enveloppe, activités idempotentes, corrélation, données, droits et versionnement. Les services métier restent indépendants de la technologie candidate.
La quatrième semaine implémente nominal, refus, timeout, événement tardif et compensation. L’horloge est accélérée et les erreurs sont injectées volontairement.
Semaines 5 et 6 : exploitation et décision
La cinquième semaine ouvre une cohorte avec console support, alertes, runbook, rollback et métriques. Les opérations traitent un incident simulé sans intervention développeur.
La sixième semaine compare résultats, coût, testabilité et réversibilité au chemin actuel. La décision étend, réduit ou abandonne le moteur avec les preuves du pilote.
- Cartographier les attentes et décisions avant de dessiner le diagramme.
- Maintenir invariants et données opposables dans les domaines propriétaires.
- Tester temps, doublons, retards et compensations avant le scénario heureux.
- Donner au support une chronologie et des reprises bornées.
- Versionner les définitions avec une stratégie pour les instances en cours.
- Étendre seulement si le moteur retire plus de toil qu’il n’ajoute de plateforme.
Standards officiels et modèles marketplace complémentaires
Les documentations des moteurs décrivent leurs capacités. La décision d’architecture doit les confronter au processus, au domaine et aux conditions réelles d’exploitation.
Workflow, machine à états et tâches humaines
La documentation officielle du composant Workflow de Symfony distingue places, transitions, guards, événements et audit trail. Sa présentation des workflows et machines à états clarifie les modèles de marquage.
La documentation Camunda sur l’orchestration de tâches humaines illustre assignation et traitement, tandis que son API d’orchestration expose opérations de tâches et résolution d’incidents.
Architecture et exploitation marketplace
Les tests d’architecture marketplace protègent les frontières que l’orchestrateur ne doit pas contourner. La machine à états explicable au support protège les transitions internes à chaque objet.
Ensemble, ces modèles séparent trois questions : qui possède la décision, quel état l’objet peut accepter et comment plusieurs acteurs avancent jusqu’à un résultat commun.
- Choisir selon le processus réel, pas selon la seule qualité du modeler.
- Garder la vérité métier hors des variables de coordination.
- Inclure testabilité, migration, run et sortie dans le coût complet.
Conclusion : orchestrer sans déplacer la complexité métier
Le code métier reste le meilleur outil pour une décision locale et atomique. La machine à états rend explicite le cycle d’un objet. Le workflow engine prend sa valeur lorsque la coordination traverse temps, systèmes et personnes.
La frontière est décisive : le domaine autorise et produit les conséquences ; le moteur ordonne, attend, reprend et explique. Cette séparation protège les tests comme la réversibilité.
Une matrice puis un pilote révèlent le coût réel, la visibilité obtenue et le toil retiré. L’équipe peut adopter une architecture hybride sans transformer un diagramme en nouvelle base métier.
Pour cadrer le processus, construire le back-office et choisir une orchestration exploitable, notre accompagnement en création et évolution de marketplace opérateur relie métier, architecture et run.
