dbt Cloud vs dbt Core : le vrai comparatif pour décideurs

Pourquoi ce comparatif est nécessaire en 2026

Si vous lisez cet article, c’est probablement que vous avez déjà compris pourquoi dbt a remplacé les ETL traditionnels. La question suivante est inévitable : Core ou Cloud ?

La réponse n’est pas aussi simple que “gratuit vs payant”. dbt Labs a considérablement fait évoluer sa plateforme Cloud depuis 2024 : dbt Mesh pour gérer des projets multi-équipes, Explorer pour naviguer le lineage en temps réel, Semantic Layer pour centraliser les définitions de métriques, et dbt Copilot pour assister la documentation. La plateforme n’a plus grand-chose à voir avec le “scheduler de jobs dbt” qu’elle était en 2022

Côté Core, l’écosystème open-source a aussi mûri. Les adaptateurs pour Snowflake, BigQuery, Databricks et PostgreSQL sont stables et performants. Les outils complémentaires (sqlfluff pour le linting, elementary pour le monitoring, dbt-expectations pour les tests avancés) comblent une partie des fonctionnalités de Cloud

Le marché a dépassé le stade du “cool tool de startup”. En 2026, dbt est un composant critique du SI data de milliers d’entreprises. Le choix entre Core et Cloud est un choix structurant qui impacte votre équipe, votre budget et votre gouvernance pour les 3 à 5 prochaines années

dbt Core : ce que vous gagnez, ce que vous payez

dbt Core est le moteur open-source de dbt, distribué sous licence Apache 2.0. C’est un outil en ligne de commande que vous installez sur votre machine, dans un conteneur Docker, ou dans votre pipeline CI/CD. Il fait exactement ce que dbt fait : compiler des modèles SQL, gérer les dépendances, exécuter les transformations dans votre warehouse, lancer les tests, générer la documentation

Ce que vous gagnez :

• Contrôle total. Le code est sur votre infrastructure, dans votre réseau, sous votre responsabilité. Aucune donnée ne transite par un tiers : les requêtes SQL sont envoyées directement de votre serveur à votre warehouse.
• Flexibilité illimitée. Vous choisissez votre IDE (VS Code avec l’extension dbt Power User est le standard de facto), votre orchestrateur, votre pipeline CI/CD, votre monitoring. Rien n’est imposé.
• Coût de licence : zéro. dbt Core est gratuit. Point.
• Communauté massive. Plus de 10 000 contributeurs, des centaines de packages communautaires, et un Slack de 70 000+ membres

Ce que vous payez, et c’est là que le “gratuit” se nuance :

• CI/CD à construire. Vous devez mettre en place votre pipeline de déploiement (GitHub Actions, GitLab CI, Jenkins). Voici un exemple minimal :

# .github/workflows/dbt-ci.yml
name: dbt CI
on: [pull_request]
jobs:
  dbt-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-snowflake
      - run: dbt deps
      - run: dbt build --select state:modified+ --defer --state ./prod-manifest
        env:
          DBT_PROFILES_DIR: ./ci

• IDE sans intégration native. VS Code fonctionne très bien, mais le feedback loop est plus lent qu’avec l’IDE Cloud (pas de preview en temps réel, pas de lineage visuel intégré).
• Monitoring à implémenter. Pas d’alerting natif. Vous devez intégrer elementary, Monte Carlo, ou un outil maison.
• Sécurité à gérer. Gestion des credentials, rotation des secrets, audit des accès, c’est votre responsabilité.
• Profil requis : au minimum un data engineer senior capable de maintenir l’infrastructure. Comptez 20-30 % de son temps pour les tâches d’ops dbt

C’est précisément ce coût d’ingénierie interne que dbt Cloud promet d’éliminer. Voyons ce que la plateforme SaaS apporte concrètement, et à quel prix

dbt Cloud : ce que vous gagnez, ce que vous payez

dbt Cloud est la plateforme SaaS de dbt Labs. Elle embarque dbt Core comme moteur, mais y ajoute tout ce qui manque pour une utilisation en production en entreprise

Ce que vous gagnez :

• IDE intégré. Un éditeur SQL dans le navigateur avec preview en temps réel, autocomplétion, lineage visuel, et documentation contextuelle. Les analytics engineers sont productifs dès le premier jour.
• Orchestration native. Jobs planifiés, triggers sur événements, CI checks sur les pull requests. Pas besoin d’Airflow ou de Dagster si dbt est votre seule couche de transformation.
• Gouvernance et observabilité. Logs d’exécution, historique des runs, alertes email/Slack, audit trail. Tout est centralisé dans une interface unique.
• dbt Mesh (depuis 2024). Gestion multi-projets avec dépendances cross-projets, versionnement des contrats d’interface, et déploiement indépendant par équipe. C’est la réponse de dbt Labs au “comment scaler dbt dans une grande organisation”.
• Explorer. Navigation interactive dans le lineage, recherche full-text sur les modèles et les colonnes, impact analysis avant modification.
• Semantic Layer. Définition centralisée des métriques, exposée via API à n’importe quel outil de BI. Une seule source de vérité pour “qu’est-ce que le chiffre d’affaires”

Quand dbt Mesh est utile : si vous avez plus de 3 domaines ou business units avec des cycles de release indépendants. La majorité des ETI (un seul domaine data ou 2-3 étroitement couplés) n’en ont pas besoin : Mesh répond à un problème de grande organisation, pas de PME ou ETI mono-équipe

Ce que vous payez :

• Pricing. Le plan Developer est gratuit (1 utilisateur, idéal pour tester). Le plan Team coûte environ 100 $/utilisateur/mois (tarif avril 2026, susceptible d’évoluer, vérifier la page pricing officielle). Le plan Enterprise est sur devis et inclut SSO, hébergement EU, support dédié, audit logs granulaires.
• Vendor lock-in, mais limité. Votre code dbt (modèles SQL, tests, documentation YAML) est strictement identique entre Core et Cloud. Ce qui est lié à Cloud : la configuration des jobs, les environnements, les intégrations d’alerting. En pratique, une migration Cloud → Core prend quelques jours.
• Dépendance SaaS. Si dbt Cloud est en panne, vos jobs planifiés ne tournent pas. dbt Labs affiche un uptime de 99,9 %, mais c’est un risque à évaluer.
• Coût warehouse induit. Le mode IDE web de Cloud exécute les requêtes de preview en temps réel sur le warehouse. Sur Snowflake/BigQuery, ces previews consomment des crédits marginaux mais réels : typiquement 50-200 $/mois pour une équipe de 5-10 utilisateurs actifs. Ce surcoût n’apparaît pas sur la facture dbt Labs mais sur celle du warehouse.
• Fonctionnalités en évolution rapide. Certaines features (Semantic Layer, dbt Copilot) sont encore en maturation. Évaluez ce qui est GA (Generally Available) vs ce qui est en beta avant de baser votre architecture dessus

Les deux options ont des forces claires. Pour y voir net, un tableau de synthèse critère par critère

Comparatif structuré

Critère	dbt Core	dbt Cloud Team	dbt Cloud Enterprise
Coût licence	Gratuit	~100 $/user/mois	Sur devis
Coût infra	À votre charge (CI/CD, serveur)	Inclus	Inclus
IDE	VS Code + extensions	IDE web intégré	IDE web intégré
CI/CD	À construire (GitHub Actions, etc.)	Intégré (CI checks sur PR)	Intégré + contrôle granulaire
Orchestration	Externe (Airflow, Dagster, cron)	Native (jobs, schedules, triggers)	Native + orchestration cross-projets
Monitoring / alerting	Elementary, custom, ou rien	Logs + alertes email/Slack	Logs + alertes + audit trail complet
Gouvernance	Manuelle (conventions + PR reviews)	Explorer + lineage	Explorer + Mesh + RBAC
Multi-projets	Repos séparés (manuel)	Non	dbt Mesh (dépendances cross-projets)
Courbe d’apprentissage	Modérée (CLI + Git + CI/CD)	Faible (IDE web, UX guidée)	Faible
Portabilité	Totale (vous possédez tout)	Code portable, config spécifique	Code portable, config spécifique

Tarifs Cloud indiqués en avril 2026 ; consulter la page pricing officielle pour les valeurs à jour

Le point clé : le code dbt est identique entre Core et Cloud. La différence porte sur l’outillage autour : orchestration, monitoring, gouvernance, IDE. Ce sont des choix d’infrastructure, pas des choix de code

Cette portabilité du code ouvre une option que ni dbt Labs ni les puristes open-source ne mettent en avant : combiner les deux

L’approche hybride : la troisième voie

Dans nos missions, nous observons qu’une majorité d’ETI adoptent une approche hybride : dbt Core en local pour le développement, dbt Cloud pour l’orchestration en production. Ce n’est pas un compromis, c’est souvent la meilleure architecture

Comment ça fonctionne :

1. Les analytics engineers développent en local avec VS Code + dbt Core. Ils bénéficient de leur IDE familier, de leur configuration personnalisée, et d’un feedback loop rapide (dbt run --select model_name en 2 secondes).
2. Le code est poussé sur GitHub/GitLab. Un CI check dans dbt Cloud valide automatiquement les modifications (compilation, tests).
3. Une fois mergé, dbt Cloud orchestre l’exécution en production : jobs planifiés, monitoring, alerting

Pourquoi ça marche :

• Les développeurs gardent leur environnement local, sans contrainte d’IDE imposé.
• L’orchestration est déléguée à Cloud, pas besoin de maintenir un Airflow ou un Dagster.
• La gouvernance (logs, historique, alertes) est centralisée dans Cloud.
• La migration est progressive : on peut commencer full Core, puis ajouter Cloud pour l’orchestration quand le besoin se fait sentir

Les limites :

• Double outillage (Core en local, Cloud en prod) qui nécessite une documentation claire des workflows.
• Le plan Team de Cloud ne supporte pas dbt Mesh : il faut passer en Enterprise pour le multi-projets. Comme indiqué plus haut, ce n’est un bloqueur que si vous êtes déjà sur une architecture multi-domaines (rare en ETI).
• La configuration initiale demande 1 à 2 jours pour aligner les environnements dev et prod

Core, Cloud ou hybride : trois options valables. Le bon choix dépend avant tout du profil de votre organisation

Matrice de décision : 4 profils, 4 recommandations

Profil 1 : Startup ou PME, équipe Data de moins de 5 personnes

Recommandation : dbt Cloud Team. Votre priorité est la productivité, pas le contrôle. L’IDE intégré, l’orchestration native et le monitoring inclus vous font gagner des semaines de setup. À 100 $/user/mois pour 5 personnes, le coût (6 000 $/an) est négligeable par rapport au temps d’un data engineer qui configure et maintient une infrastructure Core

Exception : si votre équipe est composée de data engineers seniors qui ont déjà un pipeline CI/CD robuste, Core est parfaitement viable

Profil 2 : ETI, équipe Data de 5 à 15 personnes, budget contraint

Recommandation : approche hybride (Core en local + Cloud en production). Vous avez besoin de gouvernance et de monitoring (trop de modèles pour du “artisanal”), mais le budget Enterprise n’est pas justifié. Le plan Team + Core en développement donne le meilleur rapport qualité/prix

Budget indicatif : 12 000-18 000 $/an en licences Cloud Team + 20 % du temps d’un data engineer pour la maintenance

Profil 3 : Grand compte, équipe plateforme Data existante

Recommandation : dbt Core + infrastructure maison. Vous avez déjà un Airflow ou un Dagster. Vous avez des exigences de sécurité qui nécessitent un contrôle total. Votre équipe plateforme a les compétences pour maintenir l’infrastructure. Ajouter dbt Cloud serait un outil de plus dans une stack déjà riche

Exception : si vous envisagez dbt Mesh pour gérer des dizaines de projets dbt across business units, Cloud Enterprise est le seul chemin viable : reconstruire Mesh en interne n’a aucun sens

Profil 4 : Organisation réglementée (santé, finance, secteur public)

Recommandation : dbt Cloud Enterprise. Le plan Enterprise offre l’hébergement EU (conformité RGPD), le SSO (intégration avec votre IdP), les audit logs (traçabilité des accès et des modifications), et le support dédié. Ces fonctionnalités sont coûteuses à reconstruire en interne et critiques pour la conformité

Point d’attention : vérifiez que l’hébergement EU couvre votre juridiction spécifique et que le DPA de dbt Labs satisfait vos exigences réglementaires avant de vous engager

Ces recommandations sont génériques par nature. Pour illustrer comment le choix se joue en situation réelle, voici un cas concret

Ce qu’on a vu sur le terrain

Dans le REX composite Nobori (plusieurs missions menées auprès d’ETI similaires entre 2023 et 2026, illustré dans notre article dbt a tué l’ETL traditionnel), le choix s’est porté sur dbt Core + Snowflake

Contexte de la décision : une équipe de 3 personnes (1 responsable data + 2 analystes), un budget serré, et un CI/CD déjà en place via GitHub Actions. Le besoin d’orchestration était simple : un dbt build quotidien à 6h du matin, un dbt test après chaque run

Pourquoi Core et pas Cloud : pour 3 utilisateurs, le coût de Cloud Team (3 600 $/an) n’était pas prohibitif, mais l’équipe maîtrisait déjà Git et GitHub Actions. L’IDE web n’apportait pas de valeur ajoutée par rapport à VS Code avec dbt Power User. Et surtout, le monitoring a été couvert par elementary (gratuit, open-source, et largement suffisant pour le volume de modèles)

Recul à 6 mois : le choix Core a tenu. La maintenance de l’infrastructure CI/CD représente environ 2 heures par semaine. Si l’équipe passe à 6-8 personnes, la migration vers Cloud sera envisagée, principalement pour la gouvernance (Explorer, logs centralisés) et l’onboarding simplifié des nouveaux arrivants

Ce cas s’est bien passé parce que l’équipe a évalué ses besoins réels avant de décider. Toutes les organisations ne font pas ce travail, et c’est la source des erreurs les plus fréquentes

Les 3 erreurs du choix Cloud vs Core

1. Choisir Core “parce que c’est gratuit”. Le coût de licence de Core est zéro. Mais le coût total de possession inclut : le temps de l’ingénieur qui configure le CI/CD (1-2 semaines), qui le maintient (2-4 heures/semaine), qui met en place le monitoring (elementary, alertes Slack), qui gère les secrets et les credentials. Pour une équipe de 10 personnes, ce coût caché dépasse souvent le prix de Cloud Team. Faites le calcul honnêtement avant de décider

2. Choisir Cloud sans évaluer la maturité des features. dbt Labs itère vite. Certaines fonctionnalités annoncées avec enthousiasme (Semantic Layer, dbt Copilot) sont encore en phase de maturation. Avant de baser votre architecture sur une feature Cloud, vérifiez son statut : GA (stable, supporté), Public Preview (fonctionnel mais susceptible de changer), ou Beta (expérimental). Ne construisez pas sur du sable

3. Décider avant d’avoir un projet dbt fonctionnel. Le piège classique : passer 3 semaines à comparer Core et Cloud avant d’avoir écrit un seul modèle dbt. Notre recommandation : commencez par Core (5 minutes d’installation, zéro friction), construisez vos 10 premiers modèles, comprenez vos besoins réels, puis évaluez si Cloud apporte une valeur ajoutée dans votre contexte. La migration Core → Cloud prend quelques heures, ce n’est pas une décision irréversible

Conclusion

Le choix entre dbt Core et dbt Cloud n’est pas un choix technologique, c’est un choix organisationnel. Core vous donne le contrôle et la flexibilité, au prix de l’ingénierie interne. Cloud vous donne la productivité et la gouvernance, au prix d’une dépendance SaaS et d’un coût récurrent

Pour la majorité des ETI que nous accompagnons, l’approche hybride (Core en développement, Cloud en production) offre le meilleur compromis. Elle combine l’expérience développeur de Core avec la gouvernance de Cloud, et permet une migration progressive au rythme de la croissance de l’équipe

La bonne question n’est pas “Core ou Cloud ?” mais “de quoi ai-je besoin aujourd’hui, et comment mon besoin va-t-il évoluer dans les 2-3 prochaines années ?”. La réponse honnête à cette question vous donnera la bonne architecture

Nobori accompagne les ETI dans le choix et le déploiement de leur stack data. Découvrir notre offre Data

Sources et méthodologie

• dbt Labs, Pricing : grilles tarifaires Developer, Team, Enterprise (consultées en mars 2026)
• dbt Labs, “State of Analytics Engineering” (2024) : adoption Core vs Cloud, profils d’équipes, tendances
• dbt Labs, dbt Mesh documentation : architecture multi-projets, contrats d’interface
• Retours d’expérience Nobori : données issues de nos missions d’accompagnement data auprès d’ETI (choix d’architecture, TCO observé)

Les estimations de TCO et les recommandations par profil sont basées sur nos observations terrain sur une dizaine de missions dbt accompagnées entre 2023 et 2026. Les prix de dbt Cloud sont indicatifs et susceptibles d’évoluer, consultez la page pricing officielle pour les tarifs à jour

Pour aller plus loin

• Découvrez pourquoi dbt a remplacé les ETL traditionnels : le contexte qui rend ce choix nécessaire
• Apprenez à structurer un projet dbt en entreprise une fois votre choix Core/Cloud fait
• Explorez notre expertise Data et nos approches d’industrialisation des plateformes data