dbt : ce qui change avec la v2
dbt (data build tool) reste un pilier de notre stack data, aux côtés de Snowflake, BigQuery et Power BI. Fivetran et dbt Labs ont fusionné en 2025, avant de livrer dbt v2 le 14 septembre 2026 : la première version majeure depuis dbt 1.0, en 2021.
Cet article rappelle ce qu’est dbt, puis détaille ce que change la v2 pour nos projets et ceux de nos clients.
– Qu’est-ce que dbt ?
dbt est un framework de transformation de données : il prend le relais une fois les données chargées dans l’entrepôt (Snowflake, BigQuery…), pour les nettoyer, les modéliser et les documenter avec du SQL versionné.
Il s’inscrit dans une architecture ELT (Extract-Load-Transform) plutôt qu’ETL classique : les données brutes sont d’abord chargées telles quelles, puis transformées directement dans l’entrepôt, ce qui tire parti de sa puissance de calcul et simplifie la chaîne.
Concrètement, dbt apporte :
- des modèles SQL réutilisables et testables, organisés en couches (staging, dwh, datamarts)
- des tests de qualité de données automatisés (unicité, valeurs non nulles, cohérence référentielle)
- une documentation et un lignage générés automatiquement à partir du code
- un contrôle de version Git, avec revue de code sur les transformations comme sur n’importe quel développement logiciel
Chez Effidic, dbt est au cœur de nos architectures data (aux côtés de Snowflake, BigQuery, Talend et Power BI), pour unifier et fiabiliser les données avant leur exploitation en pilotage ou en reporting. En amont, nous assurons nous-mêmes l’ingestion des données brutes en Python, avant que dbt ne prenne le relais pour la transformation.
– Le contexte : la fusion Fivetran + dbt Labs
En 2025, l’éditeur d’ingestion de données Fivetran et dbt Labs ont fusionné pour former, selon leurs propres mots, l’infrastructure data de l’IA agentique de confiance. L’objectif affiché : couvrir toute la chaîne, de l’ingestion (Fivetran) à la transformation (dbt), avec un socle commun.
Cette fusion a aussi mis fin à une situation transitoire. Depuis l’introduction du moteur Fusion (une réécriture en Rust, sous licence propriétaire), dbt existait en deux versions parallèles : le cœur historique en Python (dbt Core, open source) et Fusion, plus rapide mais non open source.
dbt v2, annoncée en juin 2026 et disponible en version stable depuis le 14 septembre 2026, réunifie les deux : un seul moteur, écrit en Rust, devient la base commune de toutes les distributions de dbt.
– Les évolutions techniques de la v2
dbt v2 est la première version majeure depuis dbt 1.0 (2021) : elle rebâtit le moteur en Rust, là où dbt 1.x reposait sur Python.
| dbt Core 1.x | dbt v2 | |
|---|---|---|
| Moteur | Python | Rust (issu de Fusion) |
| Licence | Open source (Apache 2.0) | Apache 2.0 (édition dbt-oss) + édition complète dbt (gratuite, options premium) |
| Analyse du SQL | Limitée | Compréhension fine par dialecte, lignage colonne par colonne |
| Format des artefacts | JSON | Parquet, interrogeable directement (DuckDB, etc.) |
| Vitesse de parsing/lint | Référence | Nettement plus rapide sur les gros projets (linting jusqu’à ~50x plus rapide) |
Quatre points méritent d’être soulignés :
- une spécification de langage plus stricte : une erreur de frappe dans une clé de configuration (par exemple « desciptin » au lieu de « description ») est désormais détectée, alors qu’elle passait silencieusement en v1
- une installation simplifiée, sans gestion d’environnement virtuel Python
- un serveur de langage qui alimente l’extension VS Code officielle, avec complétion et détection d’erreurs avant l’exécution
- un contrôle de non-régression entre modèles, grâce au graphe de dépendances de dbt : si un développeur modifie un modèle parent d’une manière qui casse un modèle enfant, il en est informé automatiquement
Pour nos projets chez Effidic, la licence Apache 2.0 de l’édition dbt-oss suffit : nous n’avons pas besoin des fonctionnalités premium de l’édition complète (dbt Cloud/Fusion).
– Les nouvelles fonctionnalités qui accompagnent la v2
Au-delà du moteur, dbt Labs a annoncé plusieurs fonctionnalités lors du dbt Summit 2026 :
| Fonctionnalité | Ce qu’elle apporte | Statut |
|---|---|---|
| dbt State | Analyse les métadonnées de l’entrepôt et le SQL des modèles pour ne reconstruire que ce qui a changé | Disponible (-59 % de coûts d’entrepôt rapportés par un client sur ses jobs planifiés) |
| Lake Compute | Moteur SQL basé sur DuckDB pour transformer des tables Apache Iceberg, sans migrer toute la plateforme | Bêta |
| dbt Wizard | Agent IA dédié à l’ingénierie analytique (plateforme, CLI, ou application de bureau) | Preview / bêta selon le format |
| dbt Charts | Tableaux de bord définis en YAML, versionnés avec les modèles dans le même dépôt | Bêta publique |
À noter également : des intégrations directes avec Anthropic et ChatGPT pour donner à des agents IA un accès contrôlé au contexte d’un projet dbt.
– Ce que ça change concrètement pour un projet existant
dbt v2 est une version majeure, avec des changements de compatibilité comparables au passage à dbt 1.0 en 2021. Rien n’oblige toutefois à migrer dans l’urgence : dbt Core 1.x continue d’être maintenu, jusqu’à la version 1.12 sortie en juillet 2026.
Le chemin recommandé par dbt Labs pour préparer une migration :
- passer à dbt Core 1.12, qui impose déjà les changements de comportement qui deviendront obligatoires en v2
- tester la compatibilité avec la commande
dbt parse --use-v2-parser - corriger les points bloquants avec l’outil
dbt-autofix - recenser les dépendances sensibles : adaptateurs propriétaires ou peu maintenus, packages externes non encore mis à jour, matérialisations spécifiques à un entrepôt
- tester Fusion/v2 en environnement de développement, en parallèle de la version 1.12 en production
Point de vigilance pour nos clients sur Snowflake, BigQuery, Databricks ou Redshift : ce sont les entrepôts les mieux supportés dès aujourd’hui. Un projet reposant sur un adaptateur de niche ou des packages communautaires peu maintenus a intérêt à rester en 1.x le temps que l’écosystème rattrape la v2.
dbt Labs fixe par ailleurs une échéance : les versions 1.3 à 1.7 seront retirées de la plateforme dbt le 31 janvier 2027.
– Ce que nous en retenons chez Effidic
Pour nos projets, la v2 confirme une tendance déjà à l’œuvre avec Fusion : des architectures data plus rapides à construire et plus fiables, avec une détection d’erreurs plus précoce. Cela devrait notamment changer la vie des développeurs dbt qui attendent parfois plusieurs minutes une compilation : nous avons constaté jusqu’à 50 % de gain sur de larges projets (plus de 1 000 modèles). Le contrôle de non-régression grâce au column lineage est lui aussi impressionnant.
Elle ne change rien à l’urgence immédiate de nos clients : la bascule peut se préparer méthodiquement, sans pression de calendrier tant que la version 1.x reste maintenue.
Nous suivrons en priorité la compatibilité de nos projets Snowflake et BigQuery, ainsi que les briques dbt State et Lake Compute, qui rejoignent directement nos sujets de maîtrise des coûts et d’architecture data lake / data warehouse. Un projet de migration dbt à préparer ? Parlons-en.