SAP S/4HANA Public Cloud + SAP Sales Cloud V2 : la stack CX + ERP intégrée

S/4HANA Public Cloud et Sales Cloud V2 sont conçus pour partager le même client : le même Business Partner, les mêmes produits et prix, un seul flux de commandes. La plupart des entreprises DACH qui utilisent SAP ont déjà un CRM et un ERP ; le problème, c’est que les deux ne sont pas d’accord sur qui est le client.

En bref : les deux produits reposent sur le modèle Business Partner de SAP, et SAP publie un contenu d’intégration standard pour Sales Cloud V2 et S/4HANA Cloud Public Edition qui s’exécute sur SAP Integration Suite. Les données de base, les prix et l’exécution des commandes restent dans l’ERP ; le pipeline, les activités et les cas de service vivent dans Sales et Service Cloud V2 ; l’intégration et les extensions se trouvent sur Business AI Platform (BAIP, anciennement BTP). Ce qui reste à décider dans votre projet, c’est le périmètre : quels champs répliquer, dans quel sens va chaque flux, comment surveiller les erreurs et qui porte l’intégration après la mise en production.

Cet article explique comment fonctionne cette intégration, où se trouve la logique et comment séquencer une implémentation sans reporter les anciens problèmes de qualité des données dans un système plus récent.

Pourquoi associer S/4HANA Public Cloud à Sales Cloud V2 ?

Parce qu’une commerciale qui prépare un devis et un comptable qui enregistre une facture devraient regarder le même client.

Dans beaucoup de paysages SAP que nous rencontrons, ce n’est pas le cas. Le CRM contient une fiche client avec un autre format de nom, d’autres champs d’adresse et un autre statut de crédit que la fiche ERP. Les ventes ignorent la facture en retard, la finance ignore le nouveau contrat qui vient d’être signé.

La solution classique est une interface qui aligne des champs entre deux modèles de données différents. Cela fonctionne, mais c’est fragile : chaque changement de schéma d’un côté casse quelque chose, et tôt ou tard une seule personne maintient une interface que personne d’autre ne comprend.

La combinaison de S/4HANA Public Cloud et de Sales Cloud V2 réduit ce problème, car les deux utilisent le concept de Business Partner. S/4HANA est le système maître, Sales Cloud V2 reçoit l’enregistrement répliqué, et le mappage est en grande partie prédéfini dans le paquet de contenu de SAP au lieu d’être réinventé à chaque projet. Quand un commercial consulte un client, il voit le compte que la finance tient dans l’ERP. Il reste une intégration à exploiter et à surveiller, mais elle relie deux modèles compatibles au lieu de traduire entre des modèles incompatibles.

Pour les entreprises DACH qui quittent SAP S/4HANA on-premise ou ECC, c’est l’un des vrais arguments en faveur du cloud public : un CRM et un ERP sur les mêmes fondations.

Quel est le meilleur CRM pour SAP S/4HANA Public Cloud ?

Le meilleur CRM pour SAP S/4HANA Public Cloud est SAP Sales Cloud V2, parce qu’il partage le modèle de données de l’ERP : les enregistrements clients suivent le concept de Business Partner des deux côtés, les produits et les prix passent de S/4HANA au devis, et SAP livre du contenu d’intégration standard pour le transfert des commandes. Tout CRM a besoin d’une couche d’intégration vers l’ERP ; avec Sales Cloud V2, l’essentiel est prédéfini et suit le cycle de versions d’un seul éditeur, avec Salesforce ou Dynamics vous la concevez, la mappez et la maintenez vous-même, durablement.

Quand un CRM tiers reste pertinent

Un bon conseil inclut aussi les cas où la réponse est différente. Si Salesforce tourne déjà dans plusieurs divisions, avec des configurations matures, des intégrations AppExchange actives et sa propre équipe d’administration, en changer pour un projet S/4HANA est probablement une erreur. Il en va de même lorsqu’un travail analytique important repose sur le modèle de données du CRM (objets personnalisés, modèles Einstein, flux vers un entrepôt de données) ou lorsque vos besoins vont bien au-delà de la vente B2B, vers la gestion des partenaires ou des fonctions sectorielles où cet écosystème a de l’avance. La comparaison n’est jamais purement technique : elle dépend d’où vous venez et de l’ampleur du changement que vos équipes souhaitent.

Un seul modèle de données client, pas deux

Le modèle Business Partner est la colonne vertébrale des deux systèmes. Dans S/4HANA Public Cloud, chaque client est créé comme Business Partner. Sales Cloud V2 reçoit cet enregistrement via SAP Integration Suite, de sorte que les données du compte dans Sales Cloud reflètent ce que contient S/4HANA : raison sociale, adresses, conditions de paiement et, si vous les incluez dans le périmètre, les informations de crédit et de relance.

Pour les ventes, cela change la conversation avec le client. En ouvrant un compte dans SAP Sales Cloud V2, on voit la situation financière : postes ouverts, exposition au crédit, historique des commandes. Inutile d’appeler la finance pour savoir si une affaire est en danger.

Pour le service, le même modèle signifie que les cas dans SAP Service Cloud V2 sont liés à la même entité client que celle de l’ERP. Pas de recherche séparée, pas de « à quel système dois-je me fier ? ».

La synchronisation est une décision de conception, pas un automatisme. Les enregistrements Business Partner sont gérés dans S/4HANA comme système maître, et les modifications parviennent à Sales Cloud V2 par des événements d’intégration. Les nouveaux clients créés dans Sales Cloud V2 lors de la prospection peuvent remonter vers S/4HANA pour leur création dans l’ERP. Le sens de chaque flux et le mappage des champs se décident pendant l’implémentation, ils ne se découvrent pas après la mise en production.

Le cycle devis, commande, facture

C’est là que l’intégration rapporte le plus visiblement aux équipes commerciales.

Un commercial prépare un devis dans Sales Cloud V2. Les produits et les prix viennent de S/4HANA ; si vous utilisez SAP CPQ, la configuration et la logique de prix s’y exécutent. Le client reçoit un devis fondé sur des prix réels, pas sur un tableur tenu à part. Notre article sur le quote-to-cash entre Sales Cloud V2 et S/4HANA Public Cloud détaille ce flux étape par étape.

Quand le client accepte, la commande part vers S/4HANA pour exécution, au lieu d’être envoyée par courriel à une équipe interne qui la saisit à la main. L’entrepôt prépare, la logistique expédie, la finance facture.

Le statut de livraison et de facture (comptabilisée, payée, en retard) revient dans la vue du compte dans Sales Cloud. Le commercial voit si la commande du mois dernier a été payée sans ouvrir de portail financier, et le service voit le statut de livraison sans appeler l’entrepôt.

Ce cycle du devis à la commande puis à la facture, visible dans Sales Cloud, c’est ce que « CRM et ERP intégrés » veut dire en pratique : un flux où les données circulent sans ressaisie manuelle.

Clean core : où se trouve la logique d’intégration

Le principe du clean core de SAP compte ici. L’objectif est de garder les personnalisations hors du cœur de S/4HANA et de placer la logique d’intégration et d’extension sur la SAP Business AI Platform.

Pour une intégration entre Sales Cloud et S/4HANA, cela signifie :

• des API standard publiées des deux côtés (OData, SOAP, événements), documentées sur le SAP Business Accelerator Hub ;
• des flux d’intégration dans SAP Integration Suite sur BAIP ;
• les paquets de contenu prédéfinis de SAP comme point de départ pour les scénarios standard ;
• la logique propre (règles de prix, workflows d’approbation, mappages spécifiques) dans des extensions BAIP ou SAP Build, pas dans des modifications de S/4HANA.

L’avantage est concret. SAP met à jour S/4HANA Public Cloud pour tous les clients selon un calendrier de versions fixe, et une intégration fondée sur des API publiées et des extensions side-by-side est conçue pour survivre à ces mises à jour. C’est la logique qui dépend d’objets non publiés qui transforme chaque mise à jour en campagne de tests de régression.

Ce qui reste dans S/4HANA, dans Sales Cloud V2 et sur BAIP

Responsabilité	Où elle se trouve
Données de base client (Business Partner)	S/4HANA Public Cloud
Catalogue produits, conditions de prix	S/4HANA Public Cloud
Gestion des commandes, exécution, facturation	S/4HANA Public Cloud
Gestion des opportunités, pipeline, prévisions	Sales Cloud V2
Interactions client, activités, rapports de visite	Sales Cloud V2
Cas de service, suivi des SLA, escalades	Service Cloud V2
Flux d’intégration, traitement des événements, gestion des erreurs	BAIP Integration Suite
Extensions, applications sur mesure, fonctions d’IA	BAIP (side-by-side)

Il existe des cas limites, mais comme modèle de départ c’est plus propre que la plupart des paysages dont nous héritons. Le guide d’architecture d’intégration approfondit les patterns sur le plan technique.

À quoi cela ressemble dans les projets Spadoom

La situation avant un projet se répète : les ventes tiennent les données client dans un CRM vaguement synchronisé avec SAP, la finance détient la fiche client de référence que les ventes ne voient pas, la saisie des commandes est manuelle, et les ventes découvrent un blocage de crédit quand le client se plaint.

Après le projet, la vue du compte dans Sales Cloud affiche les postes ouverts et l’historique des commandes issus de l’ERP, les devis reposent sur des prix réels et les commandes arrivent sans ressaisie.

Trois projets publiés illustrent différentes parties de ce tableau :

• Chez intelligentfood, Spadoom a réalisé Sales Cloud V2, l’intégration avec le Cloud ERP et des travaux dans certaines parties de MM et SD. La plateforme Sales & Service était en production en trois mois (ce chiffre concerne cette plateforme, pas l’ensemble de l’implémentation ERP).
• Chez Nussbaum Matzingen, fabricant d’emballages, Sales Cloud V2 a remplacé les tableurs et dossiers Outlook par une seule plateforme de vente en cinq mois et a donné à la direction une transparence complète sur le pipeline, avec SAP ECC comme back-end.
• Chez Miltenyi Biotec, nous avons relié Commerce Cloud, le marketing, Customer Data Cloud, S/4HANA et Service Cloud V2 via SAP Integration Suite, pour que le service travaille sur les mêmes données client que le reste du paysage.

Rien de spectaculaire. C’est ce que doit faire une intégration entre CRM et ERP, et cela fonctionne quand le modèle de données est partagé dès le départ.

Dans quel ordre mener les deux projets

L’erreur la plus fréquente consiste à mener le CRM et l’ERP comme des projets parallèles et indépendants censés « se connecter plus tard ». C’est rarement le cas, ou seulement en surface, et la dette d’intégration s’accumule.

La meilleure séquence :

1. Concevoir d’abord le modèle de données partagé. Avant toute configuration, s’accorder sur la forme d’un Business Partner, la structure des comptes et des contacts et l’endroit où les données de base sont gérées. C’est une décision métier, pas technique.
2. Mettre en place S/4HANA d’abord, ou en parallèle de Sales Cloud, pas après. Si Sales Cloud démarre avec une intégration provisoire vers l’ancien ERP, cette intégration sera à refaire à la mise en production de S/4HANA.
3. Définir les scénarios d’intégration avant la mise en production. Devis vers commande, visibilité des factures et synchronisation des données client se configurent et se testent dans un environnement d’intégration dédié ; on ne les ajoute pas à la fin.
4. Tester l’intégration dans des systèmes réels avant la mise en production. Le côté S/4HANA peut être simulé au début, mais les flux doivent être testés de bout en bout avant la première vraie commande.

Les options de séquencement et leurs compromis sont décrits dans notre guide pour déployer ensemble S/4HANA Public Cloud et Sales Cloud V2. Si vous choisissez encore qui le réalisera, notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse explique pourquoi une seule équipe pour les deux moitiés fait la différence.

---

La plupart des entreprises sont entre les deux : un ou deux systèmes en service, mais pas entièrement reliés. L’évaluation de readiness S/4HANA de cinq jours fournit un périmètre, une séquence et une fourchette de coûts pour les deux moitiés avant tout engagement, comme première étape d’une transformation ERP et CX. Ou parlons de votre configuration.

À lire aussi :

• Ce que S/4HANA Public Cloud couvre nativement et ce qui exige Sales/Service Cloud V2
• S/4HANA Public Cloud + Sales Cloud V2 vs Salesforce
• SAP S/4HANA Public Cloud : aperçu de la solution