Technologie · 9 min de lecture

dbt

Vos transformations SQL versionnées, testées et documentées, avec un graphe de dépendances qui se construit tout seul. Ce que l’outil fait vraiment, et les deux choses qu’il ne fait pas du tout.

Mis à jour le

Dans la plupart des entreprises, les transformations de données vivent dans des procédures stockées écrites il y a cinq ans, des vues empilées les unes sur les autres, et un document Excel qui recense à peu près ce qui alimente quoi. Ça tourne. Personne n’ose y toucher.

dbt part d’une idée simple : ces transformations sont du code, alors traitons-les comme du code. Versionnées dans Git, testées automatiquement, documentées à la source, relues avant d’être déployées. C’est tout, et c’est suffisant pour changer la façon dont une équipe travaille.

Graphe orienté de blocs SQL, chaque nœud portant une coche de validation.
Le mécanisme

Un modèle est un SELECT, et le reste suit

Un modèle dbt est un fichier qui contient une requête SELECT. Rien d’autre. C’est dbt qui se charge d’en faire une table ou une vue dans l’entrepôt, de la recréer dans le bon ordre, et de gérer les instructions de création que personne n’a envie d’écrire à la main.

La pièce centrale tient en un mot. Au lieu d’écrire le nom d’une table en dur, on écrit une référence vers un autre modèle. dbt en déduit alors seul le graphe complet des dépendances, sans que personne ait à le déclarer ni à le maintenir. C’est ce qui rend l’ordre d’exécution automatique, le graphe de lignage toujours juste, et le remplacement d’une table sans douleur.

Le mode de matérialisation se choisit par modèle. Une vue ne stocke rien et se recalcule à chaque interrogation. Une table est recalculée entièrement à chaque exécution. Un modèle incrémental ne traite que les nouvelles lignes, ce qui devient indispensable au-delà de quelques millions d’enregistrements. Le modèle éphémère, lui, n’existe jamais dans l’entrepôt et s’insère comme une sous-requête dans les modèles qui l’appellent.

Ce choix se change en modifiant une ligne, sans réécrire la requête. C’est le genre de détail qui paraît anodin et qui, en mission, économise des semaines.

Ce qui change vraiment

Les tests, et la confiance qui va avec

C’est la fonction qui justifie l’outil à elle seule, et curieusement celle que les équipes activent en dernier.

Quatre tests s’écrivent en une ligne chacun dans un fichier de configuration : une colonne est unique, elle n’est jamais vide, elle ne contient que certaines valeurs, ou elle correspond bien à une clé présente dans une autre table. Sur un modèle de facturation, ces quatre contrôles détectent la grande majorité des anomalies avant qu’elles n’atteignent un tableau de bord.

Au-delà, un test peut être n’importe quelle requête qui ne doit renvoyer aucune ligne. « Aucune facture ne doit avoir un montant négatif », « le total consolidé doit égaler la somme des filiales » : ces règles métier deviennent des tests qui tournent à chaque exécution.

On peut aussi déclarer une fraîcheur attendue sur les sources. Si les données de la veille ne sont pas arrivées, la chaîne s’arrête au lieu de produire un rapport partiel que quelqu’un prendra pour argent comptant. C’est la différence entre un chiffre faux et une alerte.

À savoir

Deux choses que dbt ne fait pas

C’est la source de malentendu la plus fréquente en avant-vente, alors autant l’écrire noir sur blanc.

dbt ne déplace pas les données. Il transforme ce qui se trouve déjà dans l’entrepôt. Il faut donc un outil en amont pour amener les données depuis vos sources : Fivetran, Azure Data Factory, Talend ou du code maison. dbt est le T de l’ELT, pas la chaîne entière.

dbt n’orchestre rien au-delà de son propre graphe. Il sait exécuter ses modèles dans le bon ordre, mais il ne sait pas attendre qu’un fichier arrive, relancer une tâche qui a échoué trois heures plus tard, ni enchaîner avec un traitement qui n’est pas du SQL. Pour cela il faut Airflow ou Dagster.

Un dernier point sur les formules. dbt Core est le moteur en ligne de commande, sous licence Apache 2.0, que l’on exécute où l’on veut. dbt Cloud est l’offre commerciale, qui ajoute un environnement de développement dans le navigateur, un planificateur et l’hébergement de la documentation. Beaucoup d’équipes commencent avec Core exécuté par leur orchestrateur, et ne passent au Cloud que si le confort le justifie.

Arbitrage

Quand dbt vaut le coup

Le cas typique est celui d’une équipe qui a déjà un entrepôt, Snowflake, BigQuery, Databricks ou Fabric, et dont les transformations sont devenues assez nombreuses pour que plus personne ne sache dans quel ordre elles tournent. À partir d’une trentaine de modèles, la question ne se pose plus vraiment.

C’est aussi le bon choix quand plusieurs personnes touchent aux mêmes calculs. Le versionnement et la relecture avant fusion évitent les écrasements silencieux, qui sont la plaie des procédures stockées partagées.

Et quand on vous demande d’où vient un chiffre, le graphe de lignage répond en quelques secondes, sans documentation à tenir à jour.

Quand ce n’est pas le sujet

Sans entrepôt, dbt n’a aucun objet : il travaille dans une base, pas sur des fichiers ni sur des API.

Avec cinq modèles et une seule personne aux commandes, la mise en place coûtera plus cher que le désordre qu’elle évite. Il faut un minimum de volume pour amortir.

Et si vos traitements ne sont pas du SQL mais du Python lourd, de l’apprentissage automatique ou du traitement de fichiers, l’outil n’est pas fait pour ça. Il sait déclencher du Python sur certaines plateformes, mais ce n’est pas son terrain.

Notre intervention

Ce que nous faisons sur dbt

Nous structurons le projet en couches, de la reprise brute des sources jusqu’aux tables prêtes à être consommées par Power BI, avec des conventions de nommage qui tiennent quand l’équipe grandit. C’est la partie que l’on saute quand on est pressé, et celle qu’on regrette au bout d’un an.

Nous migrons aussi des procédures stockées existantes, sans big bang : les modèles arrivent par lots, l’ancien et le nouveau cohabitent le temps de comparer les résultats, et l’on ne débranche que ce qui est vérifié.

Le reste du travail porte sur les tests et la fraîcheur des sources, sur les modèles incrémentaux quand les volumes l’imposent, et sur l’intégration à votre orchestrateur, y compris pour obtenir un suivi modèle par modèle plutôt qu’une commande unique.

Questions fréquentes

Ce qu’on nous demande le plus souvent

Qu’est-ce que dbt et à quoi sert-il ?

dbt est un outil de transformation de données qui traite les requêtes SQL comme du code : versionnées dans Git, testées automatiquement et documentées. Un modèle dbt est un simple SELECT, et l’outil se charge d’en faire une table ou une vue dans l’entrepôt. En référençant les modèles entre eux plutôt qu’en écrivant les noms de tables en dur, dbt déduit seul le graphe de dépendances et l’ordre d’exécution.

dbt déplace-t-il les données ?

Non. dbt transforme les données déjà présentes dans l’entrepôt, ce qui correspond au T de l’ELT. Il faut donc un outil d’ingestion en amont, comme Fivetran, Azure Data Factory, Talend ou du code maison, pour amener les données depuis les sources. C’est le malentendu le plus fréquent au moment du choix d’outil.

Faut-il un orchestrateur en plus de dbt ?

Oui dès que la chaîne dépasse les transformations SQL. dbt exécute ses modèles dans le bon ordre, mais il ne sait pas attendre qu’un fichier arrive, relancer une tâche échouée plus tard, ni enchaîner avec un traitement qui n’est pas du SQL. Airflow ou Dagster prennent ce rôle, Dagster ayant l’avantage d’orchestrer chaque modèle dbt individuellement.

Quelle différence entre dbt Core et dbt Cloud ?

dbt Core est le moteur en ligne de commande, sous licence Apache 2.0, exécutable sur votre propre infrastructure. dbt Cloud est l’offre commerciale qui ajoute un environnement de développement dans le navigateur, un planificateur et l’hébergement de la documentation. Beaucoup d’équipes commencent avec Core déclenché par leur orchestrateur et ne passent au Cloud que si le confort le justifie.

Quels tests peut-on écrire avec dbt ?

Quatre tests génériques s’écrivent en une ligne : unicité d’une colonne, absence de valeur vide, appartenance à une liste de valeurs autorisées, et correspondance avec une clé d’une autre table. Au-delà, tout test personnalisé est une requête qui ne doit renvoyer aucune ligne, ce qui permet d’encoder des règles métier. On peut également déclarer une fraîcheur attendue sur les sources pour arrêter la chaîne quand les données du jour ne sont pas arrivées.

Pour aller plus loin

Ce qu’on lit ensuite

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : matérialisations, tests, fonction ref.

Des transformations que plus personne n’ose toucher

Nous reprenons l’existant par lots, avec des tests qui prouvent que les résultats n’ont pas bougé. Vous gardez la main à chaque étape.

Demander un audit ou 01 83 64 60 25
01 83 64 60 25 Réserver un appel