Pourquoi l'intégration ERP avec Salesforce échoue, et comment y remédier

Les intégrations SAP-Salesforce échouent le plus souvent pour des raisons métier, pas techniques. La synchronisation tourne, mais les données sont trop anciennes pour la décision que prend l'utilisateur, les deux systèmes ne s'accordent pas sur le bon enregistrement client, ou personne n'est responsable du flux quand une mise à jour le casse. Le remède consiste à concevoir à partir de la décision de l'utilisateur, à nettoyer d'abord les données, à choisir un middleware adapté à votre échelle et à donner à chaque flux un responsable et un plan en cas d'échec.

Cet article s'adresse aux DSI, aux responsables des opérations commerciales et aux responsables de l'intégration qui connectent Salesforce à SAP. Il couvre les quatre schémas d'échec, les options d'intégration, ce dont une intégration fiable a besoin et un modèle de spécification.

J'ai travaillé avec des entreprises où même un décalage d'une heure entre les systèmes provoquait des erreurs de devis qui faisaient perdre des ventes. La cause habituelle : personne n'avait demandé quelle fraîcheur devaient avoir les données de stock pour qu'un commercial s'en serve pour établir un devis.

Une intégration peut fonctionner techniquement et être commercialement défaillante. C'est par cette distinction qu'il faut commencer.

Une fréquence de synchronisation inadaptée à la décision

La synchronisation par lots convient pour certaines données. Elle ne convient pas pour le stock disponible à la vente (available-to-promise), les prix ou le statut des commandes, quand les clients attendent une réponse immédiate.

Le schéma d'échec : l'équipe d'intégration construit ce qui est techniquement commode pour les volumes et fixe les intervalles de lots sur des critères techniques. Personne côté métier ne vérifie si cette fréquence soutient la décision que prend l'utilisateur.

Posez une question avant de spécifier quoi que ce soit : quel est l'âge maximal des données pour qu'elles restent utiles ? Une mise à jour quotidienne peut suffire pour les données de base clients. Pour la disponibilité du stock en vente B2B, tout ce qui dépasse quinze minutes pose problème.

1. 01Données de base clientsDe SAP vers Salesforce, 24 heures
2. 02Listes de prixDe SAP vers Salesforce, 1 heure
3. 03Disponibilité du stockDe SAP vers Salesforce, 15 minutes
4. 04Opportunité gagnéeDe Salesforce vers SAP, immédiat
5. 05Statut des commandesDe SAP vers Salesforce, 15 minutes
6. 06Facture et paiementDe SAP vers Salesforce, 24 heures

Le devis, la commande et la facture concordent

Écarts de qualité des données

Si le nom de l'entreprise dans Salesforce n'est pas formaté comme dans les données de base clients de SAP, chaque synchronisation crée des écarts à corriger à la main.

J'ai travaillé avec des équipes qui passaient des heures chaque semaine à rapprocher les informations clients de base entre Salesforce et l'ERP, et j'ai vu des projets où la seule cartographie des hiérarchies de clients a pris des semaines parce que les deux systèmes ne définissaient pas un « compte » de la même façon. Les systèmes avaient été maintenus séparément pendant des années et avaient dérivé de manières que personne n'avait cartographiées.

Nettoyez les données avant d'intégrer. Cela paraît évident. C'est l'étape la plus systématiquement sautée.

Une architecture inadaptée à l'échelle

L'intégration point à point fonctionne pour deux systèmes, quelques flux et des processus stables. C'est la façon la moins chère de commencer.

Elle ne passe pas à l'échelle. Ajoutez un module SAP, une nouvelle unité commerciale dans Salesforce ou un troisième système, et les connexions se multiplient. Chacune doit être maintenue, testée et dépannée séparément.

Un middleware (SAP Integration Suite, MuleSoft, Boomi ou équivalent) vous donne une couche unique et gouvernée, avec supervision et gestion des erreurs centralisées. La contrepartie est un investissement initial en architecture et en gouvernance. Les entreprises qui déploient un middleware sans lui donner de responsable nommé se retrouvent avec les mêmes problèmes que le point à point, plus une plateforme que personne ne comprend.

Aucune gouvernance de l'intégration

Chaque version de Salesforce et chaque support package SAP peut casser un flux : changements d'API, nouvelles règles de validation, champs modifiés, nouvelles exigences d'authentification. Les intégrations construites puis oubliées tombent à la première mise à niveau que personne n'a testée en non-régression. C'est la défaillance la plus courante que je vois après le go-live.

SAP Integration Suite. La plateforme d'intégration de SAP sur SAP BTP, et le choix naturel dans les paysages centrés sur SAP. Elle gère bien les IDocs, les BAPI, OData et les formats de messages SAP, et propose du contenu prêt à l'emploi pour les scénarios SAP courants. Les processus métier complexes exigent toujours des flux d'intégration spécifiques et de vraies compétences d'intégration. Si vous êtes encore sur SAP PI/PO, sachez que sa maintenance standard prend fin à la fin de 2027 : les nouveaux flux Salesforce ne doivent donc pas y être construits. Sur RISE, vérifiez quels droits d'usage SAP BTP votre contrat inclut déjà avant d'en acheter davantage.

MuleSoft. Propriété de Salesforce depuis 2018, avec une large bibliothèque de connecteurs, un connecteur SAP S/4HANA officiel et des modèles d'accélération pour l'order-to-cash SAP. Un bon choix si vous le possédez déjà. L'inconvénient pour les organisations très orientées SAP : MuleSoft est un autre domaine de compétences, et l'équipe qui pilote votre programme SAP n'est probablement pas celle qui devrait concevoir votre architecture MuleSoft.

Boomi. Une plateforme d'intégration cloud (indépendante de Dell depuis 2021), avec des connecteurs SAP et Salesforce et un ticket d'entrée plus bas que MuleSoft. Raisonnable pour les organisations de taille intermédiaire qui veulent un middleware gouverné sans le coût ni la complexité de MuleSoft.

API point à point. Les appels REST ou SOAP directs entre Salesforce et SAP évitent le coût d'un middleware. Ils exigent un versionnement d'API rigoureux, des tests de non-régression à chaque version et une équipe qui comprend les deux systèmes. Très bien pour des cas simples et stables. Une machine à fabriquer de la dette dès que c'est complexe.

Mon guide de SAP CPI et d'Integration Suite détaille davantage la plateforme côté SAP, et les cinq options de CRM pour SAP comparent les CRM eux-mêmes.

1. Une spécification de chaque flux : champs, sens, fréquence, correspondance des clés, et ce qui se passe quand les deux systèmes ne sont pas d'accord.
2. Une conception explicite des cas d'échec. Quand une synchronisation échoue, que deviennent les données en transit ? Combien de nouvelles tentatives ? Qui reçoit l'alerte ? Quelle est la reprise manuelle ? La plupart des intégrations sont sous-conçues sur ce point.
3. Des tests de non-régression avant chaque mise à niveau. Salesforce publie trois versions majeures par an, et SAP livre ses propres support packages et mises à jour. Une suite automatisée couvrant les flux critiques doit tourner avant chacune d'elles.
4. Une supervision avec alertes. Une défaillance silencieuse est pire qu'une défaillance bruyante. Des erreurs qui s'accumulent pendant des jours sont bien plus difficiles à corriger que des erreurs repérées en quelques minutes.
5. Un responsable. Une personne qui sait ce que fait l'intégration, voit quand elle casse et dispose des accès et de l'autorité pour la réparer.

Remplissez une ligne par flux avant que quiconque rédige un document de spécification. Si une cellule est vide, le flux n'est pas prêt à être construit. Les valeurs ci-dessous sont des illustrations ; convenez des vôtres avec les personnes qui utilisent les données.

Flux	Sens	Déclencheur et fréquence	Ancienneté maximale acceptable des données	Système de référence	En cas d'échec	Responsable
Données de base clients	De SAP vers Salesforce	À chaque modification	24 heures	SAP	Nouvelle tentative, puis alerte au data steward	Propriétaire des données de base clients
Disponibilité du stock	De SAP vers Salesforce	À la demande ou quasi temps réel	15 minutes	SAP	Afficher l'indicateur « à vérifier auprès des opérations »	Responsable des systèmes de la supply chain
Listes de prix et conditions	De SAP vers Salesforce	À chaque modification	1 heure	SAP	Bloquer le devis si le prix est périmé	Responsable de la tarification
Opportunité gagnée vers commande client	De Salesforce vers SAP	À la clôture	Immédiat	Salesforce jusqu'à la création de la commande, puis SAP	Mettre en file d'attente et alerter les opérations commerciales	Responsable des opérations commerciales
Statut des commandes et des livraisons	De SAP vers Salesforce	À chaque jalon	15 minutes	SAP	Nouvelle tentative, puis alerte au support d'intégration	Responsable de l'intégration
Statut des factures et des paiements	De SAP vers Salesforce	Quotidien	24 heures	SAP	Alerter les systèmes financiers	Responsable des systèmes financiers

La colonne « ancienneté maximale acceptable des données » est celle que la plupart des équipes ne remplissent jamais. Convenez-en avec les utilisateurs qui prennent les décisions, pas avec la seule équipe d'intégration. Si vous êtes déjà en retard, les retards de livraison de SAP Integration Suite en présentent les causes courantes.

Les enregistrements clients ne concordent pas. Cause : les deux référentiels clients n'ont jamais été alignés. Remède : rapprocher avant le go-live, faire de SAP le système de référence des données clients et faire respecter la correspondance dans l'intégration.

Le statut des commandes ne se met pas à jour dans Salesforce. Cause : l'intégration couvre le passage du devis à la commande, mais pas les retours de statut. Remède : renvoyer les mises à jour de statut de SAP SD vers Salesforce à chaque jalon de la commande.

Les prix des devis diffèrent des prix facturés. Cause : les prix sont tenus à la main dans Salesforce et s'écartent des conditions de prix de SAP. Remède : faire de SAP la référence des prix et en alimenter Salesforce par l'intégration.

L'intégration casse après une mise à jour SAP. Cause : aucun test de non-régression de l'intégration dans le plan de mise à niveau. Remède : inclure les tests de non-régression de l'intégration dans le périmètre de chaque mise à jour SAP.

Salesforce peut-il s'intégrer à SAP ?

Oui, via SAP Integration Suite, MuleSoft, Boomi, d'autres plateformes d'intégration ou des API directes. Les flux typiques sont la synchronisation des données de base clients, le passage d'une opportunité gagnée à une commande client, le retour du statut des commandes et des livraisons vers Salesforce, les prix remontés dans Salesforce pour les devis, et le statut des factures et des paiements. Une synchronisation des données de base clients est simple. Un quote-to-cash complet avec des prix complexes, de nombreuses sociétés (company codes) et un stock en temps réel est un projet conséquent.

Salesforce est-il un ERP ou un CRM ?

Un CRM. Il gère le pipeline, les opportunités, les interactions clients, le marketing et le service. Il ne comptabilise pas d'écritures et ne gère pas les stocks. SAP est l'ERP de la finance, des achats, des stocks et de la production. Bien intégrés, un commercial voit le stock et le statut des paiements dans Salesforce, et la finance voit la valeur des affaires dans SAP.

Pourquoi les intégrations ERP-CRM échouent-elles le plus souvent ?

Parce que les exigences sont définies à partir de la technologie au lieu de la décision de l'utilisateur. L'intégration est construite correctement selon une spécification qui était fausse : des données vieilles de quatre heures, des prix qui ne correspondent pas aux factures, des statuts qui arrivent en retard. Avant de rédiger une spécification technique, documentez les décisions que chaque groupe d'utilisateurs prend avec les données et la fraîcheur dont il a besoin.

Comment maintenir dans la durée une intégration ERP-Salesforce ?

Lancez des tests de non-régression automatisés sur les flux critiques avant chaque version de Salesforce et chaque mise à jour SAP. Supervisez chaque flux critique avec des alertes qui se déclenchent à l'échec, et non dans un rapport de fin de journée. Nommez un responsable qui a accès à la supervision et participe à la planification des changements des deux systèmes.

Quand utiliser SAP Integration Suite pour l'intégration de Salesforce ?

Quand SAP est le système dominant, quand vous avez accès à SAP BTP et quand les flux mettent en jeu du contenu propre à SAP, comme les IDocs, les BAPI ou les formats de messages SAP. C'est un choix plus faible si vous avez déjà beaucoup investi dans MuleSoft ou Boomi, si votre équipe manque de compétences d'intégration SAP ou si SAP n'est qu'un acteur mineur dans des flux surtout non SAP. Pour les nouveaux programmes RISE où Salesforce est dans le périmètre, c'est le point de départ naturel.

Combien de temps dure un projet d'intégration ERP-Salesforce ?

Un périmètre standard (synchronisation des données de base clients, du devis à la commande et statut de commande de base) avec du contenu prêt à l'emploi prend généralement de 8 à 16 semaines, du cadrage au go-live, à condition de disposer de données propres et d'un développeur d'intégration dédié. Un quote-to-cash complet avec des prix complexes, plusieurs entités, la gestion du crédit et un stock en temps réel prend généralement de 4 à 9 mois. Les problèmes de données découverts en cours de projet et les flux ajoutés pendant la construction sont les causes habituelles de dépassement : réalisez donc une évaluation de la qualité des données avant le début de la construction.