Connecter Salesforce à un ERP, un outil de facturation, un entrepôt de données ou une application métier n'est jamais un détail. C'est souvent là que se jouent le délai, le budget et la réussite d'un projet. Trois familles de solutions dominent : MuleSoft (l'iPaaS de Salesforce), un iPaaS tiers, ou du développement d'API sur mesure. Aucune n'est universellement supérieure. L'enjeu pour une ETI est d'arbitrer selon ses volumes, ses compétences internes et son horizon, sans se retrouver verrouillée par un choix pris trop tôt.

Pourquoi la question de l'intégration se pose si vite

Salesforce est rarement seul. Dès la première phase, il faut échanger des données avec un ERP, un PIM, un outil de gestion d'abonnements ou une base client historique. La qualité de ces flux conditionne la fiabilité de ce que voient les équipes commerciales et le service client. Un CRM alimenté par des données incohérentes perd rapidement la confiance de ses utilisateurs, ce qui pèse directement sur l'adoption.

La difficulté : le choix d'intégration engage sur plusieurs années. Changer d'approche en cours de route coûte cher, car les flux se ramifient et les dépendances se multiplient. D'où l'importance de cadrer avant de choisir un outil.

3
grandes familles de solutions d'intégration
2-5 ans
horizon typique d'un choix d'architecture d'intégration
1er
facteur de confiance des utilisateurs : la qualité des données

Les trois voies, sans idéalisation

MuleSoft : l'iPaaS de l'éditeur

MuleSoft appartient à Salesforce. Son intégration avec l'écosystème est native, avec des connecteurs prêts à l'emploi et une gouvernance d'API structurée (catalogue, réutilisation, sécurité). Pour des organisations qui manipulent de nombreux systèmes et veulent industrialiser leurs API, c'est une plateforme robuste.

Le revers est budgétaire. Le modèle de licence de MuleSoft peut représenter un coût significatif, souvent perçu comme surdimensionné pour une ETI qui n'a que quelques flux à gérer. La montée en compétence sur l'outil demande aussi du temps ou l'appui d'un prestataire spécialisé. Enfin, le fait que ce soit une plateforme de l'éditeur crée une dépendance supplémentaire au même fournisseur.

Un iPaaS tiers

Les plateformes d'intégration indépendantes proposent également des connecteurs Salesforce et une logique de flux visuels. Leur promesse : un coût d'entrée souvent plus accessible, une neutralité vis-à-vis de l'éditeur et une bonne couverture pour des besoins standards (synchronisation de comptes, remontée de commandes, mise à jour de statuts).

Les limites apparaissent sur des cas complexes ou des volumes élevés, où la tarification à la consommation ou au nombre de tâches peut grimper. Il faut aussi vérifier la pérennité du fournisseur et la profondeur réelle de son connecteur Salesforce, car tous ne couvrent pas les objets et les événements de la même façon.

Des API maison

Développer ses propres flux via les API REST et Bulk de Salesforce donne un contrôle total. Pas de licence d'intégration supplémentaire, une logique parfaitement adaptée au métier, et une indépendance vis-à-vis d'un éditeur d'iPaaS.

Cette liberté a un prix : la charge de développement, de test et surtout de maintenance repose entièrement sur l'équipe. Chaque évolution de Salesforce ou d'un système connecté doit être suivie. Sans documentation ni monitoring, le "maison" devient une dette technique. Cette voie convient aux organisations disposant de compétences internes solides et prêtes à investir dans la durée.

Le piège le plus courant n'est pas de choisir la mauvaise solution, mais de la choisir avant d'avoir cartographié ses flux. Sans inventaire des systèmes, des volumes, de la fréquence et de la criticité de chaque échange, l'arbitrage repose sur une intuition — et c'est ainsi qu'on se verrouille.

Comment arbitrer concrètement

Aucune règle absolue, mais quelques critères structurants permettent de comparer objectivement :

  • Nombre et complexité des flux. Deux ou trois synchronisations simples n'appellent pas la même réponse qu'un SI à quinze systèmes interconnectés.
  • Volumes et fréquence. Un batch nocturne de quelques milliers d'enregistrements diffère d'un flux temps réel à fort débit, tant en architecture qu'en coût.
  • Compétences internes. L'API maison suppose une équipe capable de maintenir dans le temps ; l'iPaaS déplace une partie de cette charge vers l'outil et l'éditeur.
  • Budget total sur la durée. Comparer non pas le coût de démarrage mais le coût cumulé sur trois à cinq ans, licences et maintenance incluses.
  • Réversibilité. À quel point est-il possible de changer d'approche plus tard sans tout réécrire ?

Limiter le verrouillage : les bons réflexes

Le verrouillage n'est pas une fatalité. Quelques principes d'architecture réduisent la dépendance quel que soit l'outil retenu :

  • Isoler la logique métier des connecteurs. Concevoir des couches d'échange (mapping, transformation) séparées de l'outil, pour pouvoir en changer sans tout reprendre.
  • Documenter les flux. Un référentiel des échanges, à jour, garde de la valeur même si l'outil change.
  • S'appuyer sur des standards. Les API REST de Salesforce sont documentées publiquement ; s'y référer plutôt qu'à des mécanismes propriétaires facilite la portabilité.
  • Ne pas surdimensionner d'emblée. Commencer avec le juste nécessaire, quitte à monter en puissance si les volumes le justifient.

Une approche mixte est fréquente et souvent saine : un iPaaS pour les flux standards, quelques API maison pour les cas très spécifiques. La cohérence d'ensemble compte plus que le choix d'une plateforme unique.

Faire vérifier son architecture par un tiers

Le choix d'intégration est aussi une question de compétences côté prestataire. Un intégrateur habitué à MuleSoft aura tendance à le recommander ; un développeur préfèrera l'API maison. Ce biais est normal, mais il gagne à être objectivé. Cadrer le besoin par les faits — nombre de flux, volumes, criticité, budget cible — permet de comparer les propositions sur la même base et de repérer un surdimensionnement.

C'est précisément l'approche d'INTEGREER : qualifier le besoin à partir de données publiques et objectives, puis aider à trouver le prestataire dont les compétences correspondent, sans partenariat commercial avec l'éditeur qui orienterait le conseil. L'objectif est de choisir une architecture pour de bonnes raisons, pas par défaut ou par habitude de son prestataire.

Arbitrer entre MuleSoft, un iPaaS tiers et des API maison n'est pas un choix technique isolé : c'est une décision d'architecture qui engage votre budget et votre autonomie sur plusieurs années. En posant les bons critères en amont et en préservant la réversibilité, vous gardez la main.

Un projet Salesforce à cadrer ?

Trouver le bon intégrateur Salesforce

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