Un acheteur professionnel connecté voit 92 euros sur la fiche, 88 dans le panier et 95 sur le devis PDF. Son groupe possède un contrat national, mais la filiale est rattachée à une grille régionale et la remise quantité commence à dix unités. Le support applique manuellement le prix le plus bas sans savoir quelle règle avait autorité.
Le problème ne vient pas seulement d’une formule. Identité du compte, contrat, quantité, date, devise et fiscalité ont été évalués à des moments différents. Chaque surface a reconstruit « son » prix, rendant la marge et l’engagement commercial impossibles à défendre.
Le vrai enjeu des grilles tarifaires B2B dans une marketplace opérateur est d’appliquer le bon contrat à la bonne entité et au bon instant, puis de conserver la décision. Contre-intuitivement, exposer toutes les remises dans une table unique augmente souvent les collisions.
Vous allez comprendre comment modéliser comptes, grilles, priorités, paliers, promotions, devis et commandes, puis relier calcul et marge. Le moteur retourne raisons et version ; les intégrations restent idempotentes, tandis que réconciliation et monitoring détectent prix divergents avant la facture.
Définir la décision de prix
Séparer prix candidat et prix engagé
Catalogue, seller, contrat, promotion et quantité fournissent des candidats. Le moteur choisit selon priorité et contexte. Le résultat contient montant, devise, taxes, composants, raisons et expiration. Il reste une cotation tant que le client ne l’a pas engagée.
Le devis accepté ou la commande confirmée crée un snapshot opposable. Les évolutions futures ne modifient pas ce prix. Une renégociation produit une nouvelle version liée à l’ancienne, jamais une réécriture silencieuse de la ligne.
Définir les grains monétaires
Produit, offre seller, compte, unité, ligne, panier et commande peuvent porter des règles. Le modèle indique le grain de chaque remise et son allocation. Un rabais panier n’est pas copié comme prix unitaire avant que sa répartition soit définie.
Les frais, livraison, taxes et services restent des composantes distinctes. Le total client se rapproche au centime. Finance peut expliquer marge et financement sans extraire une formule cachée du template checkout.
Stabiliser l’identité du compte
Distinguer utilisateur, société et groupe
Un utilisateur agit pour une entité acheteuse, éventuellement rattachée à un groupe ou une centrale. Le contrat vise un niveau précis. L’email professionnel ne suffit pas à déduire la société. Les délégations portent rôle, période et plafond.
Le contexte de prix contient compte facturé, compte livré, groupe, marché et canal. L’utilisateur choisit l’entité lorsqu’il en gère plusieurs. Le snapshot conserve ce choix afin qu’un changement de rattachement ne réécrive pas ses commandes.
Le référentiel refuse une cotation lorsque l’entité sélectionnée n’a plus de délégation valide ou lorsque facturation et livraison violent le contrat. Il renvoie le motif, la source et l’action attendue. Support peut corriger le rattachement sans dévoiler une autre grille ; commercial voit les comptes affectés avant expiration d’un mandat et prépare leur renouvellement.
Versionner les hiérarchies
Fusion, acquisition, filiale ou changement de centrale modifient les relations dans le temps. Le registre garde périodes et sources. Une grille héritée du groupe peut être remplacée par une exception locale selon policy.
Scénario : une filiale quitte son groupe le 1er juillet. Si un devis a été accepté en juin, alors son prix reste valable jusqu’à son expiration. Les nouvelles cotations de juillet utilisent la nouvelle hiérarchie et citent la version.
Modéliser les grilles et priorités
Décrire portée et validité
Une grille associe produit ou catégorie, compte ou segment, seller, marché, canal, période et devise. Elle peut définir prix fixe, coefficient ou remise. Les critères absents ne sont pas des jokers implicites ; leur sens est contractualisé.
Chaque ligne possède source, owner, approbation et version. Les chevauchements sont détectés avant publication. Une grille expirée ne continue pas parce qu’elle reste dans un cache. Le fallback choisi est visible.
Résoudre les collisions
La priorité peut suivre spécificité, niveau de compte, contrat nommé et date. Elle est totale ou retourne une ambiguïté. « Dernière ligne importée » n’est pas une règle de prix. Les exceptions portent motif et expiration.
Le moteur conserve tous les candidats et explique le gagnant. Si deux contrats de même priorité s’appliquent, alors la cotation rejoint une revue ou utilise le fallback validé. Elle ne choisit pas automatiquement le montant le plus bas au détriment de la marge.
Une analyse statique simule les intersections avant activation : même population, même produit, périodes superposées et priorités identiques. Elle produit collision, gagnant prévu et impact de marge. Pricing possède la règle, commercial tranche le contrat et plateforme empêche la publication ambiguë. Le manifeste cite chaque exception acceptée avec approbateur et date de disparition.
Déterminer l’éligibilité
Vérifier statut et conditions
Compte actif, contrat signé, limite de crédit, territoire, canal, catégorie et seller déterminent l’accès. Une grille visible n’est pas nécessairement utilisable. Les règles d’éligibilité sont évaluées avant le montant.
Les raisons d’exclusion sont actionnables : contrat expiré, entité incorrecte, quantité, devise ou produit hors périmètre. Le commercial et l’acheteur voient des messages adaptés sans exposer les prix d’un autre compte.
Gérer segments calculés
Volume annuel, secteur ou niveau de service peuvent former un segment. La définition cite fenêtre, source et cadence. Le changement de segment a une date d’effet ; il ne bascule pas au milieu d’une commande.
Si les données de segmentation sont périmées au-delà du SLA, alors le moteur conserve la dernière version sûre ou revient à la grille standard selon contrat. Il n’attribue pas le meilleur segment par optimisme. Le dashboard signale la dette.
Gérer quantité et paliers
Définir le volume mesuré
Le palier peut porter unité de ligne, colis, commande, période ou engagement contractuel. Quantité commandée et livrée ne sont pas interchangeables. Le contrat précise conversion d’unités, minimum, maximum et traitement des retours.
Les paliers sont continus ou par blocs avec limites explicites. L’interface montre le gain possible sans promettre un stock. Le moteur recalcule après modification de panier et conserve la version utilisée.
Éviter les effets de bord
Un palier qui rend dix unités moins chères que neuf est attendu ; un total qui baisse en ajoutant une unité peut l’être ou signaler une erreur. Des tests de monotonie et de marge vérifient chaque grille selon intention.
Par exemple, si le prix unitaire passe de 10 à 8 euros à cent unités, alors le panier affiche 800 euros et la règle. Si un arrondi produit 799,97 sans convention, le déploiement est bloqué. Finance valide le résiduel.
Versionner les prix négociés
Relier contrat et grille
Chaque grille négociée référence accord, parties, périmètre, date, approbation et condition de révision. Le document et la configuration partagent un identifiant. Une feuille reçue par email ne devient pas production sans validation.
Les clauses complexes sont soit modélisées, soit maintenues hors automatisation avec workflow. Le système ne simplifie pas une condition silencieusement. Le commercial voit les écarts entre contrat signé et moteur avant activation.
Déployer renouvellement et indexation
Une indexation crée une nouvelle version avec formule, source, date et arrondi. Elle est calculée en shadow sur produits et clients représentatifs. Le diff montre revenu, marge et commandes affectées.
Si l’augmentation dépasse le plafond contractuel de 3 %, alors la publication est refusée ou plafonnée selon clause validée. Les clients sont informés au bon délai. La version précédente reste disponible jusqu’à la date d’effet.
Le calendrier sépare calcul, approbation, notification et entrée en vigueur. Une tâche contrôle les sources d’indice, leur période et leur révision éventuelle. Si l’indice manque, le contrat dicte maintien, report ou source de secours ; le moteur n’extrapole pas. Le reporting compare prix attendu, prix activé et première facture pour chaque compte renouvelé.
Combiner promotions et remises
Définir cumul et exclusivité
Prix contractuel, remise quantité, coupon, campagne seller et subvention opérateur ont des règles de cumul. Une matrice indique ordre et exclusions. Le moteur ne choisit pas toujours le prix minimal si le contrat interdit une combinaison.
Chaque composante cite financeur et assiette. Le snapshot garde candidats refusés et raison. Le support explique pourquoi un code ne s’applique pas sans révéler le tarif d’autres comptes.
Protéger marge et budgets
Les garde-fous vérifient prix plancher, marge seller, subvention et budget campagne. Une exception commerciale requiert approbation et plafond. Elle expire. Le coût n’est pas déplacé vers un seller sans contrat.
Scénario : une promotion de 10 % se cumule avec un contrat déjà à marge minimale. Si la marge franchit le seuil zéro, alors le coupon est refusé pour cette ligne ou financé explicitement par l’opérateur. Le panier affiche le résultat cohérent.
Aligner devise et fiscalité
Conserver devise contractuelle
Une grille possède devise. La conversion cite source, paire, instant et politique. Le prix contractuel peut être affiché dans une autre devise mais la commande garde les deux valeurs. Un taux courant ne réécrit pas un devis accepté.
Les arrondis suivent devise et grain. Les écarts de change et subventions sont séparés. Finance distingue croissance de prix et effet monnaie dans le reporting.
Appliquer taxes après qualification
Compte, pays, produit et rôle déterminent la règle fiscale validée. Prix HT et TTC sont nommés. Le moteur de grille fournit l’assiette commerciale ; le moteur fiscal calcule la composante sans dupliquer les responsabilités.
Si le profil fiscal est incomplet, alors le checkout applique le fallback contractuel ou demande une correction. Il ne mélange pas HT sur la fiche et TTC sur la facture. Chaque snapshot relie versions tarifaire et fiscale.
La recette fiscale utilise des comptes témoins par pays, statut et adresse de livraison, avec produit, quantité et devise identiques. Elle compare fiche, panier, devis, commande et facture. Toute divergence indique la composante fautive plutôt qu’un total générique. Fiscal valide les règles, pricing l’assiette et finance les arrondis ; les cas non couverts restent bloqués jusqu’à qualification.
Figer devis et commande
Créer une cotation versionnée
La cotation reçoit compte, panier, quantité, date et contexte ; elle retourne prix, composants, raisons, version et expiration. Un identifiant permet au devis et au checkout de réutiliser le résultat sans recalculer différemment.
Le devis ajoute durée, approbations et conditions. Une modification du panier crée une nouvelle cotation. L’ancienne reste consultable. Les lignes verrouillées et variables sont distinguées avant acceptation.
Revalider avant engagement
À la commande, le système vérifie cotation, contrat, stock et plafond. Si elle reste valide, il crée le snapshot. Sinon, il propose une nouvelle version et demande accord selon impact. Une hausse n’est pas appliquée silencieusement.
Le pipeline reçoit cotation et contexte réconcilié ; sa sortie contient commande, ledger de remises et preuve. Commerce possède les policies, finance les garde-fous et plateforme les dépendances. L’instrumentation journalise chaque décision et retry.
Contractualiser les intégrations
Séparer import et calcul
ERP, seller et CRM fournissent comptes, contrats et grilles via schémas versionnés. Le service de prix les valide puis publie. L’API de cotation consomme les versions actives. Un fichier n’est pas interrogé directement par le checkout.
Les imports retournent rejets par ligne, conflits et manifeste. La reprise est idempotente. Un batch partiel ne remplace pas toute la grille. Les versions précédentes restent actives jusqu’à publication complète.
Le pipeline reçoit fichier signé, schéma, compte source et date d’effet ; il produit version candidate, rejets, collisions et empreinte. L’équipe commerciale possède la donnée contractuelle, pricing les contrôles et plateforme la publication atomique. Les métriques suivent lignes reçues, valides, rejetées, modifiées et orphelines. Un retry reprend le même run sans créer de nouvelle version active.
Prévoir cache et indisponibilité
Le cache inclut compte, produit, quantité, marché, date et versions. Une clé trop large mélange les clients ; trop fine explose sans bénéfice. L’expiration suit contrat et changement d’identité.
Si le moteur est indisponible, alors le fallback dépend du parcours : dernière cotation valide, prix standard ou blocage. Le monitoring déclenche le runbook. Le rollback restaure règles et cache cohérents, puis réconcilie les commandes engagées.
Mesurer marge et erreurs
Rapprocher prix et contribution
Le dashboard suit chiffre, remise, marge, subvention, conversion et commandes par grille, compte et version. Il distingue prix affiché, coté, commandé et facturé. Les écarts portent une cause et une population.
Le coût business inclut correction, avoir, litige et perte de marge. Une petite erreur sur un gros compte passe avant de nombreux écarts sans commande. Les seuils déclenchent correction, gel ou revue commerciale.
Déployer en shadow et canary
Toute évolution compare gagnants, prix, marge et éligibilité sur des paniers témoins. Le canary limite comptes et catégories. Les équipes commerciales valident les cas sans modifier directement la sortie.
Si plus de 0,1 % des cotations divergent sans raison attendue ou si la marge tombe sous le plancher, alors le go est refusé. Le rollback restaure la release précédente. Deux clôtures cohérentes autorisent l’extension.
Le canary commence par des comptes dont les contrats et commandes récentes ont été rapprochés manuellement. Chaque cotation nouvelle est comparée à une référence attendue et à la facture simulée. Les alertes ventilent grille, seller, devise et surface afin d’éviter qu’une moyenne masque un gros client. Toute correction repasse shadow, réconciliation et signature finance avant reprise.
Adapter la méthode et éviter les erreurs
Pour qui les grilles B2B conviennent
Elles deviennent nécessaires lorsque comptes, groupes, quantités ou négociations modifient durablement le prix. Une marketplace simple peut commencer avec standard et contrat nommé, sans moteur générique excessif.
Commercial possède contrats ; pricing les priorités ; finance marge ; seller operations les grilles seller ; plateforme calcul et versions ; support l’explication. Chaque ligne critique possède owner.
Erreurs fréquentes des tarifs B2B
Identifier par email, écraser les grilles, résoudre par prix minimal, cumuler toutes les remises, recalculer un devis, cacher la devise et calculer côté front sont les erreurs majeures. Elles produisent des prix impossibles à défendre.
Une autre erreur consiste à confondre segment et contrat individuel. Enfin, une table immense sans règle de priorité n’est pas un moteur : les collisions doivent devenir impossibles ou explicites.
Plan d’action pour déployer les grilles B2B
Semaines 1 à 4 : identités et modèle
La première semaine rapproche vingt commandes à leurs contrats et prix. La deuxième ferme compte, hiérarchie, grain, priorité et cumul. Commercial et finance écrivent exemples, collisions et garde-fous.
Les semaines trois et quatre construisent grilles versionnées, cotation et raisons. Les tests couvrent filiale, palier, devise, taxe, coupon, contrat expiré et concurrence. Chaque cas produit marge et snapshot.
La revue de phase rapproche ensuite vingt paniers réels entre contrat, ancien calcul et moteur candidat. Chaque écart reçoit une cause, un owner et une décision. Les critères de sortie fixent zéro collision silencieuse, marge au-dessus du plancher, prix reproductible et explication disponible pour commercial comme support.
Semaines 5 à 8 : devis et bascule
La cinquième semaine connecte devis, commande et ledger. La sixième exécute en shadow sur comptes témoins. L’instrumentation suit collisions, prix, marge, cache, facture et support avec owners et seuils.
Les semaines sept et huit ouvrent un canary, provoquent hiérarchie modifiée, import partiel et moteur indisponible, puis exécutent le rollback. Le go exige prix reproductible, marge protégée et surfaces réconciliées.
Le dossier final conserve contrats, grilles, policies, fixtures, décisions, dashboards et runbooks. Toute exception possède approbation et expiration ; tout devis garde sa cotation. Aucun prix ne peut être publié sans raison et version.
Après le canary, l’extension progresse par famille de contrats et devise. Une clôture quotidienne compare cotations, commandes, factures et avoirs, puis recherche les appels ayant utilisé un fallback. Une population hors seuil suspend le palier suivant ; le rollback restaure grilles et caches, sans modifier les snapshots déjà acceptés par les acheteurs.
- À faire d’abord : fermer identité de compte, grain et priorité des grilles.
- À tester ensuite : collision, palier, cumul, devise, devis et rollback.
- À différer : les règles sans contrat ni population réelle.
- À refuser : tout prix choisi par ordre d’import ou minimum implicite.
Ressources complémentaires pour l’opérateur
Structurer catalogue et pilotage
Le catalogue PIM marketplace stabilise les produits des grilles.
Les écrans du back-office opérateur rendent cotations et écarts consultables.
Borner les premiers contrats
Le MVP marketplace avant ouverture limite les règles initiales.
La méthode pour ouvrir une première catégorie fournit des paniers témoins.
Conclusion : un prix explicable
Une grille B2B relie compte, contrat, quantité et contexte à une décision de prix versionnée et reproductible.
Priorités, garde-fous et snapshots empêchent les surfaces de reconstruire des montants contradictoires.
Shadow, ledger et rollback protègent marge et engagement commercial pendant chaque évolution.
Dawap peut vous accompagner pour industrialiser des grilles B2B explicables dans votre marketplace opérateur.
