dbt pour les nuls : guide pratique

dbt, c’est quoi en une phrase

dbt te permet d’écrire des transformations SQL comme du code versionné, testé, documenté et déployé proprement.

Pourquoi dbt change la donne

Sans dbt, on voit souvent :

  • des requêtes SQL copiées dans plusieurs endroits
  • des définitions métier incohérentes
  • peu de tests
  • une doc obsolète

Avec dbt :

  • chaque modèle est un fichier clair
  • les dépendances sont explicites
  • les tests sont automatisés
  • la documentation est générée

Le minimum à comprendre

1. model

Un model = une transformation SQL matérialisée en table ou view.

2. ref()

ref('nom_modele') déclare une dépendance entre models.

3. tests

Deux niveaux :

  • tests génériques (not_null, unique, accepted_values)
  • tests métier personnalisés

4. sources

Permet de documenter et tester les tables d’entrée.

Structure simple pour commencer

models/
  staging/
    stg_customers.sql
    stg_orders.sql
  marts/
    fct_orders.sql
    dim_customers.sql
  schema.yml

Règle utile :

  • staging = nettoyage léger + renommage cohérent
  • marts = logique métier et indicateurs

Exemple concret

-- models/staging/stg_orders.sql
select
  order_id,
  customer_id,
  cast(order_date as date) as order_date,
  amount
from {{ source('app', 'orders') }}
where order_id is not null
-- models/marts/fct_orders.sql
select
  o.order_id,
  o.customer_id,
  o.order_date,
  o.amount,
  c.country
from {{ ref('stg_orders') }} o
left join {{ ref('stg_customers') }} c
  on o.customer_id = c.customer_id

Les 5 commandes à connaître

  • dbt debug
  • dbt run
  • dbt test
  • dbt build
  • dbt docs generate

Plan de déploiement en 3 phases

  1. Pilote : un domaine métier, 5 à 10 models, tests de base.
  2. Standardisation : conventions de nommage, revues SQL, CI.
  3. Industrialisation : monitoring des runs, SLA, ownership par domaine.

Erreurs fréquentes

  • tout mettre dans un seul model géant
  • ignorer les tests source
  • mélanger logique métier et nettoyage dans les marts
  • ne pas versionner les changements de définitions KPI

En résumé

dbt n’est pas magique. C’est surtout une discipline qui rend les transformations lisibles, testables et maintenables. Commence petit, impose des conventions, et monte en puissance progressivement.


Vous avez un projet data similaire ? Parlons-en → isdataconsulting.com

Besoin d'aide pour mettre ça en place ?

Missions Data Engineering, Architecture Data, Data Product Owner — ISData Consulting.