Un acheteur commande pour un établissement, utilise le tarif négocié par le groupe, consomme le budget d’une direction et demande une facture au nom d’une filiale. Si le produit résume tout cela à un unique « compte entreprise », la première commande paraît simple ; la suivante révèle un prix transmis à la mauvaise société, une adresse non autorisée ou une validation déclenchée par le mauvais responsable.
Le problème ne vient pas seulement des droits. Il apparaît lorsque des notions différentes partagent le même objet technique : entité qui signe, lieu livré, centre de coût, collectif d’utilisateurs, propriétaire du contrat et débiteur. Une modification destinée à l’une de ces dimensions se propage alors aux autres sans intention métier.
Le vrai enjeu est de représenter qui achète, pour qui, où, selon quel accord et sous quelle autorité au moment précis de la transaction. Une marketplace opérateur orientée B2B doit préserver ce contexte depuis l’invitation de l’utilisateur jusqu’au devis, à la commande, à la livraison et à la facture.
Le bon modèle n’est pas nécessairement un grand arbre. Il sépare les responsabilités stables, autorise plusieurs rattachements, applique des règles d’héritage explicites et photographie les données contractuelles sur chaque opération. Cette discipline réduit les comptes dupliqués tout en empêchant qu’une réorganisation réécrive l’histoire.
Ne pas confondre organigramme et compte d’achat
L’organigramme décrit une structure de management. Le processus d’achat suit souvent une autre géographie : centrale de référencement, filiales facturées séparément, établissements livrés, budgets transverses et équipes projet temporaires. Copier l’organigramme produit donc une hiérarchie élégante mais fausse pour la transaction.
L’équipe part des décisions que le système doit prendre. Quelle entité accepte les conditions ? Qui reçoit la facture ? Quel lieu peut être livré ? Qui porte le crédit ? Quels utilisateurs partagent un panier ou une approbation ? Chaque réponse peut désigner un niveau différent.
Le compte racine sert à regrouper et administrer, mais ne devient pas automatiquement acheteur, facturé ou livré. Les capacités sont attachées aux unités qui les exercent. Cette séparation empêche une filiale nouvellement ajoutée d’hériter par accident de tous les pouvoirs du groupe.
Nommer les niveaux qui ont un effet réel
Un vocabulaire court suffit généralement : groupe commercial, entité juridique, établissement ou site, unité d’achat, puis utilisateur. L’unité d’achat représente un périmètre opérationnel comme un service, une agence ou un projet lorsqu’il possède budget, approbateurs ou catalogue propres sans personnalité juridique.
Chaque niveau existe parce qu’il porte au moins une règle. Une couche décorative ajoutée « au cas où » alourdit invitations, recherche et intégrations. À l’inverse, fusionner deux niveaux aux responsabilités distinctes pousse les équipes à compenser avec des champs libres et des exceptions.
La fiche de définition indique ce que le niveau peut posséder : identifiant, contrat, membres, adresses, catalogue, budget, crédit, commandes et factures. Elle précise aussi ce qu’il ne peut jamais porter. Ce négatif rend le modèle plus facile à relire qu’une liste de tables.
Séparer identifiants légaux et clés internes
Une entité de la marketplace possède une clé interne immuable. Les identifiants externes — SIREN, SIRET, numéro TVA, code ERP ou GLN — lui sont associés avec leur type, leur source, leur pays, leur période de validité et leur statut de vérification. Aucun identifiant métier ne remplace la clé technique.
En France, l’Insee distingue l’unité légale, entité juridique, de l’établissement, unité géographiquement individualisée qui en dépend. Cette distinction fournit un repère utile, sans suffire à représenter budgets, contrats et organisations internationales.
Pour des échanges interentreprises, le GLN de GS1 peut identifier entité juridique, fonction ou lieu physique. Le modèle conserve la nature de ce qui est identifié ; il ne suppose pas que deux codes de même format portent la même responsabilité.
Autoriser plusieurs rattachements par personne
Un utilisateur n’appartient pas toujours à une seule branche. Un directeur régional peut approuver pour cinq établissements, un acheteur groupe négocier pour plusieurs filiales et un consultant intervenir sur un projet borné. Le rattachement relie donc personne, organisation, rôle, périmètre et dates.
La connexion ne choisit pas silencieusement le compte le plus puissant. L’utilisateur sélectionne le contexte d’achat parmi ses rattachements actifs, ou l’application le déduit d’un parcours sans élargir les droits. Le contexte reste visible dans l’en-tête, le panier et la confirmation.
La fin d’un rattachement ne supprime pas la personne ni ses actions passées. Elle interdit les nouvelles opérations dans ce périmètre et ferme les délégations associées. Les commandes historiques continuent d’afficher le contexte qui existait lors de leur création.
Porter les droits au bon périmètre
Le rôle exprime une responsabilité : administrateur d’organisation, acheteur, demandeur, approbateur, réceptionnaire ou lecteur finance. Le périmètre indique où elle s’applique. « Approbateur » au niveau d’une filiale ne donne aucun pouvoir sur les autres filiales du groupe.
L’héritage descendant est une règle choisie, pas un comportement implicite. Un administrateur groupe peut gérer les membres de toutes les unités si le contrat le prévoit ; un catalogue groupe peut être visible par défaut ; un droit de paiement peut rester local. Chaque type de capacité définit s’il hérite, s’il peut être bloqué localement et qui modifie cette décision.
Contre-intuitivement, quelques rôles combinés à des périmètres explicites sont plus fins qu’une centaine de rôles. La multiplication des étiquettes cache les relations réelles et rend impossible une revue des droits après réorganisation.
Distinguer filiale, établissement et service
La filiale peut signer, être facturée et porter une obligation. L’établissement représente un lieu d’activité ou de livraison rattaché à une unité légale. Le service ou centre de coût organise la dépense sans devenir partie au contrat. Ces différences changent le contenu du devis et de la facture.
Le produit n’impose pas qu’un établissement ait sa propre administration d’utilisateurs. Il peut hériter des membres de la filiale et ne porter que des adresses, un réceptionnaire et des contraintes logistiques. Une unité d’achat peut au contraire traverser plusieurs sites tout en restant rattachée à une seule entité facturée.
Les organisations internationales demandent un type générique et des identifiants adaptés au pays. Le code français ne doit pas structurer toute la base. Les règles locales de validation sont branchées sur le type d’identifiant, pas sur la forme centrale du compte.
Modéliser les fonctions des adresses
Une adresse peut servir au siège, à la facturation, à la livraison, au retour ou à l’administration. Une même valeur postale peut remplir plusieurs fonctions ; deux fonctions peuvent aussi pointer vers des lieux différents. Le modèle relie donc une adresse versionnée à un usage et à un périmètre.
L’utilisateur ne saisit pas librement une adresse de livraison si le contrat limite les sites autorisés. Il choisit parmi les lieux actifs ou demande une validation. Les informations de quai, horaires, contact et contraintes transport sont propres à la destination, pas à l’entité juridique.
Modifier l’adresse courante ne réécrit pas une commande livrée l’année précédente. Le document conserve une copie des données utilisées avec leur référence d’origine. Cette photographie permet de comprendre l’opération même si un site déménage ou ferme.
Hériter des catalogues et prix sans fuite
Un accord groupe peut définir un catalogue et une remise commune, tandis qu’une filiale ajoute des produits locaux ou une condition particulière. La règle de résolution suit un ordre documenté : exclusion locale, accord spécifique, héritage du parent, puis offre publique si elle est autorisée.
Le prix n’est jamais obtenu en cherchant « le premier ancêtre qui répond ». Le moteur reçoit compte d’achat, entité contractante, produit, quantité, date et devise ; il retourne le tarif, sa source et sa version. Une absence de règle produit un refus explicable plutôt qu’un prix par défaut dangereux.
Le cache intègre le périmètre et la version du catalogue. Sinon, une réponse calculée pour une filiale peut être servie à une autre. Le panier revalide prix et éligibilité avant le devis ou la commande, puis conserve la preuve de la règle appliquée.
Partager budget, crédit et approbation avec mesure
Budget et crédit ne sont pas synonymes. Le budget est une autorisation interne de dépense ; le crédit mesure l’exposition acceptée par le vendeur ou l’opérateur. Ils peuvent être portés au groupe, à la filiale, à l’unité d’achat ou au projet, avec des règles de consommation différentes.
Une enveloppe partagée ne doit pas être copiée dans chaque enfant. Elle possède une source unique et des allocations ou réservations. Le calcul distingue disponible, réservé, engagé et consommé. En cas de commande simultanée, l’opération de réservation doit être atomique pour éviter de dépenser deux fois la même capacité.
Le workflow d’approbation observe montant, catégorie, budget, demandeur et entité. Par exemple, si le seuil local est fixé à 15 000 €, une commande à 16 200 € doit réserver son budget puis attendre le second niveau groupe ; elle ne doit ni être transmise au vendeur ni consommer définitivement l’enveloppe avant ce verdict. Le modèle conserve la version de la délégation et interdit l’auto-approbation.
Figer le contexte au moment de la commande
Une commande B2B indique au minimum le compte d’achat, l’entité contractante, l’entité facturée, le lieu de livraison, la devise, les conditions, la référence acheteur et les décideurs. Ces relations pointent vers les objets vivants tout en conservant un instantané des données contractuelles.
La commande ne change pas de propriétaire parce qu’un utilisateur est transféré ou qu’une filiale rejoint une autre branche. Une correction suit une opération tracée : annulation, avoir, changement autorisé ou migration explicite. Modifier le parent courant n’altère jamais silencieusement l’historique.
Les entrées du service de commande contiennent le contexte résolu et les preuves d’approbation ; les sorties portent les identifiants internes et externes. Le contrat, la journalisation, les dépendances de prix et le seuil de crédit sont vérifiés avant l’écriture. Un rollback ne rouvre pas un ancien périmètre de droits.
Consolider sans perdre l’entité redevable
La consolidation réduit le nombre de documents, mais ne fusionne pas les responsabilités. Une facture groupe peut regrouper des commandes seulement si contrat, fiscalité, devise, période et partie facturée le permettent. Les lignes gardent leur commande, leur vendeur et leur lieu de livraison.
Un centre de coût peut recevoir un reporting sans devenir destinataire légal de la facture. L’adresse de facturation, le numéro fiscal et les conditions de paiement viennent de l’entité redevable au moment de l’émission. Leur version est conservée sur le document.
Les litiges et avoirs doivent retrouver la ligne initiale même après réorganisation. La consolidation offre une vue de paiement ; elle ne supprime pas la granularité nécessaire au rapprochement entre commande, livraison, facture et règlement.
Déléguer l’administration du compte
L’opérateur ne doit pas gérer manuellement chaque mouvement d’un grand client. Un administrateur d’organisation invite des membres, attribue des rôles dans son périmètre et demande l’ajout d’unités. Il ne peut ni s’accorder un pouvoir supérieur ni administrer une autre branche par simple identifiant.
L’invitation précise organisation, rôle, périmètre, initiateur et expiration. Accepter avec une adresse déjà connue rattache la même personne au nouveau contexte au lieu de créer un doublon. Un domaine de messagerie peut faciliter une suggestion, jamais prouver seul l’appartenance.
Les actions sensibles — nouvel administrateur groupe, changement d’entité facturée, délégation de crédit — demandent une approbation ou une vérification opérateur. Le journal distingue demande, validation et effet produit.
Absorber fusion, cession et fermeture
Une société peut être cédée, fusionnée ou dissoute ; un établissement peut fermer ; un service peut changer de rattachement. Ces événements ne se traitent pas par suppression. L’unité reçoit une date de fin, un motif et, si nécessaire, une relation de succession.
Les nouvelles commandes suivent la nouvelle structure à partir d’une date décidée. Les opérations ouvertes sont soit conservées sur l’ancienne entité, soit transférées par une procédure qui vérifie contrat, budget, crédit, prix et facturation. Un déplacement graphique dans l’arbre ne vaut pas migration.
Le premier signal faible d’un modèle fragile est une demande récurrente de « renommer le compte » pour résoudre une restructuration. Le second est l’export manuel utilisé pour savoir à quelle société appartient réellement une commande. Ces symptômes révèlent que l’identité et l’historique sont confondus.
Construire un modèle de données explicite
Séparer les objets stables
Le noyau peut contenir organisation, unité organisationnelle, relation parent-enfant datée, identité légale, lieu, personne, rattachement et rôle. Catalogue, contrat, budget, crédit et workflow référencent ensuite le périmètre auquel ils s’appliquent. Les commandes conservent leur propre contexte transactionnel.
Le type de relation est explicite : possède, administre, achète pour, est facturé par ou reçoit pour. Un unique champ parent_id ne peut pas répondre à toutes ces questions lorsque les hiérarchies divergent. Plusieurs graphes ciblés valent mieux qu’un arbre universel.
Versionner les décisions qui influencent un prix ou un droit
Les relations, rattachements et politiques portent début, fin et auteur. Une modification crée une nouvelle période au lieu d’écraser la précédente lorsqu’elle affecte l’explication d’une transaction. Le moteur peut ainsi évaluer le présent et reconstruire le passé.
Les contraintes techniques protègent l’intégrité : pas de cycle dans une hiérarchie, identifiant externe unique dans son espace, une relation active compatible avec ses dates et aucun rattachement vers une unité fermée. Les migrations de masse passent par les mêmes contrôles.
Contractualiser les échanges avec ERP et achats
L’ERP, le CRM et la plateforme d’achats ne partagent pas forcément le même découpage. Une table de correspondance versionnée relie leurs identifiants aux objets internes. L’intégration ne suppose pas qu’un « customer ID » distant représente toujours une entité juridique.
Les entrées déclarent type d’objet, identifiant source, événement, version et date d’effet ; les sorties donnent résultat, identifiant interne et éventuels refus. Le contrat d’API, la file de reprise, l’idempotence, la journalisation et les responsabilités sont définis avant le premier import complet.
Une synchronisation ne déplace pas automatiquement une unité lorsqu’un parent change dans l’ERP. Elle ouvre une proposition de réorganisation si l’impact touche prix, commandes ou facturation. Le responsable métier arbitre et choisit la date d’effet.
Tester héritage, isolement et historique
Les tests unitaires couvrent la résolution des droits, tarifs, budgets et approbateurs. Pour chaque héritage, ils vérifient le parent, l’exception locale, le blocage explicite et l’absence de règle. Les cycles et périodes incohérentes sont refusés.
Les scénarios d’intégration permutent deux groupes, deux filiales et deux sites. Un utilisateur autorisé dans une branche tente d’accéder à l’autre ; un prix local ne doit jamais apparaître ailleurs ; une enveloppe partagée ne peut pas être consommée deux fois. Les exports et tâches asynchrones font partie du test.
La recette historique déplace une filiale après une commande, ferme un établissement puis relit devis, commande et facture. Le test réussit si les nouvelles opérations utilisent la nouvelle structure tandis que les anciennes restent intelligibles avec leurs preuves.
Dérouler un groupe B2B à trois filiales
Le besoin et le mauvais raccourci
Cas concret. Un groupe possède trois filiales et douze sites. Les prix sont négociés au groupe, chaque filiale est facturée séparément, deux sites partagent un budget projet et les commandes supérieures à 15 000 € exigent l’accord de la direction achats. Le premier prototype crée un compte par site et duplique les administrateurs.
Ce raccourci produit trente-six associations de prix, trois copies du même acheteur groupe et aucun encours consolidé. Fermer un site impose de rechercher ses utilisateurs un par un. Une adresse ajoutée par erreur peut même devenir une nouvelle identité cliente.
La structure et le verdict
La version corrigée crée un groupe, trois entités juridiques, douze lieux et une unité d’achat projet reliée à deux sites. Le catalogue groupe hérite ; la facturation et le crédit restent au niveau filiale ; le budget projet est unique ; les acheteurs sont rattachés aux périmètres utiles.
La recette passe si une filiale ne voit jamais le tarif spécifique d’une autre, si le budget partagé est réservé atomiquement, si le seuil de 15 000 € déclenche le bon approbateur et si le déplacement d’un site ne modifie aucune facture ancienne. Ces preuves remplacent l’impression que « l’arbre semble correct ».
Mesurer la qualité du modèle
Le nombre de comptes n’est pas une mesure de réussite. L’équipe suit plutôt les utilisateurs dupliqués, les commandes corrigées pour mauvaise entité, les prix refusés faute de contexte, les adresses saisies hors référentiel et le délai de rattachement d’un nouveau membre.
Les exceptions révèlent la dette : droits ajoutés directement, correspondances ERP manuelles, factures réaffectées et commandes placées sur un compte générique. Chaque exception possède un propriétaire, une date de sortie et une cause à traiter.
Le coût complet inclut support, finance, achats et intégration. Une hiérarchie qui économise une journée de développement mais impose une correction comptable mensuelle déplace la charge au lieu de simplifier le produit.
Identifier les marketplaces concernées
Cette méthode vise les marketplaces B2B privées ou sectorielles qui servent groupes multi-filiales, réseaux d’agences, collectivités, franchises ou grands comptes. Elle devient prioritaire dès que paiement, livraison, budget et contrat ne sont pas portés par la même unité.
Le product owner définit les parcours, la finance les responsabilités de crédit et facturation, les achats les délégations, l’architecture le modèle et l’exploitation les reprises. Un administrateur client valide la lisibilité du dispositif sur des cas réels.
Pour un acheteur indépendant avec une seule adresse, le modèle reste simple. Il ne faut pas exposer toute la hiérarchie à chaque client. Les capacités avancées s’activent lorsque le besoin existe, sur le même noyau de données.
Repérer les erreurs fréquentes de modélisation
- Faire de l’adresse l’identité : un déménagement crée alors un faux nouveau client et détruit la continuité.
- Utiliser un arbre unique : management, facturation, livraison et budget suivent rarement exactement la même hiérarchie.
- Copier les règles dans les enfants : toute évolution groupe exige une mise à jour fragile de dizaines de lignes.
- Attacher la personne à un seul compte : les acheteurs transverses finissent avec plusieurs identités et mots de passe.
- Écraser les valeurs passées : les commandes et factures deviennent impossibles à expliquer après une réorganisation.
- Laisser l’ERP décider seul : un changement technique de parent peut modifier des engagements commerciaux sans arbitrage.
Une autre erreur consiste à rendre toute règle héritée impossible à bloquer localement. Une filiale peut devoir exclure un produit, imposer une approbation ou utiliser une adresse spécifique. L’exception doit être explicite et traçable, pas cachée dans un champ libre.
Enfin, le back-office ne doit pas autoriser un déplacement massif sans prévisualisation. L’opérateur doit voir membres, contrats, tarifs, opérations ouvertes et factures affectés avant de confirmer ou de différer.
Mettre le modèle en place en six semaines
Semaines 1 à 3 : observer et construire
La première semaine collecte dix à vingt comptes représentatifs : groupe simple, filiales autonomes, sites multiples, acheteur transverse et réorganisation récente. Pour chacun, l’équipe dessine qui contracte, commande, approuve, reçoit et paie. Les divergences avec l’organigramme sont marquées.
La deuxième semaine fixe le vocabulaire et les responsabilités. Chaque niveau indique identifiants, relations, capacités et interdictions. Les règles d’héritage pour droits, catalogue, prix, budget et crédit sont écrites avec un exemple nominal, une exception locale et une absence de règle.
La troisième semaine implémente le noyau : unités, relations datées, identités externes, lieux, rattachements et contexte d’achat. Une migration pilote importe deux clients depuis l’ERP. Les erreurs de correspondance rejoignent une file de reprise plutôt qu’un compte générique.
Semaines 4 à 6 : raccorder et prouver
La quatrième semaine branche tarifs, budgets, approbations et commande sur le contexte résolu. Chaque décision expose sa source et sa version. La commande photographie entité, adresse, prix et délégation sans recopier toute la structure.
La cinquième semaine raccorde facturation et administration déléguée. L’équipe teste invitation multi-rattachement, fin de mission, fermeture de site et changement d’entité facturée. Les journaux permettent au support de retrouver la règle sans accès direct à la base.
La sixième semaine rejoue le cas à trois filiales et une réorganisation. Le comité décide : étendre si isolement, héritage et historique sont prouvés ; limiter si une fonction reste manuelle mais bornée ; replier si une fuite de tarif, un double budget ou une réécriture de facture reste possible.
- Étendre lorsque chaque transaction restitue entité, lieu, accord et autorité qui l’ont produite.
- Limiter lorsque l’intégration ERP exige encore une correspondance manuelle contrôlée et réversible.
- Refuser l’ouverture multi-entités si les droits ou prix peuvent traverser une branche sans règle explicite.
Approfondir hiérarchie, crédit et facturation
Prolonger la conception B2B
La hiérarchie réelle des comptes B2B approfondit les décisions d’autorité et les scénarios de rattachement. Pour replacer le modèle dans le processus complet, l’intégration du processus d’achat relie contrat, demande, commande et systèmes du client.
Ces contenus ne remplacent pas le travail de données décrit ici : ils donnent les décisions à supporter, tandis que le modèle garantit leur exécution et leur histoire.
Traiter les responsabilités financières
Une enveloppe commune demande les garanties détaillées dans le crédit acheteur multi-entités. Lorsque plusieurs commandes sont regroupées, la facturation consolidée B2B aide à préserver taxes, vendeurs et preuves.
La chaîne reste cohérente si le compte résout le contexte, si le crédit réserve l’exposition et si la facture conserve l’entité redevable. Aucun de ces modules ne doit reconstruire sa propre version de la hiérarchie.
Conclusion : conserver le contexte d’achat
Un compte B2B fiable ne reproduit pas simplement l’organigramme du client. Il sépare identité juridique, lieu, unité d’achat, personne et relation, puis attribue à chacun les responsabilités qu’il exerce réellement.
Les règles d’héritage réduisent la duplication, tandis que les exceptions locales et les rattachements multiples préservent la réalité opérationnelle. La transaction photographie ensuite entité, adresse, tarif, budget et autorité pour résister aux changements futurs.
La qualité du modèle se voit lors d’une fermeture de site, d’un transfert d’acheteur ou d’une fusion : les nouvelles opérations suivent la décision sans rendre les anciennes incompréhensibles.
Un accompagnement expert peut vous aider à structurer cette architecture dans votre projet de création de marketplace, puis à la raccorder aux tarifs, à l’ERP et à la facturation avec des preuves de non-régression.
