Dans l'article précédent, on a vu ce qu'est dbt et pourquoi il est partout dans les offres data. C'était la théorie avec le pourquoi, les modèles, les couches, les tests. Maintenant on passe au clavier.

À la fin de cet article, tu auras dbt installé sur ta machine, connecté à Snowflake, et ton premier modèle qui tourne.

On part de zéro. La seule chose que je suppose, c'est que tu as déjà lu le premier article de la série.

Ce dont tu as besoin avant de commencer

Trois choses :

  • Un compte Snowflake. Si tu n'en as pas, prends l'essai gratuit de 30 jours avec 400 € de crédits sur snowflake.com. Largement suffisant pour toute la série.
  • Python installé (on va utiliser la version 3.12). Tape python --version dans un terminal pour vérifier.
  • Cinq minutes pour préparer le terrain côté Snowflake.

Préparer Snowflake pour dbt

dbt va écrire des tables et des vues dans ton warehouse. Pour ça, il lui faut un endroit où travailler et un rôle qui a le droit de le faire. On ne va pas lui filer ACCOUNTADMIN, ce serait une mauvaise habitude. On crée un rôle dédié.

Ouvre une feuille SQL dans Snowsight et lance ça :

USE ROLE ACCOUNTADMIN;

-- Un warehouse dédié à dbt, en XSMALL pour ne pas cramer tes crédits
CREATE WAREHOUSE IF NOT EXISTS dbt_wh
    WAREHOUSE_SIZE = 'XSMALL'
    AUTO_SUSPEND = 60          -- s'éteint après 60s d'inactivité
    AUTO_RESUME = TRUE
    INITIALLY_SUSPENDED = TRUE;

-- La base où dbt va construire tes tables
CREATE DATABASE IF NOT EXISTS analytics;

-- Un rôle dédié à dbt
CREATE ROLE IF NOT EXISTS dbt_role;

-- On donne au rôle ce qu'il faut pour travailler
GRANT USAGE ON WAREHOUSE dbt_wh TO ROLE dbt_role;
GRANT ALL ON DATABASE analytics TO ROLE dbt_role;
GRANT ALL ON ALL SCHEMAS IN DATABASE analytics TO ROLE dbt_role;
GRANT ALL ON FUTURE SCHEMAS IN DATABASE analytics TO ROLE dbt_role;

-- On attribue le rôle à ton utilisateur
GRANT ROLE dbt_role TO USER ton_utilisateur ;

Remplace ton_utilisateur par ton login Snowflake. Si tu veux retrouver les concepts de warehouse et de rôles, tout est détaillé dans Virtual Warehouse Snowflake et Rôles système Snowflake.

On passe à dbt.

Installer dbt Core

dbt Core s'installe avec pip. Mais avant, on crée un environnement virtuel Python pour isoler le projet. C'est une bonne pratique, ça t'évite de tout casser quand tu auras plusieurs projets.

# On va se positionner sur le dossier de notre projet
CD C:\dbt-project

# On crée l'environnement virtuel
# On va utiliser la version 3.12 pour éviter tout problème de compatibilité
py -3.12 -m venv dbt-env

# On l'active (PowerShell)
.\dbt-env\Scripts\Activate.ps1
💡
Si PowerShell refuse avec "l'exécution de scripts est désactivée sur ce système"

C'est normal, Windows bloque les scripts par défaut. Lance ça une seule fois, puis réactive :

Set-ExecutionPolicy -Scope CurrentUser -ExecutionPolicy RemoteSigned

Sur un poste d'entreprise verrouillé où cette commande est refusée, utilise la version pour la session : Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass.

Une fois l'environnement actif, on installe le package dbt-Snowflake :

python -m pip install dbt-snowflake

Vérifie que c'est bon :

dbt --version

Tu dois voir la version de dbt-core et celle de dbt-snowflake. Si oui, c'est installé.

Créer le projet avec dbt init

Un projet dbt, c'est un dossier avec une structure précise. Plutôt que de la créer à la main, dbt te la génère :

dbt init dbt_projet

dbt te pose quelques questions. Il te demande quel adapter utiliser (choisis snowflake), puis les infos de connexion.

Une fois lancé, tu obtiens cette arborescence :

Chaque dossier a son rôle. Pour l'instant, le seul qui nous intéresse c'est models/.

Configurer la connexion : le profiles.yml

C'est le fichier qui dit à dbt comment se connecter à Snowflake. Il ne vit pas dans le projet (pour ne pas pousser tes identifiants sur Git), mais dans le dossier : C:\Users\<ton_nom>\.dbt\profiles.yml

Ouvre-le et mets ça :

dbt_projet:
  target: dev
  outputs:
    dev:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"   # ton account identifier
      user: ton_utilisateur
      password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
      role: dbt_role
      warehouse: dbt_wh
      database: analytics
      schema: dev
      threads: 4

Quelques points à comprendre :

  • account : c'est l'identifiant de ton compte Snowflake, pas son URL complète. C'est le piège numéro un (voir le callout plus bas).
  • role, warehouse, database : exactement ceux qu'on a créés tout à l'heure.
  • schema : le schéma où dbt écrira en dev. Ici dev.
  • threads : le nombre de modèles que dbt construit en parallèle. 4 est un bon départ.

J'utilise env_var() pour ne pas écrire le mot de passe en dur dans le fichier. Tu définis tes variables avant de lancer dbt :

# Dev local simple
$env:SNOWFLAKE_ACCOUNT="BWLTXTP-PQ43272"
$env:SNOWFLAKE_PASSWORD="ton_mot_de_passe"


# Production / CI-CD recommandé
private_key_path: "{{ env_var('SNOWFLAKE_PRIVATE_KEY_PATH') }}"
private_key_passphrase: "{{ env_var('SNOWFLAKE_PRIVATE_KEY_PASSPHRASE') }}"
Pour démarrer, le mot de passe suffit. Mais en production, on n'utilise jamais ça. On passe par une authentification par clé (key pair), bien plus sûre. Je l'explique en détail dans MFA et Key Pair Snowflake. Garde-le en tête pour plus tard.

💡
Le champ account ne prend pas l'URL https://app.snowflake.com/.... Il prend ton identifiant au format orgname-account_name. Pour le trouver ==> dans Snowsight, clique sur ton profil en bas à gauche, puis sur le nom de ton compte, et copie l'Account Identifier.

Vérifier que tout est branché : dbt debug

Avant d'aller plus loin, on teste la connexion. Place-toi dans le dossier du projet et lance :

cd C:\dbt-project\dbt_projet
dbt debug

Si tout est bon, tu vois une série de coches vertes et le message :

All checks passed!

Si ça échoue, ne panique pas. C'est presque toujours un de ces trois trucs :

Symptôme Ce qu'il faut vérifier
Could not connect ou timeout L'account est mal formaté
Role 'DBT_ROLE' does not exist Le GRANT du rôle à ton user n'est pas passé
Object does not exist sur le warehouse Le nom du warehouse ne correspond pas au profiles.yml

Ton premier modèle qui tourne

dbt a généré des modèles d'exemple dans models/example/. On va les supprimer et écrire le nôtre, plus propre.

Supprime le dossier models/example/, puis crée un fichier models/mon_premier_modele.sql :

SELECT 1 AS id, 'Marc'   AS nom, 'Paris' AS ville
UNION ALL
SELECT 2 AS id, 'Sophie' AS nom, 'Lyon'  AS ville
UNION ALL
SELECT 3 AS id, 'Karim'  AS nom, 'Marseille' AS ville

C'est volontairement basique. Pas de source, pas de jointure, juste un SELECT qui tourne partout. L'idée ici c'est de voir le mécanisme dbt fonctionner, pas d'écrire une transformation compliquée. On branchera des vraies sources dans le prochain article.

Maintenant, le moment qu'on attendait :

dbt run

dbt prend ton SELECT, l'exécute dans Snowflake et matérialise le résultat. Tu vois ça dans le terminal :

1 of 1 OK created sql view model dev.mon_premier_modele ... [SUCCESS 1 in 0.8s]
Completed successfully

Retourne dans Snowsight, déplie ANALYTICS > DEV, et tu vois ta vue mon_premier_modele. Lance un SELECT * FROM analytics.dev.mon_premier_modele : tes trois lignes sont là.

C'est tout. dbt vient de transformer ton fichier SQL en objet dans Snowflake. C'est exactement ce qu'il fera avec 5 modèles ou avec 200, dans le bon ordre, tout seul.

Deux commandes bonus pour la route

Dans l'article 1, j'ai parlé des tests et de la documentation. Tu as déjà tout sous la main pour les essayer. On verra le détail dans les prochains articles, mais teste juste pour voir la puissance :

dbt test    # lance les tests (aucun défini pour l'instant, donc ça passe)
dbt docs generate # génère la doc
dbt docs serve   # ouvre la doc dans ton navigateur

Le dbt docs serve t'ouvre un site web avec le graphe de tes modèles. Pour l'instant il n'y en a qu'un, mais tu vois déjà l'idée.

Ce qu'on a fait, et la suite

Récap rapide. Tu as :

  • Préparé un warehouse, une base et un rôle dédiés dans Snowflake,
  • Installé dbt Core avec l'adapter Snowflake,
  • Créé un projet avec dbt init,
  • Configuré la connexion dans profiles.yml,
  • Validé avec dbt debug,
  • Fait tourner ton premier modèle avec dbt run.

Tu as un projet dbt fonctionnel connecté à Snowflake. C'est la base de tout le reste de la série.

Dans le prochain article, on arrête les SELECT demo. On branche de vraies données brutes avec les sources, et on construit la première couche de staging proprement, dans la logique Bronze vers Silver de l'architecture Médaillon.

Aller plus loin

Si tu veux consolider la partie Snowflake en parallèle (warehouses, rôles, sécurité, stockage), tout est regroupé dans le parcours complet.

👉 Accéder à la Formation Snowflake

Et pour t'entraîner sur dbt en conditions d'examen, la certification dbt Analytics Engineering teste exactement ces concepts. J'ai préparé des questions dédiées sur DataCertification.fr.

👉 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

Faut-il un compte Snowflake payant pour suivre ?

Non. L'essai gratuit de 30 jours avec 400 € de crédits suffit largement pour toute la série dbt. Un warehouse XSMALL avec auto-suspend à 60 secondes consomme très peu, tu ne risques pas d'épuiser tes crédits en apprenant.

Où se trouve le fichier profiles.yml ?

Dans un dossier caché de ton répertoire utilisateur : C:\Users\ton_nom\.dbt\profiles.yml sur Windows. Il est volontairement en dehors du projet pour ne pas pousser tes identifiants sur Git.

dbt debug échoue, par où commencer ?

Dans neuf cas sur dix, c'est l'account identifier mal formaté. Il prend le format orgname-account_name, pas l'URL Snowflake. Vérifie ensuite que le rôle a bien été attribué à ton utilisateur et que les noms de warehouse et de base correspondent exactement à ceux du profiles.yml.

Comment trouver mon account identifier Snowflake ?

Dans Snowsight, clique sur ton profil en bas à gauche, survole le nom de ton compte, puis copie l'Account Identifier. C'est lui qui va dans le champ account du profiles.yml.

dbt Core ou dbt Cloud pour apprendre ?

dbt Core, en ligne de commande. C'est gratuit, open source, et tu comprends ce qui se passe vraiment sous le capot. dbt Cloud apporte une interface web et un scheduler, pratiques en entreprise, mais pour apprendre, le Core est la meilleure école. C'est ce qu'on utilise dans toute la série.