Fondamentaux open source de dbt Core

dbt Core est le fondement open source de l’écosystème dbt. C’est un outil en ligne de commande qui compile des modèles SQL, les exécute dans votre data warehouse et fournit des capacités de test, de documentation et de gestion des dépendances. Tout ce qui constitue dbt Cloud est construit sur Core. Comprendre Core, c’est comprendre ce que dbt fait réellement à son niveau le plus fondamental.

Ce que dbt Core fait

dbt (data build tool) occupe la couche de transformation du modern data stack. Il n’extrait pas de données. Il ne charge pas de données. Il transforme des données qui se trouvent déjà dans votre warehouse en exécutant des modèles SQL dans l’ordre de dépendance.

Le workflow fondamental :

Vous écrivez des instructions SQL SELECT sous forme de fichiers .sql (modèles)
dbt résout les dépendances entre les modèles via {{ ref() }} et {{ source() }}
dbt compile le SQL templaté Jinja en SQL brut
dbt exécute le SQL compilé dans votre warehouse
dbt exécute des tests pour valider le résultat

# Les commandes dbt fondamentales
dbt run          # Exécuter tous les modèles
dbt test         # Lancer tous les tests
dbt build        # Exécuter modèles + tests dans l'ordre de dépendance
dbt compile      # Générer le SQL compilé sans exécution
dbt docs generate  # Construire le site de documentation

La commande dbt build est celle que la plupart des équipes exécutent en production. Elle exécute les modèles et leurs tests associés dans l’ordre topologique — si le modèle B dépend du modèle A, A s’exécute en premier, ses tests passent, puis B s’exécute. Un échec de test sur A empêche B de s’exécuter, ce qui empêche les mauvaises données de se propager en aval.

Développement piloté par CLI

dbt Core fonctionne entièrement via la ligne de commande. Il n’y a pas d’interface graphique. Vous écrivez des modèles dans votre éditeur de texte, exécutez des commandes dans votre terminal et examinez les résultats dans la sortie de votre terminal ou les artefacts compilés.

C’est une fonctionnalité, pas une limitation. Le développement piloté par CLI s’intègre naturellement avec les outils que les ingénieurs logiciels utilisent déjà :

# Développer en local, tester un seul modèle
dbt run --select my_model

# Exécuter un modèle et tout ce qui en dépend en aval
dbt run --select my_model+

# Exécuter seulement les modèles modifiés depuis le dernier commit
dbt run --select state:modified --state ./target

# Build complet avec sources fraîches
dbt source freshness && dbt build

La syntaxe --select est l’une des fonctionnalités les plus puissantes de Core. La sélection de nœuds permet de cibler des modèles, tags, répertoires ou relations de graphe spécifiques sans modifier les fichiers de configuration. Combinée avec state:modified, elle permet des boucles de développement efficaces où on ne reconstruit que ce qui a changé.

Intégration du contrôle de version

Les projets dbt Core sont des fichiers ordinaires sur disque : fichiers SQL, configuration YAML, macros Jinja. Cela signifie qu’ils fonctionnent nativement avec Git. Chaque changement de modèle, chaque ajout de test, chaque mise à jour de configuration passe par le même workflow de pull request que les équipes logicielles utilisent pour le code applicatif.

my_dbt_project/
├── models/
│   ├── staging/
│   │   └── stg_orders.sql
│   ├── intermediate/
│   │   └── int_orders_enriched.sql
│   └── marts/
│       └── mrt_sales_orders.sql
├── tests/
├── macros/
├── dbt_project.yml
└── profiles.yml

Cette structure Git-native permet la revue de code pour les transformations de données. Un analyste de données propose un changement de modèle dans une pull request. Un collègue revoit le diff SQL, vérifie la couverture de tests, et approuve. Le changement fusionne vers main et se déploie. Le même workflow qui prévient les bugs dans le code applicatif prévient les régressions de qualité des données dans votre warehouse.

Des outils comme Claude Code peuvent accélérer significativement ce workflow de développement local — écrire des modèles, générer des tests, déboguer des erreurs de compilation — précisément parce que dbt Core n’est que des fichiers et un CLI.

L’écosystème open source

La nature open source de dbt Core a créé un écosystème qui est sans doute son avantage concurrentiel le plus durable :

Packages communautaires. Plus de 200 packages disponibles via dbt Hub. dbt-utils fournit des macros utilitaires et des tests. dbt-expectations porte les validations style Great Expectations. dbt-audit-helper simplifie la validation des migrations. Les macros de ces packages étendent les capacités de Core sans écrire de code personnalisé.

Adaptateurs de warehouse. Adaptateurs maintenus par la communauté pour BigQuery, Snowflake, Databricks, Redshift, Postgres, DuckDB et des dizaines d’autres. L’architecture d’adaptateur signifie que la logique de transformation de Core est agnostique au warehouse — le même modèle peut s’exécuter sur différentes plateformes avec une compilation spécifique à l’adaptateur.

Plus de 100 000 membres de la communauté. Le Slack dbt est l’une des communautés de données les plus actives. Les problèmes obtiennent des réponses rapidement. Les patterns sont partagés. La base de connaissances collective — articles de blog, conférences, code source des packages — signifie que vous rencontrez rarement un problème que personne n’a résolu auparavant.

Portabilité des compétences. dbt apparaît dans presque chaque offre d’emploi en analytics engineering. Les compétences développées avec Core se transfèrent directement car les patterns SQL, Jinja, YAML et CLI sont universels dans les déploiements dbt. Qu’une entreprise utilise Core ou Cloud, les compétences de modélisation sont identiques.

Environnement de développement local

Configurer dbt Core en local nécessite Python, pip et une connexion au warehouse :

# Installer dbt avec votre adaptateur de warehouse
pip install dbt-core dbt-bigquery

# Initialiser un nouveau projet
dbt init my_project

# Configurer la connexion au warehouse
# Éditer ~/.dbt/profiles.yml avec vos identifiants

# Vérifier la connexion
dbt debug

Le fichier profiles.yml stocke les détails de connexion au warehouse. Pour le développement local, il utilise généralement des identifiants personnels. Pour la production, il utilise des comptes de service ou des application default credentials.

La configuration locale signifie un contrôle total sur votre environnement Python. Vous épinglez des versions exactes de dbt-core et des adaptateurs. Vous pouvez exécuter plusieurs versions de dbt pour différents projets. Vous pouvez installer n’importe quel package Python aux côtés de dbt. Cette flexibilité est essentielle pour les équipes qui doivent intégrer dbt avec des scripts Python personnalisés, des outils de qualité des données ou des systèmes CI/CD.

Le compromis est clair : vous gérez votre propre environnement. Conflits de versions Python, configuration des environnements virtuels, compatibilité des adaptateurs — c’est votre responsabilité. Pour les ingénieurs à l’aise avec les outils Python, c’est trivial. Pour les analystes dont la compétence principale est SQL, cela peut constituer une barrière.

Ce que dbt Core n’inclut pas

Comprendre Core signifie comprendre ce qu’il exclut délibérément :

Pas de planification. Core est un outil CLI. Il s’exécute quand vous l’invoquez. Pour la planification en production, vous avez besoin d’un outil externe : cron, Cloud Scheduler, Airflow, Dagster, ou tout orchestrateur. Si vous optez pour l’auto-hébergement, vous pouvez déployer dbt Core sur une cloud function ou utiliser des Cloud Run Jobs pour gérer la planification.
Pas d’IDE web. Le développement se fait dans votre éditeur local. VS Code avec l’extension dbt Power User est la configuration la plus courante.
Pas de contrôle d’accès intégré. Les permissions multi-utilisateurs sont gérées via Git (protection des branches, code owners) et l’IAM de votre warehouse, pas via dbt lui-même.
Pas d’infrastructure managée. Vous conteneurisez, déployez, monitorez et maintenez le runtime vous-même.

Ces exclusions ne sont pas accidentelles. Elles permettent à Core de se concentrer sur ce qu’il fait bien — compilation SQL, résolution des dépendances, tests, documentation — tout en vous laissant choisir les meilleurs outils externes pour la planification, l’hébergement et la collaboration.

Profil d’équipe

dbt Core convient aux équipes ayant au moins un membre à l’aise avec Python, Git et les outils CLI, qui préfèrent une approche code-first où chaque changement est versionné et revu. L’équipe dispose déjà d’une solution d’orchestration (Airflow, Dagster, cron) ou est prête à en configurer une.

Le coût est un facteur courant. Core est gratuit. Pour les équipes plus grandes où la tarification par siège de dbt Cloud devient significative — 10+ utilisateurs à 100-300 $/mois chacun — l’auto-hébergement de Core avec un orchestrateur open source réduit substantiellement les coûts. La comparaison Dagster vs dbt Cloud couvre cette dynamique de coûts.

Le choix n’est pas définitif. Les équipes peuvent commencer avec Core et migrer vers Cloud quand la planification ou la collaboration devient un point de friction, ou commencer avec le plan gratuit Developer de Cloud et migrer vers Core auto-hébergé à mesure que l’équipe grandit. Les compétences de modélisation (SQL, Jinja, YAML, structure de projet) se transfèrent complètement dans les deux sens.