Salesforce expose plusieurs façons de faire circuler la donnée. Le choix entre REST, Bulk API, Change Data Capture, Platform Events, webhooks ou synchronisation planifiée dépend du volume, de la latence et de la capacité du SI à absorber les événements.
Le mauvais choix ne se voit pas toujours en recette. Il apparaît quand les volumes montent, que les retries s’accumulent, que les quotas approchent et que les équipes ne savent plus quelle donnée est à jour.
Une intégration Salesforce API doit donc être pensée pour la production : filtrage, reprise, idempotence, observabilité, gouvernance des objets et protection du SI cible.
Cette décision est rarement purement technique. Elle engage la fraîcheur commerciale, la qualité du support, la charge de l’ERP, le coût d’infrastructure et la capacité des équipes à expliquer un retard. Le bon choix est celui qui reste lisible quand les volumes changent.
Il faut aussi accepter que plusieurs modes cohabitent. Un traitement Bulk peut alimenter une base de reporting, un flux CDC peut suivre des changements sensibles, et une synchronisation planifiée peut suffire pour des enrichissements moins critiques.
La question qui évite les mauvaises architectures
Avant de choisir Bulk ou CDC, il faut demander : quel retard métier est acceptable, combien d’événements peuvent arriver en pic, et que fait-on si le SI cible ralentit ?
Pourquoi Salesforce casse parfois en volume
Salesforce peut devenir très bruyant : un changement de compte déclenche des mises à jour, un import corrige des milliers de contacts, une automatisation modifie des opportunités et plusieurs systèmes attendent un signal.
Si chaque événement déclenche un appel immédiat, le SI cible subit la charge au lieu de la maîtriser.
Choisir REST, Bulk, CDC ou événement
REST convient à des opérations unitaires contrôlées. Bulk sert les traitements de masse. CDC aide à suivre des changements. Les événements conviennent à certains scénarios, mais ne remplacent pas une stratégie de reprise.
Le bon mode dépend du besoin métier : fraîcheur attendue, volume, criticité, fenêtre de traitement et coût d’un retard.
Dimensionner volumes, quotas et fenêtres
Une intégration doit estimer les volumes moyens, les pics, les imports, les corrections et les traitements de nuit. Les quotas API ne sont pas une abstraction : ils structurent l’architecture.
Le dimensionnement doit aussi tenir compte des systèmes aval : ERP, data warehouse, marketing, support ou portail client.
Arbitrer fraîcheur, coût et criticité
Toutes les données Salesforce n’exigent pas le temps réel. Un changement de statut commercial critique peut mériter une faible latence ; un enrichissement reporting peut attendre une synchronisation planifiée.
Réduire la latence sans besoin clair augmente souvent le coût d’exploitation et le risque de saturation.
Filtrer les changements à valeur métier
Un changement technique ou cosmétique ne mérite pas toujours un traitement aval. Il faut filtrer les objets, champs et statuts qui portent une décision métier.
Ce filtrage limite les cascades d’appels et protège les quotas. Il rend aussi les dashboards plus lisibles, car les événements suivis ont un sens opérationnel.
Protéger le SI cible sous charge
Le SI aval doit pouvoir ralentir sans perdre la preuve. Files d’attente, regroupement, priorisation, limites de débit et reprise doivent être prévus avant les pics.
Sans backpressure, un incident temporaire devient une dette de correction : événements perdus, retries désordonnés, doublons ou statuts contradictoires.
Prévoir replay, retry et idempotence
Un événement Salesforce peut être rejoué ou traité en retard. Chaque traitement critique doit avoir une clé de reprise et une règle de non-doublon.
La reprise doit dire ce qui a été reçu, ignoré, traité, rejeté ou rejoué. C’est la seule façon de réparer sans deviner.
Surveiller backlog, erreurs et latence
Le dashboard doit suivre latence, backlog, taux d’erreur, quotas, événements filtrés, retries, rejets et délais par famille d’objet. Un taux de succès global ne suffit pas.
Les alertes doivent aussi nommer l’impact métier : contrats en attente, comptes non synchronisés, commandes bloquées ou factures non visibles.
Gouverner les objets sensibles
Les comptes, opportunités, contrats, commandes, factures et consentements ne doivent pas être traités comme des objets techniques équivalents. Leur propriétaire métier doit être explicite.
- Filtrer les événements à valeur métier.
- Choisir le mode API selon volume, latence et criticité.
- Conserver une clé de reprise par changement traité.
- Surveiller quotas, backlog et latence par objet.
- Tester les pics d’import et les ralentissements aval.
La gouvernance doit aussi prévoir les changements Salesforce eux-mêmes : nouvelle automatisation, champ renommé, import massif, règle de validation ajoutée ou modification d’un process commercial. Ces évolutions peuvent changer la charge sans modifier l’architecture.
Une revue régulière des flux permet d’éviter l’accumulation silencieuse. On regarde les objets les plus bruyants, les erreurs récurrentes, les champs qui déclenchent trop d’événements et les systèmes aval qui absorbent mal les pics.
Cette discipline fait la différence entre un connecteur qui marche en démonstration et une intégration Salesforce qui tient une vraie exploitation multi-équipes.
Conclusion : le bon mode dépend du run
L’intégration Salesforce doit être choisie pour tenir en production, pas seulement pour livrer vite. Bulk, CDC, événements et REST peuvent cohabiter, à condition de leur donner des responsabilités distinctes et observables.
Pour compléter, le guide Salesforce API pose les bases CRM, tandis que l’article Salesforce contrats, commandes et factures traite les objets business sensibles.
