Dataform vs. dbt : quel outil de transformation choisir ?

La fusion dbt-Fivetran annoncée en octobre 2025 redessine le paysage de l’analytics engineering. L’entité combinée approche les 600 M$ de revenus récurrents annuels et compte plus de 10 000 clients. De son côté, Dataform de Google reste gratuit pour les utilisateurs BigQuery — une alternative séduisante si vos données vivent entièrement dans GCP.

J’ai travaillé de manière approfondie avec les deux outils. Voici mon évaluation de leurs forces respectives et celui que vous devriez probablement choisir.

Le paysage a changé en 2026

Il y a deux ans, cette comparaison aurait été simple : dbt pour les équipes sérieuses, Dataform pour les amateurs BigQuery. Ce cadre ne tient plus.

Dataform a considérablement mûri depuis l’acquisition par Google en 2020. L’outil inclut désormais les VPC Service Controls, l’intégration Dataplex, l’authentification SSH et les certifications de conformité entreprise. Google le positionne comme un service gratuit et prêt pour la production au sein de l’écosystème BigQuery — pas un jouet.

dbt, de son côté, continue de creuser l’écart entre Core et Cloud. Le moteur dbt Fusion, basé sur Rust, offre un parsing 30 fois plus rapide, mais seuls les clients Cloud y ont accès. La fusion avec Fivetran confirme un virage vers les plateformes unifiées plutôt que la composition best-of-breed.

Le choix entre ces deux outils implique aujourd’hui de vrais compromis.

Ce qui les distingue réellement

Les deux outils font fondamentalement le même travail : compiler des transformations SQL et les exécuter dans votre data warehouse. Puisque les deux envoient du SQL standard à BigQuery, les performances d’exécution sont identiques. Une jointure complexe prend le même temps quel que soit l’outil qui l’a générée.

Les différences significatives se situent ailleurs :

Expérience développeur : JavaScript vs Jinja

Le débat sur le langage de templating suscite des avis tranchés. Après avoir écrit des codebases conséquentes dans les deux, je trouve que chacun a de véritables atouts.

Syntaxe de référence

dbt utilise la syntaxe à double accolade de Jinja :

SELECT
    customer_id,
    customer__name,
    customer__email,
    customer__status,
    updated_at
FROM {{ ref('base__source__customers') }}
WHERE customer__status IN {{ var('active_statuses') }}
{% if is_incremental() %}
    AND updated_at > (SELECT MAX(updated_at) FROM {{ this }})
{% endif %}

Dataform utilise les template literals JavaScript :

config { type: "incremental", uniqueKey: ["customer_id"] }

SELECT
    customer_id,
    customer__name,
    customer__email,
    customer__status,
    updated_at
FROM ${ref("base__source__customers")}
WHERE customer__status IN ${dataform.projectConfig.vars.active_statuses}
${when(incremental(), `AND updated_at > (SELECT MAX(updated_at) FROM ${self()})`)}

Aucun des deux n’est objectivement meilleur. Jinja semble naturel pour ceux qui ont travaillé avec le templating Python. JavaScript plaît aux développeurs frontend et à ceux qui trouvent la gestion des espaces de Jinja frustrante.

Génération dynamique de modèles

JavaScript a un avantage net pour la génération dynamique de modèles. Dataform permet de créer des modèles par programmation dans de simples fichiers .js :

const countries = ["US", "GB", "FR", "DE"];
countries.forEach(country => {
  publish(`mrt__reporting__${country}`)
    .dependencies(["base__analytics__events"])
    .query(ctx => `
      SELECT
        event_id,
        event__name,
        event__country,
        event__created_at
      FROM ${ctx.ref("base__analytics__events")}
      WHERE event__country = '${country}'
    `);
});

dbt ne propose pas de support natif pour ce pattern. Il faut recourir à dbt_codegen, un prétraitement externe, ou des acrobaties Jinja de plus en plus créatives. Comme l’a bien résumé un développeur : « Parfois Jinja commence à ressembler à un langage de programmation (des macros dans des macros), mais ça donne une expérience développeur horrible. »

Approches de test

dbt utilise des tests de schéma en YAML :

models:
  - name: mrt__analytics__customers
    columns:
      - name: customer_id
        tests: [unique, not_null]
      - name: customer__email
        tests:
          - not_null
          - unique

Dataform intègre les assertions directement dans le modèle :

config {
  type: "table",
  assertions: {
    uniqueKey: ["customer_id"],
    nonNull: ["customer_id", "customer__email"],
    rowConditions: ['customer__email LIKE "%@%.%"']
  }
}

Les tests intégrés de Dataform couvrent l’unicité, les vérifications de nullité et les conditions sur les lignes. C’est souvent suffisant pour des projets simples. Mais l’écosystème dbt étend considérablement les possibilités de test, et c’est là que se fait la vraie différence.

L’écart d’écosystème : le principal atout de dbt

Les comparaisons fonctionnalité par fonctionnalité sous-estiment l’écart entre ces outils. La différence d’écosystème est substantielle et ne cesse de se creuser.

La communauté Slack de dbt dépasse les 100 000 membres. Le hub de packages en recense plus de 200. L’extension Power User pour Cursor et VS Code totalise plus d’un million d’installations. Les offres d’emploi chez Apple, Netflix, Spotify et dans la plupart des entreprises data-driven exigent explicitement une expérience dbt.

La communauté Dataform est plus réduite et concentrée dans les organisations centrées sur GCP. Il n’y a pas de hub centralisé de packages. Aucune extension Cursor ou VS Code n’approche les capacités de Power User pour dbt.

Profondeur des tests

Le package dbt_expectations à lui seul fournit plus de 50 tests couvrant les distributions statistiques, le matching regex et les comparaisons inter-tables. Reproduire ces patterns dans Dataform nécessiterait des centaines de lignes de SQL custom. Elementary ajoute l’observabilité des données avec détection d’anomalies. Les tests unitaires natifs sont arrivés avec dbt 1.8.

Pour obtenir une couverture comparable, les utilisateurs Dataform doivent implémenter manuellement des fichiers d’assertions custom. Le package dataform-assertions de Devoteam aide, mais on n’est pas dans la même catégorie.

Maturité CI/CD

dbt Cloud propose le Slim CI clé en main : ne construire que les modèles modifiés et leurs dépendants, créer automatiquement des schémas de PR, linter le SQL avant le build. La configuration se fait en quelques clics.

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 GitHub Actions ou Cloud Build. Comme l’a noté un analyste : « On ne peut pas implémenter de CI/CD ou de Slim CI dans Dataform aussi facilement qu’avec dbt, qui ne demande que quelques clics. »

Outillage de développement

L’extension dbt Power User 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 — le tout dans Cursor.

L’IDE Cloud Console de Dataform propose la compilation en temps réel et l’estimation des coûts, mais vous êtes captif de l’interface Google.

Coût et stratégie plateforme

L’argument le plus fort de Dataform est financier. dbt Cloud coûte 100 $ par utilisateur et par mois. Pour une équipe de 10 personnes, cela représente 12 000 $ par an — en plus de ce que vous payez pour le compute BigQuery.

Dataform ne coûte rien. Vous ne payez que l’exécution BigQuery.

Verrouillage plateforme

Dataform fonctionne exclusivement avec BigQuery. Si votre organisation envisage d’adopter Snowflake, Databricks ou Redshift à l’avenir, Dataform devient un passif. dbt se connecte à plus de 20 plateformes grâce à son architecture d’adaptateurs, ce qui facilite les migrations de warehouse.

Dataform Core est open source, et votre logique SQL est portable. Mais vos configurations d’orchestration, de tests et de CI/CD ne le sont pas.

dbt a ses propres risques de verrouillage. L’écart fonctionnel entre Core et Cloud ne cesse de se creuser. Après la fusion, certains membres de la communauté évoquent un fork à la OpenTofu si les pressions commerciales s’intensifient. Mais le support multi-warehouse de dbt offre une flexibilité stratégique que Dataform ne peut pas égaler.

Les réalités de la migration

Si vous envisagez de passer d’un outil à l’autre, préparez-vous à un investissement conséquent.

Correspondance des concepts

Outils disponibles

Des outils de migration existent dans les deux sens (j’ai rédigé des guides pour la migration de dbt vers Dataform et de Dataform vers dbt). rittmananalytics/ra_dbt_to_dataform utilise Python et GPT-4 pour la conversion de macros complexes. elyobo/dataform-to-dbt est basé sur Node.js et gère les refs, assertions et matérialisations de vues.

Aucun outil ne couvre tout. Les seeds, snapshots et la couche sémantique nécessitent un travail manuel dans les deux sens.

Délais réels

Un exemple parlant : la migration d’une équipe a pris deux mois, plus trois semaines supplémentaires pour corriger des problèmes de pipeline ML, car le comportement du templating JavaScript différait de Jinja d’une manière qui cassait le réentraînement des modèles. Le temps d’ingénierie et la fraude qui s’est glissée entre les mailles « ont coûté bien plus que n’importe quels frais de licence ».

Quand la migration a du sens

Migrer dbt → Dataform si :

• Engagement à 100 % sur BigQuery sans plans multi-cloud
• Pression forte sur les coûts liés aux licences dbt Cloud
• L’équipe préfère JavaScript à Jinja
• Cas d’usage simples sans stratégies incrémentales complexes

Migrer Dataform → dbt si :

• Stratégie multi-warehouse en cours de définition
• Besoin immédiat de workflows CI/CD matures
• Nécessité d’un écosystème de packages étendu
• Équipe engagée dans un parcours de certification dbt

Rester sur l’outil actuel si :

• L’utilisation intensive de macros ou d’includes rend la conversion pénible
• Des pipelines ML dépendent d’un comportement de templating spécifique
• Le coût de migration dépasse 2 ans ou plus d’économies sur les licences

La recommandation

Pour la plupart des équipes en 2026, dbt reste le choix le plus solide.

La profondeur de l’écosystème, la flexibilité multi-warehouse et la portabilité de carrière créent des avantages cumulatifs. Quand vous rencontrez un problème (tests complexes, patterns incrémentaux inhabituels, modélisation d’attribution), dbt a probablement un package ou une solution communautaire. Dataform nécessitera probablement un développement custom.

Le marché de l’emploi le confirme. 87 % des analytics engineers nord-américains gagnent plus de 100 000 $, et la maîtrise de dbt apparaît dans presque toutes les offres. L’expertise Dataform reste valorisée mais concentrée dans les organisations fortement orientées GCP.

Choisir Dataform quand toutes ces conditions sont réunies :

• Engagement à 100 % sur BigQuery sans feuille de route multi-cloud
• Le coût de 100 $/utilisateur/mois est une vraie contrainte
• Vos cas d’usage sont simples (pas de stratégie incrémentale complexe, besoins de test limités)
• L’équipe est à l’aise avec JavaScript et la construction de solutions sur mesure

Choisir dbt pour tout le reste.

La fusion avec Fivetran positionne l’entité combinée comme la principale plateforme data indépendante. Dataform va probablement se renforcer en tant que couche de transformation par défaut de BigQuery. La dynamique « gratuit vs premium » va s’intensifier à mesure que les fonctionnalités commerciales de dbt (couche sémantique, Mesh, CI avancé) restent exclusives à Cloud.

Les deux outils transforment le SQL efficacement. La question est de savoir si la trajectoire de votre organisation s’aligne avec la simplicité exclusive BigQuery ou l’optionalité multi-cloud — et si un outillage d’écosystème mature justifie les coûts d’abonnement. Pour la plupart des équipes, c’est le cas.