Un acheteur crée un compte avec son adresse professionnelle, puis commande pour trois filiales. La facture part vers la mauvaise entité, le plafond budgétaire n’est pas appliqué et un administrateur local accède aux commandes de tout le groupe. Le problème n’est pas le checkout : le modèle organisationnel est trop plat.
Les symptômes s’accumulent avec des créations manuelles, des rattachements incohérents, des validations hors plateforme et une charge support qui augmente à chaque nouveau client. Un signal faible apparaît lorsque les mêmes adresses, numéros d’entreprise ou centres de coût sont recréés sous plusieurs libellés.
Le vrai enjeu consiste à représenter qui achète, pour quelle entité, avec quel contrat, quel budget et quelle autorité au moment exact de la commande. Vous allez comprendre comment construire ce graphe, gouverner ses changements et prouver chaque décision d’accès ou d’approbation.
La création d’une marketplace B2B commence par traduire l’organigramme réel en droits et responsabilités vérifiables. La spécialisation marketplace B2B opérable prolonge ce modèle jusque dans les contrats, commandes, factures et systèmes d’achats existants.
Reconnaître un modèle de compte B2B trop plat
Le modèle défaillant associe un utilisateur à une entreprise et une entreprise à une adresse. Il ne distingue ni groupe, entité légale, établissement, service, centre de coût, rôle temporaire, délégation ni périmètre contractuel.
Observer les contournements avant les incidents
Le partage d’identifiants, l’ajout d’un centre de coût en commentaire ou le déplacement manuel d’une commande après validation constituent un avertissement plus précoce. Le système fonctionne en apparence, mais l’organisation réelle vit déjà ailleurs.
Le diagnostic rapproche comptes, utilisateurs actifs, commandes, factures, corrections et tickets. Il mesure doublons d’entités, approbations manuelles, commandes réaffectées et droits dormants afin de borner la dette avant de modifier le schéma.
Construire un graphe organisationnel versionné
Une organisation B2B se représente mieux comme un graphe que comme une arborescence figée. Une entité peut appartenir à un groupe, partager un contrat, utiliser plusieurs établissements et déléguer une fonction achats à une équipe transverse.
Nommer nœuds, relations et périodes de validité
Les nœuds portent identité et attributs stables ; les relations portent rôle, périmètre, date d’effet, expiration et source. Un utilisateur devient approbateur d’un centre de coût pendant une période sans acquérir des droits permanents sur toute l’entreprise.
Chaque lecture utilise une date de référence. Une commande historique conserve l’organisation et les pouvoirs qui existaient lors de son approbation, même si une fusion, une mobilité ou une nouvelle délégation modifie ensuite le graphe courant.
Le graphe porte également la provenance de chaque relation : import MDM, invitation validée, décision d’un administrateur ou synchronisation RH. Cette information sépare une vérité certifiée d’une proposition locale et définit qui peut réellement la corriger sans écraser une source plus autoritaire.
Stabiliser les identités et les rattachements
Le SIREN, le SIRET ou l’identifiant fiscal aident à reconnaître une entité, mais ne suffisent pas toujours pour des groupes internationaux, administrations ou structures internes. La marketplace attribue un identifiant durable et conserve les correspondances externes versionnées.
Résoudre rapprochement, fusion et séparation
Une inscription ne crée pas automatiquement une nouvelle entreprise. Elle propose un rattachement selon domaine, numéro légal, contrat, fournisseur d’identité et validation d’un administrateur autorisé, avec une file de revue pour les ambiguïtés.
Une fusion rapproche les doublons sans réécrire les commandes ; une séparation déplace seulement les relations autorisées. Chaque action conserve identifiants source, décideur, motif, objets affectés et possibilité de revenir à la version précédente.
Le traitement d’un doublon commence par une simulation : membres, contrats, commandes, factures et rôles qui changeraient de rattachement sont listés avant exécution. Les conflits restent bloqués dans une file dédiée, car une fusion automatique peut élargir des droits tout en semblant simplement nettoyer des données.
Distinguer groupe et entités légales
Le groupe négocie parfois les conditions, mais l’entité légale passe la commande, reçoit la facture et porte la dette. Confondre ces niveaux applique le bon prix au mauvais débiteur et rend crédit, taxe et recouvrement impossibles à expliquer.
Attribuer contrat, risque et facturation au bon niveau
Un contrat-cadre peut couvrir le groupe tandis qu’une annexe fixe prix, plafonds ou catégories par filiale. Le moteur d’éligibilité résout d’abord l’entité acheteuse, puis hérite uniquement des conditions explicitement transmissibles.
Par exemple, si une filiale perd son assurance-crédit, alors son paiement différé est suspendu sans retirer les conditions des autres entités. La règle protège le périmètre risqué plutôt que fermer tout le groupe par facilité opérationnelle.
Modéliser établissements, livraison et facturation
Un établissement n’est pas une simple adresse libre. Il peut posséder horaires, quai, contraintes transport, contacts, instructions, pays fiscal, capacité de réception et droits d’achat différents selon la catégorie commandée.
Séparer lieux autorisés et instantanés de commande
La plateforme maintient les établissements approuvés, puis copie un instantané d’adresse dans la commande et la facture. Une correction ultérieure améliore les prochaines transactions sans modifier les documents déjà opposables.
Une adresse ponctuelle suit une approbation spécifique, avec motif et expiration. Le risque est de croire qu’un champ libre apporte de la flexibilité ; en réalité, il déplace contrôle fiscal, fraude et qualité logistique après le paiement.
Gouverner centres de coût, budgets et projets
Le centre de coût relie dépense, responsabilité et comptabilisation. Il peut dépendre d’un établissement, d’une entité ou d’un projet transverse, avec une période budgétaire, un owner et des catégories autorisées.
Réserver le budget sans inventer une comptabilité parallèle
La marketplace vérifie disponibilité et politique, puis crée un engagement corrélé à la commande. L’ERP ou l’outil procurement reste maître du budget ; la plateforme conserve le verdict, sa version et la preuve reçue.
Si le système maître est indisponible, alors la règle choisit blocage, plafond conservateur ou approbation renforcée selon montant et criticité. Aucun mode dégradé ne doit transformer une absence de réponse en autorisation illimitée.
Le budget distingue disponible, engagé, consommé, libéré et contesté. Une annulation ne rend la capacité qu’après l’accusé du système maître ; un remboursement tardif ne recrée pas artificiellement un droit d’achat dans une période déjà clôturée.
Attribuer rôles et permissions par périmètre
Les rôles utiles décrivent une capacité : administrer les membres, acheter, demander un devis, approuver, réceptionner, consulter les factures ou gérer le budget. Leur effet dépend du nœud et du périmètre auxquels ils sont attachés.
Combiner RBAC et attributs métier
Le RBAC fournit une base lisible ; les attributs ajoutent entité, catégorie, montant, centre de coût, pays et type de commande. Un acheteur peut commander du matériel sous 5 000 euros pour deux établissements sans voir les dépenses RH du groupe.
Les permissions négatives restent rares et explicites, car leur composition devient vite imprévisible. Un simulateur affiche le verdict et les règles appliquées avant déploiement, avec des tests de non-régression sur les personas critiques.
Une matrice de recertification liste rôle, périmètre, dernière utilisation, manager responsable et date de revue. Les droits jamais utilisés expirent ou demandent une justification renouvelée, tandis que les comptes de service suivent un cycle distinct avec propriétaire technique et secret géré.
Orchestrer approbations et délégations
L’approbation dépend de la commande, pas seulement de l’utilisateur. Montant, catégorie, fournisseur, budget, contrat et exception déterminent le circuit, tandis qu’une même personne peut intervenir à plusieurs niveaux sans valider deux fois le même risque.
Rendre toute délégation bornée et auditable
Une délégation nomme délégant, délégataire, périmètre, motif, début, fin et interdictions. Elle ne copie pas le rôle d’origine : elle crée une relation temporaire dont l’usage reste visible dans chaque décision.
Le workflow gère absence, escalade, séparation des tâches et quorum. Une approbation expirée retourne vers le bon niveau ; une modification matérielle de la commande invalide le verdict au lieu de réutiliser une autorisation devenue hors contexte.
Le délai d’approbation est mesuré par étape et par motif, sans classer automatiquement les contrôles comme une friction inutile. Une attente longue peut révéler un approbateur absent, une politique ambiguë ou une commande mal attribuée ; chaque cause appelle une correction différente.
Relier contrats, catalogues et prix négociés
Le catalogue visible résulte de l’entité, du contrat, du pays, des habilitations et de la période. Le prix peut être porté par le groupe, une filiale, un palier de volume ou une campagne, avec une priorité de résolution déterministe.
Expliquer l’offre calculée à l’acheteur
La fiche expose vendeur, référence contractuelle, unité, prix, taxes, minimum, délai et motif d’indisponibilité. Elle évite qu’un utilisateur croie à un bug lorsqu’un produit autorisé pour une filiale reste interdit à une autre.
Contre-intuitivement, afficher moins d’offres peut augmenter l’adoption : le catalogue devient achetable sans vérification manuelle, le prix est opposable et la commande traverse approbation puis facture sans correction cachée.
La résolution conserve les candidats évalués, la priorité gagnante et les conditions écartées. Le support peut ainsi expliquer pourquoi un accord groupe ne s’applique pas, identifier la donnée manquante et corriger le contrat plutôt que forcer un prix isolé sur une commande.
Synchroniser les systèmes maîtres sans double autorité
Le fournisseur d’identité porte l’utilisateur, le MDM ou l’ERP les entités, le procurement les politiques et budgets, le CRM la relation commerciale. La marketplace orchestre l’expérience sans devenir silencieusement maître de toutes ces données.
Contractualiser entrées, sorties et réconciliation
L’entrée d’organisation inclut identifiant, type, parent, période et version ; la sortie d’approbation inclut commande, verdict, règle et décideur. Chaque contrat fixe owner, seuil de fraîcheur, idempotence, file de rejet et procédure de rollback.
Le monitoring suit retard, doublons, relations orphelines et commandes sans rattachement opposable. Un runbook attribue le repli : bloquer une création, conserver la dernière hiérarchie sûre ou demander une validation manuelle bornée.
Prouver droits, décisions et séparation des tâches
Une preuve complète relie utilisateur authentifié, organisation, rôle, attributs, version de politique, commande, verdict et événement de délégation. Elle reste consultable par le support sans exposer des données d’autres entités.
Tester les invariants de sécurité
Les tests vérifient qu’un administrateur local ne voit que son périmètre, qu’un approbateur ne valide pas sa propre demande interdite et qu’une mobilité retire les droits précédents dans le délai convenu.
Le monitoring associe seuil, owner et action : un rattachement orphelin bloque la commande, une délégation expirée est rejetée, un écart d’identité ouvre une file de revue et un droit dormant déclenche une campagne de recertification.
Les journaux séparent consultation, modification et décision. Ils conservent acteur, contexte organisationnel, objet, valeur précédente, valeur nouvelle et corrélation de commande, avec une durée de conservation alignée sur les obligations contractuelles et les besoins réels d’investigation.
Éviter les erreurs fréquentes de modélisation B2B
Le modèle B2B devient faux lorsqu’il utilise l’adresse comme identité, confond groupe et débiteur, copie les rôles lors d’une délégation, écrase l’historique après une fusion ou laisse choisir librement l’entité de facturation.
Revenir au premier rattachement incohérent
Le diagnostic compare une commande affectée et un témoin : identité, rattachement, contrat, centre de coût, rôle, règle, verdict et export comptable. Le premier écart reproductible désigne la donnée ou la politique à réparer.
Un cas concret survient lorsqu’un acheteur change de filiale mais conserve une ancienne session. Si le contexte n’est pas réévalué, alors la commande peut utiliser un prix et un budget périmés malgré une authentification valide.
Une autre erreur consiste à permettre au support de corriger directement l’entité d’une commande validée. La reprise sûre annule le verdict, rattache la demande au bon contexte, relance prix et approbation, puis conserve les deux trajectoires pour expliquer le changement à la finance.
Résoudre un cas multi-filiales et multi-budgets
Un groupe industriel possède huit filiales, vingt-trois établissements et des achats centraux pour trois catégories. Les prix sont négociés au groupe, les factures portées par les filiales et les budgets contrôlés par établissement.
Ouvrir une cohorte sans migrer tout le groupe
La première cohorte couvre deux filiales, quatre établissements, trois rôles et un contrat. Trente commandes historiques sont rejouées ; chaque prix, approbation, adresse, imputation et facture doit produire le même résultat ou un changement volontaire documenté.
Après quatre semaines, les rattachements manuels diminuent et le rapprochement comptable ferme sans correction. L’extension vers une nouvelle filiale exige zéro droit transversal non prévu et un rollback de politique exécuté sur un environnement représentatif.
Le bilan sépare ensuite trois effets : temps gagné par les acheteurs, reprises évitées par la finance et risque retiré grâce aux permissions bornées. Les métriques sont comparées à une filiale témoin de taille proche, car une hausse du volume seule pourrait masquer davantage de corrections ou un circuit d’approbation devenu trop permissif.
Les exceptions restantes sont classées par règle, fréquence et valeur affectée. Cette file nourrit la roadmap suivante sans compromettre le modèle central ni transformer un besoin local non prouvé en permission globale durable.
Plan d’action : déployer la hiérarchie en huit semaines
Le déploiement doit fermer une boucle procure-to-pay bornée avant de couvrir toutes les variantes organisationnelles. Chaque phase produit des artefacts vérifiables et une porte de décision partagée avec le client pilote.
Semaines 1 et 2 : inventorier et rapprocher
Collectez entités, établissements, utilisateurs, centres de coût, contrats et rôles depuis les systèmes maîtres. Identifiez doublons, relations manquantes, périodes incohérentes et propriétaires de correction.
La sortie comprend un graphe de référence, un dictionnaire d’identités, une baseline des corrections et vingt scénarios de commande classés par risque, montant, entité et circuit d’approbation.
Semaines 3 à 5 : construire et rejouer
Implémentez relations versionnées, permissions, délégations et résolution contractuelle. Rejouez les scénarios avec journalisation du verdict, files de rejet, seuils de fraîcheur et procédures de repli.
Chaque divergence reçoit un owner et une décision : défaut du nouveau modèle, anomalie historique, amélioration volontaire ou donnée encore indécidable. Aucun écart inexpliqué n’entre dans la cohorte publique.
Semaines 6 à 8 : ouvrir et recertifier
Activez une entité, mesurez complétion, délai, erreurs et rapprochement, puis ajoutez un établissement ou un rôle à la fois. Testez mobilité, délégation, expiration et retour arrière avant chaque extension.
La porte finale exige des commandes et factures réconciliées, aucune permission hors périmètre, un support autonome et une campagne de recertification exécutée par les administrateurs réellement responsables.
- D’abord, stabiliser les identités et les relations temporelles avant de dessiner les écrans d’administration ou les workflows avancés.
- Ensuite, attribuer contrats, budgets, rôles et approbations au niveau organisationnel qui porte réellement la décision et le risque.
- Puis, rejouer des commandes complètes avec les systèmes maîtres, des seuils de fraîcheur et un rollback praticable par le run.
- À faire enfin : ouvrir par cohorte, recertifier les droits, mesurer les corrections supprimées et étendre une dimension organisationnelle à la fois.
Guides complémentaires : achats, crédit et identité B2B
La hiérarchie donne le contexte de décision ; le parcours procurement, le crédit acheteur et le KYC/KYB utilisent ensuite ce contexte pour rendre chaque transaction exécutable et auditable.
Relier le compte au processus d’achat
La méthode de marketplace B2B compatible procurement relie comptes, contrats, commandes et factures. Le contrôle du crédit acheteur attribue encours et plafonds au bon débiteur.
Le graphe organisationnel évite de dupliquer ces politiques dans chaque écran. Les services consomment un contexte résolu et conservent la version qui a réellement déterminé la transaction.
Sécuriser l’entrée des organisations
La démarche KYC/KYB marketplace gouverne documents, contrôles et reprises manuelles. La clôture financière marketplace vérifie ensuite que commandes, remboursements et reversements portent les bonnes références.
- À faire : versionner chaque relation, pouvoir et rattachement afin de reconstruire exactement le contexte d’une commande historique contestée.
- À différer : les exceptions rares tant que groupe, entités, établissements, centres de coût et rôles principaux ne ferment pas la boucle standard.
- À refuser : un administrateur global par défaut, une délégation sans expiration ou une correction d’organisation qui réécrit silencieusement les transactions passées.
Conclusion : rendre l’autorité explicable
Une marketplace B2B fiable ne demande pas seulement qui est connecté. Elle détermine pour quelle organisation, quel contrat, quel budget et quel périmètre cette personne peut agir à l’instant de la transaction.
Le graphe versionné protège l’identité, les délégations bornées protègent les pouvoirs et les systèmes maîtres conservent leur autorité. La commande garde la preuve qui relie ces décisions.
La valeur apparaît lorsque l’achat devient plus simple sans déplacer validation, correction et risque vers le support, la finance ou des fichiers invisibles après le checkout.
Pour structurer cette fondation, l’expertise Dawap en création de marketplace vous accompagne du premier rattachement organisationnel jusqu’à une commande B2B approuvée, facturée et réconciliée.
