Une marketplace B2B d’e-procurement ne se résume pas à vendre en ligne à des entreprises. Elle doit représenter des organisations, des droits, des contrats, des budgets, des validations et des preuves comptables qui n’existent pas dans un tunnel B2C standard.
La page dédiée à la création d’une marketplace B2B opérateur pose ce cadre. L’architecture devient crédible lorsqu’elle suit la transaction réelle, depuis l’habilitation de l’acheteur jusqu’au rapprochement de la facture, sans obliger les équipes à reconstruire le contexte dans des e-mails.
Ce guide aide à cadrer les objets métier, les frontières avec l’ERP et le système achats, le rôle des vendeurs et un MVP qui prouve la valeur. Il donne aussi les tests indispensables pour éviter une plateforme séduisante en démonstration mais inutilisable dès qu’une entreprise possède plusieurs établissements ou plusieurs niveaux d’approbation.
L’enjeu n’est pas de reproduire tout le système d’information dans la marketplace. Il consiste à décider quelles règles doivent être visibles au moment de l’achat, quelles données restent maîtres ailleurs et quelles exceptions nécessitent une intervention humaine traçable.
Distinguer marketplace B2B et boutique B2C enrichie
Dans un achat B2C, l’utilisateur décide généralement pour lui-même et paie immédiatement. Dans l’e-procurement, le demandeur peut préparer un panier qu’un responsable valide, sur un catalogue négocié, avec un centre de coût, une adresse autorisée et un paiement différé. La personne connectée n’est donc qu’un acteur d’une transaction portée par une organisation.
Ajouter un champ « entreprise » au compte client ne couvre ni les délégations, ni les plafonds, ni les contrats, ni la séparation des rôles. La première décision d’architecture est de traiter l’organisation comme un objet métier de premier rang, avec son cycle de vie, ses établissements et ses politiques.
Cette différence modifie également le rôle et les informations accessibles à l’équipe support. Une commande bloquée peut être correcte techniquement mais contraire à une règle d’achat. Le back-office doit expliquer qui a bloqué, pour quelle règle, quelle action est attendue et si une dérogation est possible.
Choisir les transactions que la plateforme doit porter
Avant de choisir une solution, l’équipe décrit les transactions cibles : achat sur catalogue, demande de devis, appel d’offres simplifié, réapprovisionnement récurrent, réservation de service ou commande issue d’un punch-out. Chaque modèle impose des statuts, des preuves et des délais différents.
Le périmètre initial doit préciser la valeur moyenne, la fréquence, le nombre de lignes, les catégories, les types de vendeurs et le niveau de négociation. Un achat récurrent de fournitures standardisées n’a pas le même besoin qu’un équipement technique configuré après plusieurs échanges.
L’équipe choisit ensuite précisément l’endroit où naît l’engagement commercial et financier. Le panier peut devenir une demande interne, une commande ferme ou un brouillon de devis. Ce point détermine les intégrations, les responsabilités et l’expérience ; il ne peut pas rester implicite jusqu’aux tests.
Modéliser organisations, établissements et utilisateurs
Le modèle minimal comprend une organisation juridique, un ou plusieurs établissements, des adresses de livraison et de facturation, des utilisateurs et des rôles. Les identifiants provenant du CRM, de l’ERP ou de l’outil achats sont conservés pour éviter les rapprochements par nom libre.
Les rôles séparent au moins demandeur, approbateur, acheteur, administrateur client et lecteur financier. Un utilisateur peut cumuler des rôles ou agir sur plusieurs entités, mais le système doit toujours évaluer ses droits dans le contexte de la commande concernée.
Le cycle d’entrée et de sortie est aussi important que la connexion. Qui crée l’organisation, qui vérifie l’identité, comment un administrateur invite ses collègues et que deviennent les demandes d’un salarié parti ? L’authentification protège l’accès ; la gouvernance des habilitations protège le processus.
Construire catalogues privés et assortiments contractuels
Un catalogue B2B est l’intersection entre une offre vendeur, un contrat acheteur, une période, un territoire et parfois une disponibilité logistique. Deux utilisateurs connectés peuvent donc voir des assortiments différents sans que l’un des deux résultats soit erroné.
Le modèle doit distinguer le produit de référence, l’offre commerciale et l’assortiment autorisé. Cette séparation permet de partager les données techniques tout en adaptant prix, conditionnement, quantité minimale, délai et vendeur selon le compte.
Les règles de visibilité doivent rester explicables par organisation, contrat, période et utilisateur. Le support doit pouvoir répondre : « cette référence est absente parce que le contrat C-184 n’inclut pas cette famille depuis telle date », et non « le moteur ne la remonte pas ». Un outil d’aperçu par organisation simplifie fortement la recette et le run.
Rendre prix et conditions commerciales explicables
Le prix peut dépendre d’un tarif de base, d’une remise par compte, d’un palier de quantité, d’un contrat, d’un lieu de livraison et d’une période. La plateforme doit conserver la version de règle utilisée au moment de la commande afin qu’une modification ultérieure ne rende pas l’historique inexplicable.
Les frais de port, minimums de commande, franco, taxes et unités de vente sont présentés avant validation. Dans un contexte multi-vendeur, il faut indiquer si ces conditions s’appliquent au panier global, à chaque vendeur ou à chaque expédition.
Une fonction de simulation est plus utile qu’un grand moteur opaque. Elle prend une organisation, un produit, une quantité et une date, puis retourne le prix et les règles appliquées. Cette capacité sert aux tests, au support et aux négociations commerciales.
Concevoir paniers, validations et budgets
Le workflow part d’une matrice de décision : montant, catégorie, centre de coût, établissement, exception de prix ou fournisseur. Les niveaux d’approbation sont configurés par politique, avec une version datée. Une commande suit la règle valable au moment de sa soumission, même si la politique change le lendemain.
Les approbateurs voient le contexte nécessaire : demandeur, besoin, lignes, budget, fournisseur, écarts et justificatifs. Une notification sans écran de décision complet entraîne des validations aveugles ou des conversations parallèles qui échappent à la plateforme.
Le budget peut être informatif, bloquant ou géré dans un système externe. Cette nature doit être explicite pour chaque étape et chaque population d’acheteurs. Une synchronisation quotidienne n’autorise pas la même promesse qu’un contrôle temps réel ; l’interface doit afficher la fraîcheur de la donnée et le comportement en cas d’indisponibilité.
Intégrer demande de prix, devis et négociation
Le devis doit être un objet versionné, pas une pièce jointe isolée. Il relie une demande, un acheteur, un ou plusieurs vendeurs, des lignes, des quantités, des conditions, une date d’expiration et une décision. Chaque nouvelle proposition conserve l’historique complet sans écraser l’offre précédente ni ses validations.
L’équipe décide quand un devis peut devenir commande : acceptation simple, validation interne supplémentaire, signature, acompte ou création préalable d’un compte fournisseur. Le passage doit être idempotent afin qu’un double clic ou une reprise technique ne crée pas deux commandes.
Les échanges libres restent possibles, mais les décisions structurantes sont capturées : prix accepté, délai, incoterm, quantité et motif de refus. La plateforme crée ainsi une donnée exploitable sans prétendre remplacer toute la relation commerciale.
Orchestrer commande, livraison et facture
Une commande multi-vendeur est souvent un agrégat de plusieurs ordres juridiques et opérationnels distincts. La plateforme conserve un identifiant acheteur commun tout en créant les sous-commandes nécessaires au traitement vendeur, aux expéditions et aux factures. L’interface montre clairement les articles, les dates et les documents qui seront traités séparément.
Les statuts sont traduits dans un vocabulaire commun sans perdre le statut source. Une livraison partielle, une substitution ou une rupture après validation sont des scénarios métier, pas des erreurs de bord. Leur traitement, leur délai et le pouvoir de décision doivent être conçus.
La facture est rapprochée de la commande et, lorsque le modèle l’exige, de la réception. Les écarts de quantité, prix ou taxe ouvrent une exception assignée. La promesse d’e-procurement se mesure ici : moins de ressaisie et une preuve plus rapide, pas seulement un panier plus agréable.
Définir le contrat avec ERP, PIM et système achats
Une matrice de responsabilité indique la source maître pour organisations, utilisateurs, produits, offres, prix, budgets, commandes, réceptions et factures. Pour chaque donnée, elle précise direction, fréquence, identifiant, règle de conflit et comportement en cas d’échec.
Les intégrations SI de la marketplace opérateur doivent transporter des événements métier, pas uniquement des fichiers. Une commande acceptée, un budget refusé ou une réception partielle ont une signification que les systèmes doivent partager.
Le mode dégradé est cadré avant toute mise en ligne et testé avec les utilisateurs concernés. Peut-on créer une demande si l’ERP ne répond pas pendant plusieurs minutes ? Peut-on approuver avec un budget dont la fraîcheur dépasse le seuil accepté ? Quelle file reçoit les messages en attente et qui surveille leur ancienneté ? La réponse dépend du risque métier ; elle ne doit pas être décidée automatiquement par un délai technique dépassé.
Choisir un MVP e-procurement qui prouve le modèle
Un MVP pertinent retient une catégorie, quelques organisations pilotes, un nombre limité de vendeurs et un workflow d’approbation réel. Il inclut au moins un catalogue privé, un tarif contractuel, une exception, une commande transmise et une preuve exploitable côté finance.
Il n’a pas besoin de couvrir tous les pays, toutes les devises ou toutes les familles. Il doit en revanche aller jusqu’au bout d’une transaction, y compris annulation, réception ou facture selon la promesse. Un MVP arrêté au paiement ou à l’émission d’un e-mail ne prouve pas l’e-procurement.
Les pilotes sont choisis pour apprendre : une organisation simple, une organisation multi-sites et un compte avec validation plus exigeante. Les vendeurs incluent un acteur bien intégré et un acteur plus manuel, afin de mesurer la réalité du support et de l’onboarding.
Tester les scénarios et les exceptions critiques
La recette suit des scénarios métier nommés : demande sous plafond, demande au-dessus du plafond, approbateur absent, catalogue expiré, prix modifié, budget indisponible, vendeur refusant une ligne, livraison partielle, facture en écart et utilisateur désactivé.
Chaque scénario vérifie l’écran, la donnée, les événements, les notifications et la capacité du support à comprendre. Un test est incomplet si le front affiche « succès » alors que la commande n’a pas été créée dans le système cible, ou si la reprise produit un doublon.
Les preuves sont conservées avec des identifiants reconstituables entre chaque étape et chaque système. Elles servent à la décision go/no-go, à la formation et au diagnostic des premiers incidents. La sécurité complète cette recette avec séparation des organisations, contrôle des accès indirects, journalisation des actions sensibles et révocation des habilitations.
Déployer par vagues sans figer le futur
La première vague stabilise le modèle organisationnel et une transaction complète. La deuxième ajoute des variations déjà prouvées utiles : autres politiques d’approbation, punch-out, devis ou nouveaux vendeurs. La troisième industrialise international, analytique, automatisation financière et self-service avancé.
Chaque vague possède des seuils d’adoption, de taux de commande saine, de délai d’approbation, d’écarts et de charge support. L’ouverture suivante dépend directement de ces signaux et des causes encore non résolues. Une date commerciale peut rester une contrainte, mais elle ne doit pas rendre invisibles les risques connus.
Cette progression préserve l’architecture : objets métier stables, règles versionnées, intégrations observables et exceptions explicites. Elle évite aussi de construire très tôt une flexibilité hypothétique que les premiers acheteurs n’utiliseront jamais.
Conclusion : concevoir depuis l’acte d’achat réel
La bonne architecture d’une marketplace B2B commence par les responsabilités de l’achat, pas par la liste des écrans. Elle sait qui demande, au nom de quelle organisation, sur quel contrat, avec quelle autorisation et quelle preuve financière.
Organisations, catalogues privés, prix, workflows, devis et commandes doivent former une chaîne cohérente. L’ERP, le PIM et le système achats restent maîtres là où ils sont légitimes, tandis que la marketplace orchestre l’expérience et rend les exceptions opérables.
Un MVP devient convaincant lorsqu’une transaction réelle traverse toute cette chaîne et reste explicable après coup. C’est cette preuve qui permet de décider quelles fonctions industrialiser et quelles complexités laisser volontairement hors périmètre.
Dawap accompagne le cadrage et la réalisation d’une création de marketplace B2B avec modèles métier, intégrations, scénarios de recette et trajectoire de déploiement reliés à la valeur d’achat.
