CDC & streaming temps réel : Debezium, Kafka Connect, Materialize, Flink

Quand le batch nocturne ne suffit plus — détection de fraude en quelques secondes, supply chain qui doit réagir à chaque mouvement de stock, personnalisation produit qui se calque sur le comportement de l'utilisateur — il faut passer au temps réel. Le Change Data Capture (CDC) et le streaming sont les deux briques qui rendent cela possible sans réécrire les applications source. Voici comment articuler Debezium, Kafka, Flink et les streaming databases modernes.

Pourquoi le temps réel devient la norme

Trois forces poussent le streaming :

• Attentes utilisateur : un client qui clique veut une réponse cohérente immédiatement.
• Cas d'usage métier : fraude, supply, IoT, personnalisation, alerting, surveillance.
• Maturité technologique : Kafka, Flink, Debezium sont stables et déployés à grande échelle.

Le batch reste indispensable pour beaucoup de reporting — mais les événements deviennent la colonne vertébrale de l'architecture data.

CDC en bref

Le Change Data Capture capte les modifications d'une base de données sans interroger la base : on lit les logs de réplication (binlog MySQL, WAL PostgreSQL, redo log Oracle, change feed SQL Server) et on les publie comme événements.

Approche	Mécanisme	Avantage	Limite
Trigger-based	Triggers SQL qui écrivent dans une table	Universel	Charge sur la base, latence, intrusif
Polling	Lire WHERE updated_at > x régulièrement	Simple	Latence, charge requête, manque les DELETE
Log-based (CDC moderne)	Lecture des logs de transaction	Faible impact, latence basse, complétude (INSERT/UPDATE/DELETE)	Configuration plus exigeante

Le standard 2026 : log-based, via Debezium.

L'écosystème Debezium / Kafka

Debezium

• Connecteurs CDC open source pour MySQL, PostgreSQL, Oracle, SQL Server, MongoDB, Cassandra.
• Émet les événements avant / après changement sur des topics Kafka.
• Gère le snapshot initial + le flux incrémental.
• Déployable comme Kafka Connect ou Debezium Server standalone.

Kafka Connect

• Framework de connecteurs source/sink autour de Kafka.
• Source : Debezium, JDBC, fichiers, MQ, SaaS via Confluent Hub.
• Sink : data warehouse (Snowflake, BigQuery, Databricks), S3, Elasticsearch, etc.
• Permet de brancher des sources et destinations sans écrire de code applicatif.

Schema Registry

• Avro / Protobuf / JSON Schema versionnés.
• Brique de compatibilité ascendante entre producteurs et consommateurs.
• Voir Data Contracts.

Traitement temps réel : Flink, Kafka Streams, ksqlDB

Outil	Positionnement	Forces
Apache Flink	Stream processing avancé	Stateful, exactly-once, joins streaming, fenêtres complexes, scale extrême
Kafka Streams	Lib Java intégrée aux apps	Léger, pas de cluster externe
ksqlDB	SQL sur Kafka	Accessible, prototype rapide
Spark Structured Streaming	Streaming intégré au monde Spark	Pratique si stack Databricks

Flink est devenu le standard pour les workloads exigeants (state important, exactly-once, joins multi-streams).

Streaming databases : Materialize, RisingWave

Nouvelle catégorie : des bases qui consomment des streams et maintiennent des vues matérialisées toujours à jour en SQL classique.

Outil	Modèle	Cas d'usage
Materialize	Postgres-compatible, incremental view maintenance	Dashboards live, alerting, jointures streaming complexes
RisingWave	SQL sur stream, stockage cloud-native	Pipelines streaming pilotables en SQL
Clickhouse + materialized views	OLAP très rapide	Analytics quasi temps réel
Apache Pinot / Druid	OLAP streaming	Dashboards utilisateur exposés

Ces outils permettent à des équipes habituées au SQL de bénéficier du temps réel sans devenir développeurs Flink.

Cas d'usage métier

Fraude bancaire / paiement

• CDC sur la base de transactions.
• Flink calcule des features (vitesse, géoloc, montant moyen).
• Scoring ML temps réel → décision en <300 ms.

Supply chain

• CDC sur ERP (SAP, Oracle), WMS.
• Streaming des mouvements de stock, jointure avec prévisions.
• Alerting sur ruptures probables, optimisation des réassorts.

Personnalisation produit

• CDC sur la base e-commerce, événements front (Segment, Snowplow).
• Streaming → mise à jour de feature store → recommandations live.

Observabilité / sécurité

• Streaming des logs applicatifs et infrastructure.
• Détection d'anomalies, SIEM (Splunk, Elastic), corrélations multi-sources.

Customer 360 temps réel

• CDC sur CRM, e-commerce, support.
• Construction d'une vue client unifiée mise à jour en continu.
• Active la Reverse ETL & operational analytics avec données fraîches.

Architecture type

╭──────────╮     ╭──────────╮     ╭──────────╮     ╭──────────╮
│ 💾 Prod  │──▶──│ 🔌 CDC   │──▶──│ 📥 Kafka │──▶──│ 🔥 Flink │
│ (Postgres)     │ (Debezium)     │ (Ingest) │     │ (Stream) │
╰──────────╯     ╰──────────╯     ╰──────────╯     ╰─────┬────╯
                                                         │
                                                         ▼
╭──────────╮     ╭──────────╮     ╭──────────╮     ╭──────────╮
│ 📊 Dash  │◀───-│ 📦 WH    │◀───-│ 🧠 AI/ML │◀───-│ 🔍 Elastic
│ (Real-t) │     │ (Iceberg)│     │ (Vector) │     │ (Search) │
╰──────────╯     ╰──────────╯     ╰──────────╯     ╰──────────╯

C'est le dual write moderne : un seul stream source, plusieurs consommateurs (apps temps réel + warehouse + lakehouse).

Bonnes pratiques

Schéma et versioning

• Schema Registry obligatoire.
• Politique de compatibilité (backward, forward, full).
• Versionner les Avro / Proto.

Exactly-once

• Activer les sémantiques exactly-once (Flink, Kafka transactionnel) sur les pipelines critiques.
• Définir un clé naturelle pour la déduplication.

Idempotence côté consommateur

• Toujours coder les consommateurs comme idempotents (UPSERT, vérification ID).
• Permet de rejouer un topic sans casser le downstream.

Observability

• Suivre lag de consommation, taux de messages morts (DLQ), latence p99.
• Voir Data observability.

Sécurité

• Chiffrement TLS, ACL Kafka, gestion des PII (masking, schémas séparés).
• Authentification SASL/OAuth pour les producteurs.

Coûts

• Kafka peut devenir coûteux à l'échelle (storage + IOPS).
• Tiered storage (Confluent, MSK) déporte les vieux segments en S3.
• Voir FinOps de la donnée.

Pièges fréquents

• Streaming pour le streaming : 80 % des cas d'usage n'en ont pas besoin.
• Faire du CDC trigger-based par paresse : faux gain.
• Oublier le rollback / replay : un mauvais déploiement peut polluer la prod en quelques minutes.
• Surdimensionner Kafka : pour <10k msg/s, des alternatives plus simples suffisent (Pub/Sub, SQS, NATS).
• Coupler trop fort schéma source et consommateurs : un changement de modèle base casse 10 pipelines.

Profils mobilisés

• Streaming Engineer : maîtrise Kafka, Flink, Debezium.
• Data Engineer : intègre le warehouse / lakehouse.
• Architecte data : arbitre batch vs streaming, dimensionne.
• SRE / Platform : opère le cluster, surveille les SLO.

Indicateurs TJM marché :

Profil	TJM EUR/jour
Confirmé Kafka / Flink	650–800 €/jr
Senior streaming + CDC + observability	800–1000 €/jr
Expert streaming temps réel grands comptes	1000 € +

Voir TJM consultant IT.

Conclusion : streamer ce qui mérite de l'être

Le streaming n'est pas une panacée — c'est une architecture qui change la complexité opérationnelle. Bien ciblé (fraude, supply, personnalisation, customer 360 actif), il déverrouille des cas d'usage à très forte valeur. Mal ciblé, il rajoute du coût et de la complexité sans bénéfice. La discipline : identifier où le batch nuit, pas remplacer le batch partout.

Pour aller plus loin :

• Data Contracts
• Iceberg vs Delta vs Hudi : open table formats
• Data observability
• Reverse ETL & operational analytics

ForTeam IT positionne des streaming engineers, data engineers et architectes data event-driven capables de poser une architecture CDC + Kafka + Flink à l'échelle. Si c'est votre terrain, vous êtes au bon endroit.

Rejoindre ForTeam IT