Le monde de l’analytics engineering tourne autour de dbt. Avec plus de 100 000 membres sur Slack, une présence quasi universelle dans les offres d’emploi et un écosystème mature de packages et d’outils, dbt est devenu le choix par défaut pour la transformation SQL. Mais par défaut ne veut pas dire universel.
Pour les équipes entièrement engagées sur BigQuery sans ambitions multi-cloud, Dataform propose une alternative séduisante : des capacités de transformation comparables à zéro coût de licence. La contrepartie ? Vous échangez la richesse de l’écosystème contre la profondeur d’intégration plateforme.
Ce qu’est réellement Dataform en 2026
Google a acquis Dataform en décembre 2020, rachetant une startup londonienne de 7 personnes fondée par d’anciens Googlers. Depuis, l’outil a évolué en un service GCP entièrement géré, intégré directement dans la console BigQuery.
Les bases : Dataform utilise des fichiers SQLX avec du templating JavaScript au lieu de Jinja. Vous définissez vos transformations, dépendances et assertions, puis Dataform les compile et les exécute sur BigQuery. Pas d’infrastructure à gérer, pas de frais de licence. Vous ne payez que le compute BigQuery consommé par vos transformations.
L’intégration GCP est profonde. L’IAM contrôle les accès via des comptes de service standards. Dataplex assure l’intégration automatique des métadonnées. La planification fonctionne via les configurations de workflow intégrées, Cloud Composer ou Cloud Scheduler. Tout vit dans l’écosystème Google Cloud.
Depuis la migration vers la version hébergée sur GCP en 2024, Dataform a ajouté les VPC Service Controls, l’authentification SSH pour les dépôts git privés et les certifications de conformité SOC 1/2/3, HIPAA et ISO 27001. C’est devenu un service mature.
L’équation financière
Parlons chiffres. dbt Cloud coûte 100 $ par utilisateur et par mois. Pour une équipe de 10 analytics engineers, cela représente 12 000 $ par an. Dataform ne coûte rien au-delà de votre consommation BigQuery existante.
Ces 12 000 $ peuvent sembler dérisoires pour un budget d’entreprise, mais ils s’accumulent au fil des années et de la croissance de l’équipe. Surtout, pour les petites équipes ou les organisations soucieuses de leurs coûts, c’est un poste de dépense difficile à justifier quand une alternative gratuite existe.
Dataform permet évidemment d’économiser sur les licences. Que ces économies résistent aux lacunes de l’écosystème, aux coûts de migration et aux différences de fonctionnalités, c’est moins évident.
Une étude de cas de Bilt Rewards a montré 20 000 $ par mois d’économies sur les coûts BigQuery grâce à des modèles incrémentaux implémentés dans dbt. Dataform supporte aussi les tables incrémentales. Le potentiel d’optimisation warehouse est équivalent car les deux outils envoient au final du SQL à BigQuery. Vos coûts de requêtes dépendent de la qualité de vos transformations, pas de l’outil qui les compile.
Là où Dataform tient la route
Le templating JavaScript de Dataform présente de vrais avantages par rapport à Jinja pour certains cas d’usage.
La génération dynamique de modèles en est l’exemple le plus parlant. Besoin de créer des modèles identiques pour plusieurs pays, clients ou périodes ? Dans Dataform, vous écrivez du JavaScript standard :
const countries = ["US", "GB", "FR", "DE"];countries.forEach(country => { publish(`reporting_${country}`) .dependencies(["source_table"]) .query(ctx => `SELECT * FROM ${ctx.ref("source_table")} WHERE country = '${country}'`);});Quatre modèles créés avec une simple boucle. En dbt, obtenir le même résultat nécessite le package dbt_codegen, un prétraitement externe ou des acrobaties Jinja de plus en plus alambiquées.
L’IDE intégré à la Cloud Console offre un retour de compilation en temps réel et des estimations de coût BigQuery pendant l’écriture. Pas besoin d’attendre un build pour vérifier votre syntaxe. Pour les équipes qui n’ont pas besoin d’intégration IDE, ce workflow est agréablement réactif.
La vitesse de compilation a historiquement favorisé le moteur JavaScript de Dataform face à l’approche Python de dbt. La sortie de dbt Fusion en 2025 (une réécriture en Rust offrant un parsing 30 fois plus rapide) comble cet écart, mais uniquement pour les utilisateurs dbt Cloud. dbt Core auto-hébergé utilise toujours le compilateur Python, plus lent.
Là où Dataform est en retrait
Les tests constituent la lacune la plus significative. Les assertions intégrées de Dataform couvrent trois scénarios : vérification d’unicité, validation de nullité et conditions sur les lignes. C’est tout.
config { type: "table", assertions: { uniqueKey: ["customer_id"], nonNull: ["customer_id", "email"], rowConditions: ['email LIKE "%@%.%"'] }}Comparez avec l’écosystème dbt. Le package dbt_expectations à lui seul fournit plus de 50 tests couvrant les distributions statistiques, le matching regex et les comparaisons inter-tables. Le package Elementary ajoute la détection d’anomalies et l’observabilité des données. dbt 1.8 a introduit les tests unitaires natifs. Les utilisateurs Dataform qui souhaitent une couverture comparable doivent implémenter manuellement des fichiers d’assertions custom.
Le CI/CD raconte la même histoire. dbt Cloud propose le Slim CI clé en main : build automatique des seuls modèles modifiés et de leurs dépendants, création de schémas spécifiques aux PR et linting SQL. Quelques clics et c’est en place.
Dataform exige une mise en place manuelle conséquente. Les workflows ne peuvent pas se déclencher nativement à partir d’événements git. Implémenter une automatisation comparable implique d’appeler l’API REST Dataform depuis des outils CI externes comme GitHub Actions ou Cloud Build. C’est faisable, mais c’est du travail à votre charge.
L’écart côté IDE est difficile à ignorer. L’extension dbt Power User pour Cursor cumule plus d’un million d’installations. Elle offre la visualisation du lineage des modèles, la prévisualisation des requêtes avec exécution, l’auto-complétion des colonnes et macros, la génération de documentation assistée par IA et l’estimation des coûts BigQuery. Rien de comparable n’existe pour Dataform. Vous êtes limité à l’IDE de la Cloud Console ou à un éditeur de texte basique.
L’écosystème de packages est quasi inexistant. dbt compte plus de 200 packages sur hub.getdbt.com couvrant des sujets allant de la transformation GA4 à la modélisation d’attribution. Dataform n’a pas de hub centralisé de packages. Le package dataform-assertions de Devoteam est l’une des rares options tierces disponibles.
Et bien sûr : Dataform ne fonctionne qu’avec BigQuery. dbt se connecte à plus de 20 plateformes via son architecture d’adaptateurs. Si vous avez la moindre chance d’avoir besoin de Snowflake, Databricks ou Redshift à l’avenir, Dataform vous ferme la porte.
Le test de réalité de la migration
Des outils de migration existent dans les deux sens. ra_dbt_to_dataform gère la conversion dbt vers Dataform en utilisant GPT-4 pour la traduction de macros complexes. dataform-to-dbt assure le chemin inverse.
Les délais réalistes varient considérablement selon la complexité du projet :
| Taille du projet | Délai estimé | Effort principal |
|---|---|---|
| Petit (~20 modèles) | 1-2 semaines | Essentiellement automatisé |
| Moyen (~50-100 modèles) | 2-4 semaines | Conversion des macros |
| Grand (100+ modèles) | 2-3 mois | Réécriture complète de la logique programmatique |
| Entreprise avec validation | 3-6 mois | Exécution en parallèle, validation par les parties prenantes |
La conversion des macros est le point de friction. Vos macros Jinja custom ne se traduisent pas automatiquement. Chaque bloc {% macro %} nécessite une réécriture manuelle en JavaScript. Si votre projet repose fortement sur des macros partagées, prévoyez un temps conséquent pour ce travail.
Quand Dataform est le bon choix
Dataform s’impose quand plusieurs conditions sont réunies :
Vous êtes à 100 % sur BigQuery. Pas « principalement BigQuery avec peut-être un peu de Snowflake plus tard ». Pas « BigQuery pour l’instant mais on évalue d’autres options ». Un engagement total sans feuille de route multi-cloud.
Les coûts de licence pèsent sur votre budget. Si 1 200 $ par utilisateur et par an impactent réellement votre budget, Dataform élimine entièrement ce poste.
Votre équipe préfère JavaScript. Certains ingénieurs trouvent sincèrement Jinja frustrant. Si votre équipe pense déjà en JavaScript, le templating Dataform sera plus naturel.
Vos cas d’usage sont simples. Modélisation dimensionnelle standard, tables incrémentales, tests basiques. Si vous n’avez pas besoin du traitement microbatch de dbt, de stratégies incrémentales avancées ou de scénarios de tests complexes, ils ne vous manqueront pas.
Vous êtes prêts à construire ce qui manque. Dataform demande plus de travail custom pour les tests, le CI/CD et l’outillage. Si votre équipe a la capacité et la volonté de développer des solutions sur mesure pour combler ces lacunes, le compromis tient la route.
Quand rester sur dbt
dbt reste le meilleur choix dans les cas suivants :
Le multi-warehouse est dans la feuille de route. Même 20 % de chances d’avoir besoin de Snowflake, Databricks ou Redshift dans les prochaines années fait pencher la balance en faveur de la portabilité de dbt.
Vous avez besoin d’un CI/CD mature dès maintenant. Construire des fonctionnalités équivalentes dans Dataform prend des semaines. dbt Cloud les fournit immédiatement.
L’écosystème de packages compte. Transformation GA4, modélisation d’attribution, observabilité des données : si vous utilisez ou prévoyez d’utiliser ces packages, dbt est la seule option viable.
Le développement de carrière de l’équipe entre en jeu. 87 % des analytics engineers nord-américains gagnent plus de 100 000 $. La maîtrise de dbt apparaît dans presque toutes les offres d’emploi des entreprises data-driven. L’expertise Dataform reste une niche. Les opportunités futures de votre équipe penchent vers dbt.
Vous avez des besoins incrémentaux complexes. Le traitement microbatch de dbt, introduit en 2024, n’a pas d’équivalent Dataform. Si vous avez besoin d’une gestion sophistiquée des données arrivant en retard ou de stratégies incrémentales spécifiques aux séries temporelles, dbt répond présent.
Prendre la décision
Passez en revue ces questions avec votre équipe :
- BigQuery est-il notre data warehouse pour l’avenir prévisible, ou pourrions-nous diversifier ?
- Combien économiserions-nous réellement sur les licences en deux ans ?
- Quel est le coût estimé de la migration en temps d’ingénierie ?
- Quelles lacunes de l’écosystème nous obligeraient à développer des solutions custom ?
- Quelle importance a la communauté dbt au sens large pour le recrutement et la montée en compétences ?
Si le coût de migration dépasse deux années d’économies sur les licences, rester sur l’outil actuel est logique financièrement, quelle que soit votre préférence.
La fusion dbt-Fivetran annoncée en octobre 2025 ajoute une nouvelle variable. L’entité combinée approchant les 600 M$ de revenus récurrents annuels confirme la consolidation du secteur. dbt n’est pas près de disparaître, mais les tarifs et le packaging pourraient évoluer. La position de Dataform comme alternative gratuite soutenue par Google prend d’autant plus de valeur si les coûts de dbt Cloud augmentent.
Pour les équipes exclusivement BigQuery avec des besoins simples et une sensibilité aux coûts, Dataform est un choix légitime. L’outil transforme le SQL efficacement, s’intègre nativement à GCP et ne coûte rien au-delà du compute.
Pour tous les autres — équipes avec des perspectives multi-cloud, des exigences de tests complexes ou une dépendance à l’écosystème au sens large — la prime de dbt achète de vraies capacités que Dataform ne peut pas égaler.
Le bon outil dépend de votre contexte, pas du vainqueur d’un tableau comparatif de fonctionnalités.