Tous les projets Dataform ne devraient pas migrer vers dbt. La décision dépend de trois signaux de migration et d’un calcul de seuil de rentabilité.
Les trois signaux de migration
Passez-vous au multi-entrepôt ? Dataform ne fonctionne qu’avec BigQuery. Si votre organisation adopte Snowflake, Databricks ou Redshift en parallèle de BigQuery, l’architecture d’adaptateurs de dbt devient indispensable. C’est le signal de migration le plus clair et le plus univoque. Aucune personnalisation de Dataform ne peut le faire communiquer avec Snowflake.
Avez-vous besoin de l’écosystème ? Le hub de packages dbt offre plus de 200 packages couvrant les tests de qualité des données (dbt_expectations, Elementary), l’attribution marketing, les fonctions utilitaires (dbt_utils) et les transformations spécifiques aux sources (packages Fivetran). Implémenter manuellement des fonctionnalités qui existent comme packages dbt ajoute un coût de maintenance permanent.
La portabilité de carrière est-elle importante ? La maîtrise de dbt apparaît dans la plupart des offres d’emploi en analytics engineering. L’expertise Dataform reste valorisée mais concentrée dans les organisations fortement orientées GCP. L’expérience dbt a une applicabilité plus large sur le marché, ce qui impacte le recrutement et la rétention.
Quand rester sur Dataform
La migration a un coût réel. Restez sur Dataform si l’une de ces situations s’applique :
Vos includes JavaScript sont complexes. La capacité de Dataform à générer des modèles programmatiquement avec du JavaScript standard n’a pas d’équivalent direct dans dbt. La conversion de fichiers .js sophistiqués qui créent dynamiquement des dizaines de modèles nécessite une réécriture substantielle. Voir JavaScript vs Jinja en analytics engineering pour l’étendue complète de cet écart.
Des pipelines ML dépendent du comportement de templating. Une équipe a vu sa migration durer deux mois, plus trois semaines supplémentaires à corriger des problèmes où les comportements de template JavaScript et Jinja différaient de façon à casser le ré-entraînement des modèles. La fraude qui a glissé à travers pendant cette période a coûté plus que des années de frais de licence. La précision numérique, la gestion des nulls et le formatage des timestamps peuvent tous diverger de façons subtiles.
Votre cas d’usage est simple. Si vous exécutez des modèles de transformation basiques sans logique incrémentale complexe, le tier gratuit de Dataform sur BigQuery a du sens économiquement. Pourquoi ajouter des coûts de licence et des risques de migration pour le même résultat ?
Le calcul de seuil de rentabilité
Le calcul est simple. Si une migration prend trois mois de temps ingénieur et qu’on la compare à une licence dbt Cloud à 100 $/utilisateur/mois, il faut une équipe de 10 personnes qui tourne pendant plus de deux ans avant que les seules économies de licence justifient le changement.
Mais la licence est rarement le vrai moteur. Le calcul change immédiatement quand on intègre :
- Les besoins multi-entrepôts — il n’y a pas d’alternative Dataform ; le coût de ne pas migrer est un verrouillage architectural
- Les exigences de l’écosystème — chaque implémentation personnalisée évitée représente des semaines de temps ingénieur économisées
- L’efficacité du recrutement — trouver des ingénieurs expérimentés sur Dataform est plus difficile que sur dbt
- Les lacunes fonctionnelles — les snapshots, la fraîcheur des sources, les tests complets et la couche sémantique n’ont pas d’équivalents Dataform
Le calcul de seuil de rentabilité sur la seule licence est une distraction. Concentrez-vous sur les capacités dont vous avez besoin et sur ce qu’il en coûte de les construire vous-même dans Dataform par rapport à les obtenir out-of-the-box dans dbt.
Délais réalistes
Basé sur la complexité du projet :
| Taille du projet | Délai | Effort principal |
|---|---|---|
| Petit (~20 modèles) | 1-2 semaines | Conversion essentiellement mécanique |
| Moyen (50-100 modèles) | 2-4 semaines | Conversion des macros, mise en place des tests |
| Grand (100+ modèles, macros complexes) | 2-3 mois | Réécriture JavaScript, validation |
| Enterprise avec dépendances ML | 3-6 mois | Exécution parallèle, validation des parties prenantes |
Ce qui allonge les délais au-delà de l’estimation :
- Les includes JavaScript complexes nécessitant une réécriture manuelle
- Les stratégies incrémentales personnalisées au-delà du simple merge
- Les pipelines ML nécessitant une validation de régression
- Les processus d’approbation des parties prenantes
- Les exigences d’exécution parallèle pour la conformité
Outillage disponible
Deux outils open source accélèrent les parties mécaniques :
dataform-to-dbt — Outil Node.js qui gère les refs, assertions et matérialisations en vue. À exécuter avec npx dataform-to-dbt. Limitations : ne gère pas les includes JavaScript, les modèles incrémentaux ni les pre-operations complexes.
ra_dbt_to_dataform — Malgré son nom qui suggère la direction opposée, la même équipe fournit des patterns pour la conversion. Utilise GPT-4 pour la conversion de macros complexes.
Ces outils couvrent peut-être 60 à 70 % d’un projet typique. Planifiez que le reste sera du travail manuel, concentré dans les domaines les plus importants : conversion JavaScript vers Jinja, réglage des modèles incrémentaux et validation.
Le cadre de décision
Migrez quand vous passez au multi-entrepôt, avez besoin de l’écosystème de packages, ou souhaitez des fonctionnalités enterprise comme la couche sémantique et Mesh. L’investissement de 2 à 3 mois porte ses fruits en maintenance réduite et capacités étendues.
Restez en place quand votre projet Dataform est stable, vous êtes BigQuery uniquement sans plan de changement, et aucune fonctionnalité ne vous manque. Le principe « si ça marche, ne touchez pas » s’applique.
Reconsidérez le délai quand vous avez une génération JavaScript complexe, des dépendances ML dans vos pipelines, ou des parties prenantes nécessitant une longue exécution parallèle. L’estimation de deux mois devient six mois dans ces scénarios.
Les deux outils transforment le SQL de façon identique au niveau de l’entrepôt. Ce qui diffère, c’est l’écosystème, le modèle commercial et les implications de carrière. Le choix doit être basé sur la trajectoire organisationnelle, pas sur la préférence syntaxique.