L’ingestion temps réel devient une fonction native des data platforms. En septembre et en octobre 2026, Snowflake et Databricks ont tous deux renforcé leurs briques de streaming et de CDC. Or ce terrain, les DBA le connaissent depuis longtemps : journaux de transactions, réplication logique, LogMiner. Chez Axians, nous accompagnons nos clients sur ces sujets. Et nous voyons cette expertise base de données devenir un vrai atout.
Ingestion temps réel : la fin des tuyaux intermédiaires
Pendant des années, alimenter un entrepôt en continu demandait une chaîne complète. D’abord un outil de capture sur la base source. Ensuite un bus de messages, souvent Kafka. Enfin un connecteur vers la cible. Or chaque maillon ajoutait de la latence, du coût et des astreintes.
Aujourd’hui, les éditeurs veulent supprimer ces étapes et faire de l’ingestion temps réel un service intégré. Leur message est donc simple : envoyez vos données directement dans la plateforme, elle s’occupe du reste. Pour autant, la question de la source reste entière. En effet, il faut toujours lire proprement les changements d’une base de production, sans la ralentir.
Snowflake : Elastic Channels et connecteurs CDC Openflow
Le 16 septembre 2026, Snowflake a annoncé la disponibilité générale des Elastic Channels pour Snowpipe Streaming (annonce Snowflake). Les chiffres annoncés sont d’ailleurs impressionnants :
- jusqu’à 20 Go/s par table ;
- des données requêtables en 5 secondes environ, selon la charge ;
- une facturation à 0,0037 crédit par Go non compressé, sans surcoût pour les Elastic Channels.
Concrètement, un producteur choisit une table cible. Il y ajoute ensuite des lignes via un SDK Python, Java ou Node.js, ou via une API REST. Snowflake gère alors la mise à l’échelle. L’éditeur précise toutefois un point clé : les Elastic Channels livrent « au moins une fois », sans garantie d’ordre. Si vous avez besoin de l’ordre et du « exactement une fois », il faut rester sur les Named Channels. Autrement dit, le choix du mode de livraison reste une décision d’architecte.
Côté bases de données, Snowflake avance aussi avec Openflow. Le connecteur Oracle est en disponibilité générale depuis mars 2026. Il fonctionne sans agent sur la source et Snowflake l’a développé avec Oracle (blog Snowflake). Le connecteur SQL Server (CDC) l’a rejoint le 5 août 2026 (note de version). En revanche, les connecteurs PostgreSQL et MySQL/MariaDB de seconde génération restent en préversion publique (documentation Snowflake). Par ailleurs, les mises à jour d’octobre ajoutent des métriques de latence sur ces connecteurs (historique Openflow).
Databricks : Zerobus, Lakeflow Connect et Auto CDF
Databricks suit la même logique d’ingestion temps réel avec Lakeflow Connect. Ses connecteurs gérés capturent les changements de PostgreSQL, SQL Server, MySQL et Oracle. Pour Oracle, ils s’appuient sur LogMiner (documentation Databricks). Par exemple, une passerelle d’ingestion tourne en continu. Ainsi, elle lit les changements avant que la base source ne purge ses journaux.
Plusieurs annonces récentes complètent ce dispositif (notes de version de septembre) :
- Arrow pour Zerobus Ingest, en disponibilité générale le 1er septembre. Zerobus écrit directement dans des tables Delta gérées, sans bus de messages ;
- Automatic Change Data Feed, en disponibilité générale le même jour. Il calcule les changements au moment de la requête et accélère les MERGE et UPDATE d’environ 15 % ;
- des fenêtres de maintenance pour les pipelines continus, afin de choisir le moment des redémarrages.
De plus, le 15 octobre 2026, Databricks a rendu disponible le pipeline CDC intégré pour MySQL. En effet, il n’a plus besoin de passerelle séparée (notes de version d’octobre). Enfin, une offre gratuite de 100 DBU par jour et par workspace couvre les connecteurs gérés (blog Databricks).
Debezium reste la référence open source du CDC
Faut-il pour autant oublier les outils open source ? Pas du tout. Debezium 3.7 est sorti le 29 septembre 2026 avec de nombreuses nouveautés (annonce Debezium 3.7). Voici celles qui parlent le plus aux DBA :
- un adaptateur Debezium Server vers Zerobus Ingest, pour écrire dans Delta sans broker intermédiaire ;
- le minage déporté pour Oracle XStream, qui décharge la base de production ;
- le choix de l’instance de capture CDC sous SQL Server ;
- des parseurs LogMiner jusqu’à 2,6 fois plus rapides sur les UPDATE.
Debezium garde ainsi un avantage net : il reste indépendant de la plateforme cible. Pour une architecture multicloud, ou pour éviter de dépendre d’un éditeur, c’est souvent le choix le plus sûr. Nous détaillons son fonctionnement dans notre article Debezium : accélérez vos flux de données.
Pourquoi l’expertise base de données devient un atout
Ces connecteurs semblent « clés en main ». Pourtant, ils reposent tous sur des mécanismes propres à chaque moteur. Et c’est justement là que les problèmes surviennent en production.
Prenons quelques exemples concrets :
- PostgreSQL : un slot de réplication logique inactif retient les WAL et peut saturer le disque. De plus, le connecteur Openflow exige une clé d’identité adaptée sur chaque table pour répliquer UPDATE et DELETE ;
- SQL Server : la CDC doit être activée sur la base et sur chaque table. En outre, elle n’existe pas en édition Express ou Web ;
- Oracle : LogMiner et XStream demandent un dimensionnement soigné des journaux archivés et des droits précis.
En clair, la plateforme simplifie la cible de l’ingestion temps réel, mais la source reste votre responsabilité. Un DBA sait lire un plan d’exécution, surveiller la rétention des journaux et anticiper l’impact d’une capture sur la charge. Par conséquent, ce savoir-faire évite les incidents les plus coûteux.
Comment bien démarrer votre projet d’ingestion temps réel
Avant de choisir un outil, nous conseillons de suivre quatre étapes :
- Qualifier le besoin réel : une latence de quelques secondes est-elle vraiment nécessaire, ou quelques minutes suffisent-elles ?
- Auditer les sources : versions, éditions, clés primaires, volumétrie des journaux.
- Choisir entre natif et open source : connecteurs Openflow ou Lakeflow Connect d’un côté, Debezium de l’autre.
- Industrialiser la supervision : latence, retard de capture, rétention des journaux et alertes.
Si vous travaillez déjà avec Snowflake, notre article sur la plateforme data souveraine et Snowflake complète utilement cette réflexion.
Axians vous accompagne sur l’ingestion temps réel
Le CDC et le streaming ne sont plus réservés aux projets d’exception. Snowflake et Databricks en font des briques natives, et l’open source progresse au même rythme. Cependant, la réussite dépend toujours de la maîtrise des bases sources.
C’est précisément notre métier : les équipes Axians accompagnent leurs clients de bout en bout sur ces sujets. D’abord en conseil, pour cadrer l’architecture et choisir les bons outils. Ensuite, nous assurons le build des pipelines, depuis PostgreSQL, SQL Server ou Oracle vers Snowflake ou Databricks. Nous proposons aussi un service managé pour superviser vos flux au quotidien. Enfin, nos formations aident vos équipes à monter en compétence. Vous avez un projet d’ingestion temps réel ? Parlons-en.