Le nouveau socle OMS est prêt, mais 18 000 commandes restent ouvertes dans l’ancien. Certaines attendent une capture, d’autres un colis, un retour ou une décision support. Un simple export importe leur statut courant ; il perd les tentatives, les réservations et les promesses qui expliquent pourquoi chaque dossier se trouve là.
Le problème n’est pas de déplacer des lignes. Une commande ouverte est un processus vivant relié au PSP, aux vendeurs, au transport et aux clients. La copier sans ses événements et responsabilités peut déclencher une seconde capture, oublier un remboursement ou fermer un ticket encore nécessaire.
Le vrai enjeu d’une migration de commandes dans une marketplace opérateur est de maintenir la continuité métier pendant que deux socles coexistent. Contre-intuitivement, attendre qu’il ne reste presque plus de commandes ne supprime pas le risque : les dernières sont souvent les plus complexes.
Vous allez comprendre comment fermer la population, préserver identités, états, paiements, exécution, retours et support, puis organiser transformation et cutover. Le ledger reste la preuve ; les écritures sont idempotentes, tandis que réconciliation, canary et rollback protègent chaque commande jusqu’à sa clôture réelle.
Définir la continuité attendue
Lister les invariants métier
Une commande ne doit être ni perdue, ni doublée, ni financièrement altérée. Ses engagements, acteurs et prochaines actions restent compréhensibles. Chaque effet externe se produit au plus une fois et chaque mouvement financier se rapproche à une preuve.
Les invariants sont testables : somme des montants, unicité d’identité, état atteignable, réservations, expéditions et dossiers ouverts. « La page ressemble à l’ancienne » ne prouve pas la continuité.
Choisir la stratégie de coexistence
Lecture ancienne, écriture nouvelle, proxy, double lecture ou migration par cohorte possèdent des compromis. La stratégie indique quel système a autorité sur chaque commande et type d’action. Deux masters simultanés sont interdits.
Une table de routage associe identité et système owner avec version et date. Le support voit immédiatement où agir. Le basculement d’une cohorte est un événement auditable, pas une convention mémorisée par l’équipe.
Fermer la population
Définir ouverte par obligations
Payée mais non expédiée, livrée avec retour possible, remboursée partiellement, litigieuse ou en attente de payout peuvent toutes être ouvertes. La définition part des obligations restantes, pas seulement d’un statut technique.
Le snapshot de population cite date, requête, compteurs et montants. Les commandes créées après le cut-off suivent la nouvelle route. Les corrections tardives rejoignent une file explicite au lieu de modifier silencieusement l’extraction.
Segmenter par complexité et risque
Commandes simples, multi-vendeurs, paiements différés, expéditions partielles, retours et litiges forment des cohortes. Chaque cohorte possède mapping, tests et décision de migration. Le volume seul ne détermine pas l’ordre.
Les premières vagues combinent cas représentatifs et faible exposition. Les cas sans correspondance restent dans l’ancien système sous run contrôlé. Une couverture à 99 % ne justifie pas d’inventer le traitement du dernier pourcent.
La matrice de risque croise montant exposé, effets encore possibles, dépendances externes et délai de résolution. Une commande de faible valeur avec chargeback ouvert peut ainsi passer après une commande chère déjà livrée, mais avant un panier standard. Le manifeste conserve la justification de chaque inclusion, exclusion et ordre de vague ; opérations et finance peuvent challenger la population avant tout gel.
Stabiliser les identités
Conserver clés anciennes et nouvelles
Commande, ligne, vendeur, paiement, colis, retour et ticket reçoivent des identités nouvelles avec un registre de correspondance. La clé ancienne reste recherchable. Les systèmes externes peuvent continuer à envoyer leurs références pendant la transition.
Le mapping est injectif selon grain : deux anciennes commandes ne deviennent pas une seule nouvelle. Les collisions bloquent la cohorte. Les liens sont créés avant les objets dépendants et vérifiés après import.
Rendre les commandes idempotentes
Chaque écriture de migration possède clé basée sur source, objet et version. Rejouer un batch ne crée pas une seconde ligne ou un nouvel événement business. Les contraintes d’unicité protègent au-delà du code.
Scénario : le worker expire après avoir créé la commande mais avant l’accusé. Si le lot repart, alors il retrouve l’objet par clé et reprend les dépendances. Il ne déclenche ni email ni réservation une deuxième fois.
Mapper les états
Comparer les machines d’états
Les statuts ne sont pas traduits par libellé. L’équipe compare transitions, acteurs, gardes et effets. Un ancien « traité » peut regrouper accepté, expédié ou clos. Le mapping utilise événements et objets dépendants pour préciser.
Chaque état source reçoit état cible, prochaines actions et exceptions. Les combinaisons impossibles rejoignent une revue. La migration ne force pas une commande dans le statut le plus proche pour faire disparaître un rejet.
Reconstituer l’histoire utile
Lorsque les événements anciens existent, ils sont importés avec source et ordre. Sinon, un événement de migration crée le snapshot actuel et déclare la limite. Le système ne fabrique pas des dates intermédiaires.
La commande cible garde version de politique et promesses engagées. Les nouvelles transitions partent de ce snapshot. Le support sait distinguer un fait observé avant migration d’une action exécutée après.
Préserver paiements et fonds
Inventorier chaque mouvement financier
Autorisation, capture, remboursement, chargeback, commission, réserve et payout possèdent identifiant PSP et ledger. La migration importe la relation, pas seulement le total payé. Les montants se réconcilient par devise et vendeur.
Le nouveau socle n’appelle pas le PSP pour recréer un mouvement historique. Il enregistre sa preuve et son statut. Les actions futures utilisent les références existantes avec la méthode compatible.
Geler les effets pendant le passage
Une courte fenêtre peut suspendre capture, remboursement ou payout sur la cohorte. Les demandes entrantes sont mises en file avec clé idempotente. Après bascule, elles sont réévaluées dans l’ordre métier.
Si le total ledger diffère du PSP de plus d’un centime sur une commande, alors celle-ci sort du cutover. Finance analyse la cause. Le go de cohorte exige sommes et statuts réconciliés, pas seulement un taux de succès global.
Pour une commande multi-vendeurs, le contrôle descend au mouvement : capture client, commission, réserve, remboursement et payout attendu. Il compare identifiant PSP, devise, montant, bénéficiaire et disponibilité. Un rapport d’exception classe références absentes, montants divergents et mouvements orphelins ; chaque ligne possède owner, échéance et décision. La reprise n’est autorisée qu’après preuve ou compensation comptabilisée.
Préserver l’exécution logistique
Migrer expéditions et réservations
Entrepôt, seller, colis, unités, étiquette, transporteur, tracking et promesse sont liés aux lignes. Une expédition partielle conserve ce qui est envoyé et restant. Le stock déjà réservé n’est pas réservé une seconde fois.
Les identifiants transporteur restent actifs. Les webhooks entrants sont routés selon registre. Un événement reçu pendant la bascule rejoint une inbox et sera appliqué une fois à l’owner final.
Conserver les promesses acheteur
Date, fenêtre, service et adresse validée restent le contrat de la commande. Le nouveau moteur ne recalcule pas l’historique avec ses règles actuelles. Une modification future crée une renégociation visible.
Si l’ancienne promesse n’est pas représentable, alors une extension ou un champ legacy la conserve jusqu’à clôture. L’équipe ne dégrade pas silencieusement une commande pour simplifier le modèle cible.
Préserver retours et litiges
Migrer les dossiers encore actionnables
Demande, motif, preuves, échéances, autorisation, route et remboursement forment le dossier de retour. Un statut « ouvert » sans ces éléments oblige support à recommencer l’enquête. Les pièces restent accessibles selon rôle.
Les timers sont convertis avec leur date d’origine. Une migration ne redonne pas artificiellement un délai complet ni ne fait expirer un droit. Les alertes reprennent sur l’owner cible.
Conserver responsabilité et recours
Seller, opérateur, transporteur ou acheteur peuvent porter une action. Le dossier cible importe décision provisoire et arguments. Les contestations restent ouvertes. Un nouveau reviewer voit l’histoire et les limites de preuve.
Par exemple, si un retour attend une inspection seller sous 48 heures, alors la migration conserve l’échéance initiale. Si le SLA est déjà dépassé, la commande rejoint l’escalade immédiatement au lieu de repartir à zéro.
Préserver le contexte support
Relier tickets, messages et décisions
Le ticket conserve demandeur, commande, promesse, messages, pièces, motifs et prochaine action. Les canaux peuvent rester dans l’outil support, mais la nouvelle commande doit résoudre leurs identifiants. Les liens anciens redirigent.
Les notes internes sont distinguées des messages client. Les données sensibles gardent droits et rétention. Une migration n’élargit pas l’accès parce qu’un export plat a perdu ses rôles.
Donner une vue de coexistence
L’agent recherche par toute référence et voit système owner, état, risques et actions possibles. Les boutons qui écrivent dans le mauvais socle sont désactivés. Une bannière générique ne suffit pas à éviter une double action.
Les macros de réponse consomment les données de l’owner et citent la promesse historique. Le support peut expliquer la migration sans l’utiliser comme excuse. Le client reçoit une issue cohérente.
Transformer et vérifier les données
Construire un pipeline rejouable
Extraction, normalisation, mapping, validation et chargement sont séparés. Les fichiers sources sont immuables avec empreinte. Chaque objet cible cite run, source et version de transformation. Une correction crée un nouveau run.
Le pipeline reçoit snapshots et événements ; ses sorties sont objets, rejets et manifeste. Domaine commande possède les mappings, finance les contrôles et plateforme les dépendances. L’instrumentation journalise checkpoint, retry, durée et compteurs.
Comparer par invariants
Compte, montants, lignes, quantités, états, paiements, colis, retours et tickets sont réconciliés. Les totaux globaux ne détectent pas deux erreurs qui se compensent. Chaque commande produit un verdict et des écarts.
Un échantillon manuel couvre les cohortes à risque, tandis que les contrôles automatiques couvrent toute la population. Le manifeste cite accepté, rejeté et exclu. Zéro ligne ne disparaît entre ces catégories.
Le pipeline écrit d’abord dans une zone isolée, calcule les invariants, puis publie atomiquement la cohorte. Ses entrées portent snapshot, événements et registre d’identités ; ses sorties portent objets cibles, rejets et hash de contrôle. Le domaine valide les états, finance les mouvements et plateforme la publication. Métriques de débit, latence, retry, cardinalité et écarts rendent chaque run comparable au précédent.
Orchestrer le cutover
Préparer shadow et canary
La cible calcule sans écrire les effets externes et compare ses décisions à l’ancien système. Le canary migre une cohorte, puis route ses webhooks et actions. Les garde-fous portent finance, logistique et support.
La population, les critères de go et les responsables sont gelés avant la fenêtre. Les changements non essentiels sont suspendus. Un canal de décision unique évite des instructions contradictoires pendant l’incident.
Définir rollback et roll-forward
Le rollback restaure routage et droits d’écriture, puis réapplique les événements reçus depuis le cut-off à l’ancien owner. Il est testé. Si la cible a émis un effet externe irréversible, un mouvement compensatoire est prévu.
Le roll-forward corrige les objets sans revenir lorsque l’écart est local et maîtrisé. La matrice de décision utilise population, finance et délai. L’équipe ne choisit pas selon la seule préférence technique.
Le chronogramme nomme minute par minute le gel, le dernier delta, l’import, la réconciliation, le changement de routage et la décision. Chaque jalon possède un responsable principal et un suppléant. Si une dépendance dépasse son délai ou si un seuil financier tombe, alors le commandement prononce rollback sans attendre une discussion improvisée ; les demandes reçues restent dans l’inbox traçable.
Répéter et surveiller
Réaliser plusieurs répétitions
Chaque répétition utilise une copie récente, mesure durée, rejets et charge manuelle. Les corrections sont intégrées au pipeline, pas à un tableur parallèle. Le temps de fenêtre inclut réconciliation et décision.
Les scénarios provoquent webhook pendant gel, timeout PSP, colis partiel, retour tardif et rollback. Les équipes commandes, finance, logistique et support jouent leur runbook. Les contacts externes sont testés.
Surveiller après bascule
Le monitoring suit commandes sans owner, effets doubles, écarts de ledger, événements en attente, tickets et promesses. Chaque seuil possède owner et action. L’hypercare est bornée par critères, pas par une date arbitraire.
Si plus de 0,1 % des commandes présentent un état ou montant divergent, alors la vague suivante est suspendue. La cohorte courante est réconciliée. Deux jours sous seuil et zéro écart financier inexpliqué autorisent la reprise.
L’hypercare compare aussi les volumes d’actions au comportement historique : remboursements, changements d’adresse, webhooks rejetés, contacts support et expéditions sans scan. Un taux global stable peut cacher une cohorte dégradée ; les vues ventilent seller, moyen de paiement, transporteur et type de dossier. Chaque alerte ouvre le runbook correspondant, conserve la population touchée et mesure le délai réel de réparation.
Adapter la méthode et éviter les erreurs
Pour qui la migration ouverte convient
Elle devient nécessaire lorsque l’ancien système doit s’éteindre avant la clôture naturelle de toutes les commandes. Une plateforme peut éviter le transfert pour les cohortes très courtes, mais doit alors gouverner la coexistence jusqu’au bout.
Commandes possède les états ; finance les mouvements ; logistique les expéditions ; support les dossiers ; plateforme routage et pipeline. Chaque cohorte a un owner business et technique.
Erreurs fréquentes dans la migration des commandes
Copier le statut, recréer les paiements, oublier les webhooks, remettre les délais à zéro, migrer sans registre de routage et vérifier seulement les totaux sont les erreurs majeures. Elles produisent des effets après un go apparemment vert.
Une autre erreur consiste à traiter les derniers dossiers comme négligeables. Ils concentrent souvent litiges et retours. Enfin, un double write non maîtrisé crée deux autorités : une file d’événements avec owner unique est préférable.
Plan d’action pour migrer les commandes ouvertes
Semaines 1 à 4 : invariants et pipeline
La première semaine définit ouverte, inventorie obligations et segmente les cohortes. La deuxième ferme identités, routage et mappings d’états. Finance rapproche paiements ; support et logistique décrivent dossiers et effets.
Les semaines trois et quatre construisent extraction immuable, transformation et manifeste. Les tests couvrent statut ambigu, paiement partiel, colis, retour, ticket, webhook concurrent et rejeu. Chaque commande reçoit un verdict.
Une revue formelle confronte ensuite dix dossiers par cohorte entre ancienne interface, objets cibles et preuves externes. Chaque différence est qualifiée comme attendue, corrigée ou bloquante. Le procès-verbal fixe les propriétaires, les seuils de sortie et les données nécessaires au rollback ; aucune exception verbale ne rejoint la fenêtre de production.
Semaines 5 à 8 : répétitions et cutover
La cinquième semaine exécute une répétition complète. La sixième ouvre shadow et canary. L’instrumentation suit owners, ledgers, événements, promesses et tickets avec seuils, dépendances et runbooks.
Les semaines sept et huit migrent les cohortes après répétition du rollback. Le go exige sommes au centime, zéro objet perdu, effets idempotents et support capable de retrouver toute référence sous le délai approuvé. La salle de contrôle affiche aussi les files externes, les horodatages du dernier delta et la progression par obligation. À chaque jalon, le responsable lit les écarts encore ouverts ; le décideur signe poursuite, suspension ou retour avec l’heure et la population exacte.
Le dossier final conserve population, mappings, manifests, décisions, dashboards et procédures. Toute exception possède owner et voie de clôture. L’ancien socle ne s’éteint qu’après preuve que chaque obligation restante est reprise ou terminée.
Après la dernière vague, un inventaire inverse recherche encore les identifiants anciens dans PSP, transporteurs, support et exports financiers. Toute référence active doit résoudre une commande cible ou une exception gouvernée. L’arrêt des workers historiques se fait composant par composant, avec surveillance des files et possibilité de réactivation bornée, avant l’archivage en lecture seule.
- À faire d’abord : fermer population, invariants et système owner par commande.
- À tester ensuite : paiement, webhook, retour, support et rollback.
- À différer : les cohortes sans mapping prouvé.
- À refuser : toute migration qui recrée un effet externe historique.
Ressources complémentaires pour l’opérateur
Outiller commandes et contexte
Les écrans du back-office opérateur rendent routage et dossiers consultables.
Le catalogue PIM marketplace stabilise les identités produit consommées.
Borner la première cohorte
Le MVP marketplace avant ouverture aide à limiter les dépendances cibles.
La méthode pour ouvrir une première catégorie fournit une cohorte pilote.
Conclusion : migrer un processus vivant
Une commande ouverte est un ensemble d’obligations, d’événements et de preuves, pas une ligne portant un statut.
Identités, ledger et routage unique empêchent double effet et perte de responsabilité pendant la coexistence.
Répétitions, manifests et rollback testés rendent le cutover mesurable jusqu’à la dernière commande complexe encore actionnable.
Pour construire cette migration, Dawap peut vous accompagner dans votre marketplace opérateur.
