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

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

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 y'a trois ans, pis un orchestrateur qui déclenche toute sans que personne 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.

Le cœur du problème, c'est pas SQL — SQL fait très bien la job. 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 tes modèles (DAG) pis les exécute dans le bon ordre. T'as 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 pis sont vérifiés à chaque exécution. Si un test plante, le pipeline s'arrête avant que la donnée fausse atteigne les dashboards.
• Documentation générée : descriptions, lineage colonne par colonne pis schéma du DAG sont produits depuis le code pis le YAML, donc toujours à jour.
• Templating Jinja : macros réutilisables, boucles pis 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 déplace pas la donnée pis a pas de moteur de calcul. Il compile tes modèles en SQL pis 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, pis 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 pis où on transformait la donnée avant de la charger. Les warehouses infonuagiques ont inversé l'équation : le calcul est élastique pis pas cher, c'est devenu plus simple de toute charger d'abord pis de transformer ensuite. dbt est né de ce basculement ELT.

Son adoption massive tient à trois affaires : il parle SQL, donc n'importe quel analyste devient capable de contribuer sans apprendre un outil graphique propriétaire ; il s'intègre nativement avec Git pis la CI/CD, donc la donnée hérite des mêmes garde-fous que le code applicatif ; pis 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, on a 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 pis tests systématiques, le coût de la brique data a été divisé par un ordre de grandeur, toute 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 cœur d'une architecture lakehouse : ingestion en continu, stockage objet, pis 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, pis les tests ont fait chuter le nombre d'incidents de qualité en aval.

Le schéma qui marche le mieux, c'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 met aucune logique métier là-dedans.
2. Couche intermédiaire : jointures pis 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 coûte rien, tes modèles oui

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 traite juste 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 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 toute à chaque heure quand la source change juste une fois par jour revient à payer dix fois pour rien.
• Exécutions ciblées : les sélecteurs dbt permettent de relancer juste les modèles impactés par un changement, pas toute le DAG.

Notre règle terrain : on 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 exécute pas inutilement.

dbt Core ou dbt Cloud ?

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

Quand PAS utiliser dbt

dbt, c'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 infonuagique sous-jacent, y'a aucun moteur sur lequel s'appuyer.
• Besoin de transformation temps réel ou streaming : dbt travaille en batch, c'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 astheure d'orchestrer des modèles Python.
• Un seul script trivial : pour trois requêtes stables qui bougent jamais, la mise en place de dbt se justifie pas.

Par où commencer

Une migration vers dbt 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, pis 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 tu veux un regard extérieur sur ta couche de transformation — coûts, qualité, dette — c'est exactement le type d'audit data qu'on mène chez Abbeal.