Formation dbt

Dans l'article précédent, on s'est appuyé sur l'écosystème avec les packages. Jusqu'ici, on a construit un projet propre : modélisé, testé, documenté, packagé. Tant qu'on est seul dessus, ça marche.

Mais dès qu'un projet dbt est partagé entre plusieurs équipes, ou qu'il alimente des dashboards consommés par d'autres, il faut des garde-fous. Garantir qu'un modèle ne change pas de structure sans prévenir, contrôler qui peut s'appuyer sur quoi, gérer les droits d'accès proprement. C'est la gouvernance, et dbt l'outille avec trois mécanismes : les contracts, les access et les grants.

Les model contracts : garantir la structure

Un contract, c'est une promesse sur la forme de sortie d'un modèle, du style, voici mes colonnes, voici leurs types, et dbt refuse de construire le modèle si la réalité ne correspond pas. C'est ce qui empêche un changement de structure de passer en douce.

Sur mart_clients_commandes, ajoute le contract dans le fichier de propriétés de tes marts, models/marts/_models.yml (le même type de fichier _models.yml que celui où tu as mis tes tests à l'article dédié, mais cette fois dans le dossier marts) :

models:
  - name: mart_clients_commandes
    config:
      contract:
        enforced: true
    columns:
      - name: customer_id
        data_type: number
      - name: prenom
        data_type: varchar
      - name: nb_commandes
        data_type: number
      - name: total_depense
        data_type: number

Avec enforced: true, dbt vérifie à chaque build que la sortie du modèle a exactement ces colonnes avec ces types. Si quelqu'un supprime une colonne ou change un type, le build échoue avant de remplacer la table en production. Donc les dashboards en aval ne tombent jamais, parce que la rupture est identifiée au moment du build, pas une fois en prod.

On va ajouter les deux colonnes manquantes :

Relancer le build de nouveau :

Quand un contract est en place, tu dois déclarer toutes les colonnes du modèle avec leur data_type. C'est un peu de travail au départ, mais c'est idéal quand un modèle est exposé à d'autres équipes.

Access et groups : contrôler qui s'appuie sur quoi

Le deuxième risque, c'est qu'une autre équipe construise sur un modèle que tu considérais comme interne. Les access modifiers règlent ça en disant qui a le droit de faire un ref() sur un modèle.

Trois niveaux :

  • private : seuls les modèles du même groupe peuvent y faire référence
  • protected : les modèles du même projet peuvent y faire référence (le défaut)
  • public : n'importe quel modèle peut y faire référence

Pour utiliser private, on range d'abord les modèles dans un group. On déclare le groupe, puis on l'assigne, on va alors modifier le fichier models/staging/_models.yml pour ajouter le group et assigner stg_customers et stg_orders dans le groupe.

Si on lance le build, on va obtenir une erreur car mart_clients_commandes n'est pas dans le group finance et donc pas le droit d'utiliser le stg_orders.

On va basculer l'access à protected , puis relancer un build.

💡
Si tu as vu ailleurs access ou group écrits directement au niveau du modèle (au même niveau que name), c'est l'ancienne syntaxe. Depuis dbt 1.10, ces propriétés sont devenues des configs et se placent sous la clé config, comme ci-dessus.

Les grants : gérer les droits automatiquement

Troisième problème, les droits d'accès. Quand ton mart est reconstruit, il faut que le rôle de ton outil BI (Qlik Sense, PowerBI etc..) ait le droit de le lire. Géré à la main dans Snowflake, ça se désynchronise vite. dbt peut le faire pour toi à chaque build avec les grants.

D'abord, ce rôle doit exister. C'est le rôle que ton outil de BI (Power BI, Tableau, Looker...) utilise pour se connecter à Snowflake et lire les données. Comme on a créé dbt_role au début de la formation, on crée un bi_role côté Snowflake :

use role accountadmin;

create role if not exists bi_role;

-- le rôle BI doit pouvoir utiliser le warehouse et voir la base et le schéma
grant usage on warehouse dbt_wh to role bi_role;
grant usage on database analytics to role bi_role;
grant usage on schema analytics.dev to role bi_role;

Ensuite, dis à dbt d'accorder la lecture sur ton mart à ce rôle, dans models/marts/_models.yml :

  - name: mart_clients_commandes
    config:
      grants:
        select: ['bi_role']

À chaque exécution, dbt applique un GRANT SELECT ... TO ROLE bi_role sur le modèle. Comme dbt_role est propriétaire des modèles qu'il crée, il a le droit d'accorder cet accès en lecture. Le rôle de ton outil BI a donc toujours le bon droit, automatiquement, sans intervention manuelle. Tu peux vérifier le GRANT généré dans la Query History de Snowsight après un run.

C'est le point où la gouvernance dbt rejoint la sécurité Snowflake et si la notion de rôle et de privilège n'est pas claire pour toi, c'est le moment de relire les rôles système Snowflake.

💡
On peut aussi définir des grants par dossier dans dbt_project.yml, pour appliquer la même règle à toute une couche d'un coup et donc au niveau projet, au lieu de répéter la config sur chaque modèle.

Quand mettre ça en place

En entreprise, on travaille rarement seul sur un projet dbt, donc plusieurs personnes contribuent et des dashboards consomment les modèles.

La gouvernance n'est donc pas un luxe de fin de projet ou optionnel, c'est une obligation et pilier à poser dés le démarrage du projet.

Commence par les grants, dès que possible, pour automatiser les droits. Ajoute des contracts sur tous les modèles exposés à d'autres. Et passe aux access et groups quand l'équipe grandit et que tu veux clarifier ce qui est interne ou public.

La suite ?

Récap. de ce qu'on a vu :

  • Comprendre pourquoi un projet partagé a besoin de garde-fous
  • Poser un contract pour garantir la structure d'un modèle et bloquer une rupture avant la prod
  • Utiliser access et groups pour contrôler quels modèles peuvent s'appuyer sur quoi
  • Automatiser les droits de lecture avec les grants, le pont entre dbt et la sécurité Snowflake

Dans le prochain article, on revient sur la qualité, mais sous un autre angle, et c'est les testes unitaires (les unit tests), pour tester la logique d'un modèle sur des données fictives, et pas seulement vérifier la donnée réelle.

Aller plus loin

Cet article fait partie de la formation dbt complète, du premier modèle au déploiement en production.

👉 Suivre toute la formation dbt

dbt tourne sur Snowflake dans ce parcours. Pour maîtriser le socle (warehouses, rôles, sécurité) :

👉 Accéder à la Formation Snowflake

Et pour t'entraîner en conditions d'examen, la certification dbt Analytics Engineering teste précisément la gouvernance, les contracts et les accès.

👉 Préparer la certification dbt sur DataCertification.fr

Tu veux que je t'accompagne sur ton projet data (Snowflake, dbt, modélisation, industrialisation) ?

👉 Réserver un appel de 30 minutes

Questions fréquentes

C'est quoi un model contract en dbt ?

Un model contract est une garantie sur la structure de sortie d'un modèle : on déclare les colonnes attendues et leurs types, et dbt refuse de construire le modèle si la réalité ne correspond pas. On l'active avec la config contract enforced à true. Ça empêche un changement de structure de casser les modèles ou les dashboards en aval, car la rupture est détectée au build, avant la mise en production.

À quoi servent les access modifiers private, protected et public ?

Les access modifiers contrôlent quels modèles peuvent faire un ref vers un modèle donné. Private limite l'accès aux modèles du même groupe, protected aux modèles du même projet (le défaut), et public ouvre l'accès à tous. Ça permet de protéger les modèles internes comme le staging et de n'exposer que les modèles assumés comme des produits finaux.

Comment dbt gère les droits d'accès avec les grants ?

Avec la config grants sur un modèle, on indique quels privilèges accorder à quels rôles, par exemple select pour un rôle BI. À chaque build, dbt applique automatiquement le GRANT correspondant dans l'entrepôt. Les droits restent donc toujours synchronisés avec les modèles, sans gestion manuelle. C'est le lien entre dbt et la sécurité par rôles de Snowflake.

C'est quoi un group en dbt ?

Un group est un regroupement de modèles, en général par équipe ou par domaine, avec un propriétaire déclaré. Il sert surtout avec les access modifiers : un modèle marqué private n'est accessible qu'aux autres modèles de son groupe. C'est la brique qui permet d'organiser la propriété et les frontières d'un projet partagé entre plusieurs équipes.