CDC — Change Data Capture

Définition complète

Le Change Data Capture — CDC — est une famille de techniques de pipeline de données dont l'objectif est d'identifier, de capturer et de propager les modifications survenues dans une base de données source vers un ou plusieurs systèmes cibles, de façon incrémentielle et en temps quasi réel. Une « modification » au sens du CDC recouvre trois types d'opérations : les insertions (nouvelles lignes), les mises à jour (valeurs modifiées dans des lignes existantes) et les suppressions (lignes supprimées).

La méthode CDC basée sur les journaux de transactions (log-based CDC) est aujourd'hui la référence. Elle consiste à lire le journal interne que toute base de données relationnelle maintient pour assurer sa propre durabilité — le Write-Ahead Log (WAL) pour PostgreSQL, le binary log (binlog) pour MySQL, le redo log pour Oracle. Ce journal enregistre séquentiellement chaque opération d'écriture avant qu'elle soit appliquée aux données. Le CDC en extrait les événements sans jamais interroger les tables de production, ce qui lui confère son principal avantage : zéro contention avec les requêtes applicatives.

Il existe d'autres formes de CDC moins performantes : le timestamp-based CDC (qui compare la colonne updated_at entre deux exécutions) et le trigger-based CDC (qui utilise des triggers de base de données pour écrire les changements dans une table de suivi). Ces méthodes sont plus simples à mettre en place mais incapables de détecter les suppressions et plus intrusives pour la base de production. Dans cet article, sauf mention contraire, « CDC » désigne la variante log-based.

Comment implémenter le CDC

La mise en œuvre d'un CDC log-based suit un schéma en quatre étapes indépendant de l'outil choisi.

Les outils SaaS managés (Fivetran HVR, Airbyte Cloud) masquent les étapes 1 à 3 derrière une interface de configuration en quelques clics. Ils sont le bon choix pour les équipes sans expertise Kafka ou sans capacité à opérer Debezium. Debezium reste la référence pour les architectures événementielles complexes ou les contraintes de souveraineté des données.

Exemple concret

Prenons une entreprise SaaS française avec 4 500 clients actifs, opérant une base PostgreSQL hébergée sur AWS RDS. Chaque nuit, le pipeline ELT existant scanne la table subscriptions (1,2 million de lignes) pour alimenter le data warehouse Snowflake. L'exécution prend 47 minutes, bloque parfois les requêtes analytiques en début de journée, et ne capture pas les annulations d'abonnement (opérations DELETE).

Après migration vers Debezium + Kafka + Snowflake Streams, les résultats mesurés sont les suivants : latence réduite de 47 minutes à 8 secondes en moyenne, charge CPU sur RDS pendant la synchronisation réduite de 34 % à 2 %, et capture complète des suppressions permettant enfin de calculer le taux de churn en temps réel avec les données correctes. Le budget mensuel d'infrastructure associé au pipeline passe de 1 840 € à 620 €, car Debezium ne consomme que les différences et non les tables complètes.

L'opération la plus délicate a été la configuration du slot de réplication Postgres et la gestion du snapshot initial — la copie complète des tables existantes avant de commencer la capture incrémentale des changements. Cette étape prend entre 2 et 6 heures selon le volume, et doit être planifiée pendant une fenêtre de faible activité pour éviter de saturer la bande passante réseau vers RDS.

Analyse approfondie

Le CDC résout un problème fondamental de l'architecture de données d'entreprise : comment maintenir des copies cohérentes et fraîches de données opérationnelles dans des systèmes analytiques, sans dégrader les performances de production ni introduire des fenêtres de données manquantes. Les scans complets de table — la solution la plus simple — échouent sur les trois critères dès que le volume de données dépasse quelques dizaines de millions de lignes. Le CDC répond à ces trois critères simultanément.

La gestion des suppressions est l'avantage le plus sous-estimé du CDC. Dans une architecture ELT avec scan incremental basé sur updated_at, les lignes supprimées de la base source restent indéfiniment dans le data warehouse — elles ne disparaissent jamais, car il n'y a aucun signal de suppression. Pour des métriques comme le taux de churn, la cohérence du nombre d'abonnés actifs ou la vérification des stocks, cette limitation est critique et conduit à des dashboards systématiquement faux. Le CDC capture les événements DELETE et permet de propager les suppressions vers les systèmes analytiques avec la même fiabilité que les insertions et les mises à jour.

La cohérence transactionnelle est un autre avantage distinctif du CDC log-based. Comme le journal de transactions préserve l'ordre et les frontières des transactions, le CDC peut garantir que les modifications liées à une même transaction sont propagées ensemble — ce qu'aucune approche par scan ne peut assurer. Pour des cas d'usage comme la synchronisation d'une commande et de ses lignes associées, cette cohérence transactionnelle est essentielle pour éviter des états intermédiaires incohérents dans le data warehouse.

La principale complexité opérationnelle du CDC log-based est la gestion du lag de consommation. Si le consommateur CDC prend du retard — par exemple après une panne ou une surcharge — la base source doit conserver les journaux en attente de consommation. Sur PostgreSQL, un slot de réplication non consommé provoque l'accumulation de WAL segments qui peuvent saturer le disque en quelques heures sur les bases à fort débit d'écriture. Ce risque nécessite un monitoring continu du lag de réplication et des alertes configurées bien en amont du seuil critique.

Le CDC s'inscrit naturellement dans les architectures modernes orientées événements. Quand les événements de changement sont publiés dans Kafka, ils deviennent disponibles pour de multiples consommateurs simultanés : le data warehouse, des caches applicatifs, des moteurs de recherche (Elasticsearch), des systèmes de notification, des microservices downstream. Cette architecture de « capture unique, consommation multiple » réduit la charge sur la base source par rapport à plusieurs connexions de réplication indépendantes, et crée un registre immuable et ordonné de toutes les modifications — un actif architectural de valeur croissante à mesure que l'organisation accumule des cas d'usage analytiques et opérationnels.

Erreurs fréquentes dans la mise en œuvre du CDC

• ✗

  Ne pas monitorer le lag du slot de réplication : un slot Postgres non consommé accumule des WAL segments jusqu'à saturer le disque. Sur une base à fort débit d'écriture (plusieurs milliers de transactions par minute), un lag de 6 heures peut représenter plusieurs dizaines de gigaoctets de journaux retenus. La bonne pratique est d'alerter dès que le lag dépasse 30 minutes, avec un seuil critique à 2 heures, et de disposer d'une procédure documentée pour supprimer un slot bloqué sans perte de données.

• ✗

  Confondre latence CDC et fraîcheur analytique : le CDC réduit la latence d'ingestion à quelques secondes, mais la fraîcheur des données analytiques dépend aussi de la fréquence d'exécution des modèles de transformation dbt et des politiques de cache du data warehouse. Si les transformations dbt s'exécutent une fois par heure, la fraîcheur effective reste d'une heure même avec un CDC à 5 secondes. Il faut dimensionner l'ensemble du pipeline — ingestion, transformation, service — selon la latence analytique réellement requise.

• ✗

  Négliger les changements de schéma : le CDC est sensible aux évolutions de schéma sur la base source. L'ajout, la suppression ou le renommage d'une colonne peut casser le connecteur CDC si le schéma de destination n'est pas mis à jour de façon coordonnée. Les outils managés (Fivetran, Airbyte) gèrent cela automatiquement ; Debezium nécessite une configuration de Schema Registry et des procédures de migration documentées. Sans gestion explicite des évolutions de schéma, un déploiement applicatif anodin peut silencieusement interrompre votre pipeline de données pendant des heures.

Comment Fairview utilise le CDC

Fairview utilise le CDC comme couche d'ingestion principale pour les sources de données transactionnelles à fort débit — systèmes de facturation, CRM, bases produit. Le pipeline CDC alimente le data warehouse opérationnel de Fairview avec une latence inférieure à 60 secondes, ce qui permet de présenter des métriques comme le MRR, le taux de churn et les revenus par segment avec une fraîcheur quasi temps réel. Les suppressions sont capturées et propagées explicitement, garantissant que les comptages de clients actifs et les calculs de rétention sont toujours cohérents avec la réalité opérationnelle. La configuration CDC est entièrement gérée par Fairview — vous connectez vos sources, Fairview s'occupe de la réplication.

Questions fréquentes