Comment intégrer Salesforce avec SAP ou un autre ERP ?

Décider du système maître, objet par objet

Avant tout choix technique, on fixe pour chaque donnée qui fait foi. En général, les clients et les produits sont maîtrisés dans l'ERP et diffusés vers Salesforce ; les leads, opportunités et devis naissent dans Salesforce ; les commandes et factures reviennent de l'ERP. Un objet avec deux maîtres est un conflit garanti.

Dans SAP S/4HANA, clients et fournisseurs sont gérés comme des partenaires commerciaux. C'est l'identifiant du partenaire, stocké dans un champ External ID côté Salesforce, qui fait le lien entre les deux systèmes.

Les flux typiques

• Clients : création ou mise à jour dans l'ERP, diffusion vers les comptes Salesforce.
• Produits et prix de base : diffusés de l'ERP vers le catalogue Salesforce.
• Commandes : créées dans Salesforce à la signature, transmises à l'ERP qui les exécute.
• Statuts, livraisons et factures : remontés de l'ERP vers Salesforce pour les commerciaux.
• Encours et conditions de paiement : consultés à la demande depuis Salesforce.

Le flux des factures et de leurs statuts prend une importance particulière avec la facturation électronique obligatoire. Si les devis et la facturation passent par Revenue Cloud, le découpage des rôles est décrit dans le guide sur le cycle complet avec Revenue Cloud.

Les interfaces disponibles côté SAP

• IDoc : échanges asynchrones par documents, adaptés aux flux de masse comme les clients, commandes et factures, avec suivi et reprise natifs.
• BAPI et RFC : appels synchrones de fonctions métier, utiles pour des créations ou contrôles à la demande.
• OData : services exposés par SAP Gateway ou SAP BTP, adaptés aux lectures et aux intégrations web modernes.
• SAP Integration Suite : la couche d'intégration de SAP BTP, qui orchestre ces interfaces et expose des API REST.

Sur S/4HANA, et en particulier dans sa version cloud, on privilégie les API publiées par SAP, comme API_BUSINESS_PARTNER pour les partenaires commerciaux ou API_SALES_ORDER_SRV pour les commandes de vente, plutôt que des développements spécifiques. C'est le principe du « clean core » : garder le cœur de l'ERP standard pour faciliter les mises à jour.

Les interfaces côté Salesforce

• API REST et Bulk 2.0 pour les lectures et écritures, avec External ID pour les upserts idempotents.
• Platform Events et Change Data Capture pour publier les changements Salesforce vers l'extérieur sans scrutation.
• Appels sortants en Apex pour des besoins ciblés, avec des Named Credentials pour l'authentification.

Avec ou sans middleware

Une intégration point à point tient pour un ou deux flux simples. Au-delà, un middleware, comme SAP Integration Suite, MuleSoft ou un ETL déjà en place, apporte le routage, la transformation, la journalisation et la reprise sur erreur au même endroit. Le critère n'est pas la taille de l'entreprise mais le nombre de flux et le besoin de supervision.

Quel que soit l'outil, découper les intégrations en couches réutilisables, une pour l'accès à chaque système et une pour chaque processus métier, évite de reconstruire les mêmes connecteurs pour chaque nouveau besoin.

Rendre les flux rejouables

Une intégration fiable est idempotente : rejouer un message ne crée pas de doublon. Les upserts sur External ID côté Salesforce et les identifiants de message côté ERP garantissent ce comportement. Chaque message porte aussi un identifiant de corrélation qui permet de suivre une commande de bout en bout, de Salesforce à la facture.

Gérer les erreurs comme un flux à part entière

Une intégration sans gestion d'erreurs explicite finit en tickets et en ressaisies. Chaque flux doit définir ce qui se passe quand l'ERP est indisponible, quand une donnée est rejetée par une règle de validation, quand un identifiant est inconnu : file d'attente et rejeu, alerte à un responsable, enregistrement en erreur visible dans Salesforce.

Les tests se font avec des données réelles anonymisées, sur le cas nominal comme sur des scénarios d'erreur.