Du package à la production : S/4HANA Public Cloud et Sales Cloud V2

Pour relier SAP S/4HANA Public Cloud et SAP Sales Cloud V2 via SAP Integration Suite, vous copiez deux packages standard du SAP Business Accelerator Hub dans votre tenant, vous les configurez et les déployez, vous chargez listes de codes et données de base dans un ordre fixe, et ce n’est qu’ensuite que vous activez offres et commandes. La logique propre va dans des iFlows séparés, jamais dans ceux de SAP.

TL;DR : Deux packages standard couvrent les données de base (version 1.0.48) et les processus de vente (version 1.0.20), état au 7 octobre 2026. Configurer, ne pas modifier : un artefact modifié ou renommé ne reçoit plus les mises à jour SAP. Chargez d’abord données organisationnelles et listes de codes, puis produits, puis partenaires commerciaux, puis transactions. Testez un enregistrement et une offre de bout en bout, plus trois cas d’erreur. En exploitation, chaque type d’erreur a besoin d’un responsable nommément désigné.

Sofiene Karaja a expliqué l’architecture d’intégration et Marek Budik le modèle de responsabilités du quote-to-cash. Cet article traite de l’exploitation, du package à la production. Si SAP BAIP (anciennement BTP) est nouveau pour vous, commencez par l’introduction à SAP BAIP et les premiers pas avec un compte d’essai de Lea Marijanovic.

Deux modes d’exploitation : géré par SAP ou géré par le client

La page produit de SAP Sales Cloud V2 liste deux guides d’intégration pour S/4HANA Cloud Public Edition. Le premier est le guide « Set Up and Managed by SAP ». Il s’applique uniquement si votre contrat inclut les services de mise en place de l’intégration par SAP.

Dans cette option, SAP crée les utilisateurs, systèmes et accords de communication dans S/4HANA, configure les flux d’intégration dans SAP Cloud Integration, met en place les value mappings par défaut dans Sales Cloud V2 et renouvelle les certificats. SAP est propriétaire des flux d’intégration, les surveille et les gère.

Après la remise, vous configurez Sales Cloud V2, ajoutez des value mappings au-delà des valeurs par défaut, effectuez le chargement initial, mettez en place l’authentification unique et corrigez les erreurs de données métier dans les deux applications. Vous ne devez pas modifier la configuration de communication créée par SAP.

Le second guide, « SAP Sales Cloud and SAP Service Cloud Version 2 Integration with SAP S/4HANA Cloud Public Edition », couvre la voie gérée par le client. Il se trouve sur le site de support SAP et exige une connexion SAP ; je décris donc cette voie ci-dessous à partir des packages et de la documentation de Cloud Integration. Elle s’applique lorsque votre contrat n’inclut pas le service de mise en place de SAP, ou lorsque vous avez besoin d’une logique au-delà du périmètre standard, car des flux détenus par SAP ne laissent pas de place aux vôtres.

Ce que contient le contenu standard

Les deux packages se trouvent sur le SAP Business Accelerator Hub, maintenus par SAP, composant de support CEC-CRM-INT. Versions au 7 octobre 2026 :

Package	Version	Contenu
Master Data with SAP S/4HANA Cloud Public Edition (Sales et Service Cloud V2)	1.0.48	46 iFlows, 1 value mapping, 1 collection de scripts
Sales Processes with SAP S/4HANA Cloud Public Edition (Sales Cloud V2)	1.0.20	12 iFlows, 1 value mapping

Regroupé, le package de données de base couvre :

• Partenaires commerciaux dans les deux sens, ainsi que les relations entre partenaires dans les deux sens, chacun avec son propre iFlow de confirmation vers l’émetteur.
• Produits : produit, type de produit, groupe de produits et une confirmation pour la réplication des produits.
• Prix : conditions de prix, type de liste de prix client, spécification de prix par groupe de clients, conditions d’escompte et une lecture du paramétrage des prix.
• Données organisationnelles : société, organisation commerciale, domaine commercial, agence commerciale, groupe de vendeurs, canal de distribution, secteur d’activité, division.
• Listes de codes : motifs de blocage de commande, de livraison et de facturation, classification Incoterms, priorité de livraison, groupe de clients, classification ABC, secteur industriel, forme juridique, codes de région, unité de mesure, motif VIP, service, titre de fonction, cycle de facturation.
• Objets de service et autres : équipements, postes techniques, taux de change, collaborateurs et une lecture des stocks de produits.

Le package des processus de vente couvre : offres de suivi dans S/4HANA à partir d’une opportunité, simulation d’offre et de commande client, commandes de suivi à partir d’une offre, réplication des commandes client vers et depuis S/4HANA, lecture des détails des offres et commandes de suivi, et suppression des références d’offre et de commande.

Trois artefacts portent le préfixe « Deprecated » : l’ancien flux des codes de région, un ancien flux de commande de suivi et une ancienne simulation d’offre. Déployez le jumeau actuel, pas les deux.

Ordre d’activation et configuration

Sur la voie gérée par le client, la séquence dans votre tenant est la suivante :

1. Copiez les deux packages de la zone Discover vers votre espace de conception. Le nom technique du package est fixé à ce moment et ne peut plus être modifié ensuite.
2. Configurez les paramètres externalisés de chaque iFlow (adresses, noms des identifiants). Utilisez les paramètres externalisés plutôt que de modifier le flux lui-même.
3. Déployez le matériel de sécurité : identifiants et certificats auxquels renvoient les paramètres.
4. Maintenez les value mappings des deux packages pour vos codes.
5. Mettez en place la communication des deux côtés : utilisateur, système et accords de communication dans S/4HANA, et système de communication avec services entrants et sortants dans Sales Cloud V2. Reprenez les noms exacts des scénarios de communication dans le guide de mise en place SAP de votre release.

Vient ensuite le chargement. Le guide SAP indique l’ordre du chargement initial : société, structure organisationnelle, groupe de produits, produit, partenaires commerciaux et relations, collaborateurs. Les listes de codes passent avant tout cela. Offres et commandes viennent en dernier, dès qu’un client de test et un produit de test existent des deux côtés.

Deux prérequis du guide SAP : avant la réplication des listes de codes, il faut un groupe d’autorisations pour les vues d’extraction de données (SAP Knowledge Base Article 3525713), et les identifiants de personnel diffèrent entre les deux systèmes, ils nécessitent donc un mapping via l’identifiant externe de l’affectation de travail.

Standard ou propre : où placer votre logique

La documentation SAP sur les mises à jour des packages d’intégration SAP est sans ambiguïté. Un artefact modifié ne reçoit plus de mises à jour, un artefact renommé non plus. Les paramètres externalisés configurés survivent à une mise à jour du package. SAP recommande de se limiter à la configuration du contenu standard.

Situation	Approche	Coût à la prochaine mise à jour du package
Autres points de terminaison, identifiants, valeurs de code	Configurer paramètres et value mappings	Aucun, les réglages sont conservés
Champ ou règle de mapping supplémentaire	iFlow propre séparé, appelé depuis le flux standard là où celui-ci offre un exit	Faible, le flux standard continue de recevoir les mises à jour
Le flux standard ne fait pas ce qu’il faut	Copier l’iFlow standard, modifier la copie, documenter l’écart	Élevé : vous reportez chaque correction SAP à la main
Nouveau scénario non couvert par SAP	iFlow propre séparé dans un package dédié	Aucun pour le contenu standard

La recommandation SAP séparer les modifications du contenu préconfiguré décrit le schéma : flux propres déployés sur le même tenant, appelés via des customer exits et l’adaptateur ProcessDirect. Nos conventions : un préfixe client sur chaque package et iFlow propre, un nouveau numéro de version à chaque transport, une courte note sur l’écart dans les documents du package.

Tester : un enregistrement, une offre, trois erreurs

Testez sur les tenants de test, avec un enregistrement que vous pouvez suivre à chaque étape.

#	Test	Résultat attendu
1	Modifier un partenaire commercial dans S/4HANA	Compte mis à jour dans Sales Cloud V2, message de confirmation terminé
2	Opportunité, offre avec simulation en direct, commande de suivi	Prix de S/4HANA dans l’offre, numéro de commande visible dans Sales Cloud V2
3	Valeur de code sans value mapping	Message en erreur avec un motif lisible, rien d’écrit à moitié
4	Offre avec un produit inconnu dans S/4HANA	La simulation ou le document de suivi échoue de manière visible, le commercial voit pourquoi
5	Envoyer deux fois la même modification	Pas de doublon dans le système cible ; documenter le comportement réel

Notez qui a déclenché chaque test et où vous avez vu le résultat : votre premier manuel d’exploitation.

Surveillance en exploitation

Les messages en erreur apparaissent à trois endroits. Dans Cloud Integration, Monitor Message Processing liste chaque exécution avec son statut. Dans Sales Cloud V2, Settings, Integration, Message Monitoring affiche les messages entrants et sortants avec les statuts Successful, Error ou Pending, avec la charge utile et le détail de l’erreur. S/4HANA dispose de sa propre surveillance des messages.

SAP Cloud ALM Integration & Exception Monitoring réunit le tout en un seul endroit pour les composants pris en charge : surveillance des messages, suivi par attributs métier comme un numéro de commande, et alertes sur les messages en erreur qui arrivent dans une Alert Inbox où vous attribuez une personne chargée du traitement. La page Business Object montre l’état de la réplication des données de base.

Rythme	Contrôle	Responsable
Quotidien	Alertes ouvertes dans Cloud ALM, messages en Error dans Cloud Integration	Responsable de l’intégration
Quotidien	Erreurs de données métier dans Sales Cloud V2 et S/4HANA	Key user du système source
Hebdomadaire	Messages bloqués en Pending, erreurs récurrentes par iFlow	Responsable de l’intégration
Hebdomadaire	Libellés « Update Available » dans l’espace de conception, dates d’expiration des certificats	Responsable de l’intégration
À chaque mise à jour du package	Rejouer les tests 1 à 5 avant le transport en production	Responsable de l’intégration avec les key users

Le retraitement suit les responsabilités : corrigez les données à la source, puis redéclenchez la modification. Un renvoi sans correction échoue simplement une deuxième fois.

Pour aller plus loin : S/4HANA Public Cloud, SAP BAIP et l’intégration de Service Cloud V2. Vous voulez passer en revue votre propre paysage ? Parlons-en.

Questions fréquentes

Faut-il exploiter l’intégration dans notre propre tenant SAP Integration Suite ?

Pas toujours. Si votre contrat inclut le service de mise en place de l’intégration par SAP, SAP configure les flux d’intégration, en est propriétaire, les surveille et les gère. Sinon, vous copiez les packages standard de SAP dans votre propre tenant Integration Suite et vous les exploitez vous-même.

Dans quel ordre charger les données ?

Le guide SAP indique cet ordre pour le chargement initial : société, structure organisationnelle, groupe de produits, produit, partenaires commerciaux avec leurs relations, collaborateurs. Les listes de codes viennent d’abord, les flux transactionnels comme les offres et les commandes seulement lorsque les données de base sont complètes.

Peut-on modifier un iFlow standard du package SAP ?

Techniquement oui, les deux packages autorisent les modifications. Mais la documentation SAP est claire : un artefact modifié ou renommé ne reçoit plus de mises à jour. Configurez là où c’est possible et placez votre propre logique dans des iFlows séparés, à côté des flux standard.

Qui corrige un message en erreur en exploitation ?

Les erreurs techniques (connexion, certificat, déploiement) reviennent au responsable de l’intégration. Les erreurs de données métier (mapping manquant, client bloqué, produit inconnu) reviennent au key user du système source. Même dans l’option gérée par SAP, le guide SAP laisse les erreurs de données métier au client.