Le moteur de transformation principal de Dataform — compiler du SQLX en SQL et l’exécuter contre BigQuery — est mature et prêt pour la production. Les lacunes se situent dans l’écosystème environnant : automatisation CI/CD, outillage de développement local, écosystème de packages et portabilité entre plateformes. Ce sont des domaines où l’investissement communautaire de dbt sur une décennie crée un avantage cumulatif.
Automatisation CI/CD
dbt Cloud propose un Slim CI intégré. Lorsqu’un développeur ouvre une pull request, dbt Cloud :
- Identifie automatiquement quels modèles ont changé (et leurs dépendants en aval)
- Crée un schéma spécifique à la PR pour que les builds n’interfèrent pas avec la production
- Construit uniquement les modèles affectés
- Exécute les tests associés
- Lance le linting SQL
- Renvoie les résultats dans la PR
Quelques clics dans l’interface de dbt Cloud et ce workflow est opérationnel. Pas de fichiers YAML de pipeline, pas de scripts personnalisés, pas d’infrastructure à gérer.
Dataform exige que tout cela soit construit manuellement. Les workflows ne peuvent pas être déclenchés nativement par des événements git. Implémenter une automatisation comparable signifie :
- Appeler l’API REST Dataform depuis des outils CI externes (GitHub Actions, Cloud Build, ou équivalents)
- Écrire une logique personnalisée pour déterminer quels modèles ont changé
- Gérer la création et la suppression de schémas pour les environnements PR
- Construire l’intégration de reporting vers votre plateforme git
Ce n’est pas un travail théorique. C’est 2 à 4 semaines d’effort d’ingénierie pour construire, auxquelles s’ajoute une maintenance continue à mesure que l’API évolue et que les cas limites apparaissent. Beaucoup d’équipes Dataform sautent le CI entièrement et examinent les changements de transformation uniquement via des revues de code manuelles. L’absence de CI ne provoque pas d’échecs immédiats — elle engendre une accumulation lente de changements non testés qui se manifestent en incidents de production plusieurs semaines plus tard.
Pour les équipes utilisant dbt Core (auto-hébergé) plutôt que dbt Cloud, l’écart CI est moins prononcé. dbt Core requiert également une construction personnalisée du pipeline CI, bien que la commande dbt build --select state:modified+ simplifie la détection des changements que Dataform ne propose pas.
IDE et outillage développeur
L’écart d’expérience développeur est cumulatif à travers chaque ingénieur de l’équipe.
L’extension Power User de dbt pour VS Code et Cursor dépasse 1 million d’installations. Elle offre :
- Visualisation de la lignée des modèles — voir les dépendances en amont et en aval sans quitter l’éditeur
- Aperçu de requête avec exécution — exécuter des modèles directement depuis l’IDE
- Auto-complétion au niveau des colonnes — suggestions basées sur les schémas réels en amont
- Génération de documentation assistée par IA — ébauche de descriptions à partir du SQL du modèle
- Estimation de coût BigQuery — visualiser le coût attendu d’une requête avant de l’exécuter
Rien de comparable n’existe pour Dataform. Les options de développement sont :
- L’IDE Cloud Console — basé sur le navigateur, fournit un retour de compilation en temps réel et des estimations de coût, mais manque de l’extensibilité et des workflows pilotés au clavier d’un éditeur de bureau
- Un éditeur de texte basique — au mieux une coloration syntaxique pour SQLX, sans fonctionnalités orientées transformation
L’IDE Cloud Console n’est pas mauvais. Son retour de compilation en temps réel est véritablement utile — on voit immédiatement si le SQLX est valide et ce que le SQL compilé coûtera à exécuter. Mais c’est un outil unique sans écosystème de plugins, sans extensions communautaires, sans possibilité de personnalisation. Cursor avec dbt Power User représente ce qui est possible quand une grande communauté construit des outils autour d’une plateforme. La base d’utilisateurs plus restreinte de Dataform signifie que ce niveau d’investissement en outillage ne se matérialise jamais.
Pour les équipes qui ont standardisé le développement dans le cloud (Cloud Workstations, Cloud Shell Editor), l’écart IDE importe moins. Pour les équipes habituées à des environnements de développement local riches, c’est un point de friction quotidien.
Écosystème de packages
dbt compte plus de 200 packages sur hub.getdbt.com couvrant :
- Transformations spécifiques aux sources — GA4, Shopify, Stripe, Salesforce, HubSpot, Facebook Ads, Google Ads
- Utilitaires transversaux — dbt-utils, dbt-expectations, dbt-date, dbt-audit-helper
- Observabilité — Elementary, re_data
- Patterns spécialisés — modélisation d’attribution, sessionisation, reconnaissance de revenus
Chaque package représente des centaines d’heures de développement, de testing et de maintenance communautaire. Quand une équipe dbt a besoin d’une sessionisation GA4, elle installe un package et le configure en une après-midi. Quand une équipe Dataform a besoin de la même capacité, elle la construit de zéro.
Dataform n’a pas de hub centralisé de packages. Le package dataform-assertions de Devoteam est l’une des rares options tierces. Des équipes individuelles mettent occasionnellement en open source leurs utilitaires Dataform, mais la découverte est fragmentée et la maintenance est incohérente.
C’est un problème d’effets de réseau : plus d’utilisateurs dbt génère plus de packages, ce qui génère plus de raisons de choisir dbt. La base d’utilisateurs plus restreinte de Dataform ne peut pas générer le volume de packages qui rendrait l’écosystème auto-entretenu. Rien n’indique que Google prévoit d’investir dans des packages propriétaires.
Dépendance à la plateforme
dbt se connecte à plus de 20 plateformes de données via son architecture d’adaptateurs : BigQuery, Snowflake, Databricks, Redshift, Postgres, DuckDB, et bien d’autres. La logique de transformation écrite pour dbt est portable. Le pattern dispatch gère même les différences de dialecte SQL entre les bases de données.
Dataform fonctionne exclusivement avec BigQuery. Ce n’est pas une limitation actuelle susceptible de s’élargir — c’est un choix de conception reflétant l’identité de Dataform en tant que service natif GCP. Si votre organisation adopte Snowflake pour une nouvelle charge de travail, acquiert une société fonctionnant sur Databricks, ou a besoin d’un cluster Redshift pour un cas d’usage spécifique, Dataform ne peut pas suivre.
Le risque de dépendance est probabiliste. Si vous êtes certain que BigQuery est votre seul entrepôt dans un avenir prévisible, le support mono-plateforme est sans importance. Mais “avenir prévisible” en infrastructure de données s’étend rarement au-delà de 3 à 5 ans, et les changements organisationnels (fusions, nouvelles lignes de produits, négociations avec les fournisseurs) imposent souvent des scénarios multi-plateformes que personne n’avait planifiés.
L’effet cumulatif
Ces lacunes interagissent. Sans CI/CD, le testing devient plus important — mais le testing est également limité. Sans packages, les équipes écrivent plus de code personnalisé — mais sans outillage IDE riche, écrire ce code est plus lent. Sans portabilité entre plateformes, les coûts de changement augmentent — rendant la décision de rester avec Dataform de plus en plus irréversible avec le temps.
Chaque lacune individuellement peut être acceptable. L’ensemble crée un déficit écosystémique qui croît avec la complexité du projet. Pour un projet de 20 modèles avec des besoins basiques, les lacunes importent à peine. Pour un projet de 200 modèles avec des exigences CI, des SLA de qualité des données, et des futurs potentiellement multi-cloud, elles définissent l’expérience quotidienne de chaque ingénieur de l’équipe.