Faire cohabiter un legacy et de nouveaux flux vendeurs n’est pas seulement un sujet technique. Pendant quelques semaines ou quelques mois, deux systèmes peuvent lire, transformer ou pousser des données qui impactent les offres, les stocks, les commandes, les statuts et la marge marketplace.
Le risque principal est de créer deux vérités : un stock dans l’ancien système, un autre dans le nouveau ; une commande préparée côté legacy, mais encore ouverte côté OMS ; un prix corrigé dans un flux, mais pas dans l’autre.
La cohabitation doit donc être pilotée comme une phase de transition avec règles, contrôles, responsables et date de sortie. Sinon elle devient une architecture permanente par accident.
Notre accompagnement Agence marketplace aide à cadrer cette période sans laisser les équipes vendeur gérer la migration au cas par cas, puis à choisir les connecteurs et les règles de bascule au service d’une vérité métier explicite.
Diagnostiquer la cohabitation legacy par flux
Le diagnostic commence par lister les flux concernés : catalogue, prix, stock, offres, commandes, statuts, transport, retours, facturation et reporting. Pour chacun, il faut nommer l’ancien système, le nouveau système et la source qui fait foi.
La question centrale est simple : qui a le droit d’écrire la donnée ? Si deux systèmes peuvent modifier le même champ, l’équipe doit savoir lequel gagne et comment l’écart est résolu.
Définir les sources de vérité
La source de vérité peut varier selon le flux. Le legacy peut rester maître des coûts et de la comptabilité, tandis que le nouveau flux devient maître des commandes ou du stock diffusé.
Chaque choix doit être explicite. "On verra selon le cas" crée des reprises manuelles, des conflits de données et des décisions impossibles à auditer.
La source de vérité doit aussi être connue du support, car c’est souvent lui qui subit les incohérences face au client.
Cartographier les doublons
Un doublon n’est pas toujours mauvais. Pendant une phase de test, il peut permettre de comparer les résultats avant bascule.
Il devient dangereux quand il n’a plus de propriétaire, plus de règle de comparaison ou plus de date de fin.
Le vendeur doit identifier les doublons tolérés, les doublons interdits et les doublons à surveiller chaque jour.
Pour qui et dans quel cas le double run protège une migration vendeur
La cohabitation est normale lors d’une migration ERP, PIM, OMS, connecteur marketplace, prestataire logistique ou outil de pilotage vendeur. Elle devient risquée quand elle concerne des flux qui touchent directement la promesse client.
Le vendeur doit donc accepter la cohabitation pour apprendre et sécuriser, mais refuser qu’elle devienne un mode de fonctionnement durable sans gouvernance.
Migration progressive
Une migration progressive permet de tester un canal, une famille produit, un entrepôt ou un type de commande avant généralisation. C’est souvent plus sûr qu’une bascule complète trop rapide.
Mais cette prudence doit être organisée : périmètre pilote, critères de succès, seuils d’arrêt, procédure de retour et date de revue.
Sans ces éléments, le pilote devient un flux parallèle qui ajoute de la charge sans réduire la dette.
Run vendeur déjà sous tension
Si les équipes corrigent déjà beaucoup de stocks, commandes ou statuts à la main, la cohabitation doit être plus stricte. Ajouter un nouveau flux sur un run fragile peut amplifier les écarts.
Il faut alors prioriser les flux qui retirent une douleur visible : moins de survente, moins de commandes bloquées, moins d’offres rejetées ou une marge plus lisible.
La centralisation des commandes marketplace devient utile lorsque la cohabitation touche directement le traitement des commandes.
Repérer les conflits de données et de responsabilité
Les signaux à suivre sont les écarts entre ancien et nouveau système : stock différent, prix différent, commande absente, statut incohérent, offre publiée dans un canal mais refusée dans l’autre, retour non rapproché.
Le vendeur doit aussi regarder le temps passé à réconcilier. Une cohabitation qui demande trop de rapprochements manuels cache souvent une règle de bascule insuffisante.
Écarts de données
Les écarts doivent être classés par gravité. Un écart de libellé produit peut attendre. Un écart de stock disponible, de prix publié ou de statut expédition doit être traité plus vite.
Chaque écart doit avoir une règle : source prioritaire, correction autorisée, personne responsable et délai maximum.
Le suivi doit porter sur les références et commandes à impact, pas seulement sur le volume brut d’anomalies.
Écarts de responsabilité
La cohabitation crée parfois une zone floue entre métier, SI, intégrateur, 3PL et support. Si personne ne sait qui corrige, la donnée reste fausse plus longtemps.
Un tableau de responsabilités doit couvrir les flux critiques : qui détecte, qui corrige, qui valide, qui informe et qui clôture.
Cette gouvernance est plus importante qu’une documentation exhaustive. Les équipes doivent savoir quoi faire pendant le run.
Arbitrer les droits d’écriture objet par objet
Une règle générale du type « le nouveau système devient maître » est trop vague pour protéger le run. Le droit d’écriture doit être posé pour chaque objet, chaque état et chaque fenêtre de transition. Un ERP peut rester maître du stock comptable tandis que l’OMS décide du stock promettable ; le point essentiel est de documenter la conversion entre les deux.
Cette matrice sert à décider, pas seulement à décrire. Elle précise l’entrée autorisée, la sortie attendue, le propriétaire de la règle, le contrôle de cohérence et l’action à prendre si deux versions arrivent dans le mauvais ordre. Elle doit être relue avec le support, car une règle techniquement juste mais impossible à expliquer produit encore une dette opérationnelle.
Offre, prix et stock : protéger la promesse publiée
Pour l’offre, le nouveau flux peut calculer la disponibilité sans obtenir immédiatement le droit de modifier la quantité de référence dans le legacy. Pendant le pilote, il publie sur un canal limité et compare chaque variation à la réserve ERP. Si l’écart dépasse 1 % des références actives, la diffusion s’arrête et la source reste inchangée jusqu’au diagnostic.
Le prix demande une règle encore plus stricte. Une promotion validée dans le nouveau moteur ne doit jamais être écrasée par un batch ancien arrivé dix minutes plus tard. L’équipe conserve donc la version de tarif, la date d’effet, le canal et la borne de marge dans le même journal, puis refuse toute écriture dont la version est antérieure.
Contre-intuitivement, laisser le legacy en lecture seule plus tôt peut être plus sûr que maintenir une écriture de secours. Une voie de repli non testée devient vite une deuxième production : les équipes l’utilisent sous pression, sans savoir quelles transformations elle réintroduit ni comment annuler ses effets.
Commande et statut : une seule chronologie client
Une commande ne peut pas être « nouvelle » dans un système et « expédiée » dans l’autre sans règle de rapprochement. Le contrat de transition définit l’identifiant partagé, l’ordre autorisé des statuts et les événements qui peuvent encore être émis par le legacy. Tout événement hors séquence passe en quarantaine au lieu de réécrire l’histoire client.
Le scénario de test doit couvrir une commande reçue deux fois, un accusé de marketplace en retard et une expédition créée pendant un timeout OMS. Pour chaque cas, le runbook précise quel système garde la main, quel message est ignoré et quelle preuve autorise un replay. Sans ce protocole, l’idempotence reste une promesse technique non vérifiable par les opérations.
Le support doit pouvoir retrouver cette chronologie depuis le numéro de commande, sans demander trois exports. Si le temps de qualification dépasse quinze minutes sur le lot pilote, la bascule reste incomplète : le nouveau flux transporte peut-être correctement les données, mais il ne rend pas encore la décision suffisamment exploitable.
Retour, remboursement et finance : ne pas solder trop tôt
Les retours et remboursements exposent la limite des bascules centrées sur la commande. Un dossier peut naître dans le nouveau parcours alors que la facture, l’avoir ou le settlement restent produits par le legacy. Il faut alors fixer la référence de rapprochement et interdire qu’un remboursement soit confirmé avant d’avoir retrouvé la pièce financière attendue.
La finance conserve un journal des montants attendus, reçus et compensés. Un écart inférieur à un seuil documenté peut attendre la clôture suivante ; un écart qui touche la TVA, la marge ou plusieurs commandes déclenche une escalade immédiate. Ce tri évite de bloquer toute la migration pour des centimes tout en protégeant les erreurs réellement coûteuses.
La règle de sortie est concrète : aucun dossier du pilote ne doit nécessiter une double saisie après deux cycles complets de settlement. Si une correction reste manuelle, elle reçoit un propriétaire, une date d’extinction et une preuve de non-régression avant l’élargissement du périmètre.
- À faire : nommer un seul système autorisé à écrire chaque état critique et tracer toutes les exceptions.
- À différer : conserver temporairement en lecture les fonctions legacy encore utiles au contrôle mais sans pouvoir de modification.
- À refuser : maintenir une écriture de secours sans seuil, sans journal et sans procédure de rollback testée.
Concevoir le double run comme une expérience réversible
Le double run n’est pas une architecture cible. C’est une expérience bornée qui doit répondre à trois questions : le nouveau flux produit-il le bon résultat, le résultat reste-t-il explicable, et l’équipe sait-elle revenir à l’état précédent sans perdre une commande ou republier une offre fausse ? Tant que l’une de ces réponses manque, la migration n’est pas prête à gagner du périmètre.
Commencer en mode miroir avant d’ouvrir l’écriture
En mode miroir, le nouveau flux reçoit les mêmes entrées et calcule les mêmes sorties, mais ne publie pas encore de décision client. L’équipe compare stock, prix, statut et transformation sur un échantillon représentatif. Cette étape révèle les écarts de contrat sans créer immédiatement de correction sur les canaux.
Le payload d’entrée, la version de mapping et le résultat attendu sont stockés ensemble. La comparaison ne porte pas seulement sur l’égalité brute : elle distingue un arrondi toléré, une donnée enrichie et une divergence qui change la promesse. Une variation acceptable doit être expliquée à l’avance, sinon elle sera interprétée différemment selon l’équipe.
Le passage en écriture limitée intervient seulement quand les écarts critiques sont nuls sur deux cycles complets et que les écarts mineurs ont tous une cause. Le canal pilote, la famille produit et la fenêtre d’activation sont alors explicitement bornés pour que le rollback ne touche pas le reste du portefeuille.
Fixer des seuils qui commandent une action
Un seuil utile doit modifier la décision. Si plus de 0,5 % des commandes du pilote perdent un statut ou si le rapprochement stock dépasse trente minutes, alors le nouveau flux repasse en lecture seule. Si l’écart concerne uniquement un enrichissement non bloquant, il reste en quarantaine avec une date de revue et n’empêche pas la poursuite du test.
Les seuils doivent aussi protéger la capacité humaine. Au-delà de vingt corrections manuelles par jour sur le même motif, l’équipe suspend l’extension, même si le taux global semble faible. Ce volume indique que la règle n’est pas industrialisée et que le support subventionne encore le fonctionnement du nouveau dispositif.
Le comité de bascule lit donc quatre preuves : taux d’écart critique, délai de qualification, nombre de reprises manuelles et capacité à expliquer la version active. Ces mesures évitent un go/no-go fondé sur une impression générale ou sur un taux de succès technique qui masque les exceptions les plus coûteuses.
Préparer le rollback avant le premier go
Le rollback décrit précisément ce qui est arrêté, ce qui continue à être lu et quel système reprend le droit d’écriture. Il ne consiste pas à réactiver tous les anciens jobs. Chaque batch, webhook ou queue legacy doit être identifié avec son dernier curseur traité afin d’éviter un rattrapage qui rejoue des événements déjà consommés.
La mise en œuvre exige un drapeau d’activation par flux, une journalisation des changements, un export des objets en transit et une procédure de réconciliation après retour. Le test inclut un timeout, un message dupliqué et une coupure pendant une commande réelle de sandbox. Le runbook indique les commandes, les contrôles et l’owner de chaque étape.
Le bon rollback restaure une capacité minimale en quelques minutes tout en conservant les preuves nécessaires pour reprendre le diagnostic. S’il dépend d’une personne qui connaît encore un script non documenté, il ne protège pas la migration ; il reporte simplement le risque sur le moment où l’équipe sera déjà sous pression.
Superviser la transition sans créer une troisième vérité
Un dashboard de migration peut lui aussi devenir une source concurrente s’il recalcule des statuts sans conserver leur origine. La supervision doit présenter les écarts entre systèmes, pas inventer une synthèse impossible à auditer. Chaque ligne renvoie donc vers l’objet source, la version de flux et la décision de correction.
Corréler endpoint, queue et preuve métier
Le même identifiant doit suivre l’objet depuis l’endpoint d’entrée jusqu’au payload de sortie, en passant par la queue, le mapping et les retries. Les logs enregistrent la version active, le timeout rencontré et la décision finale. Cette corrélation permet de savoir si l’écart vient de la donnée, du transport ou d’une règle métier devenue obsolète.
Deux alertes suffisent au départ : un objet sans résultat dans le délai attendu et une divergence critique entre legacy et nouveau flux. Chaque alerte nomme un owner et propose une action de premier niveau. Ajouter dix métriques sans circuit de décision ne rendrait pas la transition plus sûre ; cela ralentirait seulement la qualification.
Le contrôle quotidien compare un échantillon de commandes, de stocks et de prix. La revue hebdomadaire recherche les motifs récurrents et décide lesquels doivent devenir une règle, un test ou une suppression de fonction legacy. Cette cadence transforme les incidents du pilote en apprentissage avant l’extension.
Utiliser Ciama comme mémoire de transition
Ciama Marketplace devient utile pour réunir l’objet, le système qui fait foi, le seuil cassé, le responsable et la preuve de sortie dans une même lecture. L’outil ne décide pas quelle vérité retenir ; il rend la décision traçable et évite que chaque équipe reconstruise le dossier depuis ses propres exports.
Cette mémoire permet aussi de comparer les deux cycles précédents avant d’autoriser une bascule. Une exception corrigée doit rester fermée, une reprise ne doit pas recréer le même écart et un droit d’écriture retiré ne doit plus apparaître dans les logs. Le suivi devient alors un contrôle de non-régression, pas un simple historique.
Au moment d’éteindre le legacy, la liste des exceptions ouvertes fournit la dernière preuve de go/no-go. Les cas sans owner ou sans sortie testée restent bloquants ; les écarts mineurs documentés peuvent être transférés dans le backlog du nouveau flux. Cette séparation protège la date de bascule sans sacrifier la qualité du run.
Plan d’action sur 30 jours pour préparer la bascule
Un plan court doit sécuriser la cohabitation, puis préparer l’extinction du legacy sur les flux concernés. La transition doit avoir une trajectoire, pas seulement une date de début.
La méthode consiste à limiter le périmètre, comparer les données, décider la source de vérité et fermer les doublons inutiles.
Jours 1 à 5 : cadrer la matrice de flux
La première semaine liste chaque flux et précise : legacy, nouveau système, source de vérité, droit d’écriture, contrôle attendu, responsable et date cible de bascule.
L’équipe identifie ensuite les flux qui ne doivent jamais être modifiés par deux systèmes en même temps : stock diffusé, prix publié, statut client et commande à préparer.
Ces flux reçoivent des seuils d’alerte et une procédure de correction prioritaire.
Jours 6 à 30 : tester, basculer, éteindre
La suite compare les résultats sur un périmètre pilote. Si les écarts restent sous le seuil accepté, le nouveau flux peut devenir maître sur ce périmètre.
Le legacy doit ensuite être réduit ou verrouillé sur le flux basculé. Sinon les équipes continueront à l’utiliser par habitude.
La réussite se mesure à la baisse des écarts, des reprises manuelles, des questions support et des décisions où personne ne sait quel système croire.
Prouver l’extension puis l’extinction
Exemple concret : le pilote commence avec 500 références et un seul canal pendant cinq jours ouvrés. Si aucune commande n’est perdue, si le stock diverge sur moins de 0,5 % des références et si chaque anomalie est qualifiée en moins de quinze minutes, alors l’écriture peut être ouverte à une deuxième famille. Dans le cas contraire, le lot reste borné et la cause doit être corrigée avant toute extension.
Le dernier contrôle vérifie l’extinction réelle : jobs désactivés, droits retirés, files vidées, alertes réattribuées et utilisateurs informés. Une revue à J+7 confirme qu’aucun export, script ou usage métier n’a recréé une écriture legacy. Cette preuve évite de déclarer la bascule terminée alors que l’ancien chemin reste encore actif en silence.
Erreurs fréquentes de double écriture qui prolongent le legacy
La première erreur consiste à laisser deux systèmes écrire la même donnée sans règle de priorité. C’est le moyen le plus rapide de créer une dette difficile à nettoyer.
La deuxième consiste à garder le legacy ouvert "au cas où" sans date d’extinction. Le run finit alors par maintenir deux processus au lieu d’en remplacer un.
Confondre test et production
Un test peut comparer les flux, mais il ne doit pas créer une décision client non contrôlée. Les commandes, prix et stocks publiés doivent rester sous gouvernance stricte.
Le périmètre pilote doit être assez petit pour être contrôlé, mais assez réel pour révéler les problèmes.
Un test sans critères de succès ne prépare pas une bascule. Il ajoute seulement un flux à surveiller.
Sous-estimer les habitudes métier
Les équipes continuent parfois à utiliser le legacy parce qu’il contient une information, un export ou une action absente du nouveau flux.
Avant d’éteindre, il faut repérer ces usages réels. Certains doivent être repris proprement, d’autres supprimés parce qu’ils entretiennent une mauvaise pratique.
La bascule est réussie quand le nouveau flux couvre les décisions utiles, pas seulement quand il reproduit les écrans anciens.
Lectures pour préparer la sortie du legacy
La cohabitation legacy se pilote mieux quand l’équipe a déjà clarifié la dette SI et l’arbitrage entre export de secours et flux propre.
Dette SI
Pour repérer les données, statuts et responsabilités qui risquent de contaminer le nouveau flux, appuyez-vous sur quand la dette SI empêche un outil de bien travailler.
Il permet de ne pas confondre migration et nettoyage de causes anciennes.
Exports et urbanisation
Pour décider quels fichiers restent temporaires et quels flux doivent être intégrés proprement, appuyez-vous sur exporter vite ou urbaniser proprement.
Cette lecture est utile pendant une cohabitation, car les exports deviennent facilement des passerelles permanentes.
Conclusion : sortir du double run avec une vérité unique
Faire cohabiter legacy et nouveaux flux vendeurs est possible si la phase est cadrée : source de vérité, droit d’écriture, contrôles, responsabilités, seuils et date de bascule.
Le danger n’est pas la cohabitation elle-même. Le danger est de laisser deux systèmes produire deux versions de la même réalité marketplace.
Le vendeur protège son run lorsqu’il sait quel système fait foi et quand le legacy doit être verrouillé ou éteint.
Pour piloter cette transition, notre accompagnement agence marketplace aide à organiser les flux vendeurs, les contrôles et les bascules sans créer de dette supplémentaire.
