Architecture d'intégration : connecter SAP Sales Cloud V2 à S/4HANA Public Cloud

« Comment l’intégration fonctionne-t-elle concrètement ? » C’est la première question de presque chaque atelier de découverte Sales Cloud V2 que nous animons, et c’est la bonne question pour commencer.

La réponse courte : SAP fournit des contenus d’intégration préconfigurés sur SAP Integration Suite qui relient SAP Sales Cloud V2 à S/4HANA Public Cloud pour les flux qui comptent : réplication des données de base, prix en direct, de l’offre à la commande et statut des commandes en retour dans le CRM. Vous configurez et déployez les packages de SAP au lieu de construire des connecteurs de toutes pièces. Préconfiguré ne veut pas dire sans effort pour autant : le mapping, la qualité des données et la mise en place opérationnelle prennent du temps.

Cet article couvre l’architecture depuis la base. Pour la vue d’ensemble des deux systèmes exploités comme une seule pile, voir notre guide de la pile intégrée S/4HANA Public Cloud et Sales Cloud V2.

En bref : SAP fournit des packages d’iFlows standard sur SAP Integration Suite pour la combinaison Sales Cloud V2 et S/4HANA Public Cloud. Les données de base viennent de S/4HANA (partenaires commerciaux, produits, données organisationnelles, conditions de prix). Les prix peuvent être simulés en direct dans S/4HANA pendant la création d’une offre, et les offres deviennent des commandes clients de suivi dans S/4HANA. La logique spécifique a sa place sur SAP BAIP (anciennement BTP) en extensions side-by-side. La qualité des données et le monitoring des erreurs sont les deux parties les plus sous-estimées du projet.

Comment Sales Cloud V2 se connecte-t-il à S/4HANA Public Cloud ?

Les deux sont des produits SaaS de SAP, et le connecteur entre eux est SAP Integration Suite, plus précisément sa capacité Cloud Integration sur SAP BAIP. Sales Cloud V2 expose des API REST ; S/4HANA Public Cloud expose des API OData et SOAP publiées (released), documentées sur le SAP Business Accelerator Hub. Integration Suite doit être provisionné dans votre sous-compte BAIP avant qu’un iFlow puisse être déployé, une tâche d’infrastructure du premier jour parfois oubliée dans la planification initiale.

La connexion n’est pas directe de système à système. Tout passe par Integration Suite, qui gère les relances, les files d’erreurs, le monitoring des messages et le mapping entre deux modèles de données différents. Un appel d’API point à point est techniquement possible, mais vous portez alors vous-même tout ce travail d’exploitation.

Les contenus d’intégration standard

SAP publie les contenus sur le SAP Business Accelerator Hub en deux packages :

• SAP Sales Cloud Version 2 Integration for Sales Processes with SAP S/4HANA Cloud Public Edition : offre de suivi dans S/4HANA à partir d’une opportunité, commande client de suivi à partir d’une offre, simulation d’offres et de commandes pour les prix, et réplication des commandes clients dans les deux sens.
• SAP Sales Cloud and SAP Service Cloud Version 2 Integration for Master Data with SAP S/4HANA Cloud Public Edition : partenaires commerciaux et relations de contact, produits, domaines commerciaux et autres données organisationnelles, conditions de prix, stock produit et équipements.

Le déploiement consiste à copier le package dans votre tenant, à configurer les connexions et les mappings de valeurs, puis à déployer les iFlows sur votre runtime Cloud Integration. SAP maintient ces packages et livre des mises à jour, un vrai avantage face aux connecteurs spécifiques, qui disparaît dès que vous modifiez un iFlow standard au lieu de le copier d’abord. La page d’aide SAP sur l’intégration de Sales Cloud V2 avec S/4HANA Cloud Public Edition pour la simulation et le transfert décrit la configuration.

Côté S/4HANA, les communication arrangements définissent quelles API sont exposées et à quels utilisateurs techniques. Côté Sales Cloud V2, les systèmes de communication et les connexions sortantes et entrantes doivent être configurés en conséquence. Réussir les deux est l’étape préalable que la plupart des guides d’intégration traitent comme une note de bas de page ; en pratique, elle demande un sprint de mise en place et de tests avant la mise en service du premier iFlow.

Le côté service de la même topologie utilise le même package de données de base, mais d’autres documents ; voir l’intégration de Service Cloud V2 avec S/4HANA Public Cloud pour les cas, la base installée et les ordres de service.

Réplication des données de base

S/4HANA est le système de référence pour les clients, les produits et les prix ; le CRM les consomme.

Partenaires commerciaux. Les iFlows standard répliquent les partenaires commerciaux et les relations de contact entre S/4HANA et Sales Cloud V2, avec des messages de confirmation dans les deux sens. Les modifications sont transmises au moment où elles ont lieu, pas regroupées dans un traitement nocturne. Le mapping gère la différence structurelle entre le modèle de partenaire commercial de S/4HANA et le modèle compte et contact de Sales Cloud V2. Si vous vous trompez ici, vous passerez les premières semaines après le go-live à fusionner des comptes en double.

Produits. Les produits sont répliqués de S/4HANA vers le référentiel produits de Sales Cloud V2, avec les groupes de produits, les unités de mesure et les domaines commerciaux. Les commerciaux proposent des produits dont les données proviennent de S/4HANA.

Données organisationnelles. Les organisations commerciales, canaux de distribution, secteurs d’activité, agences commerciales et groupes de vendeurs sont également répliqués. C’est là que le mapping devient exigeant : la structure des domaines commerciaux de S/4HANA doit correspondre aux territoires et aux équipes du CRM.

Prix et flux transactionnels

Prix en direct. Le flux le plus utile pour la vente est souvent la simulation. Pendant qu’un commercial établit une offre, Sales Cloud V2 peut appeler S/4HANA pour simuler l’offre ou la commande et obtenir le prix, conditions spécifiques au client et barèmes compris. SAP propose aussi la réplication des conditions de prix vers le CRM ; le choix entre les deux est une décision d’architecture, et notre article sur le quote-to-cash explique pourquoi nous préférons une seule vérité des prix dans l’ERP.

De l’offre à la commande. Quand le client accepte, l’offre dans Sales Cloud V2 crée une commande client de suivi dans S/4HANA via l’iFlow standard. Les commandes clients sont répliquées en retour dans le CRM, de sorte que les responsables de compte voient la commande et son statut sans se connecter à l’ERP.

Contexte financier. Pour les factures, l’exposition de crédit et les contrats de vente, le package d’intégration Customer Insights de SAP récupère les données dans S/4HANA en temps réel et les affiche dans la vue du compte. Pour les équipes commerciales B2B dont les décisions dépendent de l’exposition de crédit, cela supprime l’appel au service financier.

En pratique, les flux transactionnels sont rarement le goulet d’étranglement technique. Le mapping des données et l’alignement organisationnel prennent plus de temps que la tuyauterie. Chez intelligentfood, Sales & Service Cloud V2 a été mis en production en trois mois, relié à l’ERP.

Où vit la logique spécifique : BAIP en side-by-side

Le principe clean core s’applique à l’intégration autant qu’aux extensions. Les iFlows standard gèrent les scénarios documentés. Tout ce qui est propre à votre modèle d’affaires, à votre processus d’approbation ou à vos règles de validation vit en dehors des deux systèmes, en extension side-by-side sur SAP BAIP.

La logique spécifique dans un mapping d’iFlow est un piège : elle fonctionne à court terme et devient impossible à maintenir dès que SAP livre une mise à jour sur laquelle vous devez réappliquer vos modifications.

Integration Suite, événements et SAP Build

SAP Integration Suite est le runtime de vos iFlows et l’endroit où vous inspectez chaque message traité, en échec ou relancé. Des tableaux de bord de monitoring et des règles d’alerte au go-live ne sont pas optionnels ; sans eux, les échecs restent invisibles jusqu’à ce qu’un commercial remarque qu’il manque des données dans une offre.

Des événements plutôt que du polling. S/4HANA publie des événements métier, et les services d’événements de SAP sur BAIP les transmettent aux abonnés. Au lieu d’une tâche qui cherche des modifications toutes les 15 minutes, l’extension réagit quand quelque chose change. Pour les scénarios à fort volume, cela réduit la latence et la charge inutile.

SAP Build Process Automation orchestre les approbations. Si une offre doit être approuvée par un responsable avant de devenir une commande, ou passer un contrôle de crédit avant sa transmission à S/4HANA, ce workflow tourne dans SAP Build plutôt que dans Sales Cloud V2 ou S/4HANA : à côté, et déployable indépendamment.

Pour aller plus loin dans la construction d’extensions sans toucher au cœur, notre guide clean core avec SAP CAP décrit le modèle d’extension.

Pièges courants et comment les éviter

Presque chaque projet d’intégration que nous avons vu en contient au moins un.

Croire que « intégré par SAP » veut dire « fonctionne sans rien faire ». Le contenu standard est un point de départ. Vous configurez toujours les connexions, définissez les mappings pour votre modèle de données, nettoyez les données de base et testez chaque flux de bout en bout. Budgétez la conception et la configuration de l’intégration comme un chantier à part entière, pas comme une tâche de deux jours.

Modifier les iFlows en place. L’erreur technique la plus fréquente. Copiez l’iFlow standard avant d’y toucher, faites les modifications dans la copie, documentez chaque écart. Cela prend une heure au départ et fait gagner des jours lorsque SAP livre la mise à jour suivante.

Négliger la mise en place du monitoring. Integration Suite intègre un monitoring des messages, mais beaucoup d’équipes déploient des iFlows sans règles d’alerte. Les messages en échec restent alors des jours dans la file. Mettez en place des alertes pour chaque iFlow au go-live, désignez un responsable et rédigez un runbook, afin qu’une mise à jour de produit ou de partenaire commercial en échec soit corrigée le jour même.

Sous-estimer la qualité des données et le mapping. S/4HANA et Sales Cloud V2 ont des modèles de données différents ; structures de partenaires commerciaux, hiérarchies de comptes et classifications de produits ne se correspondent pas trivialement. Selon notre expérience, la conception du mapping et le nettoyage des données prennent autant de temps que la configuration des iFlows, parfois plus. Les clients en double ou les produits sans affectation de domaine commercial apparaissent dès que la réplication démarre ; corrigez-les donc dans le système source avant le go-live.

Si S/4HANA Public Cloud est encore devant vous, l’évaluation de préparation S/4HANA règle les questions de données et de périmètre avant que la conception de l’intégration ne commence. Et si vous choisissez qui doit construire les deux moitiés, notre guide du meilleur partenaire SAP pour le Cloud ERP et le CRM en Suisse explique pourquoi une seule équipe pour les deux côtés est payante précisément à ces jonctions.

---

Des questions sur votre scénario d’intégration ? Que vous lanciez un nouveau déploiement de Sales Cloud V2 ou que vous deviez démêler une intégration existante, parlez à notre équipe.