Un conducteur de travaux commande 180 mètres carrés d’isolant, des fixations et un pare-vapeur indiqués compatibles. Le seller expédie 75 colis, mais les fixations ne conviennent pas au support, les unités mélangent mètre carré et panneau, et le camion ne peut pas accéder au chantier à l’heure promise.
Le problème n’est pas seulement un catalogue incomplet. Dans le bâtiment, sélection technique, quantité, prix négocié, disponibilité et logistique forment une même décision. Les séparer en fiches produit, tableur de devis et téléphone transport produit une commande exacte en apparence mais inexécutable.
Le vrai enjeu d’une marketplace B2B bâtiment dans une marketplace opérateur est de transformer un besoin chantier en combinaison compatible, chiffrée et livrable. Contre-intuitivement, ouvrir rapidement des millions de références peut réduire le choix réellement commandable.
Vous allez comprendre comment relier comptes, catalogue technique, compatibilités, quantités, tarifs, devis, stock et livraison chantier, puis conserver chaque preuve. Les calculs restent versionnés, les commandes idempotentes, et monitoring, réconciliation, canary et rollback protègent marge comme exécution.
Définir la mission métier
Vendre une combinaison exécutable
L’acheteur ne cherche pas seulement une référence : il doit résoudre usage, support, performance, quantité, délai et accès. La marketplace précise jusqu’où elle assiste et ce qui reste sous responsabilité du professionnel. Une recommandation ne devient pas une étude technique sans cadre.
La promesse porte produit conforme aux critères déclarés, conditionnement exact, prix applicable et livraison réalisable. Les incertitudes sont visibles. Un seller ne confirme pas une commande dont une contrainte critique reste « à voir avec le chantier ».
Séparer information, validation et engagement
Une fiche informe, un configurateur vérifie des règles et un devis engage selon conditions. Les trois affichent leur niveau de preuve. Une compatibilité inférée depuis des mots proches ne doit pas être présentée comme validée par le fabricant.
Le snapshot de commande conserve données fournies par l’acheteur, règles utilisées et documents. Une modification ultérieure du chantier produit une nouvelle vérification. L’historique n’est pas recalculé avec le catalogue courant.
Modéliser comptes et rôles
Distinguer groupe, société et chantier
Un utilisateur agit pour une entité facturée, un chantier livré et parfois un groupe négociateur. Les adresses et budgets ne sont pas interchangeables. Le contexte de commande cite les trois identités et leurs délégations.
Un même acheteur peut commander pour plusieurs chantiers. Il choisit explicitement celui qui détermine disponibilité, taxes, tarif et logistique. Le système ne déduit pas le compte depuis l’email ou la dernière commande.
Gérer approbations et plafonds
Prescripteur, acheteur, valideur, réceptionnaire et finance ont des droits distincts. Les règles portent montant, catégorie, chantier et période. Une délégation expire et reste auditée.
Le devis peut nécessiter plusieurs approbations avant commande. Une révision de prix ou quantité réinitialise seulement les validations affectées selon policy. Les signatures ne sont pas copiées sur une nouvelle version silencieuse.
Structurer le catalogue technique
Définir familles et attributs
Dimension, matériau, classe, résistance, performance thermique, feu, environnement, unité et norme varient par famille. La taxonomie exige les propriétés nécessaires à la sélection. Un champ libre ne remplace pas une valeur normalisée avec unité.
Chaque attribut cite source, méthode, date et niveau de confiance. Les documents fabricants restent liés à la version produit. Une nouvelle fiche technique ne réécrit pas les commandes ayant utilisé l’ancienne.
Séparer produit canonique et offre
Le produit porte caractéristiques communes ; l’offre seller porte prix, stock, conditionnement, origine et service. Deux sellers peuvent vendre la même référence sous des packs différents. Le matching ne fusionne pas des variantes techniques proches.
Les identifiants fabricant, EAN et références internes aident mais ne prouvent pas seuls l’identité. Une collision rejoint la revue. Le catalogue montre les différences qui changent compatibilité, quantité ou logistique.
Une campagne qualité compare chaque mois les nouvelles offres à un échantillon fabricant et aux commandes corrigées par le support. Les attributs absents, unités incohérentes et faux rattachements deviennent des écarts par famille. Si une source dépasse 2 % d’erreurs critiques, alors ses publications automatiques passent en revue jusqu’à deux imports conformes.
Prouver les compatibilités
Modéliser contraintes et relations
Compatible_with, requires, excludes et alternative_to portent conditions, version et source. Une relation peut dépendre du support, de l’épaisseur, de l’exposition ou de la méthode de pose. Elle ne se réduit pas à un lien marketing.
Le moteur reçoit contexte et composants, puis renvoie valide, invalide ou indéterminé avec raisons. Indéterminé bloque l’engagement automatique ou demande une validation compétente. Il ne choisit pas une réponse optimiste pour préserver la conversion.
Conserver la preuve
Fabricant, document, règle métier ou avis expert peuvent fonder la relation. La preuve possède date et périmètre. Une équipe sait quand la revoir après changement de gamme ou de norme.
Scénario : une fixation convient au béton mais pas au support creux déclaré. Si le contexte contient support creux, alors l’offre est exclue et l’acheteur voit la raison. Une exception exige une nouvelle preuve, pas un simple override commercial.
Par exemple, un isolant peut respecter la performance thermique demandée tout en étant incompatible avec l’exposition au feu du projet. Le moteur doit évaluer les deux contraintes et retourner le facteur bloquant. Si une règle ou une preuve manque, alors le devis reste en validation experte plutôt que de publier une compatibilité partielle.
Calculer quantités et conditionnements
Convertir unités sans ambiguïté
Mètre, mètre carré, mètre cube, pièce, sac, palette et tonne exigent facteurs versionnés. L’acheteur saisit besoin et marge de chute ; le moteur retourne unités commandables et reliquat. Il n’affiche pas 12,4 colis impossibles.
Les arrondis suivent conditionnement et minimum seller. Le prix total se calcule sur la quantité facturée, tandis que l’interface montre quantité utile. Les conversions restent dans le devis et la commande.
Gérer rendements et pertes
Le rendement dépend parfois du support, de l’épaisseur ou de la pose. Le calcul cite hypothèses et intervalle. Une marge standard n’est pas appliquée à toutes les familles sans justification.
Si 180 mètres carrés demandent 54 panneaux plus 7 % de perte, alors le moteur arrondit au nombre de colis et explique le surplus. Le vendeur ne réduit pas la quantité au prochain pack inférieur pour afficher un meilleur prix.
Le calcul produit aussi poids, volume, palettes et capacité de stockage nécessaires. Ces sorties alimentent transport et chantier avant acceptation. Si le nombre de palettes dépasse la capacité déclarée du créneau, alors la proposition est divisée ou replanifiée ; elle ne conserve pas un prix de livraison devenu irréalisable.
Appliquer les tarifs B2B
Résoudre compte, chantier et volume
Grille groupe, exception société, contrat chantier, palier et promotion peuvent s’appliquer. La priorité est totale et versionnée. Le moteur conserve candidats et raison du gagnant ; il ne choisit pas le minimum par défaut.
Le contexte cite compte facturé, lieu livré, quantité, date et devise. Une cotation possède expiration. Le devis et la commande réutilisent son identifiant pour éviter des surfaces avec des prix différents.
Protéger marge et coûts logistiques
Prix matière, surcharge énergie, découpe, palette, grutage et livraison restent des composantes distinctes. Leur financement est explicite. Une remise commerciale ne supprime pas silencieusement un coût seller.
Si la marge passe sous le plancher après ajout d’un service chantier, alors l’offre est revue ou le service facturé. Finance voit contribution par composante. L’acheteur reçoit un total cohérent, pas des frais ajoutés après acceptation.
Une simulation compare contrat groupe, exception chantier, paliers et surcharge logistique sur vingt paniers témoins. Chaque collision montre gagnant, raison et impact de marge. Si deux grilles de même priorité s’appliquent, alors la cotation est bloquée et pricing tranche ; le moteur ne choisit ni la dernière importée ni la moins chère.
Orchestrer le devis
Versionner besoin et proposition
Le devis relie besoin, produits, quantités, prix, disponibilité, logistique, documents et hypothèses. Toute modification crée une version avec diff. Les commentaires ne changent pas une ligne engagée sans nouveau calcul.
Le statut distingue draft, submitted, seller_review, buyer_approval, accepted, expired et converted. Les actions autorisées et délais sont clairs. Un devis accepté reste consultable après conversion.
Fermer négociation et substitution
Le seller peut proposer alternative avec équivalence prouvée, nouveau prix et impact logistique. L’acheteur accepte explicitement. Une substitution ne se cache pas sous la même référence.
Les entrées du workflow sont besoin, cotations, preuves et rôles ; ses sorties sont versions, décisions, commande ou expiration. Commerce reste owner du processus, sellers de leurs offres et experts des validations. L’instrumentation suit délais, rejets, seuils, retries et dépendances.
La revue de devis compare également version acceptée, commande créée et documents envoyés. Un hash relie les trois états. Si une ligne, une quantité ou un service diverge, alors la conversion échoue et produit un diff actionnable. Le retry reprend la même version ; il ne reconstruit pas une proposition avec les données courantes.
Qualifier stock et sourcing
Distinguer disponible, approvisionnable et fabriqué
Stock physique, stock réservé, fournisseur, fabrication et transfert portent des promesses différentes. L’interface ne présente pas « en stock » un produit commandable auprès du fabricant sous trois semaines.
Chaque source indique quantité, nœud, version, cut-off et confiance. Les offres multi-sources calculent une allocation. Le seller reste responsable de la source confirmée dans la commande.
Réserver au bon grain
La réservation porte référence, lot éventuel, quantité, nœud, commande et expiration. Elle est atomique et idempotente. Une palette indivisible ne se réserve pas comme des unités libres sans règle.
Si le stock se répartit sur deux dépôts, alors la proposition expose deux expéditions ou attend une consolidation. Le système ne promet pas une livraison unique en cachant une allocation encore incertaine.
Le sourcing tient compte du lot, de la date de fabrication et des contraintes d’homogénéité lorsque la famille l’exige. Par exemple, une teinte provenant de deux lots peut créer un rendu visible. Si l’acheteur demande un lot unique, alors l’allocation réserve cette contrainte ou indique clairement qu’elle n’est pas garantie.
Promettre la livraison chantier
Qualifier accès et déchargement
Adresse, voie, tonnage, hauteur, créneau, grue, hayon, stockage et contact déterminent le service. Un questionnaire adaptatif ferme les contraintes avant devis. Les données critiques sont confirmées par le réceptionnaire.
Le transporteur reçoit ce qui lui est nécessaire. Un camion incompatible ne part pas parce que le code postal est desservi. Les restrictions produisent alternatives, frais et délais expliqués.
Orchestrer créneau et preuve
Le créneau combine préparation, transport, capacité chantier et autorisations. Il est réservé avant confirmation ou clairement indiqué provisoire. Une modification requiert accord selon impact.
Les entrées du moteur sont colis, nœud, accès, calendrier et services ; ses sorties sont options, prix, promesse et exclusions. Logistics reste owner de la règle, seller de la préparation et chantier de l’accès. Monitoring, runbook et rollback suivent chaque engagement.
Un appel de confirmation vérifie les chantiers à risque avant départ : contact, créneau, accès, grutage et zone de dépose. Le résultat est horodaté et partagé au transporteur. Si une contrainte change après confirmation, alors une nouvelle promesse et un coût explicite sont proposés ; le camion n’est pas envoyé pour constater l’impossibilité.
Conserver documents et conformité
Lier documents à la version
Fiches techniques, déclarations, certifications, consignes et preuves portent produit, pays, langue, validité et version. Une URL générique ne garantit pas le document utilisé au moment du devis.
Les acheteurs téléchargent le dossier associé aux lignes. Une expiration ou un retrait bloque les nouvelles commandes selon policy, sans effacer la preuve des commandes passées. Les spécialistes valident les exigences applicables.
Tracer validation et responsabilité
Le seller fournit, la marketplace contrôle forme et cohérence, l’expert valide les cas prévus. Les rôles sont annoncés. Un badge « conforme » ne mélange pas ces niveaux.
Si un document requis manque, alors l’offre devient inéligible pour le contexte concerné. Le vendeur reçoit le motif et la voie de correction. Un override possède approbation, preuve et expiration.
Le contrôle vérifie aussi que la référence et la version du document correspondent exactement à la ligne proposée. Une certification proche ou une langue non admise ne comble pas le manque. Le dossier de commande conserve les pièces réellement utilisées, leur date de validité et l’acteur ayant accepté une éventuelle exception.
Piloter qualité et économie
Mesurer décision et exécution
Le dashboard suit recherche résolue, incompatibilités, devis, délais, substitutions, ruptures, livraisons et retours par famille et seller. Il distingue échec catalogue, tarif, stock ou accès.
Le coût business inclut reprise chantier, transport supplémentaire, avoir, support et marge. Les priorités suivent impact. Chaque seuil possède owner, population et action.
Déployer en shadow et canary
Une nouvelle règle de compatibilité ou quantité calcule en shadow sur cas témoins. Le canary limite familles et comptes. Les équipes comparent devis, marge, colis et promesse.
Si plus de 0,5 % des configurations validées produisent une incompatibilité en revue ou si la marge tombe sous le plancher, alors le go est refusé. Le rollback restaure règles et versions sans réécrire les devis acceptés.
La revue mensuelle relie aussi retours, reprises chantier et avoirs à la règle qui avait validé la commande. Trois incidents semblables déclenchent un correctif de taxonomie ou de compatibilité avec owner et échéance. La nouvelle version repasse les cas historiques en shadow avant de retrouver une publication automatique.
Adapter la méthode et éviter les erreurs
Pour qui la marketplace B2B bâtiment convient
Elle convient lorsque les acteurs peuvent structurer références, preuves, quantités et capacités. Une offre très sur mesure peut commencer par demande qualifiée et devis assisté plutôt que checkout automatique.
Catalogue possède données ; experts compatibilités ; Pricing tarifs ; Logistics chantier ; sellers offres ; Operations devis. Chaque décision critique possède owner et preuve.
Erreurs fréquentes du B2B bâtiment
Copier les fiches fournisseurs, confondre produit et pack, ignorer unités, déclarer compatible par texte, afficher approvisionnable comme stock, promettre au code postal et substituer sans accord sont les erreurs majeures.
Une autre erreur consiste à automatiser trop tôt les cas indéterminés. Enfin, le devis ne corrige pas un catalogue incohérent. Sans versions et règles, il devient un tableur envoyé par email hors de la commande.
Plan d’action pour lancer le B2B bâtiment
Semaines 1 à 4 : besoin et catalogue
La première semaine sélectionne une famille et vingt chantiers types. La deuxième ferme attributs, unités, compatibilités, comptes, tarifs et preuves. Experts, sellers et acheteurs valident les contre-exemples. Une revue chiffre chaque erreur actuelle en reprise, transport, délai et marge, puis attribue les données manquantes à un owner avant toute automatisation.
Les semaines trois et quatre construisent produit canonique, calcul de quantité et cotation. Les tests couvrent conditionnement, support incompatible, document expiré, grille compte, substitution et multi-source. Chaque sortie cite raisons et versions.
La recette de phase assemble ensuite dix paniers complets avec leurs pièces, quantités, prix, marges, palettes et contraintes chantier. Acheteur, expert, finance et logistique signent chacun leur portion. Toute divergence reçoit une cause, une correction testée et une date ; aucune hypothèse orale ne passe dans le devis pilote, même lorsqu’un commercial connaît personnellement le client ou le chantier.
Semaines 5 à 8 : devis et logistique
La cinquième semaine connecte devis, stock et questionnaire chantier. La sixième exécute en shadow. L’instrumentation suit décisions, délais, marge, rejets, ruptures et promesses avec owners, seuils et runbooks.
Les semaines sept et huit ouvrent un canary, provoquent stock divergent, accès impossible et rollback. Le go exige configuration prouvée, quantité reproductible, prix engagé et livraison réalisable.
Le dossier final conserve taxonomie, relations, preuves, grilles, fixtures, devis, services et procédures. Toute ligne commandée répond à un besoin déclaré. Toute promesse logistique cite capacité et responsabilité.
- À faire d’abord : fermer famille, attributs, unités et compatibilités.
- À tester ensuite : quantité, grille, devis, accès chantier et rollback.
- À différer : les familles sans données ni preuves structurables.
- À refuser : toute compatibilité ou livraison affirmée sans contexte vérifié.
Ressources complémentaires pour l’opérateur
Structurer catalogue et pilotage
Le catalogue PIM marketplace pose taxonomie, attributs et preuves.
Les écrans du back-office opérateur rendent devis et exceptions exploitables.
Borner la première famille
Le MVP marketplace avant ouverture aide à limiter les dépendances.
La méthode pour ouvrir une première catégorie fournit une cohorte technique maîtrisée.
Conclusion : vendre une solution exécutable
Une marketplace bâtiment fiable transforme le besoin chantier en références compatibles, quantités commandables et promesse logistique.
Versions, preuves et devis empêchent la négociation de masquer une donnée technique incertaine.
Stock, accès, preuve et responsabilité restent liés jusqu’à la livraison réelle sur chantier, pas seulement au paiement, avec une prochaine action et un owner visibles pour chaque exception encore ouverte.
Dawap peut vous accompagner pour construire ce parcours B2B dans votre marketplace opérateur.
