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 connecteurs marketplace ERP aide à cadrer cette période sans laisser les équipes vendeur gérer la migration au cas par cas.
Diagnostiquer la cohabitation legacy
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.
Quand faire cohabiter deux flux
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.
Signaux de conflit entre systèmes
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.
Plan d'action en 30 jours
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.
Erreurs fréquentes
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.
Guides complémentaires
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
Le guide quand la dette SI empêche un outil de bien travailler aide à repérer les données, statuts et responsabilités qui risquent de contaminer le nouveau flux.
Il permet de ne pas confondre migration et nettoyage de causes anciennes.
Exports et urbanisation
Le guide exporter vite ou urbaniser proprement aide à décider quels fichiers restent temporaires et quels flux doivent être intégrés proprement.
Cette lecture est utile pendant une cohabitation, car les exports deviennent facilement des passerelles permanentes.
Conclusion opérationnelle
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.
