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

SAP livre des contenus d’intégration standard pour relier Sales Cloud V2 à S/4HANA Public Cloud. Ce n’est pas une intégration à construire de zéro — c’est une intégration à configurer, déployer et maintenir. La nuance est importante. Pour notre guide complet du stack intégré SAP CX + ERP, lisez notre guide du stack intégré.

TL;DR : SAP fournit des iFlows préconfigurés dans SAP Integration Suite pour relier Sales Cloud V2 à S/4HANA Public Cloud. Ces flux couvrent la réplication des Business Partners, le catalogue produits, les conditions tarifaires, la commande client et le statut de facture. La logique personnalisée vit sur BTP en side-by-side, pas dans les systèmes SAP eux-mêmes. Nos projets DACH atteignent le go-live en 14 semaines en médiane.

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

L’intégration s’appuie entièrement sur SAP BTP comme couche médiane. Sales Cloud V2 expose des API OData V4. S/4HANA Public Cloud expose ses propres API OData. SAP Integration Suite, un service sur BTP, joue le rôle de chef d’orchestre : il exécute les iFlows qui transforment, mappent et acheminent les données entre les deux systèmes. Aucun appel direct point à point entre les deux applications — tout passe par Integration Suite.

Pourquoi cette architecture ? Parce qu’elle découple les deux systèmes. Quand SAP met à jour Sales Cloud V2 ou S/4HANA, l’iFlow absorbe les changements de contrat API sans que vous ayez à modifier votre logique métier. C’est aussi là que vous trouvez la surveillance des erreurs, les alertes et le journal de traitement — indispensables après le go-live.

Les contenus d’intégration standard

SAP publie des packages d’intégration dans SAP Integration Suite via le catalogue de contenu. Ces packages regroupent les iFlows correspondant aux flux de gestion standard entre Sales Cloud V2 et S/4HANA Public Cloud. Vous les découvrez, vous les déployez dans votre tenant Integration Suite, vous adaptez les mappings à votre modèle de données et vous activez.

Ce que SAP livre en standard couvre l’essentiel de ce dont une organisation commerciale a besoin :

• Réplication du Business Partner de S/4HANA vers Sales Cloud V2
• Synchronisation du catalogue produits et des hiérarchies
• Transfert des conditions tarifaires (listes de prix, remises par client)
• Passage de la commande client de Sales Cloud V2 vers S/4HANA
• Retour du statut de facture et de paiement vers Sales Cloud V2

Deux points à clarifier. Premièrement, « standard » ne signifie pas « sans effort » : chaque iFlow nécessite une configuration des paramètres de connexion, un mapping des champs personnalisés et des tests en bonne et due forme. Deuxièmement, les packages SAP évoluent. SAP les met à jour. Si vous modifiez directement un iFlow standard, vous perdrez ces mises à jour.

Réplication des données de base

Les données de base, c’est le fondement. Si un Business Partner, un produit ou un tarif est incorrect dans Sales Cloud V2, tout ce que le commercial fait à partir de là est faux. C’est pourquoi la réplication des données de base est le premier flux à configurer et le plus critique à valider.

Business Partner. S/4HANA est la source de vérité pour les comptes clients et les fournisseurs. L’iFlow réplique les Business Partners créés ou modifiés dans S/4HANA vers les comptes et contacts de Sales Cloud V2. Le mode événementiel est préférable au mode par lots : quand un nouveau client est créé dans S/4HANA, le commercial doit le voir dans Sales Cloud V2 en quelques minutes, pas le lendemain matin.

Produits et catalogue. Les références produit, descriptions, unités de mesure et hiérarchies de produits viennent de S/4HANA. Sales Cloud V2 les utilise pour la création de devis. Un catalogue désynchronisé signifie des devis avec des références inexistantes ou des prix incorrects. Cela se voit vite. Et cela fait mauvaise impression.

Conditions tarifaires. Les listes de prix et les remises spécifiques par client vivent dans S/4HANA. L’iFlow les réplique vers Sales Cloud V2 pour que le commercial voie les bons prix lors de la création d’un devis — sans appel au back-office à chaque fois.

Un avertissement sur la qualité des données : si vos données de base dans S/4HANA contiennent des doublons, des formats incohérents ou des données incomplètes, vous répliqueriez exactement ce problème dans Sales Cloud V2. Le nettoyage des données de base avant l’activation est une étape non négociable, pas optionnelle.

Flux transactionnels

Une fois les données de base en place, les flux transactionnels entrent en jeu. C’est là que la valeur métier est la plus visible pour l’équipe commerciale.

Du devis à la commande. Le commercial crée un devis dans Sales Cloud V2, le valide avec le client et le convertit en commande. L’iFlow transfère cette commande vers S/4HANA, qui prend le relais pour le traitement : livraison, facturation, recouvrement. Sales Cloud V2 n’est pas un système de gestion des commandes — son rôle s’arrête à la confirmation de la commande.

Statut de facture et paiement. Quand S/4HANA crée une facture et qu’elle est payée, cette information remonte vers Sales Cloud V2. Le commercial voit l’état de paiement directement sur l’affaire ou le compte. Cela évite les appels au service comptabilité pour savoir si un client a payé avant de le rappeler.

Un point sur le timing : ces flux ne sont pas synchrones au sens strict. Il y a un délai de quelques minutes entre l’événement dans un système et sa visibilité dans l’autre. Pour la quasi-totalité des usages, c’est acceptable. Si vous avez besoin de vérifications de stock en temps réel au moment de la création du devis, c’est un flux supplémentaire à configurer — faisable via appel OData direct, mais à planifier explicitement dès le début du projet.

Pour les flux côté service — tickets, base installée, escalades — le même principe s’applique. Lisez l’intégration Service Cloud V2 et S/4HANA pour les scénarios spécifiques au service.

Où vit la logique personnalisée : BTP side-by-side

Les iFlows standard SAP ne couvrent pas tout. Chaque organisation a des règles métier spécifiques : des approbations de devis selon des seuils, des validations de crédit, des notifications vers des systèmes tiers, des calculs de marge avant confirmation de commande. Cette logique ne va pas dans Sales Cloud V2, ni dans S/4HANA. Elle va sur BTP, en side-by-side.

Le principe est celui du Clean Core : les deux systèmes SAP restent standards. La logique personnalisée vit dans une extension déployée sur BTP, qui communique avec Sales Cloud V2 et S/4HANA via leurs API.

Integration Suite, Event Mesh, Build

Integration Suite gère les iFlows. C’est là que les transformations de données, les mappings et la logique de routage s’exécutent. Si vous avez un mapping complexe entre votre modèle de données interne et le modèle S/4HANA, l’iFlow est le bon endroit pour le gérer — pas dans le code d’une extension.

SAP Event Mesh sur BTP est la couche de messagerie événementielle. Quand un événement se produit dans Sales Cloud V2 ou S/4HANA — création d’une opportunité, mise à jour d’un statut de commande —, Event Mesh le publie. Vos extensions BTP s’y abonnent et réagissent. Cela découple les systèmes proprement et élimine le polling.

SAP Build peut orchestrer des processus d’approbation. Quand un devis dépasse un seuil de remise, Build peut déclencher un workflow d’approbation, notifier les approbateurs, attendre leur validation et ne transmettre la commande à S/4HANA qu’une fois approuvée. Visible, auditable, configurable sans code.

Sur nos projets DACH, nous atteignons un go-live médian en 14 semaines pour la combinaison Sales Cloud V2 + S/4HANA Public Cloud, avec 92 % d’adoption six mois après le go-live. Plus de 12 migrations depuis V1. L’architecture BTP side-by-side est le facteur qui différencie les projets qui réussissent de ceux qui se transforment en chantiers permanents.

Problèmes courants et comment les éviter

Après plusieurs projets Sales Cloud V2 + S/4HANA en région DACH, les mêmes problèmes reviennent. Pas les mêmes industries, pas les mêmes équipes — les mêmes erreurs d’architecture. Voici les quatre que nous rencontrons le plus souvent.

« SAP intégré » ne signifie pas « ça marche tout seul ». C’est l’hypothèse la plus dangereuse. Le fait que SAP fournisse des iFlows standard ne dispense pas de les configurer, les tester et les valider avec de vraies données de production. Une équipe qui déploie les iFlows sans test de charge et sans validation des mappings se retrouve avec des surprises au go-live. Planifiez une phase de test de bout en bout avec des volumes représentatifs.

Modifier les iFlows standard directement. Compréhensible : un champ manque, une règle spécifique est nécessaire, la modification semble mineure. Le problème arrive quand SAP publie une mise à jour du package. Votre modification est écrasée — ou vous n’appliquez pas la mise à jour pour ne pas la perdre. La règle : copiez l’iFlow standard, modifiez la copie et documentez le delta précisément. Vous restez maintenable.

Sauter la surveillance des erreurs. Integration Suite journalise chaque exécution d’iFlow. Chaque erreur est visible dans le tableau de bord. Mais si personne ne consulte ce tableau de bord après le go-live, les erreurs silencieuses s’accumulent. Un Business Partner qui n’a pas répliqué. Une commande qui n’est pas passée dans S/4HANA. Le commercial pense que la commande est confirmée — elle n’existe pas dans l’ERP. Configurez des alertes. Assignez un responsable opérationnel.

Sous-estimer l’effort de mapping et la qualité des données. Les mappings entre le modèle de données Sales Cloud V2 et S/4HANA semblent simples en théorie. En pratique, chaque organisation a des champs personnalisés, des conventions de nommage spécifiques et des données historiquement approximatives. Le mapping prend du temps. La qualité des données prend du temps. Comptez-y deux à trois semaines supplémentaires par rapport à l’estimation initiale, surtout si vous migrez depuis SAP C4C ou un CRM tiers.

Sur un projet récent, le client estimait deux semaines pour la validation des données de base. Il en a fallu six. Pas parce que l’équipe était lente — parce que S/4HANA contenait 4’200 Business Partners avec des données de contact obsolètes ou incomplètes. Ces données auraient répliqué directement dans Sales Cloud V2 si nous n’avions pas bloqué la bascule. La leçon : auditez les données de base dans S/4HANA avant de commencer l’intégration, pas pendant.

Pour connecter Sales Cloud V2 à S/4HANA Public Cloud dans votre organisation, parlez à nos architectes d’intégration. Nous travaillons sur ce stack depuis plusieurs années, en région DACH et au-delà.