Les outils BI sont de plus en plus attendus pour s’intégrer avec dbt plutôt que de maintenir une logique de transformation séparée. La présupposition par défaut dans l’assemblage d’une modern data stack s’est déplacée vers dbt comme couche fondationnelle depuis laquelle les outils BI lisent.
Auparavant, l’outil BI maintenait sa propre modélisation sémantique (LookML, le modèle de données Tableau), ses propres champs calculés, sa propre version de la logique métier, indépendamment de la couche de transformation dbt. Quand la couche sémantique vit dans dbt, quand les métriques sont définies en YAML aux côtés des modèles, et quand les tests et la documentation sont générés depuis la même base de code, un outil BI qui maintient une couche de modélisation parallèle crée une dérive des métriques par conception.
Les preuves
Le signal le plus fort est ce que les nouveaux outils BI choisissent de construire.
Lightdash est le cas le plus clair. Il lit directement depuis le YAML du projet dbt, auto-générant des dimensions et des métriques depuis les métadonnées des modèles. Il n’y a pas de couche de modélisation séparée. Ce qu’on définit dans le projet dbt est exactement ce qui apparaît dans l’outil BI. Pas de dérive entre transformation et présentation, pas d’étape “sync”, pas de définitions parallèles.
Evidence adopte une philosophie similaire dans une direction différente : rapports construits avec SQL + Markdown, déployés comme sites statiques, versionnés aux côtés du projet dbt. La sortie BI vit dans le même dépôt que la logique de transformation.
Omni a été fondé par d’anciens ingénieurs de Looker qui voulaient explicitement corriger la relation de Looker avec dbt. Sa modélisation YAML-like et son versioning Git sont conçus pour s’aligner avec les workflows dbt plutôt que les remplacer.
Même les outils legacy s’adaptent. Looker a livré un connecteur à la couche sémantique dbt. Tableau en a ajouté un dans Tableau Cloud 2025.2. Le format PBIR de Power BI (par défaut depuis janvier 2026) rend les définitions de rapports basées sur des dossiers et compatibles Git. La direction est claire, même si l’adaptation est lente et que ces outils portent des hypothèses architecturales d’une autre époque.
La fusion Fivetran-dbt Labs
L’événement déterminant qui rend la centralité de dbt structurelle plutôt que culturelle : la fusion Fivetran-dbt Labs a été finalisée fin 2025, créant une entité combinée avec environ 600 M$ d’ARR et plus de 10 000 clients. George Fraser (PDG de Fivetran) dirige la société combinée ; Tristan Handy est Président. dbt Core reste open source.
Cela importe car cela unifie le mouvement des données et la transformation des données sous un même toit. Fivetran gère l’ingestion. dbt gère la transformation, les tests, la documentation et la couche sémantique (via MetricFlow, maintenant Apache 2.0). La plateforme combinée couvre depuis l’extraction des sources jusqu’à la définition des métriques — tout ce qui est en dessous de la couche de visualisation BI.
Les acquisitions qui ont mené ici sont révélatrices :
- Fivetran a acquis Census (mai 2025) pour le reverse ETL — pousser les données transformées vers les outils opérationnels
- Fivetran a acquis Tobiko Data (septembre 2025) — l’équipe derrière SQLMesh, une alternative à dbt, maintenant intégrée à l’écosystème dbt
- MetricFlow est passé en Apache 2.0, supprimant la friction de licence pour l’adoption
La société combinée contrôle désormais le pipeline de la source à la métrique. Les outils BI qui ne s’intègrent pas avec cette stack naviguent à contre-courant.
Ce que “dbt-natif” signifie réellement
Il existe un spectre d’intégration dbt, et les différences importent :
Construit sur dbt. Lightdash et Evidence traitent le projet dbt comme leur source de vérité. Pas de définitions parallèles. Le DAG dbt est le modèle de données de l’outil BI. Les changements dans les modèles dbt mettent automatiquement à jour ce qui est disponible dans la couche BI.
Connecté à dbt. Looker, Tableau et Steep consomment des métriques depuis l’API de la couche sémantique dbt (via JDBC, GraphQL ou REST). Ils maintiennent leurs propres couches de modélisation et de visualisation mais peuvent récupérer des métriques gouvernées depuis dbt. C’est de l’intégration, pas de l’unification — il y a toujours deux systèmes, mais ils se parlent.
Parallèle à dbt. Metabase, Preset/Superset et la plupart des outils legacy fonctionnent indépendamment. Ils interrogent les tables de l’entrepôt que dbt produit, mais ne lisent pas les métadonnées dbt, ne consomment pas les métriques dbt, et définissent leurs propres concepts sémantiques (le cas échéant). Cela fonctionne, mais cela signifie que les définitions de métriques dans dbt et les calculs de métriques dans l’outil BI peuvent diverger silencieusement.
La question pratique pour toute équipe évaluant des outils BI : où sur ce spectre veut-on se situer ? Si l’investissement dans la couche de modélisation dbt est significatif — conventions de nommage, documentation, tests, modèles sémantiques — choisir un outil BI qui ignore tout ce travail revient à gaspiller de la valeur.
Le signal de consolidation
La modern data stack se consolide autour de plateformes moins nombreuses et plus grandes. La fusion Fivetran-dbt est l’exemple le plus visible, mais le pattern est plus large :
- Hex a acquis Hashboard (mai 2025) pour ajouter la modélisation sémantique à son interface notebook
- Omni a acquis Explo (septembre 2025) pour les analytics embarqués
- ThoughtSpot a acquis Mode (juillet 2023) pour les analytics code-first
- Sigma a atteint une valorisation de 1,5 Md$ et 100 M$ d’ARR, devenant le BI Partner of the Year de Snowflake et Databricks
La direction est vers des plateformes intégrées plutôt que des solutions ponctuelles best-of-breed. Et dans cette consolidation, dbt se situe au centre — la couche de transformation et sémantique à laquelle tout le reste se connecte.
Cela ne signifie pas qu’il faut aller all-in sur le BI dbt-natif. Metabase reste le meilleur choix pour les équipes priorisant le self-service des non-techniques. La gouvernance enterprise de Looker reste inégalée en maturité. Mais la gravité architecturale tire vers dbt comme fondation, et les outils BI qui résistent à cette attraction auront de plus en plus l’impression de lutter contre l’écosystème plutôt que d’y participer.
73 % des implémentations BI échouent à délivrer du ROI dans la première année (SR Analytics). Les modes d’échec principaux sont une mauvaise modélisation des données, une gouvernance absente et des définitions de métriques peu claires — des problèmes dans la couche de transformation, pas dans la couche de visualisation. Un projet dbt bien structuré avec des métriques gouvernées et une couche sémantique propre réduit ces modes d’échec quel que soit l’outil BI choisi.