Boutique en ligne B2B sur SAP Commerce Cloud avec S/4HANA Public Cloud en arrière-plan : quelles données vont où ?

Si vous construisez une boutique en ligne B2B sur SAP Commerce Cloud avec S/4HANA Public Cloud en arrière-plan, vous répondrez sans cesse à la même question, sous quatre variantes : les données vont-elles dans la boutique, ou la boutique les cherche-t-elle en direct dans l’ERP au moment où elles comptent ? Répondez par une règle générale et vous construirez soit une boutique lente, soit un ERP surchargé. La bonne réponse diffère selon la classe de données, et c’est le sujet de cet article.

En bref : répliquez les produits et le catalogue dans Commerce Cloud et enrichissez-les là. Appelez en direct depuis S/4HANA les prix spécifiques aux clients et la disponibilité, avec un cache de quelques minutes. Transmettez les commandes de manière asynchrone via une file surveillée, et lisez l’historique des commandes en direct dans l’ERP. Le package d’intégration standard de SAP couvre la plupart des flux ; les prix en direct sont la partie à concevoir délibérément.

La question centrale : répliquer ou appeler en temps réel ?

Quatre classes de données, quatre décisions. D’après notre expérience de projet, la répartition est la suivante :

Produits et catalogue : répliquer. Le référentiel produits est transféré dans Commerce Cloud et y est enrichi : textes de vente, images, attributs pour la recherche à facettes, arborescence des catégories, données SEO. Rien de cela n’a sa place dans l’ERP ; cela appartient à la boutique, où travaillent les équipes de contenu. L’ERP reste le référentiel structurel : numéro d’article, unités et classification viennent de S/4HANA et ne sont jamais écrasés dans la boutique. Les catalogues changent assez rarement pour que la réplication suffise pleinement.

Prix spécifiques aux clients : appeler en temps réel. En B2B, presque chaque client a ses propres conditions : prix contractuels, barèmes, systèmes de remise. Cette logique vit dans S/4HANA et doit y rester. Le package standard de SAP réplique les prix et les remises dans la boutique, ce qui fonctionne pour les prix catalogue. Pour les prix contractuels, nous laissons la boutique interroger S/4HANA au moment de l’affichage, sur la base de la simulation de prix de l’ERP, avec un cache court de quelques minutes. Une seule vérité des prix, pas de seconde logique de prix à synchroniser.

Stock et disponibilité : appeler en temps réel, avec un cache court. En B2B, la disponibilité est une promesse, pas une décoration. La boutique vérifie la disponibilité dans S/4HANA et met le résultat en cache pour quelques minutes, pas quelques heures. Si vous ne répliquez le stock que la nuit, vous passerez la journée à promettre des marchandises déjà parties.

Commandes : transmettre en asynchrone. La commande est confirmée dans la boutique, puis envoyée à l’ERP via une file d’attente avec une gestion d’erreurs propre : si la création dans S/4HANA échoue, la commande arrive dans une file d’erreurs avec une alerte, pas dans un trou noir. L’historique des commandes dans l’espace client, en revanche, est lu en direct dans S/4HANA, de sorte que le client voit aussi les commandes passées par téléphone ou par EDI. Le déroulement du cycle de vie de la commande dans la boutique elle-même, du panier aux retours, est décrit dans la gestion des commandes dans SAP Commerce Cloud.

SAP publie les briques sous forme du package SAP Commerce Cloud Integration with SAP S/4HANA Cloud sur le SAP Business Accelerator Hub : articles et classification, clients B2B, prix et remises, niveaux de stock, réplication des commandes vers S/4HANA, notifications de commande et de livraison vers la boutique, et retours. La documentation SAP de l’intégration de la gestion des commandes S/4HANA décrit le côté Commerce.

Pourquoi le B2B fonctionne autrement que le B2C

Les recettes du B2C ne suffisent pas en B2B, pour quatre raisons.

Premièrement, les prix. En B2C, un même prix vaut pour tous, on peut donc le répliquer sans arrière-pensée. En B2B, le prix dépend du client, de la quantité, du contrat et de l’état actuel des tables de conditions. D’où l’appel en direct.

Deuxièmement, le comportement d’achat. Les clients B2B ne flânent pas, ils s’approvisionnent. Modèles de commande, recommande depuis l’historique et saisie rapide par numéro d’article comptent davantage que la mise en scène des produits.

Troisièmement, la limite de crédit. Avant le checkout, il faut un contrôle par rapport à la gestion du crédit dans S/4HANA. Une commande qui tombe immédiatement sur un blocage de crédit dans l’ERP n’aide personne, et surtout pas le back-office qui doit la débloquer à la main.

Quatrièmement, les canaux de commande. Les grands clients commandent en punch-out depuis leur système d’approvisionnement ; les clients de taille moyenne téléversent des fichiers CSV de cinquante lignes. Les deux doivent alimenter la même interface de commande que le panier.

Ce qui tourne mal dans les projets, et comment l’éviter

L’erreur la plus fréquente que nous trouvons dans les architectures existantes est la réplication complète nocturne des prix contractuels. Elle semble anodine jusqu’à ce que le premier contrat soit adapté en cours de journée. La boutique affiche alors l’ancien prix jusqu’au lendemain matin, le client commande, la confirmation de commande de l’ERP diffère, et le back-office passe des appels. La solution n’est pas une réplication plus rapide, mais un appel de prix en direct avec un cache court.

Le deuxième classique est la comptabilisation synchrone de la commande : le checkout attend que S/4HANA ait créé la commande. Cela fonctionne jusqu’à ce que l’ERP soit dans une fenêtre de maintenance ou une mise à niveau de version. Le checkout casse alors, précisément pour les clients qui voulaient commander à dix heures du soir. Les commandes ont leur place dans une file : la boutique confirme immédiatement, l’ERP traite dès qu’il le peut, et les erreurs arrivent dans une file surveillée plutôt que chez le client.

Le troisième point est moins technique : le zoo de fonctionnalités. Configurateurs, connexions à des places de marché, fidélisation, tout dans la première phase. Notre conseil est une première version sobre : catalogue, prix spécifiques aux clients, commande, historique des commandes. C’est le cœur avec lequel un client B2B peut travailler de manière productive, et il se met en production en quelques mois, pas en années. Le reste suit, priorisé selon ce qui manque aux vrais clients dans la vraie boutique. Pour les entreprises B2B plus petites, SAP Commerce Cloud ERP Edition regroupe une grande partie de cela pour S/4HANA Public Cloud.

Construit une fois, utilisé plusieurs fois

La couche d’interfaces qui en résulte n’est pas un accessoire de la boutique, mais une brique. Appel de prix, contrôle de disponibilité, file de commandes et API d’historique sont proprement séparés du frontend. Aujourd’hui, cette couche sert SAP Commerce Cloud ; demain, elle sert une application pour la vente sur le terrain, un portail client ou un autre canal de vente, sans nouveau travail côté ERP. C’est ce que signifie « composable » en pratique, comme le décrit notre article sur le composable commerce en B2B.

C’est aussi pourquoi nous planifions boutique et ERP avec une seule équipe ; notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse défend cette approche, la pile intégrée S/4HANA Public Cloud et Sales Cloud V2 montre le côté CRM du même ERP, et les meilleurs partenaires SAP Commerce Cloud en Suisse indiquent à qui vous adresser. Notre page SAP commerce B2B pour les distributeurs en Suisse décrit comment nous le réalisons en projet.

Questions fréquentes

S/4HANA Public Cloud dispose-t-il des API pour ce modèle ?

Oui. SAP publie un package d’intégration standard pour SAP Commerce Cloud et S/4HANA Cloud couvrant les articles, les clients B2B, les prix et remises, le stock, les commandes, les notifications de commande et de livraison ainsi que les retours. Les appels de prix et de disponibilité en direct utilisent des API S/4HANA publiées, documentées sur le SAP Business Accelerator Hub, et SAP Integration Suite gère le mapping, la mise en file d’attente et les erreurs, sans modification.

Le checkout invité fonctionne-t-il en B2B ?

En général non, et ce n’est pas un défaut. Les comptes B2B sont rattachés à la fiche client dans l’ERP, où sont ancrés conditions, limite de crédit, adresses de livraison et conditions de paiement. Un panier anonyme ne peut rien en exploiter. Un parcours d’inscription simple, après lequel le back-office relie le compte de la boutique au bon client ERP, fonctionne mieux.

Où vit le contenu produit, dans l’ERP ou dans la boutique ?

Aux deux endroits, avec une répartition claire des rôles. L’ERP reste le référentiel structurel pour le numéro d’article, les unités et la classification ; Commerce Cloud sert de PIM léger pour les textes, les images, les attributs et les catégories. Un système PIM séparé n’est rentable que lorsque plusieurs canaux utilisent le même contenu en plusieurs langues ; avant cela, c’est un système de trop.

Quelle fraîcheur pour le stock affiché dans la boutique ?

Assez fraîche pour que la promesse tienne. Un cache de deux à cinq minutes sur le contrôle de disponibilité est le bon compromis dans la plupart des scénarios B2B : il protège l’ERP des pics de charge et garde l’affichage proche de la réalité. Une réplication nocturne du stock ouvre la porte aux conflits de livraison.

---

Vous planifiez une boutique B2B sur SAP Commerce Cloud, ou votre boutique actuelle souffre de prix périmés et de commandes bloquées ? Nous parcourons l’architecture avec vous, classe de données par classe de données. Parlez à notre équipe.