Connecter Salesforce à un ERP (SAP, Oracle E-Business Suite ou S/4HANA, Sage X3) est rarement un simple raccordement technique. C'est un choix d'architecture qui engage la fiabilité de la donnée, les coûts de maintenance sur plusieurs années et la capacité à faire évoluer le système d'information. Cet article compare quatre patterns d'intégration éprouvés, leurs conditions d'usage et les questions à poser avant de trancher.

Pourquoi l'intégration ERP est le vrai sujet d'un projet Salesforce

Dans une ETI, l'ERP reste le système de référence pour les données financières, les stocks, la facturation et souvent le référentiel produits ou tiers. Salesforce, lui, porte la relation commerciale, le pipeline et le service client. Les deux mondes doivent se parler : un commercial a besoin de connaître le crédit disponible d'un client, un compte doit être créé une seule fois, une commande signée dans Salesforce doit devenir une commande facturable dans l'ERP.

La difficulté n'est pas de faire transiter une donnée d'un système à l'autre. Elle est de garantir la cohérence dans la durée : qui est maître de quelle information, comment gérer les erreurs, quel volume et quelle fraîcheur sont nécessaires. Le pattern d'architecture retenu conditionne tout cela.

3
systèmes souvent concernés (ERP, CRM, référentiel)
2
sens de synchronisation à arbitrer par objet
5+
années de maintenance à anticiper dès la conception

Pattern 1 — Point-à-point (connexion directe)

Le principe est de relier directement Salesforce à l'ERP, via l'API REST/SOAP de Salesforce et l'interface exposée par l'ERP (BAPI/IDoc pour SAP, web services pour Sage X3). Chaque flux est développé spécifiquement.

Quand c'est pertinent

  • Peu de flux (deux ou trois objets à synchroniser).
  • Budget d'entrée réduit et besoin de démarrer vite.
  • Un seul ERP et un périmètre stable.

Limites

Le point-à-point vieillit mal. Chaque nouvelle intégration ajoute un lien direct, jusqu'à créer un « plat de spaghettis » difficile à maintenir. La gestion des erreurs, des rejeux et du monitoring est souvent artisanale. Un changement de version de l'ERP peut casser plusieurs flux à la fois.

Le point-à-point paraît économique au démarrage, mais le coût de maintenance croît avec le nombre de connexions. Au-delà de trois ou quatre flux, il devient rarement le bon choix pour une ETI qui prévoit d'évoluer.

Pattern 2 — Middleware / ESB (bus applicatif)

Ici, un intermédiaire centralise les échanges : ESB traditionnel (Talend, Mulesoft en mode on-premise, ou solutions SAP PI/PO côté SAP). Salesforce et l'ERP ne se parlent plus directement, ils publient et consomment via le bus.

Quand c'est pertinent

  • Système d'information déjà équipé d'un ESB que l'on souhaite réutiliser.
  • Nombreux systèmes à interconnecter au-delà du couple CRM/ERP.
  • Besoin de transformations de données complexes et de règles métier centralisées.

Limites

Le middleware demande des compétences dédiées et une gouvernance claire. Le coût de licence et d'exploitation est significatif. Pour une ETI dont le seul besoin est de connecter deux ou trois applications cloud, il peut être surdimensionné.

Pattern 3 — iPaaS (intégration cloud managée)

L'iPaaS (Integration Platform as a Service) est la version cloud et managée du bus : MuleSoft Anypoint (dans l'écosystème Salesforce), mais aussi des plateformes indépendantes comme Boomi, Workato ou Talend Cloud. Ces outils proposent des connecteurs préconstruits vers Salesforce, SAP, Oracle et Sage, ainsi que du monitoring intégré.

Quand c'est pertinent

  • Volonté d'externaliser l'infrastructure d'intégration et de réduire l'exploitation interne.
  • Plusieurs applications SaaS à connecter au fil de l'eau.
  • Besoin de traçabilité, d'alerting et de rejeu sur les flux.

Limites

Le modèle de licence, souvent basé sur le volume de transactions ou le nombre de connecteurs, peut devenir coûteux à mesure que les flux augmentent. Il faut aussi éviter le verrouillage fournisseur en documentant les mappings et la logique métier indépendamment de l'outil.

Attention aux modèles de facturation à la consommation : un pic d'activité ou une reprise de données massive peut faire dériver la facture. Simulez les volumes réels avant de contractualiser.

Pattern 4 — Event-driven (architecture événementielle)

Plutôt que d'interroger les systèmes à intervalles réguliers, l'approche événementielle diffuse des événements en quasi-temps réel. Salesforce propose Platform Events et Change Data Capture ; côté ERP, on s'appuie sur des mécanismes de publication d'événements et un broker de messages (Kafka, par exemple).

Quand c'est pertinent

  • Besoin de fraîcheur de la donnée proche du temps réel (stock, disponibilité, statut de commande).
  • Volumes élevés et découplage fort souhaité entre systèmes.
  • Roadmap SI orientée microservices et scalabilité.

Limites

C'est le pattern le plus exigeant en maturité technique. La gestion de l'ordre des événements, de l'idempotence et de la reprise sur incident demande une conception rigoureuse. Il se combine souvent avec un iPaaS plutôt qu'il ne le remplace.

Comment arbitrer entre les quatre patterns

Aucun pattern n'est universellement supérieur. Le choix se construit à partir de quelques questions structurantes :

  • Quels objets synchroniser, dans quel sens ? Comptes, contacts, produits, commandes, factures — et pour chacun, définir le système maître.
  • Quelle fraîcheur est réellement nécessaire ? Un batch nocturne suffit souvent pour la facturation ; le temps réel n'est justifié que pour certains cas (stock, encours client).
  • Quels volumes ? Quelques centaines d'enregistrements par jour ne posent pas les mêmes contraintes que plusieurs centaines de milliers.
  • Quelle est la roadmap SI ? Le nombre d'applications à intégrer à moyen terme pèse lourd dans le calcul.
  • Quelles compétences internes ? Un pattern élégant mais impossible à maintenir en interne est un risque.

En pratique, beaucoup d'ETI démarrent avec un iPaaS pour la souplesse et la traçabilité, réservent l'event-driven aux flux réellement sensibles au temps réel, et n'utilisent le point-à-point que pour des cas isolés et tactiques.

Les points de vigilance transverses

Quel que soit le pattern, certains sujets doivent être cadrés dès la conception :

  • Gouvernance de la donnée : un référentiel clair du système maître par objet évite les conflits de mise à jour.
  • Gestion des erreurs et rejeux : que se passe-t-il si l'ERP est indisponible pendant une synchronisation ?
  • Sécurité et conformité : les échanges de données personnelles doivent respecter le RGPD ; la CNIL rappelle les obligations de minimisation et de traçabilité.
  • Réversibilité : documenter les mappings indépendamment de l'outil pour ne pas dépendre d'un seul prestataire.

Ce que cela implique dans le choix du prestataire

L'intégration ERP est un domaine où l'expérience concrète compte : connaître les particularités des IDoc SAP, des BAPI, des web services Sage X3 ou des API Oracle change la trajectoire du projet. Au moment de sélectionner un intégrateur, il est utile de vérifier des réalisations documentées sur votre ERP précis, pas seulement une compétence Salesforce générale, ainsi que la manière dont le prestataire aborde la gouvernance de la donnée et la maintenance dans la durée.

C'est précisément le rôle d'un tiers de confiance : aider à cadrer le besoin d'intégration à partir de critères objectifs, puis mettre en relation avec des intégrateurs dont le profil correspond au pattern et à l'ERP en jeu.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

Mise en relation gratuite · sans engagement · qualification par la donnée publique