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

Qui construit un webshop B2B sur SAP Commerce Cloud avec un S/4HANA Public Cloud en arrière-plan répond au fond toujours à la même question, en quatre variantes : les données migrent-elles dans le shop, ou le shop va-t-il les chercher en direct dans l’ERP au moment de vérité ? Qui répond à cette question de manière globale construit soit un shop lent, soit un ERP surchargé. La bonne réponse diffère selon la classe de données, et c’est exactement le sujet de cet article.

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

Quatre classes de données, quatre décisions. Selon notre expérience projet, la répartition est la suivante :

Produits et catalogue : répliquer. Les données produits migrent par réplication vers Commerce Cloud et y sont enrichies : textes de vente, images, attributs pour la recherche à facettes, arborescence de catégories, données SEO. Tout cela n’a pas sa place dans l’ERP, mais dans le shop, où les équipes contenu travaillent avec. L’ERP reste le maître structurel : numéro d’article, unités et classification viennent de S/4HANA et ne sont jamais écrasés dans le shop. Les catalogues changent assez rarement pour qu’une réplication suffise entièrement ici.

Prix spécifiques au client : appeler en temps réel. En B2B, presque chaque client a ses propres conditions : prix contractuels, barèmes, schémas de remise. Cette logique vit dans S/4HANA, et elle doit y rester. Le shop récupère le prix au moment de l’affichage via un appel de pricing, avec un cache court de quelques minutes. Une seule vérité des prix, pas d’exports nocturnes, pas de deuxième logique de prix qu’il faudrait synchroniser pendant des années.

Stock et ATP : appeler en temps réel, avec un cache bref. En B2B, la disponibilité est une promesse, pas une décoration. Le shop interroge la disponibilité auprès de S/4HANA et met le résultat en cache pour des minutes, pas des heures. Qui ne réplique le stock que la nuit promet toute la journée de la marchandise qui n’existe plus.

Commandes : injecter de manière asynchrone. La commande est confirmée dans le shop, puis transmise à l’ERP via une file d’attente, avec une gestion d’erreurs propre : si la création échoue dans S/4HANA, la commande atterrit dans une file d’erreurs avec alerte, pas dans le néant. L’historique des commandes dans l’espace client, en revanche, est lu en direct depuis les API S/4HANA. Le client voit ainsi aussi les commandes arrivées par téléphone ou EDI, pas seulement celles du shop.

Pourquoi le B2B fonctionne autrement que le B2C

Les recettes B2C du manuel sont trop courtes pour le B2B, et ce pour quatre raisons.

Premièrement, les prix. En B2C, un prix vaut pour tous, on peut donc le répliquer sans hésiter. En B2B, le prix est une fonction du client, de la quantité, du contrat et de l’état du jour des tables de conditions. D’où l’appel en direct.

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

Troisièmement, la limite de crédit. Avant le checkout, il faut un contrôle auprès du credit management dans S/4HANA. Une commande qui tombe immédiatement en blocage crédit dans l’ERP n’aide personne, et surtout pas le service interne qui devra ensuite la déterrer à la main.

Quatrièmement, les canaux de commande. Les grands clients commandent par punch-out directement depuis leur système d’achat ; les moyens téléchargent des fichiers CSV de cinquante positions. Les deux doivent alimenter la même interface de commande que le panier.

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

L’erreur la plus fréquente que nous rencontrons dans les architectures existantes est la réplication nocturne complète des prix. Elle semble anodine, jusqu’à ce que le premier contrat soit ajusté en cours de journée. Le shop affiche alors l’ancien prix jusqu’au lendemain matin, le client commande, la confirmation de commande de l’ERP diverge, et le service interne peut passer des coups de fil. Le remède n’est pas une réplication plus rapide, mais le passage au pricing en temps réel avec un cache court. Après cela, il n’existe plus qu’un seul endroit où naissent les prix.

Le deuxième classique : la création synchrone de la commande. Le checkout attend que S/4HANA ait créé la commande. Cela fonctionne, jusqu’à ce que l’ERP soit en fenêtre de maintenance ou installe une release. Le checkout casse alors, et précisément pour les clients qui voulaient saisir leur commande à dix heures du soir. Les commandes vont toujours dans une file d’attente : le shop confirme immédiatement, l’ERP traite dès qu’il le peut, et les erreurs atterrissent dans une file surveillée plutôt que chez le client.

Le troisième point est moins technique qu’humain : le zoo de fonctionnalités. Configurateurs, connexion marketplace, loyalty, le tout en phase un. Notre conseil est un MVP côté achat : catalogue, prix spécifiques au client, commande, historique des commandes. C’est le noyau avec lequel un client B2B peut travailler productivement, et il est en production en quelques mois, pas en années. Tout le reste vient ensuite, priorisé selon ce qui manque aux vrais clients dans le vrai shop.

Construit une fois, utilisé plusieurs fois

La couche d’interfaces qui naît ici n’est pas un accessoire du shop, c’est une brique. Appel de pricing, contrôle ATP, file de commandes et API d’historique sont proprement séparés du frontend. Aujourd’hui, cette couche sert SAP Commerce Cloud. Demain, elle servira tout aussi bien une app pour la force de vente, un portail client ou un autre canal de vente, sans rien construire de nouveau côté ERP. Au final, composable veut simplement dire : l’investissement dans la couche API se rentabilise à nouveau avec chaque frontend supplémentaire.

Questions fréquentes

S/4HANA Public Cloud a-t-il seulement les API pour ce modèle ?

Oui. Des API OData et SOAP publiées sont disponibles pour les prix, la disponibilité, les commandes et les partenaires, documentées dans le SAP Business Accelerator Hub. L’orchestration, c’est-à-dire mapping, file d’attente et gestion d’erreurs, est assurée par SAP Integration Suite. On travaille dans le standard du Public Cloud, sans modifications, et on reste compatible avec les releases.

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

En règle générale non, et ce n’est pas un défaut. Les comptes B2B sont rattachés au client dans l’ERP : conditions, limite de crédit, adresses de livraison et conditions de paiement y sont ancrées. Un panier anonyme ne peut rien en utiliser. Un parcours d’inscription allégé est plus judicieux, derrière lequel le service interne relie le compte shop au bon client ERP.

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

Les deux, avec une répartition claire des tâches. L’ERP reste le maître structurel pour le numéro d’article, les unités et la classification. Commerce Cloud endosse le rôle d’un PIM léger : textes, images, attributs, catégories. Un système PIM séparé ne devient nécessaire que lorsque plusieurs canaux consomment le même contenu en plusieurs langues ; avant cela, ce serait un système de trop.

Quelle fraîcheur pour le stock dans le shop ?

Assez fraîche pour que la promesse tienne. Un cache de deux à cinq minutes sur le contrôle ATP est le bon compromis dans la plupart des scénarios B2B : il protège l’ERP des pics de charge et garde l’affichage assez proche de la vérité. La réplication nocturne du stock est en revanche de facto une invitation aux conflits de livraison.

Vous planifiez un shop B2B sur SAP Commerce Cloud, ou votre shop existant se bat avec des prix périmés et des commandes bloquées ? Nous vous montrons volontiers l’architecture à partir de vos classes de données. Parlez-nous.