Trois questions décisives – l'approche plutôt que l'outil
L'erreur courante lors du choix d'une intégration Salesforce est de commencer par l'outil : MuleSoft, Platform Events, Bulk API ou un simple Webhook. L'outil est une conséquence, pas un point de départ. Trois questions fondamentales déterminent l'approche adéquate :
- À quelle rapidité l'autre partie doit-elle être informée ? Seconde, minute, heure ou jour – c'est la distinction entre le temps réel (Real-Time) et le traitement par lots (Batch).
- Qui est le propriétaire de la donnée à tout moment ? Si la réponse n'est pas univoque, aucune approche technique ne résoudra le problème.
- Que se passe-t-il si l'autre partie n'est pas disponible ? La réponse "nous attendrons" n'en est pas une – un comportement défini est nécessaire : relance (Retry), file d'attente, ou échec visible.
Quiconque répond à ces trois questions avant de choisir une technologie parviendra presque toujours à la même conclusion qu'un architecte expérimenté – mais sans les coûts liés aux essais et erreurs en production. Une exploration plus approfondie du lien entre cette décision et l'architecture globale est disponible dans le Guide d'Architecture CRM.
Carte des approches : quand chacune est pertinente
| Approche (Pattern) | Temps de réponse typique | Exemple d'usage typique | Coût de maintenance | Risque principal |
|---|---|---|---|---|
| Synchrone Requête-Réponse | Millisecondes à secondes | Vérification de crédit avant validation d'une transaction à l'écran | Moyen | Le timeout bloque l'utilisateur |
| Fire-and-Forget | Immédiat à l'envoi, sans attente de résultat | Envoi d'un événement pour créer une tâche dans un autre système | Faible-Moyen | Échec silencieux sans monitoring |
| Batch Périodique | Heures à une journée | Synchronisation quotidienne d'un catalogue produits depuis un ERP | Faible | Décalages temporels entre les systèmes |
| CDC (Change Data Capture) | Secondes à minutes | Mise à jour du statut d'une commande impactant le support | Moyen-Élevé | Charge sur l'Event Bus en cas de modifications multiples |
| Event-Driven (Platform Events / Pub-Sub) | Secondes | Notification d'un événement commercial à plusieurs consommateurs simultanément | Élevé à l'installation, faible en maintenance | Nécessite une discipline sur le schéma et le versioning |
Ce tableau est un point de départ pour la discussion, pas une conclusion définitive. Un seul système peut, et doit parfois, utiliser plusieurs approches en parallèle selon le type de donnée.
Pourquoi la latence ne suffit pas pour décider
La deuxième erreur courante est de décider uniquement en fonction de la latence et d'ignorer la cohérence (Consistency). Une approche rapide qui met à jour un seul côté et laisse l'autre "presque synchronisé" crée un problème plus grave qu'une approche lente mais cohérente – car les utilisateurs cessent de faire confiance aux données et contournent le système.
La question pertinente est double : à quelle vitesse la réponse est-elle requise, et quelle est la gravité d'une situation où les deux parties sont désynchronisées momentanément. Un processus de tarification présenté au client exige à la fois rapidité et cohérence totale – là, une approche synchrone de type Requête-Réponse avec un timeout défini et une gestion explicite des échecs est nécessaire. La mise à jour d'un "nombre de vues d'un article" peut tolérer un délai de quelques minutes – là, Fire-and-Forget ou CDC sont suffisants.
Propriété des données : une décision antérieure à toute approche
Avant de choisir la manière dont la donnée transite entre les systèmes, il faut déterminer où elle est "vraie". Un champ mis à jour dans deux systèmes sans propriétaire défini crée une boucle de synchronisation : A envoie à B, B met à jour et retransmet à A, A renvoie à nouveau. Ce n'est pas un scénario extrême – c'est le résultat prévisible d'une synchronisation bidirectionnelle sans règle de décision claire.
Règle pratique : chaque champ partagé se voit attribuer un propriétaire unique. S'il existe un besoin commercial réel d'édition des deux côtés (par exemple, le service client met à jour une adresse à la fois dans Salesforce et dans l'ERP), une règle de résolution des conflits explicite est ajoutée – le dernier horodatage l'emporte, ou un champ est déterminant et l'autre est uniquement pour l'affichage. La gestion des autorisations autour de ces champs sensibles est abordée dans le Guide du Modèle d'Autorisations Salesforce.
Gestion des pannes : le test que la plupart des projets ignorent
Presque toutes les intégrations passent un test de "chemin heureux" (Happy Path). Peu d'entre elles subissent un test systématique de ces trois scénarios de panne :
- L'autre système n'est pas disponible au moment de l'envoi – Le message est-il mis en file d'attente et renvoyé, ou est-il perdu ?
- Le message arrive deux fois (problème courant avec le Retry automatique et l'Event Bus) – La partie réceptrice crée-t-elle un enregistrement en double ?
- Le message arrive dans le désordre – Une mise à jour de statut "annulé" arrivant avant "approuvé" entraîne-t-elle un résultat erroné ?
Un système qui n'est pas construit comme Idempotent (identifiant unique pour chaque message + vérification de son traitement antérieur) échouera précisément dans les deux premiers scénarios, et généralement sous charge – c'est-à-dire précisément lorsque l'entreprise en dépend le plus. Les limitations de l'API et la gestion du Throttling dans ce contexte sont détaillées dans le Guide des Limites de l'API Salesforce.
Cadre de décision : de la question commerciale à l'approche
| Question posée en premier | Si la réponse est "oui" | Si la réponse est "non" |
|---|---|---|
| L'utilisateur attend-il l'écran pour le résultat de l'intégration ? | Synchrone Requête-Réponse avec timeout défini | Continuer à la question suivante |
| Une mise à jour de quelques minutes d'un seul changement est-elle requise ? | CDC ou Platform Event | Continuer à la question suivante |
| Plusieurs consommateurs différents doivent-ils être informés du même événement ? | Event-Driven avec Pub-Sub | Continuer à la question suivante |
| Est-il commode de traiter un grand volume dans une fenêtre de temps fixe ? | Batch Périodique | Envisager Fire-and-Forget avec file d'attente |
Ceci est un point de départ pour la discussion lors d'une réunion d'architecture, pas une formule exhaustive – il y a toujours des cas limites (par exemple, un volume énorme qui nécessite du CDC mais aussi une réconciliation quotidienne par lots comme filet de sécurité).
Scénario illustratif : Réseau de cliniques privées avec vingt succursales
Imaginons un réseau de cliniques utilisant Salesforce pour la gestion des demandes de patients et un système de facturation distinct qui ne peut pas être remplacé à ce stade. L'exigence : lorsqu'un patient termine un rendez-vous, le système de facturation doit être mis à jour immédiatement, et lorsqu'une facture est mise à jour (par exemple, un paiement reçu), Salesforce doit refléter cela afin que le représentant du service client ne demande pas un double paiement.
Le choix initial de l'équipe a été un Batch nocturne bidirectionnel – simple à mettre en place, mais il a créé un décalage allant jusqu'à 24 heures où les représentants voyaient des informations obsolètes, entraînant des plaintes. La solution retenue en pratique : une direction (fin de rendez-vous de Salesforce vers la facturation) est passée à Fire-and-Forget avec une file de messages et un Retry automatique, car l'utilisateur n'a pas besoin d'attendre. L'autre direction (confirmation de paiement de la facturation vers Salesforce) est passée en CDC, car il s'agit d'un changement ponctuel qui doit arriver en quelques minutes. Le Batch nocturne n'a été conservé que comme mécanisme de Réconciliation – une comparaison quotidienne qui détecte les écarts et alerte, et non comme canal de mise à jour principal.
Le résultat : le temps de mise à jour est passé de plusieurs heures à quelques minutes, et le mécanisme de Réconciliation a détecté deux cas de messages perdus au cours du premier mois – exactement son rôle.
Risques et actions préventives spécifiques à l'intégration
| Risque | Comment se manifeste-t-il dans la pratique | Action préventive |
|---|---|---|
| Manque d'Idempotence | Enregistrements dupliqués après Retry ou panne réseau | Identifiant unique pour le message + vérification de l'existence avant création |
| Source de vérité non définie | Boucle de synchronisation ou mise à jour "gagnante" aléatoire | Propriétaire défini pour chaque champ + règle de résolution des conflits |
| Point-à-point sans couche d'intégration | Toute modification de schéma dans un système rompt une autre connexion | Couche Middleware/API avec contrat de versioning explicite |
| Monitoring technique uniquement | L'intégration est "verte" mais des commandes sont manquantes en réalité | Mesure de Réconciliation commerciale, pas seulement Uptime technique |
| Ignorance des Governor Limits | L'intégration tombe en panne précisément en cas de charge maximale | Planification du Bulkification et du Backoff en amont, et non en réaction |
Liste de contrôle pour le choix d'un pattern d'intégration
- ☐ Le temps de réponse requis est défini en chiffres, et non par le mot "rapide".
- ☐ Un propriétaire unique est défini pour chaque champ partagé entre les systèmes.
- ☐ Il a été vérifié ce qui se passe si l'autre partie n'est pas disponible – et documenté.
- ☐ Il a été vérifié ce qui se passe si un message arrive deux fois.
- ☐ Il a été vérifié ce qui se passe si les messages arrivent dans le désordre.
- ☐ Un mécanisme de Réconciliation existe même lorsque le pattern principal est asynchrone.
- ☐ Les limites d'API et les Governor Limits ont été vérifiées par rapport au volume prévu en période de pointe.
- ☐ Des indicateurs de succès commerciaux, et pas seulement techniques, ont été définis.
Indicateurs pour le suivi continu de l'intégration
Après le déploiement, il est conseillé de suivre seulement trois à quatre indicateurs : le taux de messages réussis au premier essai, le temps de bout en bout réel par rapport au SLA défini, les écarts de Réconciliation quotidiens entre les systèmes, et la proximité des limites de l'API. Une augmentation constante de l'un d'entre eux – et pas seulement une anomalie ponctuelle – est le signal d'une nécessité d'envisager une autre approche, avant que le système ne tombe en production. Les questions d'identité et de permissions d'accès entre systèmes sont détaillées dans le Guide SSO et Identité Salesforce.
Résumé
Le choix d’une approche d’intégration pertinente ne doit pas commencer par la question "quel outil", mais par trois interrogations essentielles : quelle est la rapidité de réponse requise, qui est le propriétaire de la donnée, et que se passe-t-il en cas de défaillance. Le temps réel (Real-Time) est adapté lorsque l'utilisateur attend un résultat ; le CDC et l'Event-Driven conviennent à la mise à jour rapide d'un changement unique ou à la diffusion à plusieurs consommateurs ; le traitement par lots (Batch) est approprié pour un volume important dans une fenêtre temporelle fixe. Quelle que soit l'approche, l'Idempotence, la propriété clairement définie des données et un mécanisme de Réconciliation ne sont pas de simples "extras" – ils sont la condition sine qua non pour que l'intégration supporte une charge réelle et pas seulement une démonstration.
Références professionnelles
- Modèles d'intégration Salesforce — https://architect.salesforce.com/docs/architect/fundamentals/guide/integration-patterns.html
- Guide de décision pour l'intégration de données Salesforce — https://architect.salesforce.com/docs/architect/decision-guides/guide/data-integration.html
- HPI Pro – Architecture CRM — https://hpi.pro/crm-architecture
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data