Le choix qui ne concerne pas vraiment la technologie
Lorsqu'une organisation commence à parler d'une architecture événementielle dans Salesforce, la conversation s'oriente trop rapidement vers « Platform Events ou CDC? » – comme s'il s'agissait d'une question d'outils. En réalité, la question est tout autre : quel côté de l'intégration est la source de vérité, que peut-il se permettre de perdre et qui supporte le coût lorsqu'un message arrive en retard, en double ou pas du tout.
La réponse courte : Change Data Capture (CDC) est adapté lorsqu'un système externe doit savoir que Salesforce a mis à jour une ligne, et qu'il n'est pas nécessaire d'y envelopper une logique métier. Les Platform Events personnalisés sont adaptés lorsque l'on souhaite publier un événement métier significatif – « le client a mis à niveau son forfait », et non pas « le champ Status__c a changé ». Le mauvais choix n'apparaît pas le jour du lancement ; il apparaît lorsque quelqu'un doit reconstituer ce qui s'est passé après une défaillance partielle et découvre qu'il n'y a aucun moyen fiable de le savoir.
Ceux qui recherchent une vue d'ensemble des intégrations Salesforce au-delà des événements la trouveront dans le guide d'architecture CRM.
Trois questions qui déterminent l'architecture avant d'écrire une ligne de code
Avant de choisir un mécanisme, il faut répondre à trois questions. S'en passer d'une est la raison la plus courante pour laquelle les projets d'intégration restent bloqués au stade des tests.
Qui est le propriétaire de la donnée? Si Salesforce est la source de vérité pour l'enregistrement client, les événements sortants de Salesforce (Platform Event ou CDC) sont la direction naturelle. Si le système ERP est le propriétaire, la direction inverse est vraie, et Salesforce doit consommer les événements plutôt que de les publier sur la même entité.
Que peut-on se permettre de perdre? Une notification pour un tableau de bord de gestion peut perdre un message unique sans dommage. Une mise à jour du solde de crédit avant l'approbation d'une transaction ne le peut pas. Cette distinction détermine s'il suffit d'un "Fire-and-Forget" ou si un mécanisme de confirmation et de surveillance des écarts (réconciliation) est nécessaire.
Que se passe-t-il si le message arrive deux fois? Les Platform Events garantissent "At-Least-Once" et non "Exactly-Once". Si la réponse est "nous ne savons pas", la solution n'est pas encore prête pour la production, peu importe la propreté du code.
Platform Events vs CDC — Tableau de décision
| Critère | Platform Event personnalisé | Change Data Capture (CDC) |
|---|---|---|
| Ce qui est publié | Événement métier défini (charge utile personnalisée) | Modification brute de ligne (Avant/Après) |
| Qui construit la logique | Développeur Salesforce, au moment du déclenchement ou du Flow | La plateforme, automatiquement pour tout DML défini |
| Couplage au schéma | Faible — la charge utile est contrôlée par l'éditeur | Élevé — toute modification de la structure de l'objet affecte le consommateur |
| Convient lorsque... | On veut publier une intention métier (« Commande approuvée ») | On veut une synchronisation de données brutes entre systèmes |
| Coût de maintenance | Plus élevé au début (construction de la charge utile et de la logique) | Faible au début, élevé lorsque la structure de l'objet change |
| Rétention | Selon la définition de la licence (heures à jours) | Selon la définition de la licence, généralement identique aux Platform Events |
| Volume recommandé | Événements de domaine à fréquence moyenne | Modifications au niveau de la ligne, y compris à haute fréquence |
Règle pratique : si le consommateur de l'événement doit comprendre "pourquoi" cela s'est produit et pas seulement "quoi" s'est produit, il faut un Platform Event personnalisé. Si le consommateur n'a besoin que d'une copie actualisée des données, le CDC économise une couche de développement entière.
Ordering, Replay et Idempotency : les trois concepts qui transforment la théorie en production stable
Ce ne sont pas des sujets pour une étape tardive du projet – ils déterminent la structure du consommateur dès le premier jour.
Ordering. Les Platform Events sont envoyés dans l'ordre de publication au sein du même sujet, mais la charge et les défaillances partielles peuvent perturber l'ordre de réception côté consommateur. Solution pratique : joindre à chaque événement un horodatage de version ou un numéro de séquence de l'enregistrement original, et permettre au consommateur de rejeter un événement dont la version est inférieure à la dernière version déjà traitée.
Replay. Chaque événement reçoit un Replay ID. Un consommateur qui échoue doit enregistrer le dernier Replay ID qu'il a traité avec succès – non pas en mémoire, mais dans un emplacement persistant (Custom Object, table externe) – et reprendre à partir de là avec la récupération. S'appuyer sur "le système redémarrera depuis le début" ne fonctionne qu'à l'intérieur de la fenêtre de rétention, et au-delà, les événements sont perdus.
Idempotency. Chaque consommateur doit identifier un événement déjà traité, généralement par un identifiant de transaction unique envoyé dans la charge utile. Sans cela, une nouvelle tentative automatique côté émetteur – ou un Replay manuel après une défaillance – se transforme en double mise à jour, création d'un enregistrement en double, ou dans le pire des cas, double facturation.
Cet écart n'est presque jamais découvert lors d'une démo. Il est découvert sous forte charge, lors d'une véritable panne réseau ou d'un changement dans l'environnement de production, et le coût pour le réparer inclut alors déjà la correction des données. Les organisations confrontées à un problème similaire au niveau de l'automatisation trouveront une analyse complémentaire dans la dette technique Salesforce via Flow et Apex.
Cas d'étude : Une chaîne de vente au détail avec 40 succursales et un système de gestion des stocks distinct
Supposons une chaîne de vente au détail hypothétique, « Détaillant du Nord », qui utilise Salesforce Sales Cloud avec des équipes de vente dans 40 succursales, et un système ERP distinct qui gère les stocks en temps réel. Jusqu'à présent, toutes les commandes conclues dans Salesforce étaient transférées à l'ERP via une tâche planifiée qui s'exécutait toutes les 15 minutes – une solution qui faisait que les représentants voyaient parfois des stocks non à jour et approuvaient des commandes pour des produits épuisés.
L'équipe d'architectes a choisi de publier un Platform Event personnalisé nommé Order_Confirmed__e à chaque confirmation de commande, avec une charge utile qui inclut un identifiant de transaction unique, une liste d'articles et leurs quantités. L'ERP écoute l'événement et met à jour les stocks en quelques secondes, tout en vérifiant l'identifiant de la transaction par rapport à une table de transactions déjà traitées – afin d'éviter une double déduction si l'événement arrive deux fois.
De plus, un processus de réconciliation nocturne a été mis en place pour comparer le total des commandes confirmées dans Salesforce au total des mises à jour reçues dans l'ERP, et alerter en cas d'écart dépassant un seuil défini. La raison : même avec une idempotence correcte, on souhaite une détection précoce d'une panne réseau prolongée et non pas seulement s'appuyer sur le fait que l'événement « est certainement arrivé ». Le résultat : le temps de mise à jour est passé de 15 minutes à moins d'une minute, et le nombre d'incidents de stocks erronés a diminué de manière mesurable en un mois après l'implémentation.
Le scénario illustre un principe clé : la valeur n'est pas créée par le simple fait de "passer aux événements", mais par la combinaison d'un événement métier clair, d'une vérification des doublons côté consommateur et d'un processus de surveillance qui identifie les écarts avant qu'ils ne deviennent une plainte client.
Risques courants et actions préventives
| Risque | Comment il se manifeste concrètement | Action préventive |
|---|---|---|
| Publication d'un événement à chaque changement de champ | Le plafond quotidien d'événements est dépassé en quelques jours | Publier des événements de domaine ayant une signification métier, et non des événements techniques à chaque DML |
| Absence de vérification des doublons côté consommateur | Les nouvelles tentatives ou les relectures créent des enregistrements ou des mises à jour en double | Joindre un identifiant de transaction unique et le vérifier avant chaque action |
| Dépendance à l'ordre d'arrivée | Une ancienne mise à jour écrase une mise à jour plus récente | Joindre un horodatage de version et rejeter les événements plus anciens que la dernière version traitée |
| Absence de sauvegarde du Replay ID | Après la défaillance du consommateur, les événements entre la défaillance et la fenêtre de rétention sont perdus | Sauvegarder le Replay ID dans un emplacement persistant et exécuter un Replay automatique lors du redémarrage |
| CDC sur un objet dont la structure change fréquemment | Tout changement de champ rompt le consommateur externe sans avertissement | Définir un contrat de données explicite et communiquer les changements de schéma à l'avance |
| Absence de surveillance métier, seulement surveillance technique | L'intégration est "verte" mais les stocks ou les commandes réels ne correspondent pas | Ajouter une réconciliation quotidienne qui compare les résultats métier entre les systèmes |
Liste de contrôle avant de commencer le développement de la couche événementielle
- ☐ Chaque événement a un propriétaire clair : qui publie et qui est le propriétaire métier de la donnée.
- ☐ Une charge utile fixe et documentée a été définie, non pas une structure qui change à chaque Sprint.
- ☐ Le choix entre Platform Event personnalisé et CDC a été fait en fonction de l'intention métier par rapport au changement brut.
- ☐ Chaque consommateur dispose d'un identifiant de transaction unique et d'une vérification des doublons (Idempotency).
- ☐ La gestion de l'ordre est définie par un horodatage de version, et non par l'ordre d'arrivée.
- ☐ Le Replay ID est enregistré dans un emplacement persistant et un processus de récupération est défini et testé.
- ☐ Un suivi métier (réconciliation) est en place en plus du suivi technique de la file d'attente des messages.
- ☐ Les scénarios de charge et de défaillance partielle ont été testés, et pas seulement le "Happy Path".
- ☐ Le plafond quotidien d'événements (publication + livraison) a été vérifié par rapport au volume attendu en production.
- ☐ Un propriétaire opérationnel a été désigné pour réagir en cas d'écart dans la réconciliation.
Comment mesurer l'efficacité de l'architecture
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Fiabilité de la livraison | Pourcentage d'événements terminés sans nouvelle tentative, et pourcentage réussis après nouvelle tentative | Continue |
| Écarts de réconciliation | Différence entre les enregistrements approuvés à la source et les enregistrements reçus à la destination | Quotidienne |
| Latence de bout en bout | Temps entre l'événement métier et la mise à jour effective chez le consommateur | Continue |
| Utilisation du plafond d'événements | Pourcentage de la limite quotidienne effectivement utilisé | Hebdomadaire |
| Doublons évités | Nombre d'événements identifiés comme doublons et bloqués avant exécution | Hebdomadaire |
Il est recommandé de ne pas choisir plus de trois ou quatre indicateurs pour la première version, et de les mesurer par rapport à une base de référence recueillie avant le passage à l'architecture événementielle, et non par rapport à une impression générale que "c'est maintenant plus rapide".
Pour la planification d'une architecture organisationnelle plus large englobant plusieurs intégrations, il est recommandé d'examiner également les modèles d'intégration de Salesforce et leurs implications pour une architecture Single Org versus Multi Org, car les décisions concernant les événements traversent parfois les frontières organisationnelles.
Résumé
Le choix entre Platform Events et CDC n'est pas une question technique à examiner rapidement au début d'un projet ; il détermine qui est la source de vérité, ce qu'on peut se permettre de perdre et comment le système se comporte en cas de défaillance partielle. Une organisation qui planifie à l'avance l'Ordering, le Replay et l'Idempotency, et ajoute une couche de réconciliation métier plutôt qu'une simple surveillance technique, obtient une intégration capable de supporter la charge et les défaillances partielles. Une organisation qui saute ces étapes obtient un système qui semble fonctionner lors des tests mais qui se brise en silence en production, généralement sans que personne ne s'en aperçoive avant que les dégâts ne soient irréversibles.
Les organisations souhaitant un accompagnement dans la construction d'une couche événementielle fiable dans Salesforce peuvent nous contacter via notre service d'architecture CRM.