Fivetran rachète dbt Labs : la fin d'une ère pour le data stack moderne ?

Le 13 mai 2024, Fivetran annonçait l'acquisition de dbt Labs pour 915 millions de dollars. Une opération qui a provoqué des réactions contrastées dans la communauté data : certains y voient l'émergence d'une plateforme unifiée de data integration enfin cohérente, d'autres redoutent la concentration d'un écosystème qui avait fait de l'ouverture et de l'interopérabilité ses valeurs cardinales.

Au-delà du montant de la transaction, c'est toute la philosophie du Modern Data Stack qui se trouve interrogée. Pendant des années, dbt s'est imposé comme l'outil de transformation par excellence, précisément parce qu'il était agnostique, open source, et qu'il s'intégrait avec l'ensemble de l'écosystème. Fivetran, de son côté, a construit sa réputation sur la robustesse de ses connecteurs d'ingestion. Deux briques complémentaires, mais jusqu'ici indépendantes.

La question n'est pas de savoir si cette fusion va créer de la valeur technique. Elle le fera, inévitablement. La vraie interrogation porte sur les implications stratégiques pour les organisations qui ont construit leur infrastructure data sur ces fondations.

Une consolidation annoncée par les dynamiques du marché data

Cette acquisition n'arrive pas de nulle part. Elle s'inscrit dans un mouvement plus large de consolidation du secteur data, amorcé depuis 2022. Databricks a racheté MosaicML, Snowflake a acquis Streamlit, et désormais Fivetran absorbe dbt Labs. Le pattern est clair : les acteurs historiques cherchent à contrôler l'ensemble de la chaîne de valeur, de l'ingestion à la visualisation.

Plusieurs facteurs expliquent cette tendance. D'abord, la pression économique. Les levées de fonds massives des années 2020-2021 ont laissé place à une exigence de rentabilité. Maintenir une dizaine d'outils spécialisés dans une stack data coûte cher, en licences comme en maintenance. Les DSI cherchent à rationaliser, les éditeurs à élargir leur périmètre.

Ensuite, la complexité croissante des architectures. Le Modern Data Stack, avec sa philosophie best-of-breed, a généré des environnements techniques fragmentés. On se retrouve avec Fivetran pour l'ingestion, dbt pour la transformation, Great Expectations pour la qualité, Airflow pour l'orchestration, Monte Carlo pour l'observabilité. Chaque outil a son propre modèle de configuration, sa propre logique de gouvernance, ses propres limitations. L'intégration devient un casse-tête, et la promesse d'agilité se transforme en dette technique.

La fusion Fivetran-dbt répond directement à cette problématique. En théorie, elle permet d'unifier l'ingestion et la transformation dans une seule interface, avec une gouvernance cohérente et des métadonnées partagées. Sur le papier, c'est séduisant. Dans les faits, plusieurs questions restent en suspens.

Les implications concrètes pour les utilisateurs

Pour les organisations déjà clientes de Fivetran et dbt, le discours officiel se veut rassurant : rien ne change à court terme, les deux produits continueront d'évoluer de manière indépendante, l'open source reste une priorité. Classique dans ce type d'opération. L'expérience montre que la réalité suit rarement ce schéma idéal.

Première conséquence prévisible : une intégration technique poussée entre les deux outils. Fivetran va naturellement privilégier dbt pour les transformations post-ingestion, au détriment d'autres solutions comme Dataform ou SQL Mesh. Les nouvelles fonctionnalités seront développées en priorité pour cette combinaison. On peut s'attendre à voir émerger des packages de licences groupés, des flux de travail optimisés pour l'usage conjoint, des dashboards d'observabilité unifiés.

Cette convergence peut apporter de la valeur. Un exemple concret : la gestion des schémas sources. Aujourd'hui, quand un connecteur Fivetran évolue suite à une modification de l'API source, il faut manuellement ajuster les modèles dbt en aval. Avec une intégration native, on peut imaginer une propagation automatique des changements de schéma, avec des alertes préventives et des suggestions de correction. De même pour la lineage : tracer l'origine d'une donnée depuis sa source jusqu'à son utilisation finale devient trivial quand les deux outils partagent la même couche de métadonnées.

Mais cette intégration a un coût. Pour les équipes qui ont fait le choix d'un autre ETL (Airbyte, Stitch, Meltano), ou d'une autre approche de transformation (Dataform chez Google, ou du SQL procédural classique), le risque de se retrouver en dehors de l'écosystème principal devient réel. dbt a longtemps été un standard de facto parce qu'il était neutre. Cette neutralité risque de s'éroder. Une situation qui rappelle certaines erreurs stratégiques dans la construction d'infrastructures data trop dépendantes d'un vendor unique.

Deuxième point d'attention : la roadmap produit. dbt Cloud, la version managée de dbt, va mécaniquement être influencée par les priorités de Fivetran. On peut anticiper un focus sur les cas d'usage ELT classiques, au détriment de scénarios plus avancés comme le streaming, les transformations en temps réel, ou l'intégration avec des architectures data mesh. Ce n'est pas nécessairement négatif, mais cela traduit une orientation stratégique qui ne conviendra pas à tous les profils d'utilisateurs.

L'enjeu de la gouvernance et de l'open source

dbt Core, la version open source, est au cœur de l'inquiétude de la communauté. Fivetran a affirmé son engagement à maintenir et développer cette version. Mais l'historique du secteur incite à la prudence. Quand un éditeur rachète un projet open source, la tentation est forte de réserver les fonctionnalités premium à la version commerciale. On l'a vu avec Elastic, avec Terraform, avec bien d'autres.

Le modèle économique de dbt Labs reposait sur un équilibre subtil : une base open source généreuse qui construit la communauté et l'adoption, et une couche SaaS (dbt Cloud) qui monétise les fonctionnalités d'entreprise comme l'orchestration, l'IDE en ligne, ou la gestion des environnements. Fivetran, qui vend avant tout des connecteurs en mode SaaS, pourrait être tenté de faire basculer davantage de valeur vers le cloud.

Concrètement, on peut imaginer que certaines évolutions futures (intégration profonde avec Fivetran, gestion avancée de la lineage cross-tools, fonctionnalités d'IA générative pour la génération de modèles) restent exclusives à dbt Cloud. Ce n'est pas un problème en soi si la version open source reste viable pour les cas d'usage standards. Mais cela change la donne pour les organisations qui ont construit leur stack sur dbt Core avec une orchestration custom.

Repenser son architecture data à l'aune de cette consolidation

Face à ce mouvement de vendor consolidation, plusieurs stratégies s'offrent aux organisations. La première consiste à embrasser pleinement l'écosystème unifié. Pour des entreprises en phase de structuration de leur data stack, partir sur une combinaison Fivetran + dbt Cloud intégrée peut avoir du sens. On gagne en simplicité opérationnelle, en cohérence, et on limite le nombre de vendors à gérer.

Cette approche convient particulièrement aux équipes de taille moyenne qui n'ont pas les ressources pour maintenir une architecture complexe. Plutôt que de jongler avec cinq outils différents, chacun avec sa propre logique et ses propres limitations, on consolide sur une plateforme qui couvre l'essentiel du périmètre. Le gain en productivité peut être significatif, surtout si l'intégration tient ses promesses.

Mais cette simplicité a un prix : la dépendance. En confiant l'ingestion et la transformation à un seul vendor, on se lie les mains pour l'avenir. Si demain Fivetran augmente drastiquement ses tarifs, ou si la roadmap produit ne correspond plus à vos besoins, migrer devient extrêmement coûteux. C'est le retour du vendor lock-in, exactement ce que le Modern Data Stack était censé éliminer.

D'où une deuxième stratégie, plus défensive : maintenir l'indépendance des couches. Garder dbt Core en open source avec une orchestration maison (Airflow, Dagster, Prefect), combiner plusieurs outils d'ingestion selon les sources, privilégier les formats ouverts et les standards. Cette approche préserve la flexibilité, mais elle exige des compétences pointues et une capacité à maintenir une infrastructure plus éclatée. Une réflexion que l'on retrouve dans la construction d'une roadmap data réaliste qui anticipe ces enjeux de dépendance.

Entre ces deux extrêmes, une voie médiane émerge : l'architecture modulaire pensée pour la portabilité. L'idée est de structurer son stack de manière à pouvoir remplacer chaque brique sans remettre en cause l'ensemble. Cela passe par quelques principes : documenter exhaustivement les transformations dbt pour faciliter une migration future, abstraire les connecteurs d'ingestion derrière une couche d'API interne, standardiser les formats de métadonnées, automatiser les tests de qualité pour garantir la fiabilité lors d'un changement d'outil.

Les signaux à surveiller dans les prochains mois

Pour les organisations qui utilisent déjà Fivetran et dbt, plusieurs signaux permettront de jauger l'évolution réelle de l'écosystème. D'abord, le rythme de sortie de nouvelles fonctionnalités sur dbt Core v2.0 versus dbt Cloud. Si l'écart se creuse significativement, c'est le signe d'une stratégie de monétisation accrue. Ensuite, les annonces de partenariats et d'intégrations : si Fivetran commence à moins investir dans les connecteurs vers des warehouses concurrents (BigQuery, Redshift) au profit de Snowflake, cela traduira une volonté de favoriser certains acteurs.

La gouvernance du projet open source dbt Core est également à observer. Fivetran va-t-il maintenir une vraie communauté contributrice, ou va-t-il progressivement internaliser le développement ? La composition du core team, la transparence de la roadmap, l'ouverture aux pull requests externes sont autant d'indicateurs de la santé du projet.

Enfin, la tarification sera révélatrice. Si des packages groupés Fivetran + dbt Cloud apparaissent avec des remises agressives, c'est que l'objectif est bien de pousser vers une adoption couplée. À l'inverse, si les deux produits restent tarifés indépendamment sans évolution notable, cela signifiera une approche plus prudente.

Conclusion : vers un nouvel équilibre du data stack

L'acquisition de dbt Labs par Fivetran marque un tournant dans l'histoire du Modern Data Stack. Elle acte la fin d'une époque où l'écosystème data pouvait se structurer autour d'outils indépendants et interopérables, orchestrés par les équipes elles-mêmes. On entre dans une phase de plateformisation, où quelques acteurs dominants cherchent à contrôler l'ensemble de la chaîne de transformation et d'intégration.

Ce mouvement n'est pas nécessairement négatif. Il peut apporter de la cohérence, simplifier les architectures, et accélérer l'innovation en permettant des intégrations profondes difficilement réalisables entre outils indépendants. Mais il implique aussi des choix stratégiques pour les organisations : accepter une dépendance accrue en échange de simplicité, ou maintenir une architecture plus complexe mais plus flexible.

La réponse dépend du contexte de chaque entreprise. Pour des équipes en phase de construction, une stack unifiée peut accélérer le time-to-value. Pour des organisations matures avec des besoins spécifiques, la modularité reste un atout précieux. Dans tous les cas, la clé est d'anticiper cette évolution et de structurer son infrastructure data en gardant en tête la question de la portabilité. Les standards ouverts, la documentation rigoureuse, et l'automatisation des tests ne sont plus des bonnes pratiques optionnelles. Ils deviennent la condition de la résilience face à un écosystème en pleine recomposition.