dbt expliqué : le data build tool qui transforme vos pipelines SQL

Le problème : des pipelines SQL maison que plus personne ne maîtrise

Dans la plupart des plateformes data qu'on reprend, le même scénario se répète. La transformation des données repose sur un empilement de scripts SQL lancés par des crons, des procédures stockées écrites il y a trois ans, et un orchestrateur qui déclenche le tout sans que personne ne sache vraiment dans quel ordre les tables se mettent à jour. Quand un chiffre est faux dans un dashboard, retrouver la requête fautive prend une demi-journée. Quand un analyste part, sa logique métier part avec lui.

Le coeur du problème n'est pas SQL — SQL fait très bien le travail. C'est l'absence d'ingénierie autour du SQL : pas de versioning propre, pas de tests, pas de gestion explicite des dépendances, pas de documentation à jour. C'est exactement le vide que dbt vient combler.

Ce que dbt fait réellement

dbt (data build tool) est un framework open-source qui apporte les pratiques du génie logiciel à la couche transformation de la donnée. On y écrit des modèles : des fichiers SQL versionnés dans Git, chacun produisant une table ou une vue dans le data warehouse. dbt se charge du reste.

• Gestion des dépendances : avec la fonction ref(), dbt construit automatiquement le graphe de vos modèles (DAG) et les exécute dans le bon ordre. Plus besoin d'aligner des cron à la main.
• Tests de qualité : unicité, non-NULL, intégrité référentielle, valeurs autorisées se déclarent en YAML et sont vérifiés à chaque exécution. Si un test échoue, le pipeline s'arrête avant que la donnée fausse n'atteigne les dashboards.
• Documentation générée : descriptions, lineage colonne par colonne et schéma du DAG sont produits depuis le code et le YAML, donc toujours à jour.
• Templating Jinja : macros réutilisables, boucles et variables d'environnement permettent de factoriser le SQL répétitif au lieu de le copier-coller.
• Matérialisations : un même modèle devient une vue, une table reconstruite ou une table incrémentale en changeant une seule ligne de configuration.

Point important : dbt ne déplace pas la donnée et n'a pas de moteur de calcul. Il compile vos modèles en SQL et délègue l'exécution au warehouse (BigQuery, Snowflake, Databricks, Redshift, Postgres...). C'est le 'T' d'une architecture ELT : on charge d'abord la donnée brute, puis on la transforme là où elle vit.

Pourquoi dbt a remplacé les ETL traditionnels

Les ETL classiques (Informatica, Talend) ont été conçus pour une époque où le calcul dans la base coûtait cher et où on transformait la donnée avant de la charger. Les warehouses cloud ont inversé l'équation : le calcul est élastique et bon marché, il est devenu plus simple de tout charger d'abord et de transformer ensuite. dbt est né de ce basculement ELT.

Son adoption massive tient à trois choses : il parle SQL, donc tout analyste devient capable de contribuer sans apprendre un outil graphique propriétaire ; il s'intègre nativement avec Git et la CI/CD, donc la donnée hérite des mêmes garde-fous que le code applicatif ; et il est open-source, ce qui a fait émerger un standard de fait — le rôle d'analytics engineer s'est structuré autour de lui.

Comment on le déploie en production chez nos clients

Chez un groupe bancaire, nous avons reconstruit la couche de transformation d'une plateforme RAG dont les coûts de base de données dérapaient. En passant d'un empilement de requêtes ad hoc à des modèles dbt avec matérialisations incrémentales et tests systématiques, le coût de la brique data a été divisé par un ordre de grandeur, tout en rendant le pipeline auditable — un prérequis non négociable en environnement bancaire.

Sur une plateforme data de mobilité (hubs Montréal/Paris), dbt s'est inséré au coeur d'une architecture lakehouse : ingestion en continu, stockage objet, et dbt orchestrant les couches de transformation (staging, intermédiaire, marts) au-dessus du moteur du lakehouse. Le lineage généré par dbt est devenu la documentation vivante de la plateforme, et les tests ont fait chuter le nombre d'incidents de qualité en aval.

Le schéma qui marche le mieux est presque toujours le même : une architecture en couches, du brut vers le métier.

1. Couche staging : un modèle par source, nettoyage minimal (renommage, typage, déduplication). On n'y met aucune logique métier.
2. Couche intermédiaire : jointures et transformations réutilisables qui factorisent la logique partagée par plusieurs sorties.
3. Couche marts : tables exposées au métier (finance, produit, marketing), conçues pour être consommées directement par la BI.

FinOps : dbt ne coûte rien, vos modèles si

dbt lui-même est gratuit en version Core. Le vrai sujet de coût, c'est le calcul qu'il déclenche dans le warehouse. C'est là que dbt devient un levier GreenOps puissant — ou un gouffre, selon la façon dont on l'utilise.

• Matérialisations incrémentales : on ne traite que les nouvelles lignes au lieu de reconstruire toute la table à chaque exécution. C'est le plus gros levier de réduction de coût.
• Vue vs table : une vue ne coûte rien à construire mais relit la donnée à chaque requête ; une table coûte à la construction mais se lit vite. Le bon choix dépend de la fréquence de lecture.
• Granularité des exécutions : reconstruire tout chaque heure quand la source ne change qu'une fois par jour revient à payer dix fois pour rien.
• Exécutions ciblées : les sélecteurs dbt permettent de ne relancer que les modèles impactés par un changement, pas tout le DAG.

Notre règle terrain : on ne juge jamais une migration dbt sur la beauté du code, mais sur la facture du warehouse avant/après. Le code le plus durable reste celui qu'on n'exécute pas inutilement.

dbt Core ou dbt Cloud ?

dbt Core est l'outil en ligne de commande, open-source et gratuit, qu'on branche sur sa propre CI/CD (GitHub Actions, GitLab CI) et son propre orchestrateur (Airflow, Dagster). dbt Cloud est l'offre SaaS payante qui ajoute un IDE web, un scheduler managé, l'hébergement de la documentation et la gestion fine des accès. Notre recommandation par défaut : démarrer sur Core avec la CI/CD déjà en place, et ne basculer vers Cloud que si le coût de l'outillage managé est clairement justifié par la taille de l'équipe ou des contraintes de gouvernance.

Quand NE PAS utiliser dbt

dbt n'est pas une réponse universelle. On déconseille de l'introduire dans plusieurs cas.

• Pas de data warehouse ou de lakehouse : dbt transforme là où la donnée vit. Sans warehouse cloud sous-jacent, il n'y a aucun moteur sur lequel s'appuyer.
• Besoin de transformation temps réel ou streaming : dbt travaille en batch, il n'est pas adapté aux transformations de flux à la milliseconde.
• Logique non exprimable en SQL : les traitements Python lourds (ML, parsing complexe) dépassent le périmètre naturel de dbt, même si certains warehouses permettent désormais d'orchestrer des modèles Python.
• Un seul script trivial : pour trois requêtes stables qui ne bougent jamais, la mise en place de dbt ne se justifie pas.

Par où commencer

Une migration vers dbt n'a pas besoin d'être un big bang. On commence par cartographier les transformations existantes, on en migre un périmètre métier à valeur visible (un mart finance, un dashboard critique), on ajoute les tests qui auraient évité les derniers incidents, et on mesure l'impact sur la facture warehouse. La couche dbt grandit ensuite source par source. Pour la définition courte, voir notre fiche glossaire dbt : /fr/glossaire/dbt. Si vous voulez un regard extérieur sur votre couche de transformation — coûts, qualité, dette — c'est exactement le type d'audit data qu'on mène chez Abbeal.