Connecter SAP Sales Cloud V2 à Business Data Cloud : les modèles d'intégration qui fonctionnent

Nous implémentons SAP Sales Cloud V2 et SAP S/4HANA Public Cloud avec une seule équipe, et longtemps la discussion sur l’analytique autour du CRM s’est terminée à l’un de deux endroits : un export vers un entrepôt de données que quelqu’un maintient, ou s’accommoder des tableaux de bord intégrés. SAP Business Data Cloud (BDC) ouvre une troisième voie. Cet article rassemble les modèles de conception que nous appliquons lorsque les données Sales Cloud V2 rencontrent les données ERP dans BDC, ainsi que les erreurs que nous déconseillons à nos clients.

En bref : utilisez les produits de données SAP partout où ils existent et vérifiez le catalogue de votre release avant de construire quoi que ce soit. Là où les données Sales Cloud V2 ne sont pas encore disponibles comme produit de données, chargez-les une seule fois dans Datasphere et gouvernez-les comme votre propre produit de données. Faites du pipeline-to-cash le premier modèle, alignez tôt trois clés de jointure, laissez les besoins en temps réel dans l’intégration applicative et faites lire à tous les consommateurs le même modèle sémantique.

Avec quoi BDC travaille

SAP a annoncé Business Data Cloud en février 2025. L’offre réunit SAP Datasphere, SAP Analytics Cloud, SAP Business Warehouse et SAP Databricks dans un service géré (SAP Learning : Introducing SAP Business Data Cloud). La brique centrale est le produit de données, que SAP décrit comme un jeu de données affiné, des métadonnées qui le décrivent et un port d’accès ou une API (SAP News, octobre 2025). Sur ces produits de données, SAP construit des applications intelligentes (auparavant appelées insight apps) ; une application Revenue Intelligence était en préversion restreinte en octobre 2025.

Pour un architecte CRM, cela signifie deux choses. D’abord, une partie des données nécessaires arrive modélisée et maintenue par SAP. Ensuite, le reste doit toujours être chargé et modélisé, et la qualité de ce travail décide si la plateforme est rentable. La manière d’activer et de consommer les produits de données gérés par SAP est documentée dans SAP Help.

Les modèles en un coup d’œil

Modèle	À utiliser pour	À éviter pour
1. Produits de données d’abord	Entités standard que SAP livre pour votre release	Reconstruire des données que SAP maintient pour vous
2. Pipeline-to-cash comme premier modèle	Ventes et finance avec des chiffres différents	Démarrer avec cinq domaines à la fois
3. Le temps réel reste dans la couche applicative	Offres, disponibilité, prix au moment de la vente	Tableaux de bord qui veulent du temps réel « au cas où »
4. Un modèle sémantique, de nombreux consommateurs	Stories SAC, notebooks Databricks, Joule	Copies du « chiffre d’affaires » propres à chaque équipe

Modèle 1 : les produits de données d’abord, votre propre produit de données ensuite

Le réflexe hérité de dix ans d’analytique CRM est de construire un pipeline d’extraction. Commencez une étape plus tôt : ouvrez le catalogue des produits de données de votre release et vérifiez quelles entités SAP livre. Les exemples cités par SAP au lancement concernaient des données S/4HANA, SAP Ariba et SuccessFactors ; ne partez donc pas du principe que chaque objet Sales Cloud V2 est déjà disponible. Chaque extracteur construit à côté d’un produit de données existant est un passif qui porte votre nom : il casse quand une API change et ramène la question « de quel montant d’opportunité parle-t-on ? ».

Là où aucun produit de données SAP n’existe pour les entités CRM nécessaires (comptes, opportunités, activités), chargez-les une seule fois, de façon délibérée :

• Chemin de chargement : les API Sales Cloud V2 ou un flux de réplication vers SAP Datasphere, un espace pour les données CRM, aucune copie parallèle.
• Le traiter comme un produit : un responsable, une définition documentée par indicateur, une fréquence de rafraîchissement convenue avec les métiers.
• Planifier la sortie : lorsque SAP livre un produit de données équivalent, basculez les consommateurs dessus et retirez votre flux. Nommez les flux de sorte que ce changement soit une liste de contrôle, pas une enquête.

Les champs d’extension demandent une étape à part. Si votre Sales Cloud V2 contient des champs personnalisés, par exemple le type de machine, la phase de projet ou des données de configuration AVC, prévoyez comment chacun rejoint la couche sémantique et qui en est responsable. Sur un tenant propre, ce sont des heures de modélisation par groupe de champs, pas des semaines.

Modèle 2 : le pipeline-to-cash comme premier modèle

Chaque client le demande ; peu l’ont. Les opportunités sont dans le CRM, les commandes et factures dans l’ERP, et le lien entre les deux est un exercice Excel trimestriel. Avec les données CRM et S/4HANA dans un même tenant BDC, le pipeline-to-cash devient une tâche de modélisation plutôt qu’un projet d’intégration.

Ce sont les clés de jointure qui décident du succès :

• Compte et partenaire commercial. Sur la pile intégrée, les comptes Sales Cloud V2 sont répliqués depuis ou vers les partenaires commerciaux S/4HANA ; la clé existe donc en général. Avant de modéliser, vérifiez les doublons et les comptes créés uniquement dans le CRM.
• Opportunité et commande client. Le lien n’existe que si le processus le crée : une offre ou une commande générée à partir de l’opportunité porte la référence. Les commandes saisies directement dans l’ERP demandent une règle d’affectation, sinon elles restent hors de l’entonnoir.
• Produit et article. Les données de base produit devraient venir de S/4HANA. Les produits en texte libre dans les opportunités ne pourront pas être reliés plus tard.

Le modèle lui-même reste simple : opportunités gagnées face aux entrées de commandes et au chiffre d’affaires facturé, par organisation commerciale, groupe de produits et période. Le bénéfice est la précision des prévisions mesurée par rapport à ce qui a réellement été livré, le chiffre qui transforme la discipline CRM d’un souhait de la direction en indicateur. L’architecture d’intégration entre Sales Cloud V2 et S/4HANA Public Cloud décrit où ces clés naissent côté transactionnel.

Modèle 3 : le temps réel reste hors de la couche analytique

L’erreur de conception la plus fréquente que nous rencontrons consiste à faire passer des besoins opérationnels en temps réel par la plateforme analytique. Un commercial qui a besoin du stock et des prix à jour avant une offre les obtient de l’intégration applicative entre Sales Cloud V2 et S/4HANA, pas de BDC. L’analytique tolère des cycles de rafraîchissement ; les offres, non.

Tracez la limite explicitement dans le document d’architecture : les transactions passent par les API applicatives, l’analyse par les produits de données. Les architectures qui brouillent cette limite héritent des faiblesses des deux côtés, des offres lentes et des tableaux de bord fragiles.

Modèle 4 : un modèle sémantique, de nombreux consommateurs

Une fois la fondation en place, résistez aux variantes par équipe. La story SAC de la direction, le notebook Databricks de l’analyste et un agent Joule qui répond à « où en est le pipeline du T4 par rapport à l’an dernier ? » doivent lire le même modèle gouverné. Dès que quelqu’un crée sa propre version du chiffre d’affaires, vous reconstruisez le problème que vous avez payé pour supprimer. Ici, la gouvernance est le produit lui-même : une définition par indicateur, un responsable par domaine, les demandes de modification via ce responsable.

C’est aussi là que la qualité des données commence à compter davantage que les outils. Les comptes en double et les opportunités orphelines se retrouvent directement chez chaque consommateur. Nous décrivons la séquence de correction dans pourquoi vos données CRM ne valent que ce que vaut votre fondation de données.

Où cela s’inscrit

Cette série a commencé par ce qu’est BDC et ce qu’il advient de Datasphere. Les modèles ci-dessus en sont la partie pratique. La raison stratégique derrière eux est l’IA : un agent ne vaut que le modèle qu’il lit, et un modèle pipeline-to-cash gouverné est ce dont un agent Joule a besoin pour répondre aux questions de chiffre d’affaires avec la même provenance qu’un rapport.

L’analytique CRM et ERP sur une seule fondation réussit le plus facilement lorsqu’une même équipe connaît les deux côtés de la jonction. C’est ainsi que nous travaillons, voir pourquoi l’ERP et le CRM chez un seul partenaire font la différence. Si vous utilisez Sales Cloud V2 et que votre analytique vit encore d’exports, notre pratique BDC commence précisément par ce premier modèle.

Questions fréquentes

Existe-t-il des produits de données natifs pour Sales Cloud V2 dans BDC ?

Vérifiez le catalogue des produits de données pour votre release avant de concevoir quoi que ce soit. Là où SAP livre un produit de données pour les entités dont vous avez besoin, utilisez-le. Sinon, chargez une seule fois les données Sales Cloud V2 dans Datasphere via les API ou un flux de réplication, modélisez-les comme votre propre produit de données gouverné et remplacez-le lorsque SAP en livre un équivalent.

Puis-je combiner les données Sales Cloud V2 et S/4HANA dans un seul modèle BDC ?

Oui, et c’est tout l’intérêt de l’exercice. Les opportunités gagnées dans Sales Cloud V2 sont reliées aux commandes clients, factures et marges de S/4HANA dans un seul modèle sémantique, ce qui donne un reporting pipeline-to-cash sans développer de middleware spécifique. Les clés de jointure (compte et partenaire commercial, opportunité et commande client, produit et article) demandent un atelier d’alignement ; ensuite, elles tiennent.

Qu’en est-il des besoins en temps réel ?

Gardez-les hors de la couche analytique. Les analyses de pipeline et de chiffre d’affaires fonctionnent avec des cycles de rafraîchissement. Un commercial qui a besoin du stock ou des prix à jour avant une offre les obtient de l’intégration applicative entre Sales Cloud V2 et S/4HANA, pas de BDC. Mélanger les deux besoins dans une même architecture est l’erreur de conception la plus fréquente que nous voyons.

Comment les champs d’extension personnalisés de Sales Cloud V2 arrivent-ils dans BDC ?

Planifiez-les explicitement. Des champs d’extension comme le type de machine ou la phase de projet ne font partie d’aucun modèle standard ; chacun demande donc un mappage vers la couche sémantique et un responsable désigné. Sur un tenant propre, c’est une tâche de modélisation de quelques heures par groupe de champs, pas un projet à part.