Toute comparaison d’orchestrateurs finit par se réduire à des matrices de fonctionnalités. Airflow a plus de 90 packages de providers. Dagster a le lineage des assets. Prefect a les workflows dynamiques. Les trois peuvent planifier dbt, relancer en cas d’échec et envoyer des alertes Slack quand quelque chose casse.
La parité fonctionnelle compte moins que le modèle mental. La vraie question est quelle abstraction correspond à la façon dont votre équipe pense le travail sur les données. Et pour les analytics engineers sur dbt + BigQuery, cette question a une réponse étonnamment claire.
Mon panorama de l’orchestration en 2026 couvre le marché dans son ensemble. Mon guide des fondamentaux Dagster et mon deep dive Dagster + dbt détaillent Dagster spécifiquement. Cet article met les trois en face à face et propose un framework pour choisir.
Trois architectures, trois philosophies
Les différences architecturales entre ces outils façonnent la manière dont vous définissez vos pipelines, débuguez les échecs et pensez votre plateforme data.
Airflow est orienté processus. Vous écrivez des scripts Python qui définissent des graphes acycliques dirigés (DAGs) de tâches. Le scheduler les récupère, les workers les exécutent, et le webserver affiche ce qui a tourné et quand. Airflow 3.0 a ajouté un API Server basé sur FastAPI et une UI React, mais le modèle fondamental n’a pas changé : vous décrivez quelles tâches exécuter et dans quel ordre. Le système suit l’historique d’exécution des tâches. Il ne sait pas et ne se soucie pas des données que ces tâches produisent.
Dagster est orienté données. Vous définissez des assets : des objets de données persistants comme des tables BigQuery, des fichiers GCS ou des modèles ML. Chaque asset a des dépendances amont, une fonction de calcul qui le produit, et des métadonnées que le système suit automatiquement (dernière matérialisation, fraîcheur, état de santé). Quand vous ouvrez l’UI Dagster, vous voyez vos produits data et leurs états, pas une liste d’exécutions de tâches.
Prefect est orienté fonction. Des fonctions Python décorées avec @flow et @task deviennent des workflows. Pas de fichier de définition DAG séparé, pas de YAML, pas de structure de projet spéciale. Les flows peuvent construire leurs dépendances dynamiquement au runtime en Python pur. Prefect 3.0 (septembre 2024) a reconstruit le moteur avec une sémantique transactionnelle et réduit l’overhead de plus de 90 %.
Une heuristique utile tirée de la comparaison de Branch Boston : « Choisissez le nom qui correspond au vocabulaire de votre organisation. DAGs pour Airflow, flows pour Prefect, assets pour Dagster. » Les analytics engineers pensent en tables, modèles et fraîcheur. C’est le vocabulaire de Dagster.
Là où l’intégration dbt fait vraiment la différence
Les trois ont des intégrations dbt. La profondeur varie considérablement.
Le package dagster-dbt lit le manifest.json de votre projet et crée un asset Dagster par modèle dbt, seed et snapshot. Les dépendances issues des appels ref() et source() deviennent des arêtes dans le graphe d’assets. Les tests dbt deviennent automatiquement des asset checks Dagster. Les owners, tags et métadonnées de colonnes sont repris. L’évaluation à 30 critères de FreeAgent le résume bien : « Quelques lignes de code et vous avez une cartographie complète de vos modèles dbt. »
En pratique, quand un modèle dbt échoue dans Dagster, vous le voyez dans le contexte de votre lineage data complet. Vous savez quelles tables en aval sont maintenant périmées, quels SLAs de fraîcheur sont menacés, et si les données amont sont même arrivées. Comparez avec Airflow, où vous voyez une tâche rouge dans un DAG et devez reconstituer l’impact sur les données vous-même.
astronomer-cosmos (21M+ de téléchargements mensuels, 140+ contributeurs) transforme les projets dbt en DAGs ou TaskGroups Airflow avec environ 10 lignes de code. Chaque modèle devient une tâche Airflow individuelle avec des retries et des notifications d’erreur. Il supporte désormais aussi le décorateur @asset d’Airflow 3. Mais il encapsule dbt dans le paradigme de tâches d’Airflow plutôt que de traiter les modèles comme des objets data de premier ordre. Vous voyez « tâche réussie » ou « tâche échouée », pas « cette table est à jour » ou « cette table est périmée ».
prefect-dbt fournit DbtCoreOperation pour exécuter des commandes CLI dbt et DbtCloudJob pour déclencher des runs dbt Cloud. Il génère des artefacts Markdown dans l’UI Prefect avec des liens vers les artefacts dbt. L’intégration est opérationnelle : elle exécute bien les commandes dbt. Mais elle ne mappe pas les modèles dbt dans le modèle interne de Prefect comme dagster-dbt le fait avec les assets.
Pour les équipes dont la charge principale est la transformation dbt, vous ressentirez cet écart à chaque incident. Si dbt n’est qu’une petite pièce d’un pipeline plus large centré sur Python, la profondeur d’intégration devient moins déterminante.
Expérience développeur et CI/CD
Le développement local est là où les frictions quotidiennes apparaissent.
Dagster offre la meilleure expérience locale des trois. Lancez dagster dev et vous obtenez l’UI complète sur localhost:3000, sans Docker. Vous pouvez matérialiser des assets individuels, inspecter le lineage et consulter les logs de run, le tout en local. Les tests sont construits autour du typage I/O et de ressources interchangeables : remplacez votre ressource BigQuery par une version en mémoire et vos tests tournent sans toucher au warehouse.
Airflow a historiquement été pénible en local. Il faut Docker (typiquement via l’Astro CLI ou docker-compose), et l’itération est lente parce que le scheduler doit parser les fichiers DAG. Airflow 2.5 a ajouté dag.test() pour exécuter toutes les tâches dans un seul processus Python, ce qui a aidé. TRM Labs a documenté comment rendre le développement Airflow 20 fois plus rapide avec de l’outillage personnalisé, réduisant le coût de l’environnement de développement de 200 $/mois à 0 $. Mais cela a nécessité un investissement significatif en outillage développeur que la plupart des équipes ne feront pas.
Prefect est le plus simple à démarrer. Installez le package, lancez le serveur, et vos flows sont des fonctions Python que vous pouvez appeler directement. Les tests sont du pytest standard sans mocking de framework nécessaire. Prefect a soutenu que Dagster nécessite « 50+ lignes de mock setup » par test, bien que ce soit exagéré pour les tests d’assets typiques.
Le différenciateur pour le CI/CD est les branch deployments de Dagster+. Quand vous ouvrez une pull request, Dagster+ déploie automatiquement un environnement de preview éphémère avec vos changements de code. Les reviewers peuvent inspecter le graphe d’assets, voir ce qui a changé, et même déclencher des matérialisations de test, le tout avant le merge. Aucun autre orchestrateur n’offre cela nativement, et pour les équipes qui itèrent fréquemment sur des modèles dbt, cela transforme le workflow de review des PR.
Déploiement GCP et coûts
Pour les équipes sur GCP (voir mon aperçu de l’architecture data sur GCP), les options de déploiement et leurs coûts varient significativement.
Cloud Composer 3 (Airflow managé, GA mars 2025) utilise une tarification par DCU à environ 0,06 $ par DCU-heure. Un petit environnement consomme environ 12 DCU par heure, soit approximativement 12,58 $ par jour même au repos. Cela représente 377 $+ par mois avant d’exécuter un seul DAG. Les plaintes sur les coûts sont courantes dans la communauté : une équipe estimait 40-60 $/jour mais les coûts réels ont atteint 188 $/jour avant optimisation. Ma comparaison Cloud Run Jobs vs. Composer couvre ce sujet en détail.
Dagster+ Hybrid déploie un control plane managé par Dagster, avec l’exécution dans votre cluster GKE via un Helm chart. Vous payez Dagster pour les crédits (matérialisations d’assets) et Google pour le compute. Le plan Solo à 10 $/mois avec 7 500 crédits suffit pour les petites équipes avec des builds dbt quotidiens. Le Starter à 100 $/mois offre 30 000 crédits, jusqu’à 3 utilisateurs et 5 code locations.
Prefect Cloud avec des workers Cloud Run fournit un type de work pool natif pour GCP. Le tier gratuit Hobby inclut 500 minutes de compute serverless. Le Starter à 100 $/mois ajoute plus de fonctionnalités. Le plan Team à 400 $/mois inclut 8 sièges et 13 500 minutes serverless.
Self-hosted est une option pour les trois. Dagster OSS est sous licence Apache 2.0, entièrement fonctionnel mais sans RBAC, branch deployments ni alerting managé. Airflow et Prefect sont également déployables sur votre propre infrastructure.
| Plateforme | Coût d’entrée | Mid-tier | Notes |
|---|---|---|---|
| Dagster+ Solo | 10 $/mo | 100 $/mo (Starter) | Basé sur les crédits, 0,03 $/crédit en surplus |
| Prefect Cloud Hobby | Gratuit | 100 $/mo (Starter) | Par siège, 500 min serverless gratuites |
| Astronomer Developer | ~252 $/mo | ~307 $/mo (Team) | Workers scale-to-zero, pay-per-task |
| Cloud Composer 3 | ~377 $/mo | ~500+ $/mo | Coût permanent, pas de scale-to-zero |
| dbt Cloud Starter | 100 $/user/mo | Custom (Enterprise) | 0,01 $/modèle en surplus, 5 sièges max |
L’écart de coût entre Dagster+ Solo (10 $/mois) et Cloud Composer (377+ $/mois) est difficile à ignorer pour les petites équipes. Même en comptant les coûts GKE côté Dagster, le total reste généralement bien en dessous de 100 $/mois pour des charges modérées.
Le framework de décision
Après examen de l’évaluation à 30 critères de FreeAgent, des témoignages de migration et des discussions communautaires (et de ma propre expérience avec les décisions build vs. buy), les recommandations se regroupent de façon prévisible par profil d’équipe.
Choisissez Dagster quand votre équipe pense en modèles dbt et tables BigQuery. Quand le lineage des données et la fraîcheur des assets sont des priorités. Quand votre pipeline s’étend au-delà de dbt (ingestion, traitement Python, modèles ML, rafraîchissement BI) et que vous voulez tout dans un seul graphe. Quand vous voulez des branch deployments pour le CI/CD. Quand vous êtes 2 à 15 personnes et pouvez investir dans l’apprentissage du framework.
La moitié des utilisateurs de Dagster Cloud exécutent dbt, le taux d’adoption dbt le plus élevé de tous les orchestrateurs.
Choisissez Airflow quand vous avez besoin de l’écosystème d’intégrations le plus large sur une infrastructure hétérogène. Quand vous êtes dans une entreprise avec une capacité DevOps dédiée. Quand vous avez besoin d’une option managée native GCP (Cloud Composer) et pouvez absorber le coût. Quand l’expérience Airflow sur les CV de votre équipe compte pour le recrutement et le développement de carrière. Avec 80 000+ organisations, 3 600+ contributeurs et 30M+ de téléchargements mensuels PyPI, Airflow reste le choix institutionnel le plus sûr.
Le décorateur @asset d’Airflow 3.0 est un clin d’oeil au modèle de Dagster. Mais le concept d’asset semble greffé plutôt que fondamental comme il l’est dans Dagster.
Choisissez Prefect quand la rapidité de mise en place compte le plus. Quand votre équipe valorise l’écriture de Python pur sans abstractions de framework. Quand vous avez besoin de workflows dynamiques et événementiels qui construisent leur structure au runtime. Quand vous voulez le minimum d’overhead infrastructure pour une petite équipe (2-10 personnes) qui privilégie la vélocité développeur aux fonctionnalités de lineage.
Et la courbe d’apprentissage ?
Cela mérite une mention honnête. La courbe d’apprentissage de Dagster est le point de friction le plus souvent cité dans les avis G2, les forums communautaires et les articles de retours d’expérience. Les analytics engineers venant de workflows purement dbt doivent apprendre les décorateurs Python, la structure de projet, la configuration des ressources et la gestion du manifest. Le changement conceptuel de « j’écris des modèles SQL » à « je définis des software-defined assets avec des ressources et des configs » déstabilise la plupart des débutants.
Dagster University (gratuit sur courses.dagster.io) aide. L’étude de cas Erewhon a montré qu’une équipe data d’une seule personne sans background technique a construit une plateforme data entière en utilisant ces cours, YouTube et ChatGPT. Mais « courbe d’apprentissage raide » est un thème récurrent dans chaque avis honnête sur Dagster.
La courbe d’apprentissage d’Airflow est différente. Le mettre en place est complexe (Docker, configuration du scheduler, choix de l’executor), mais écrire des DAGs est du Python simple. Prefect a la courbe d’apprentissage la plus faible des trois : si vous savez écrire une fonction Python, vous savez écrire un flow Prefect.
Pour les équipes dbt + BigQuery, l’investissement dans l’apprentissage de Dagster se rentabilise par une intégration dbt plus poussée, une meilleure observabilité et les branch deployments. La question de savoir si cette période de retour sur investissement est acceptable dépend du niveau de confort Python de votre équipe et de l’urgence de votre besoin d’orchestration.
La plupart des équipes regrettent davantage le timing de leur décision que la décision elle-même. Déployer Cloud Composer pour un seul dbt build quotidien gaspille de l’argent, mais rester sur un cron job jusqu’à ce qu’il livre silencieusement des données périmées pendant deux semaines gaspille la confiance. Cloud Run Jobs peut couvrir l’approche à 0 $/mois jusqu’à ce que votre pipeline le dépasse, auquel cas Dagster+ Solo à 10 $/mois est la montée en gamme la plus économique pour les équipes dbt-centric sur GCP.