Un acheteur trouve le bon produit sur la marketplace et veut commander. Pourtant, son entreprise exige un centre de coût, deux validations, une adresse autorisée, un numéro d’engagement et une facture rapprochable. Le problème finit dans un email, puis le service achat ressaisit tout dans l’ERP.
Le signal faible apparaît avant l’échec commercial : les paniers sauvegardés ne deviennent pas des commandes, les comptes partagent des identifiants et les équipes demandent des devis hors plateforme. Avant que l’adoption ne baisse, le risque business est déjà sorti du processus officiel.
Le vrai enjeu consiste à traiter l’achat comme un workflow contractuel, budgétaire et comptable, pas comme un checkout B2C enrichi. Vous allez comprendre comment modéliser organisations, droits, prix, validations, commandes, factures et intégrations sans perdre la liquidité de l’offre.
Une création de marketplace opérateur doit articuler produit et SI dès le cadrage. La page dédiée à la marketplace B2B opérateur présente les spécificités nécessaires à une adoption réelle par les équipes achats.
Reconnaître une marketplace hors processus d’achat
La friction ne se limite pas au taux d’abandon. Elle apparaît quand l’acheteur doit exporter le panier, demander manuellement une validation, créer le fournisseur après la commande ou corriger une facture qui ne reprend pas les références internes.
Le diagnostic suit vingt achats de l’intention au paiement : recherche, contrat, devis, demande d’achat, approbation, engagement, commande, réception, facture et règlement. Chaque ressaisie et chaque attente reçoit un owner et un coût.
Le second symptôme concerne la conformité. Une commande peut être livrée et pourtant rester hors politique parce que le vendeur, la catégorie, le budget ou la séparation des rôles n’ont jamais été contrôlés.
Si plus de 30 % des commandes pilotes nécessitent un traitement hors plateforme, alors l’équipe gèle l’acquisition payante. La priorité devient couverture du parcours procurement, pas ajout de vendeurs ou de fonctionnalités de découverte.
Cartographier le processus procurement cible
Distinguer demande, engagement et commande
La demande d’achat exprime un besoin ; l’approbation autorise une dépense ; l’engagement réserve le budget ; le bon de commande formalise l’achat auprès du vendeur. Ces objets ont des identifiants, états et autorités distincts.
La marketplace peut orchestrer tout le workflow ou déléguer certaines étapes à la suite achats. Le contrat d’intégration définit alors qui crée, valide, annule et corrige chaque objet sans double source de vérité.
La chronologie sépare instant utilisateur, validation, comptabilisation et transmission au vendeur. Elle permet de mesurer l’attente réelle, de rejouer une panne et de prouver quel montant était autorisé au moment précis de l’engagement.
Segmenter plutôt qu’uniformiser
Un achat catalogue sous mille euros peut suivre une validation simple ; un matériel réglementé exige habilitation ; un service implique devis, jalons et réception. Le processus dépend de catégorie, montant, entité, pays et risque fournisseur.
Une matrice de scénarios couvre achats récurrents, urgence, multi-vendeur, abonnement, livraison partielle, retour, litige et avoir. Le MVP choisit les segments fréquents et fermables de bout en bout.
Chaque scénario indique son taux, sa valeur et son coût d’exception. Cette mesure évite qu’un cas spectaculaire mais rare impose un workflow complexe à la majorité des commandes simples et contractuellement conformes.
Modéliser organisations, comptes et droits
Construire une hiérarchie d’entreprise
Le compte B2B contient groupe, entités légales, établissements, équipes, centres de coût, adresses, budgets et contrats. Un utilisateur peut acheter pour plusieurs périmètres avec des droits différents et une délégation datée.
Les rôles dépassent acheteur et administrateur : demandeur, approbateur, réceptionnaire, comptable, category manager, auditeur et gestionnaire fournisseur. La séparation des tâches interdit certaines combinaisons sur une même commande.
La hiérarchie n’est pas un simple arbre : une équipe peut partager un budget avec une entité et recevoir une politique d’un groupe. Le moteur résout ces héritages avec priorité et motif visibles pour l’administrateur.
Fédérer identité et cycle de vie
Le SSO authentifie ; le provisioning fournit organisation, groupes et attributs ; l’IAM décide des permissions. Une désactivation doit fermer sessions et délégations sans supprimer les preuves liées aux achats historiques.
Chaque action sensible conserve acteur, rôle, organisation, politique appliquée et décision. La traçabilité permet de comprendre pourquoi un panier a été approuvé, pas seulement qui a cliqué.
Les comptes invités, externes et temporaires suivent un cycle spécifique avec sponsor, expiration et périmètre. Une synchronisation défaillante bloque les nouvelles dépenses sensibles sans retirer rétroactivement la visibilité nécessaire à la réception.
Servir le bon catalogue et le bon contrat
Le catalogue visible dépend de l’organisation, du pays, des habilitations, des catégories autorisées et des accords négociés. Une même offre peut avoir prix, minimum, unité, délai et service différents selon le compte.
Le contrat versionné relie vendeur, acheteur, assortiment, tarif, palier, remise, SLA, fiscalité, incoterm, durée et condition de renouvellement. La commande conserve la version exacte appliquée pour rester explicable après une renégociation.
Les punchout et catalogues hébergés répondent à des architectures différentes. Le choix dépend de la source de recherche, du panier, de la validation et de la commande, pas d’une préférence technique isolée.
Paradoxalement, masquer une offre peut améliorer la conversion utile lorsqu’elle n’est pas achetable sous le contrat du compte. Si le prix négocié arrive après le checkout ou exige un devis systématique, alors le parcours annonce demande de prix, délai et engagement sans simuler une disponibilité inexistante.
Orchestrer panier, budget et validation
Enrichir le panier procurement
Le panier porte entité, centre de coût, projet, adresse autorisée, demandeur, justification, budget et pièces. Chaque ligne conserve vendeur, contrat, unité, quantité, date et catégorie pour appliquer les politiques.
Un panier multi-vendeur peut devenir plusieurs commandes tout en restant une demande d’achat unique. Taxes, frais, minimums et délais sont recalculés avant approbation afin que le décideur voie le montant réellement engagé.
Une modification après validation crée une nouvelle version et réévalue seulement les règles concernées. Changer une adresse ou une quantité ne doit ni contourner l’approbateur requis ni recommencer inutilement toute la chaîne.
Exécuter une politique explicable
Le moteur de règles choisit approbateurs selon montant, catégorie, entité, budget et risque. Il gère délégation, absence, escalade, rejet, modification et nouvelle approbation lorsque le prix ou le périmètre change.
En entrée figurent panier, utilisateur, organisation, contrat et budget ; en sortie, décision, chaîne, motif et expiration. Chaque règle possède owner, version, seuil, monitoring et rollback vers la politique précédente.
Le moteur journalise règles évaluées, données utilisées et dérogation éventuelle. Un back-office permet de simuler un panier contre la prochaine version avant activation, puis de comparer volume bloqué et temps d’approbation.
Gérer commandes, réceptions et exceptions
La commande possède un état agrégé, tandis que chaque ligne suit acceptation, préparation, expédition, livraison, réception, retour et annulation. Les modifications après approbation sont bornées par contrat et montant.
Le vendeur confirme prix, quantité et date dans un SLA. Une confirmation partielle propose acceptation, remplacement ou annulation selon la politique acheteur, sans transformer silencieusement le bon de commande.
La réception peut être quantitative, qualitative ou liée à un jalon de service. L’acheteur sépare reçu, accepté et facturable, puis documente écart, litige et retour avec les références d’origine.
Si un vendeur ne confirme pas dans le délai, alors la marketplace escalade ou réalloue selon catégorie. Elle n’invente jamais un statut « en cours » indéfini qui immobilise budget et cache le risque de service.
Réconcilier factures, avoirs et paiements
Réaliser le rapprochement à trois voies
Le rapprochement compare bon de commande, réception et facture par ligne, quantité, prix, taxe et devise. Les tolérances varient selon catégorie et organisation ; tout écart crée une exception attribuée.
La facture conserve vendeur légal, acheteur légal, références, dates, TVA, ventilation et pièces. Les avoirs pointent factures et lignes concernées afin d’éviter une compensation globale impossible à auditer.
Séparer paiement et orchestration marketplace
La carte, le virement, le crédit fournisseur et le paiement différé répondent à des responsabilités différentes. La marketplace doit distinguer encaissement PSP, mandat, facture directe et simple transmission procurement.
Le ledger conserve montants attendus, capturés, remboursés, versés et contestés. Une réconciliation quotidienne relie commande, facture, transaction et versement sans supposer que le statut PSP clôt le traitement comptable.
Intégrer ERP, P2P et suites achats
L’architecture choisit le système maître par objet : identité, organisation, fournisseur, catalogue, contrat, budget, demande, commande, réception et facture. La marketplace orchestre l’expérience sans devenir automatiquement référentiel de tout.
Les APIs et événements transportent identifiant stable, version, statut, instant et corrélation. L’idempotence protège création de commande et réception ; retry, backoff, queue et dead-letter queue traitent les pannes sans doublon.
Le mapping couvre codes société, taxes, unités, devises, catégories, centres de coût et adresses. Les rejets fonctionnels rejoignent une file métier avec owner, délai et action ; ils ne disparaissent pas dans les logs techniques.
Le monitoring suit fraîcheur, complétude, latence, erreurs, ordre et réconciliation. Un mode dégradé autorise consultation ou panier sans créer un engagement lorsque l’ERP ou la suite achats ne peut confirmer le budget.
Contractualiser l’exécution des vendeurs
L’onboarding valide identité, entité légale, fiscalité, coordonnées, catégories, assurance, sécurité et capacité d’intégration. Un vendeur approuvé commercialement n’est pas encore prêt pour un processus procurement exigeant.
Le contrat opérationnel définit disponibilité, confirmation, expédition, facture, avoir, données, support et preuve. Les SLA correspondent aux étapes mesurables et indiquent conséquences, période de cure et escalade.
Les vendeurs peuvent utiliser portail, API, EDI ou opérateur. Chaque canal doit produire les mêmes états métier ; le portail n’est pas une voie simplifiée qui contourne les contrôles nécessaires au rapprochement.
La scorecard sépare qualité catalogue, service, conformité documentaire et litiges. Une baisse déclenche remédiation, limitation ou suspension proportionnée, avec population de commandes et condition de retour.
Piloter conformité, liquidité et adoption
Le cockpit suit recherche utile, disponibilité contractuelle, paniers, demandes, temps d’approbation, commandes sans intervention, confirmations, réceptions, rapprochements et paiements. Chaque fuite est reliée à une étape du processus.
La liquidité B2B exige plus qu’offre et demande : elle suppose prix applicable, vendeur conforme, budget, autorité, livraison et facture acceptables. Le taux de transactions procure-to-pay complètes devient un KPI central.
Le coût-to-serve additionne support acheteur, support vendeur, exceptions, intégrations et finance. Un volume élevé de commandes manuelles peut donner une illusion d’adoption tout en rendant le modèle non scalable.
La revue mensuelle priorise d’abord les ruptures qui touchent achats répétés et valeur business, ensuite les intégrations, puis l’extension de catalogue. Ajouter des vendeurs n’est utile que si les acheteurs peuvent réellement commander.
Déployer un cas concret de procurement
Borner un achat de fournitures industrielles
Cas concret : un groupe possède cinq entités, 1 200 demandeurs et deux ERP. Le pilote couvre trois catégories récurrentes, quarante vendeurs déjà référencés et des achats sous 5 000 euros.
Chaque compte reçoit SSO, centre de coût, adresse et chaîne d’approbation. Le catalogue applique les contrats existants ; la suite achats conserve demande et engagement tandis que la marketplace crée le panier et orchestre les vendeurs.
Ouvrir par preuve de clôture
D’abord, vingt équipes passent deux cycles de commande, réception et facture. Les exceptions sont classées entre donnée, politique, vendeur et intégration, avec un seuil de 85 % de rapprochement sans ressaisie.
Si ce seuil tient quatre semaines, que le délai d’approbation baisse et qu’aucune séparation de rôle ne dérive, alors le périmètre s’étend. Sinon, l’équipe corrige le processus avant d’ouvrir de nouvelles catégories.
Pour qui construire ce socle B2B
Le socle convient aux marketplaces de fournitures, équipements, services standardisés et achats indirects qui ciblent des entreprises structurées. Il devient critique lorsque contrats, budgets et factures conditionnent chaque transaction.
Une plateforme adressant des TPE peut commencer avec comptes multi-utilisateurs, devis, bon de commande et facture. La complexité supplémentaire suit les acheteurs réellement ciblés, pas un modèle B2B abstrait.
Il faut différer le multi-ERP si un premier segment peut être fermé sur un seul système. Le MVP cherche une boucle procure-to-pay complète plutôt qu’une couverture horizontale de toutes les entreprises.
Il faut refuser un checkout qui demande à l’acheteur de contourner sa politique. La conversion immédiate ne compense pas le risque d’audit, la ressaisie ni l’impossibilité de rapprocher la facture.
Éviter les erreurs fréquentes d’une marketplace B2B
Copier le B2C : ajouter un champ société ne crée ni organisation, ni contrat, ni délégation, ni validation. Le modèle doit partir des objets procurement.
Intégrer trop tard : l’ERP découvert après le checkout impose identifiants et états incompatibles. Les systèmes maîtres doivent être choisis avant le modèle de commande.
Confondre commande et paiement : un achat approuvé peut être facturé plus tard, tandis qu’une carte peut exiger une politique. Les deux cycles restent reliés sans être fusionnés.
Mesurer seulement le GMV : une transaction ressaisie et non rapprochée déplace le coût vers achats et finance. Adoption complète et coût-to-serve doivent accompagner le volume.
Plan d’action en douze semaines
Semaines 1 à 4 : cadrer le processus
Suivez vingt achats réels, cartographiez objets, rôles, politiques et systèmes, puis choisissez une catégorie, une entité et des vendeurs déjà conformes. Écrivez le contrat de succès procure-to-pay.
Modélisez organisation, rôles, contrat, panier, demande, commande, réception et facture. Fermez explicitement les décisions de source de vérité avant de concevoir les écrans détaillés.
Semaines 5 à 8 : intégrer et tester
Connectez identité, catalogue, demande et commande avec idempotence, réconciliation et files d’exception. Testez prix changé, budget refusé, approbateur absent, livraison partielle, avoir et facture divergente.
Les vendeurs pilotes exécutent le même protocole via portail ou API. Achats, finance et support valident les sorties, les délais et les preuves d’audit.
Semaines 9 à 12 : ouvrir puis apprendre
Lancez vingt équipes, mesurez complétion, délai, exceptions et rapprochement, puis comparez au processus antérieur. Les contournements deviennent des incidents de produit, pas des habitudes tolérées.
Étendez une dimension à la fois : entité, catégorie, vendeur ou méthode de paiement. Chaque extension conserve témoin, seuil de succès et rollback de politique.
- D’abord, choisir une boucle procure-to-pay fermable avec contrats, rôles et systèmes maîtres explicitement nommés.
- Ensuite, modéliser organisation, validation, commande, réception et facture avant de généraliser le catalogue à tous les acheteurs.
- Puis, intégrer par événements idempotents et traiter chaque rejet métier dans une file attribuée.
- À faire enfin : ouvrir par cohorte, mesurer le rapprochement sans ressaisie et étendre seulement le parcours réellement adopté.
Guides complémentaires : catalogue et intégrations B2B
Le processus procurement dépend d’un modèle catalogue contractuel et d’intégrations gouvernées. Ces ressources approfondissent les deux fondations techniques et métier qui rendent l’achat exécutable et auditable.
Gouverner l’offre et les vendeurs
Le cadre KYC/KYB d’une marketplace structure habilitations, preuves et reprises manuelles. Le contrôle du crédit acheteur B2B relie encours, plafonds, commandes et recouvrement.
Le socle B2B ajoute organisation acheteuse, contrat négocié et politique de dépense. La même fiche produit devient ainsi une offre différente selon qui achète, pour quelle entité et avec quelle autorité.
Relier le produit au système d’information
La méthode de workflow marketplace de bout en bout relie devis, preuve, paiement et litige. La clôture financière marketplace rapproche ensuite commandes, PSP, commissions, remboursements et reversements.
Le processus procurement utilise ces contrats sans déléguer l’expérience au SI. La plateforme explique l’état courant et la prochaine action, même lorsque l’autorité de décision reste dans l’ERP.
Une matrice de responsabilité relie enfin incident d’identité, rejet budgétaire, commande bloquée et facture divergente au bon owner. L’acheteur reçoit une explication métier tandis que les équipes techniques conservent corrélation, payload et possibilité de rejeu.
- À faire : fermer une commande, une réception et une facture réconciliées avant d’élargir catégories ou entreprises.
- À différer : les workflows rares tant que prix, droits, budgets et exceptions fréquentes ne sont pas fiables.
- À refuser : toute transaction qui contourne une approbation, duplique un engagement ou laisse la finance sans référence exploitable.
Conclusion : acheter sans contourner le procurement
Une marketplace B2B devient utile lorsqu’elle réduit le travail d’achat sans déplacer validation, ressaisie et rapprochement vers des équipes financières ou opérationnelles invisibles dans le checkout.
Organisations, contrats, budgets, commandes, réceptions et factures forment un seul parcours gouverné. Les intégrations distribuent les responsabilités, tandis que la plateforme conserve une expérience et une preuve continues.
La liquidité progresse alors avec la conformité : davantage d’offres deviennent réellement achetables, davantage de vendeurs exécutent sans exception et davantage de commandes se ferment sans intervention.
Pour concevoir ce socle et l’intégrer au SI, l’expertise Dawap en création de marketplace aligne votre plateforme B2B sur les processus achats réels, du premier compte jusqu’à la facture rapprochée.
