Introduction à DBT pour les équipes data/marketing

DBT (data build tool) est devenu l'outil de référence pour transformer des données brutes en tables fiables et documentées, directement dans le data warehouse. Contrairement à un ETL classique qui transforme la donnée avant de la charger, DBT applique la logique ELT : la donnée brute est déjà dans l'entrepôt (BigQuery, Snowflake), et DBT orchestre sa transformation en SQL, sur place.

Qu'est-ce que DBT concrètement

DBT n'est ni un outil d'ingestion (il ne charge pas de données depuis des sources externes), ni une base de données : c'est une couche de transformation qui se branche sur un entrepôt existant. Un « modèle » DBT est simplement une requête SQL SELECT, versionnée dans un fichier, que DBT matérialise en table ou en vue dans le warehouse. L'enchaînement de plusieurs modèles (l'un consommant le résultat d'un autre) forme un pipeline de transformation lisible et traçable.

Le rôle de DBT dans la stack data moderne

Dans une architecture type, DBT intervient après l'ingestion (Fivetran, Airbyte, export natif GA4) et avant la consommation (dashboards, Reverse ETL). Il transforme les données brutes chargées telles quelles en tables métier propres : dédoublonnage, jointures entre sources, calcul de métriques, agrégation.

Avant DBT, cette logique de transformation vivait souvent dans des scripts Python éparpillés, des requêtes SQL copiées-collées d'un dashboard à l'autre, ou des vues SQL non versionnées. DBT structure cette logique en projet versionné (git), testable et documenté.

Modèles, tests et documentation

Modèles

Chaque modèle est un fichier .sql contenant une requête SELECT. DBT gère automatiquement l'ordre d'exécution en analysant les dépendances entre modèles (un modèle qui référence un autre via la fonction ref()), et matérialise chacun en table ou en vue selon la configuration choisie.

Tests

DBT permet de déclarer des tests directement sur les modèles : unicité d'une clé, absence de valeurs nulles sur une colonne critique, valeurs attendues dans un ensemble défini. Ces tests s'exécutent automatiquement et bloquent le pipeline si une anomalie de qualité est détectée — un filet de sécurité essentiel quand des dashboards ou des audiences publicitaires dépendent de ces données.

Documentation

DBT génère automatiquement une documentation navigable de tous les modèles, avec leurs colonnes, leur description et un graphe de dépendances (lineage) qui montre visuellement comment une donnée brute se transforme, étape par étape, jusqu'à la table finale utilisée dans un dashboard.

DBT et BigQuery : comment ça s'articule

BigQuery est l'un des entrepôts les mieux supportés par DBT. Le flux type pour une stack marketing/data ressemble à ceci :

1. GA4, Google Ads et le CRM chargent leurs données brutes dans BigQuery (export natif ou via Fivetran/Airbyte).

2. DBT se connecte à ce même projet BigQuery et exécute ses modèles SQL, qui lisent les tables brutes et créent des tables/vues transformées dans des datasets dédiés (staging, marts).

3. Les dashboards (Looker Studio) et les outils de Reverse ETL consomment directement les tables marts, jamais les données brutes.

Premiers pas avec DBT

1. Installer DBT (en local via pip, ou utiliser DBT Cloud qui héberge l'exécution) et le connecter à votre projet BigQuery.

2. Créer un premier modèle simple : par exemple une table qui nettoie et standardise les événements GA4 bruts (renommage de colonnes, typage des dates).

3. Ajouter un test basique sur ce modèle (ex : vérifier qu'aucune ligne n'a de date nulle).

4. Enchaîner un second modèle qui consomme le premier via ref(), pour observer comment DBT gère automatiquement l'ordre d'exécution.

5. Générer la documentation (dbt docs generate) pour visualiser le graphe de dépendances.

Bonnes pratiques pour démarrer

• Suivre une convention de nommage claire entre les couches (staging, intermediate, marts) pour que n'importe qui retrouve rapidement une table.

• Ne pas tout matérialiser en table : utiliser des vues pour les modèles intermédiaires peu consultés, et réserver les tables matérialisées aux modèles finaux consommés par les dashboards.

• Versionner le projet DBT dans un dépôt git dès le départ, même pour une petite équipe, pour garder un historique des changements de logique métier.

Christophe Dubois

Consultant tracking & data, freelance senior depuis 2012. Architecture de mesure, server-side, attribution.