Une deuxième business unit rejoint la marketplace et copie les catégories, les règles vendeurs et les connecteurs de la première. Trois mois plus tard, un même fournisseur possède deux comptes, les statuts de commande ne signifient plus la même chose et la finance rapproche des commissions calculées par deux moteurs.
Le symptôme commence par des demandes légitimes : prix locaux, validation différente, catalogue propre ou ERP historique. Faute de modèle de variation, chaque besoin devient un fork. Les équipes livrent vite au début, puis corrigent deux fois les incidents et ne savent plus quelle règle constitue le socle.
Le vrai enjeu d’une marketplace opérateur multi-BU consiste à mutualiser les capacités qui portent l’identité de plateforme tout en autorisant des politiques locales bornées. Contre-intuitivement, imposer une uniformité totale crée aussi des contournements : les entités déplacent leurs différences dans des tableurs et processus invisibles.
Vous allez comprendre comment séparer invariant, paramètre, extension et exception, puis décider où placer chaque variation. La méthode structure organisations, catalogue, vendeurs, acheteurs, finance et intégrations autour d’un même langage. Chaque BU peut agir dans son périmètre sans dupliquer la donnée ni modifier le comportement des autres.
Choisir ce qui reste central ou local
Classer invariant, configuration et extension
Un invariant garantit sécurité, intégrité financière, identité et cohérence des états. Une configuration adapte langue, seuil, assortiment ou message. Une extension ajoute une capacité prévue par contrat. Une exception temporaire déroge avec owner et expiration. Ces quatre catégories évitent de traiter chaque demande comme du code spécifique.
La classification s’appuie sur risque, fréquence, différenciation et coût de divergence. Un statut de paiement reste invariant ; un seuil de livraison peut être configuré. Une règle réglementaire locale utilise un module validé, pas une réécriture complète du checkout.
Pour qui centraliser ou déléguer les décisions
La plateforme centrale possède le socle, les contrats techniques et les risques transverses. La BU possède son offre, sa capacité et ses paramètres autorisés. Un comité arbitre les changements qui affectent plusieurs entités ou créent un nouvel axe de variation.
Le RACI précise qui propose, valide, implémente et supporte. Une direction centrale ne devient pas le support quotidien des règles locales ; une BU ne peut pas modifier un invariant parce qu’elle finance son déploiement. Les droits reflètent ces frontières.
Cartographier les capacités communes
Découper la plateforme par résultat métier
Identité, vendeur, catalogue, offre, commande, paiement, service, litige, finance et reporting forment des capacités. Pour chacune, l’équipe nomme données maîtres, événements, politiques, APIs et owner. La cartographie montre ce qui peut varier sans casser les voisins.
Les pages et microservices ne constituent pas automatiquement des capacités. Un parcours d’onboarding peut traverser plusieurs systèmes tout en appartenant au même contrat vendeur. Le découpage suit les décisions et les sources de vérité, pas l’organigramme technique existant.
Mesurer la maturité par BU
Chaque entité évalue processus, données, intégrations, volumes, compétences et exceptions pour chaque capacité. Une BU peut partager le catalogue tout en gardant temporairement ses commandes dans un ERP. La trajectoire explicite ce mode hybride et sa date de sortie.
Le modèle ne force pas toutes les entités à migrer en même temps. Il refuse cependant les doubles vérités sans contrat. La source, le sens des statuts et le rapprochement sont définis pendant la transition, avec monitoring et owner.
Composer politique socle et variantes
Hériter d’un socle versionné
La politique centrale contient exigences communes, états et contrôles. Une BU hérite d’une version et surcharge seulement les paramètres autorisés. Le résultat calculé indique socle, variante, priorité et date. Une copie locale du document n’est pas un mécanisme d’héritage.
Les changements centraux sont simulés sur toutes les BU. Une variante incompatible bloque la nouvelle version ou demande une migration. La plateforme sait quelles entités utilisent encore une ancienne règle et pourquoi, sans appliquer une mise à jour silencieuse.
Créer une variante locale défendable
La demande locale décrit source, population, valeur, risque, durée et métrique. Elle utilise un axe existant ou propose une extension générique. Une condition contenant le nom d’une BU dans le code révèle souvent un modèle incomplet.
Par exemple, un délai de préparation peut varier par catégorie et zone, pas par entité arbitraire. Le bon axe permet à d’autres BU de réutiliser la capacité. L’exception dédiée reste possible si elle expire et ne justifie pas une complexité permanente.
Modéliser organisations et droits
Séparer tenant, BU et équipe
L’organisation représente l’entité juridique ou opérationnelle selon le modèle. La BU, la marque, le pays et l’équipe sont des dimensions explicites, pas des préfixes de rôle. L’utilisateur peut appartenir à plusieurs périmètres avec des droits différents.
Les objets portent leur propriétaire organisationnel et les partages autorisés. Une commande ne change pas de BU parce qu’un agent central la traite. La corrélation conserve vendeur, acheteur, offre et entité financière responsables.
Calculer les permissions par contexte
Le droit combine rôle, organisation, action, objet et éventuellement seuil. Un administrateur local gère ses vendeurs sans voir les marges d’une autre entité. Un support central accède aux dossiers partagés selon une finalité et une durée.
Les délégations et comptes de service sont bornés. Les tests couvrent accès horizontal, export, recherche et notification. Une isolation correcte ne concerne pas seulement la base : index, caches, fichiers et analytics respectent le même contexte.
Partager le produit sans dupliquer
Distinguer produit canonique et offre locale
Le produit porte identité, attributs stables, médias et taxonomie. L’offre porte vendeur, BU, prix, stock, service et conditions. Plusieurs entités peuvent référencer le même produit sans copier toute sa fiche. Les enrichissements suivent une gouvernance commune.
Une donnée locale reste possible : traduction, classification autorisée ou document spécifique. Elle indique son périmètre et sa source. Le moteur compose la vue finale sans modifier le canonique pour satisfaire une seule BU.
Gouverner catégories et attributs
La taxonomie centrale fournit concepts et identifiants. Les BU peuvent choisir assortiment, ordre et labels, mais une catégorie locale doit mapper un concept ou suivre une procédure de création. Les forks de taxonomie rendent recherche, reporting et intégrations incomparables.
Un comité catalogue mesure demandes locales, conflits et attributs inutilisés. Les migrations de catégorie sont versionnées et rejouables. Les anciennes offres conservent leur historique tandis que les nouvelles validations utilisent la structure actuelle.
Gérer un vendeur dans plusieurs BU
Réutiliser identité et preuves communes
Le vendeur possède une identité de groupe et des relations contractuelles par BU lorsque nécessaire. Les données vérifiées réutilisables sont référencées, pas recopiées. Leur portée et leur expiration indiquent si une nouvelle entité doit demander un complément.
Le statut global ne masque pas les statuts locaux. Un vendeur peut être vérifié mais non activé dans une BU faute d’assortiment ou de contrat. Le back-office explique chaque axe et évite qu’une suspension locale ferme toutes les activités sans décision.
Composer onboarding et performance
Le parcours applique socle commun puis étapes locales. Les tâches déjà validées ne sont pas répétées. Le vendeur voit progression par entité, owner et raison. Les APIs exposent des statuts stables plutôt que cinq formulaires clonés.
La performance est mesurée globalement et localement. Un incident grave peut produire une mesure centrale selon la politique ; une qualité faible sur une catégorie reste locale. Le modèle documente les conditions de propagation afin qu’une BU ne sanctionne pas sur une moyenne hors contexte.
Préserver une promesse acheteur claire
Choisir l’expérience de marque
Une plateforme peut présenter une marque commune, plusieurs enseignes ou des portails séparés. Ce choix détermine compte, panier, service client et confiance. Le client doit comprendre qui vend, facture, livre et répond, même si le socle technique est mutualisé.
Les variations visuelles ne changent pas le sens des états. « Confirmée » possède le même contrat ou un label différent explicitement mappé. Les contenus locaux restent dans un système de thèmes et de traductions plutôt que dans des templates divergents.
Borner panier et parcours transverses
Un panier multi-BU soulève paiement, facture, livraison, retour et données. L’équipe décide s’il est autorisé et comment les commandes filles se comportent. Une interface unique ne doit pas cacher plusieurs contrats incompatibles.
Si le panier reste séparé, le client voit clairement la frontière avant paiement. Si le panier est commun, orchestration et finance partagent un contrat robuste. Le choix est testé sur annulation partielle, promotion, retour et litige.
Borner prix et règles commerciales
Séparer politique et paramètre local
Le moteur commun gère type de prix, devise, taxe, promotion et commission. La BU renseigne les paramètres dont elle est propriétaire. Les formules et priorités restent versionnées. Un tableur local ne peut pas écraser un total après calcul sans événement.
Les prix négociés, B2B ou pays utilisent des dimensions contrôlées. Le système sait pourquoi une valeur s’applique. Une condition par code de BU peut être tolérée pendant un pilote, avec une date de migration vers un axe générique.
Éviter arbitrage et cannibalisation invisibles
Deux BU peuvent proposer le même produit avec des services différents. Le classement explicite prix, disponibilité, zone et promesse. La plateforme décide les règles d’exposition ; une entité ne peut pas acheter une priorité cachée au détriment des autres.
Le reporting compare marge et conversion sans mélanger les modèles. Les campagnes et promotions portent leur financeur. Un conflit commercial rejoint le comité commun avec faits, options et durée, pas une modification manuelle du ranking.
Séparer finance et responsabilité
Attribuer chaque mouvement à une entité
Commande, commission, frais, remboursement, réserve et reversement portent BU, vendeur, devise et règle. Le ledger conserve cette dimension dès l’origine. Une répartition mensuelle depuis un total global ne permet pas d’expliquer un litige ou une correction.
Les entités juridiques, comptes PSP et factures sont mappés selon le montage validé. Le SI n’infère pas le responsable depuis un domaine ou une équipe. La banque et la comptabilité rapprochent les mêmes identifiants.
Gérer services et coûts partagés
Les coûts plateforme, support central et outils communs utilisent une règle d’allocation décidée, versionnée et expliquée. Volume, commandes ou usage peuvent servir de clé. La formule ne change pas rétroactivement sans écriture compensatrice.
Le tableau distingue économie locale et coût mutualisé. Une BU ne paraît pas rentable parce qu’une autre absorbe ses exceptions. Les seuils d’expansion incluent le coût complet et le besoin de trésorerie du périmètre.
Gouverner données et intégrations
Nommer les sources par domaine
Le groupe décide la source des produits, vendeurs, stocks, commandes, clients et finances. Une BU peut fournir une donnée sans devenir propriétaire du modèle commun. Les contrats précisent identifiant, fraîcheur, qualité et comportement en cas d’inconnu.
Les référentiels locaux sont mappés vers des identifiants stables. La correspondance est versionnée et surveillée. Un changement ERP ne doit pas créer de nouveaux vendeurs ou produits parce qu’un code a été réutilisé.
Construire des connecteurs réutilisables
Les adaptateurs traduisent chaque ERP ou PIM vers le contrat commun. Ils ne déposent pas leurs particularités au cœur du modèle. Les files, retries, idempotence et DLQ sont mutualisés, tandis que secrets et quotas restent isolés par organisation.
Le monitoring ventile événements, erreurs et retard par BU et connecteur. Un incident local ne sature pas toute la file. Le rollback désactive une route sans interrompre les entités saines, et conserve les messages pour une reprise contrôlée.
Arbitrer les exceptions locales
Utiliser une demande de variation
La BU décrit besoin, règle actuelle, impact, volume, durée, alternatives et owner. La plateforme classe configuration, extension réutilisable ou exception. Cette file rend le coût de divergence visible et évite le développement hors roadmap par relation directe avec une équipe.
Le comité évalue valeur locale, réutilisation, sécurité et maintenance. Un test borné peut précéder la décision. Les exceptions expirent et sont suivies dans un registre ; elles ne deviennent pas un produit parallèle sans arbitrage explicite.
Mesurer mutualisation et autonomie
Les indicateurs suivent taux de capacités communes, variantes, forks, temps d’intégration, incidents croisés et corrections locales. L’objectif n’est pas 100 % commun, mais une divergence intentionnelle dont le coût et l’owner sont connus.
La BU mesure aussi son autonomie : configuration, catalogue, vendeurs et support réalisables sans ticket central. Une hausse des demandes au SI révèle un manque d’outillage ou une frontière trop rigide. Le produit central priorise les self-services qui réduisent ce coût récurrent.
Éviter les erreurs fréquentes
Cloner la première BU
Copier code, taxonomie et comptes livre vite mais crée des identités et règles divergentes. La deuxième entité devient le bon moment pour isoler socle, paramètres et extensions. Les données communes restent référencées, pas dupliquées.
Autre erreur : forcer toute différence dans un champ générique. Une configuration sans sémantique devient aussi dangereuse qu’un fork. Chaque axe possède type, validation, owner et impact connu sur les capacités.
Centraliser toutes les décisions
Une équipe centrale qui approuve chaque offre et prix devient un goulot. Le socle doit déléguer les décisions locales dans des limites testées. Les droits et outils matérialisent l’autonomie au lieu de la promettre dans une charte.
Enfin, un reporting global peut masquer une BU déficitaire ou défaillante. Les événements gardent leur contexte organisationnel. Les indicateurs se lisent au niveau groupe et local, avec une réconciliation commune qui évite deux versions des chiffres.
Plan d’action pour intégrer une BU
Cartographier écarts et contrats
L’équipe choisit un parcours complet, de l’onboarding vendeur au reversement. Elle cartographie capacités, données, systèmes, politiques, rôles et volumes de la BU. Chaque écart est classé invariant, configuration, extension ou exception. Les owners centraux et locaux valident source, portée, entrées, sorties et responsabilité. Vingt scénarios couvrent vendeur commun, produit partagé, prix local, commande croisée, remboursement, droit d’accès et panne d’un ERP local. La revue ajoute les cas d’un utilisateur présent dans deux entités, d’un identifiant réutilisé et d’une variante centrale mise à jour pendant une commande ouverte.
La mise en œuvre prépare organisations, permissions, mapping d’identifiants, contrats d’API, files, idempotence, journalisation et monitoring. Un environnement utilise des données synthétiques de deux BU pour tester l’isolation. Les politiques calculées affichent socle et variante. Finance rapproche chaque mouvement par entité. Le runbook coupe une intégration locale sans toucher les autres. Une seconde équipe doit expliquer une commande sans connaître le système historique de la BU.
Piloter une capacité puis étendre
Le canary limite une catégorie, quelques vendeurs et un cycle financier. Le tableau suit erreurs de mapping, violations d’accès, interventions centrales, écarts de règle et balances. Si une donnée d’une BU apparaît dans une autre, si un mouvement reste sans entité ou si plus de 5 % des cas exigent un contournement, alors les nouvelles entrées sont coupées. Les commandes ouvertes suivent leur contrat jusqu’à clôture.
Le palier suivant ajoute une capacité ou une population. Les exceptions du pilote sont corrigées ou expirent avant l’extension. Après trois cycles stables, la BU rejoint le run et possède ses rôles, dashboards et support. Le groupe réutilise les axes créés pour la prochaine entité, mais revalide obligations et systèmes. La plateforme grandit par capacités communes, pas par empilement de copies.
- À faire d’abord : classer chaque différence en invariant, paramètre, extension ou exception.
- À tester ensuite : isolation, mapping, finance et panne locale.
- À différer : les parcours transverses sans contrat commun.
- À refuser : toute copie de donnée ou de règle sans source et owner.
Guides complémentaires pour l’opérateur
Structurer catalogue et première entité
Le dossier sur le catalogue et la taxonomie marketplace aide à séparer produit canonique, offre locale et catégories partagées.
La méthode pour ouvrir une première catégorie donne un périmètre borné pour intégrer une BU sans lancer tout son catalogue.
Outiller droits et exploitation
Les écrans du back-office opérateur matérialisent contexte organisationnel, rôles, files et décisions locales.
Le cadre de refonte et migration marketplace complète la reprise des données et intégrations historiques de chaque entité.
Conclusion : mutualiser les invariants
Une marketplace multi-BU ne doit ni cloner la première entité ni centraliser chaque geste. Elle distingue invariants de plateforme, paramètres locaux, extensions réutilisables et exceptions temporaires.
Organisations, droits, catalogue, vendeurs et finance partagent un langage commun tout en conservant leur contexte. Les politiques héritées et versionnées remplacent les copies divergentes.
Les intégrations traduisent les systèmes locaux vers des contrats stables. Isolation, mapping, balance et autonomie sont testés par paliers avant de généraliser la BU.
Pour modéliser les capacités, intégrer les entités et gouverner les variations, Dawap peut vous accompagner dans votre projet de marketplace opérateur, de la première BU au socle groupe.
