Change Data Capture (CDC) comme méthode d'ingestion

Le Change Data Capture (CDC) résout un problème que ni le batch complet ni le polling ne traitent efficacement : détecter et propager uniquement les modifications survenues sur une source de données, sans avoir à comparer des snapshots entiers ni à interroger la source en continu. Dans l'écosystème Salesforce, Salesforce CDC publie des événements de changement sur les objets standards et personnalisés, consommables directement par Data Cloud ou par des abonnés externes.

Comment fonctionne Salesforce Change Data Capture

Salesforce CDC repose sur la plateforme d'événements Salesforce (Platform Events / Pub/Sub API). Dès qu'un enregistrement est créé, modifié, supprimé ou restauré (undelete) sur un objet activé pour CDC, une notification est publiée automatiquement sur un canal dédié, au format /data/{ObjectName}ChangeEvent. Chaque événement contient :

• Les champs modifiés (et non l'enregistrement complet, sauf configuration contraire) — optimisation importante pour le débit.
• Des métadonnées d'en-tête (ChangeEventHeader) : type de changement (CREATE, UPDATE, DELETE, UNDELETE), horodatage de commit, identifiants des enregistrements affectés.
• Le numéro de séquence permettant de garantir l'ordre de traitement par transaction.

Contrairement à un trigger Apex classique, CDC fonctionne de manière asynchrone et découplée : la publication de l'événement ne bloque pas la transaction d'origine et les abonnés peuvent être hors ligne temporairement sans perte de données grâce à la rétention des événements (généralement 72 heures en standard, jusqu'à 3 jours étendus selon l'add-on).

Activer CDC sur un objet

L'activation se fait dans Setup > Change Data Capture, en sélectionnant les objets à surveiller :

Setup > Integrations > Change Data Capture
[x] Account
[x] Contact
[x] Opportunity
[x] Custom_Order__c

Chaque objet activé génère un canal d'événements distinct. Il faut être sélectif : activer CDC sur un objet à très fort volume de transactions (millions de mises à jour/jour) sans besoin métier réel génère un bruit inutile et consomme les limites d'événements de la plateforme.

CDC comme source d'ingestion pour Data Cloud

Data Cloud consomme nativement les objets CRM Salesforce via le Salesforce CRM Connector, qui s'appuie en interne sur ce même mécanisme CDC pour propager les changements de manière incrémentale après le chargement initial. Concrètement, cela signifie que :

1. Le premier chargement d'un objet CRM vers Data Cloud effectue un full sync initial.
2. Les synchronisations suivantes ne transfèrent que les deltas, détectés via CDC, réduisant considérablement la charge par rapport à un re-scan complet périodique.
3. La fréquence de synchronisation incrémentale est configurable par data stream, généralement de quelques minutes à une heure.

Pour des sources externes (hors CRM Salesforce natif), CDC peut aussi être exploité en amont via des outils comme Debezium (sur des bases de données MySQL, PostgreSQL, Oracle) qui publient les changements vers un bus d'événements (Kafka), lui-même relié à Data Cloud via l'Ingestion API ou un connecteur streaming — une architecture fréquente pour synchroniser un ERP legacy sans imposer de polling batch lourd sur la base de production.

Limites et pièges du CDC

Le CDC n'est pas une solution magique et impose une discipline opérationnelle :

• Fenêtre de rétention limitée : si un consommateur est hors service plus longtemps que la fenêtre de rétention des événements, des changements sont définitivement perdus — il faut alors relancer un full sync de rattrapage.
• Pas d'historique complet : CDC capture les changements à partir du moment de son activation ; il ne reconstitue pas l'historique antérieur, qui doit être chargé séparément (Bulk API par exemple).
• Volumétrie des événements : certaines opérations de masse (mise à jour en masse via Data Loader, batch Apex) génèrent un pic d'événements CDC qui peut saturer temporairement un abonné mal dimensionné.
• Champs non inclus par défaut : seuls les champs modifiés sont envoyés sauf si l'option "Send all fields" (via un champ "gate") est activée sur l'objet, ce qui a un impact sur les besoins de reconstruction complète côté cible.

Ne construisez jamais un pipeline reposant à 100% sur CDC sans mécanisme de réconciliation périodique. Un audit hebdomadaire comparant le volume d'enregistrements source vs Data Cloud permet de détecter une dérive silencieuse causée par une perte d'événements.

CDC vs Streaming SDK : quand utiliser quoi

Ces deux mécanismes sont complémentaires plutôt que concurrents : CDC est adapté à la propagation des changements sur des données de référence structurées (comptes, contacts, commandes) déjà stockées dans un système transactionnel, tandis que le Streaming SDK cible des événements comportementaux générés à la volée (clics, vues de page) qui n'existent dans aucune base avant leur émission. En combinant les deux, on obtient une architecture d'ingestion à la fois fraîche et fiable sans imposer de charge excessive sur les systèmes source.