Dans le commerce direct au consommateur (DTC), la logique est simple : « Voici une chemise. Elle coûte 50 €. » Dans le commerce Business-to-Business (B2B), la réponse à la question « Combien cela coûte ? » est toujours : “Cela dépend.”

*Qui es-tu ? (Partenaire Or vs Revendeur Bronze). *Combien en achetez-vous ? (1 unité contre 1 000 unités).

Où expédiez-vous ? (TVA européenne par rapport à la taxe de vente américaine). *Quand payez-vous ? (Carte de crédit vs facture Net 30).

Pour les anciens portails B2B existants, cette logique est enfouie dans du code spaghetti SAP vieux de 20 ans. Les acheteurs B2B modernes s’attendent à « l’expérience Amazon » (interface utilisateur fluide, recherche instantanée, compatibilité mobile), mais avec la logique de tarification complexe d’un ERP.

Chez Maison Code Paris, nous construisons des portails B2B Headless qui allient une UX grand public à une logique de niveau entreprise.

Pourquoi Maison Code en parle

Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.

Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.

Pourquoi Maison Code parle B2B

Le commerce B2B est 5 fois plus important que le DTC. Pourtant, les sites Web B2B sont souvent 5 fois pires. Nous pensons que les acheteurs B2B sont aussi des humains. Ils détestent les interfaces maladroites. Ils détestent attendre les PDF. Nous aidons les Fabricants et Grossistes à transformer leurs centres de « Prise de Commandes » en machines de « Revenus Libre-Service ». Nous concevons des systèmes qui gèrent des milliers de SKU et des millions de permutations de prix sans sourciller.

1. Le modèle de données : entreprises et sites

Dans la nouvelle B2B Primitive de Shopify, nous nous éloignons du simple objet « Client ».

erDiagramme
    Entreprise ||--|{ CompanyLocation : a
    Entreprise ||--|{ EntrepriseContact : emploie
    Localisation de l'entreprise ||--|| Catalogue : assigné_à
    Catalogue ||--|{ PriceList : contient
    EntrepriseContact }|--|| Client : links_to

Société : l’entité juridique (par exemple, « Sephora »).
CompanyLocation : Le magasin physique (par exemple, “Sephora Paris Champs Elysées”).
Catalogue : sous-ensemble de produits que cet emplacement est autorisé à acheter.
CompanyContact : L’acheteur humain (Buying Manager).

Cette hiérarchie permet à un seul acheteur d’acheter pour plusieurs emplacements, avec des règles fiscales différentes pour chacun correctement appliquées.

2. Logique de tarification : la cascade

La partie rigoureuse du B2B consiste à calculer le prix final. L’algorithme suit une cascade spécifique :

Prix de base : 100 € (PDSF).
Prix catalogue : 80 € (liste de gros).
Remplacement de prix fixe : 75 € (tarif contractuel pour ce SKU).
Pourcentage de réduction : -10 % (réduction du niveau Or).
Rupture de quantité : -5 % (pour l’achat de >100 unités).

Implémentation de la tarification dynamique (fonctions Shopify)

Nous ne synchronisons pas 50 variantes pour 50 niveaux de prix. Nous utilisons Shopify Functions (WASM) pour calculer la logique lors du paiement.

// rust/discount-allocator/src/main.rs (simplifié)

fn run(entrée : Entrée) -> Sortie {
    laissez company = input.cart.buyer_identity.company;
    let tier = company.metafields.get("custom.tier").unwrap_or("BRONZE");
    
    laissez la réduction = correspondre au niveau {
        "OR" => 0,25, // 25 % de réduction
        "ARGENT" => 0,15, // 15 % de réduction
        _ => 0,0,
    } ;

    // Appliquer la remise aux lignes éligibles
    //...
}

Cela garantit que, quelle que soit la complexité du contrat, le calcul s’effectue en <5 ms à la périphérie.

3. Règles de quantité (le problème des palettes)

Vous ne pouvez pas expédier 1 brique. Vous expédiez une palette de 500 briques. Le B2B nécessite des incréments de quantité et des quantités minimales de commande (MOQ).

Nous appliquons cela sur le PDP (Product Detail Page) en utilisant des contraintes d’interface utilisateur, mais nous le validons également côté serveur.

// composants/QuantitySelector.tsx
fonction d'exportation QuantitySelector({ moq, incrément }) {
  const [val, setVal] = useState(moq);
  
  const stepUp = () => setVal(v => v + incrément); // 500 -> 1000
  
  return <input type="number" min={moq} step={increment} value={val} />;
}

4. Le paiement : conditions nettes vs carte de crédit

Les caisses B2B utilisent rarement les cartes de crédit pour les commandes importantes. Les frais (2,9 %) sont trop élevés sur une commande de 50 000 €. Nous utilisons des Brouillons de commandes et des Conditions de paiement.

Commandement : l’utilisateur sélectionne « Payer par facture (Net 30) ».
Contrôle des risques : nous appelons l’API ERP (NetSuite) pour vérifier la limite de crédit de l’entreprise.
- Si CurrentBalance + CartTotal > CreditLimit : Rejeter la commande.
- Si « OK » : Continuez.
Soumission : la commande est créée dans Shopify avec le statut « Paiement en attente ».
Facturation : le middleware synchronise la commande avec l’ERP. L’ERP envoie la facture PDF par e-mail.
Rapprochement : lorsque le virement bancaire arrive, l’ERP met à jour la commande Shopify sur « Payée ».

5. Le modèle « Gatekeeper »

Une boutique B2B est souvent privée. Nous implémentons un Gatekeeping Middleware en périphérie (Cloudflare / Vercel Edge).

// middleware.ts
exporter le middleware de fonction par défaut (demande : demande) {
  const jeton = request.cookies.get('b2b_session');
  
  si (!jeton) {
    return NextResponse.redirect(new URL('/login', request.url));
  }
  
  const user = wait verifyToken(token);
  si (!user.is_b2b_approved) {
    return NextResponse.rewrite(new URL('/ending-approval', request.url));
  }
}

Cela empêche Google d’indexer les prix de gros (ce qui ruine la valeur de la marque) et exclut les compétences.

6. Ordre matriciel (haute vitesse)

Un acheteur qui commande la collection FW25 doit commander 50 SKU dans 4 tailles. Ils ne veulent pas visiter 50 pages de produits. Nous construisons des Matrix Grids (interfaces de type Excel). (Voir notre article spécifique sur Matrix Ordering).

Cela nécessite une optimisation lourde du frontend (virtualisation) pour restituer 2 000 entrées sans planter le navigateur.

7. Intégration ERP : la source de la vérité

En B2B, Shopify n’est pas le maître des données. L’ERP l’est.

Inventaire : nous ne faisons pas confiance à l’inventaire Shopify. Nous récupérons l’ATP (Available to Promise) en temps réel depuis l’ERP.
Données client : lorsqu’un client met à jour son adresse dans Shopify, nous devons la transmettre à l’ERP.

Nous utilisons Event-Driven Architecture (Voir Infrastructure AWS) pour gérer ces synchronisations de manière asynchrone via des Webhooks et des files d’attente (SQS).

8. Catalogues spécifiques au client

Certaines marques proposent des produits « exclusifs ». Nike pourrait vendre des « Air Jordans » uniquement aux détaillants de « niveau 1 ». Les détaillants standards ne doivent même pas voir le produit. Nous utilisons Séparation de catalogue.

Tag Produits : tag: "exclusif".
Marquer les entreprises : métachamp : "access_level : 1".
Filtrage de recherche : Lors de l’interrogation d’Algolia, nous injectons le filtre : filters: '(tag:exclusive AND user.access_level >= 1) OR NOT tag:exclusive'. Cela garantit la sécurité malgré l’obscurité.

9. Architecture B2B sans tête (hydrogène)

Nous construisons le B2B sur Shopify Hydrogen (React). Pourquoi pas liquide ? Parce que Liquid ne peut pas gérer assez rapidement la complexité des « commandes matricielles » ou des « listes de prix personnalisées ». Avec Remix/Hydrogène :

Nous mettons en cache les « Données produit de base » au Edge (CDN).
Nous récupérons le “Prix personnalisé” via defer (Streaming).
La page se charge instantanément. Le prix apparaît 200 ms plus tard. Cela ressemble à une application grand public, pas à un portail d’entreprise.

10. Le workflow de demande de devis

Pour les commandes > 50 000 €, le prix n’est pas fixe. Cela se négocie.

Ajouter au devis : l’utilisateur crée un panier. Au lieu de « Commander », ils cliquent sur « Demander un devis ».
Agent commercial : le représentant commercial dans Salesforce reçoit le devis.
Négociation : le représentant modifie les prix (“Je vous offrirai 5 % de réduction de plus si vous ajoutez 100 unités”).
Approbation : L’utilisateur reçoit un e-mail : “Devis prêt”.
Conversion : l’utilisateur clique sur le lien, voit les prix personnalisés et paie via Net 30. Cela numérise la négociation sans supprimer la touche humaine.

11. Tarification basée sur l’IA (rendement dynamique)

Les contrats négociés sont statiques. “Vous bénéficiez de 10 % de réduction.” Mais que se passe-t-il si le client est sur le point de se désinscrire ? Nous utilisons l’IA (Dynamic Yield / Nosto) pour injecter des Promotions dynamiques. “Si le client X visite le site 3 fois et n’achète pas -> Offrez 5 % de réduction supplémentaire pendant 24 heures.” Ceci est strictement contrôlé par les règles de marge (définies dans l’ERP). L’IA est le « représentant commercial numérique » qui sait exactement quelle quantité de jus il faut utiliser pour conclure la transaction.

12. Conclusion

Le B2B n’est plus le « vilain petit canard » du e-commerce. Les marques gagnantes en gros sont celles qui offrent une expérience de type DTC. En résumant la complexité de la tarification et de la logistique derrière une interface utilisateur sans tête propre, vous respectez le temps de l’acheteur. Et en B2B, le temps est la seule monnaie qui compte.

**[Engagez nos Architectes](/contact)**.