Orchestration dbt simplifiée : quand un cron suffit

Vous avez livré votre premier projet dbt sur BigQuery. Les modèles fonctionnent, les tests passent, et vos parties prenantes sont satisfaites des données dans Looker. Maintenant, il faut que tout tourne automatiquement chaque matin à 7h.

Le réflexe naturel est de se tourner vers un orchestrateur. Dagster, Airflow, Prefect : internet a un avis sur chacun d’eux. Mais avant de passer des semaines à évaluer des plateformes qui coûtent 250 à 500 $/mois, posez-vous une question plus simple : est-ce qu’un cron job couvre réellement vos besoins ?

L’effet falaise sur les coûts

Il existe un écart spectaculaire entre le scheduling simple et l’orchestration managée. Un dbt build quotidien déclenché par Cloud Scheduler et Cloud Run coûte 0 à 3 $/mois grâce au free tier de GCP. Passez à Cloud Composer (Airflow managé) et c’est minimum 377 $/mois, même quand rien ne tourne.

Approche	Coût mensuel
Cloud Scheduler + Cloud Run Job	0-3 $
GitHub Actions (free tier)	0 $
Cloud Workflows + Cloud Run	0-5 $
Dagster+ Solo	10 $
Dagster+ Starter	100 $
dbt Cloud Starter (5 sièges)	500 $+
Cloud Composer 3 (small)	377-400 $+

Adaptez l’outil au problème. Un praticien solo qui exécute 15 modèles dbt sur un scheduling quotidien a des besoins fondamentalement différents d’une équipe de huit personnes gérant des dépendances inter-systèmes avec des engagements de SLA.

Cloud Scheduler + Cloud Run : dbt en production pour 0 $/mois

L’approche la plus directe sur GCP consiste à déclencher un Cloud Run Job via Cloud Scheduler. Pas de serveur HTTP, pas d’infrastructure toujours allumée. Le job exécute vos commandes dbt et s’arrête.

La mise en place comporte quatre étapes : conteneuriser votre projet dbt, le déployer en tant que Cloud Run Job, le planifier avec Cloud Scheduler, et router les credentials via Secret Manager.

Commencez par un Dockerfile :

FROM ghcr.io/dbt-labs/dbt-bigquery:1.9.0

COPY . /usr/app
WORKDIR /usr/app

RUN dbt deps

ENTRYPOINT ["dbt"]
CMD ["build", "--target", "prod"]

Build et déploiement :

# Build du conteneur
gcloud builds submit --tag gcr.io/YOUR_PROJECT/dbt-runner

# Création du Cloud Run Job
gcloud run jobs create dbt-daily \
  --image gcr.io/YOUR_PROJECT/dbt-runner \
  --region europe-west1 \
  --memory 1Gi \
  --cpu 1 \
  --task-timeout 3600 \
  --set-secrets "GOOGLE_APPLICATION_CREDENTIALS=dbt-sa-key:latest" \
  --service-account dbt-runner@YOUR_PROJECT.iam.gserviceaccount.com

# Planification
gcloud scheduler jobs create http dbt-morning-run \
  --schedule "0 7 * * *" \
  --time-zone "Europe/Paris" \
  --uri "https://europe-west1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/YOUR_PROJECT/jobs/dbt-daily:run" \
  --http-method POST \
  --oauth-service-account-email dbt-scheduler@YOUR_PROJECT.iam.gserviceaccount.com

Les Cloud Run Jobs supportent des timeouts allant jusqu’à 24 heures, donc même les projets dbt volumineux ne seront pas bloqués. Le free tier seul couvre 180 000 vCPU-secondes par mois, soit environ 50 heures de calcul.

Pour un guide détaillé du processus de déploiement, consultez mon guide de déploiement dbt sur Cloud Run.

GitHub Actions : si vous y êtes déjà

Pour les équipes sur GitHub, un workflow planifié est le chemin le plus rapide de zéro à un scheduling de production. Pas d’infrastructure GCP à configurer, pas de conteneurs à builder.

name: dbt daily run
on:
  schedule:
    - cron: '0 6 * * *'
  workflow_dispatch:

jobs:
  dbt-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install dbt-bigquery
      - run: dbt deps && dbt build --target prod
        env:
          DBT_PROFILES_DIR: .
          GOOGLE_APPLICATION_CREDENTIALS: ${{ secrets.GCP_SA_KEY }}

Les dépôts privés bénéficient de 2 000 minutes gratuites par mois, et une exécution dbt typique prend 3 à 10 minutes, installation des dépendances incluse. C’est largement suffisant pour un scheduling quotidien, voire horaire.

Les compromis méritent d’être connus. GitHub ne garantit pas un timing cron exact en période de forte charge : un job planifié à 6h peut démarrer à 6h03 ou 6h15. Il n’y a pas de logique de retry intégrée, pas de gestion des dépendances entre workflows, et chaque exécution démarre à froid en installant Python et dbt from scratch. Pour un rafraîchissement analytique quotidien où une fenêtre de 15 minutes est acceptable, aucun de ces points n’est rédhibitoire.

Cloud Workflows pour la coordination multi-étapes

Quand votre pipeline implique plus qu’un simple dbt build, Cloud Workflows ajoute une couche d’orchestration légère. Cloud Scheduler déclenche Cloud Workflows, qui coordonne plusieurs Cloud Run Jobs avec gestion d’erreurs et logique conditionnelle.

C’est utile quand vous devez exécuter une étape d’ingestion avant la transformation, valider des données entre les étapes, ou passer des paramètres dynamiquement. GetInData a développé dbt-workflows-factory, une bibliothèque Python qui génère du YAML Cloud Workflow directement à partir des manifests dbt.

Les coûts restent bas : 5 000 étapes internes par mois sont gratuites, puis 0,01 $ pour 1 000 étapes. Combiné à Cloud Run, vous restez sous les 5 $/mois pour la plupart des configurations.

Pour une comparaison entre cette approche et Cloud Composer, mon comparatif Cloud Run vs Composer approfondit la question.

Et dbt Cloud ?

Le scheduler intégré de dbt Cloud gère le scheduling cron, les vérifications de fraîcheur des sources, les builds CI sur les pull requests et les jobs déclenchés par les merges. Si vous payez déjà pour dbt Cloud, le scheduling est inclus et ne nécessite aucun travail d’infrastructure.

La question est de savoir si vous payez déjà. Le tier Developer est gratuit (1 siège, 3 000 builds de modèles par mois), ce qui couvre les praticiens solo. Le prix du tier Starter passe à 100 $/utilisateur/mois avec un maximum de 5 sièges. Pour une équipe de consulting de trois personnes, c’est 300 $/mois pour un scheduling que Cloud Run gère gratuitement.

dbt Cloud a du sens quand l’équipe travaille exclusivement en SQL, n’a jamais besoin d’orchestrer quoi que ce soit en dehors de dbt (pas d’ingestion, pas de traitement Python, pas d’appels API), et valorise l’expérience CI/CD managée. Dès que vous avez besoin de dépendances inter-systèmes ou de transformations Python dans le même pipeline, vous en aurez fait le tour. J’ai approfondi ce compromis dans mon comparatif dbt Core vs dbt Cloud.

Les signaux qu’il est temps de passer à l’étape supérieure

L’orchestration simple ne casse pas de manière catastrophique. La confiance s’érode plutôt par de petits décalages. La finance obtient des chiffres techniquement corrects mais métier-incorrects parce que les données amont n’étaient pas prêtes. Les pipelines se terminent « avec succès » mais livrent les insights trop tard. Le monitoring affiche du vert tandis que les parties prenantes voient des dashboards obsolètes.

Le temps que les rustines lâchent, la migration devient urgente plutôt que planifiée.

Surveillez ces déclencheurs concrets :

Plus de trois pipelines interconnectés qui dépendent les uns des autres. Si le pipeline B doit attendre le pipeline A, et que le pipeline C a besoin des deux, vous avez dépassé les capacités des cron jobs séquentiels.
Des échecs silencieux de plus en plus fréquents. Votre dbt build a réussi, mais les données sources qu’il a traitées dataient de la veille parce que la synchronisation amont n’était pas terminée. Rien dans vos logs n’indique un problème.
Des dépendances inter-systèmes. dbt doit attendre une synchronisation Fivetran ou Airbyte, ou un modèle Python doit tourner après dbt, ou un rafraîchissement de dashboard BI ne doit se déclencher qu’à l’arrivée de données fraîches.
Une équipe qui grandit au-delà de trois contributeurs. Plusieurs personnes qui planifient des cron jobs à différents endroits créent de la confusion sur ce qui tourne quand et qui est responsable de quoi.
Des engagements de SLA de la part des parties prenantes. Quand quelqu’un dit « le rapport pour le board doit utiliser des données de moins de 6 heures », vous avez besoin de monitoring de fraîcheur, pas juste de savoir « est-ce que le job a tourné ».

La progression typique suit un arc prévisible. Vous commencez avec un seul cron job exécutant dbt build. Puis vous ajoutez un second script, peut-être quelques alertes Slack. Les dépendances inter-pipelines se multiplient et les alertes Slack avec. Finalement, les rustines ne tiennent plus, et vous migrez vers un vrai orchestrateur dans l’urgence.

Identifiez l’étape 3 et planifiez la migration à l’étape 4, avant que l’étape 5 ne vous y force.

Choisir la prochaine étape

Le saut du cron vers un orchestrateur complet n’a pas besoin d’être une falaise. Deux options font le pont.

Dagster+ Solo à 10 $/mois offre un scheduling asset-aware, un DAG visuel et du monitoring de fraîcheur pour 7 500 matérialisations par mois. Pour un petit projet dbt, c’est des mois d’exécutions quotidiennes. C’est l’étape naturelle suivante quand vous avez besoin de visibilité sur la fraîcheur des données plutôt que sur la simple exécution des jobs. Le guide des fondamentaux Dagster couvre ce que les analytics engineers doivent savoir.

Le free tier de Prefect Cloud propose une approche Python-first avec 500 minutes de calcul serverless. Si votre équipe préfère écrire des fonctions Python plutôt qu’apprendre un nouveau framework, ça vaut le coup d’évaluer.

Les deux options permettent de commencer petit et de monter en charge, ce qui est la bonne approche pour les équipes qui ne sont pas encore sûres de la complexité de leurs besoins d’orchestration. Pour un comparatif détaillé sur le choix entre Dagster, Airflow et Prefect, consultez mon cadre de décision pour les outils d’orchestration.

Commencez là où vous êtes

Un dbt build quotidien sur Cloud Run avec un déclencheur cron Cloud Scheduler est une infrastructure de production à part entière. Ça ne coûte presque rien, ça prend un après-midi à mettre en place, et ça couvre les besoins de la plupart des petites équipes pendant des mois, voire des années. Pour une vue d’ensemble de la façon dont ces pièces s’intègrent dans une architecture de plateforme data GCP, ce guide couvre l’ensemble du stack.

Quand le cron job ne suffira plus, vous le saurez. Les déclencheurs décrits ci-dessus commenceront à apparaître dans votre quotidien. C’est le bon moment pour évaluer les orchestrateurs, pas avant.