La question de l’orchestration pour les analytics engineers était autrefois simple : Airflow, ou le système D. Cette époque est révolue. Airflow 3.0 a livré sa plus grande mise à jour en cinq ans, Dagster est devenu discrètement le choix par défaut des équipes centrées sur dbt, Prefect a reconstruit son moteur de zéro, et Kestra est passé de nulle part à 20 000 étoiles GitHub. Pendant ce temps, la fusion Fivetran–dbt Labs a redistribué les cartes stratégiques pour tous ceux qui s’appuient sur le scheduler intégré de dbt Cloud.
Si vous êtes analytics engineer et que vous vous demandez si vous avez besoin d’un orchestrateur, lequel correspond à votre stack, ou si un simple cron job à 0 €/mois suffit réellement, voici la carte du territoire.
L’état des lieux en 2026
Le marché s’est stratifié en catégories claires, et les chiffres parlent d’eux-mêmes.
Apache Airflow domine toujours par l’ampleur de son adoption. Il a franchi les 30 millions de téléchargements PyPI mensuels, fonctionne dans plus de 80 000 organisations et a attiré plus de 3 600 contributeurs uniques (plus qu’Apache Spark ou Kafka). Airflow 3.0, sorti en avril 2025, est la plus grande release depuis la réécriture 2.x : versioning des DAG, nouvelle UI en React, Task Execution Interface, et un décorateur @asset directement inspiré du playbook de Dagster. En mars 2026, Airflow a atteint la v3.1.7.
Dagster mène le peloton des « challengers modernes ». Avec 47 M$ de financement total (Série B, mai 2023), environ 7,2 M$ d’ARR fin 2023, et 15 M de téléchargements PyPI en 2024, il affichait la base de code la plus active par volume de commits, avec 27 000 commits en 2024. Le framework Components est passé en GA dans le cycle 1.12.x, et 50 % des utilisateurs de Dagster Cloud intègrent dbt. C’est le taux d’adoption de dbt le plus élevé de tous les orchestrateurs, et de loin.
Prefect se classe deuxième en téléchargements bruts avec 32 M de téléchargements PyPI en 2024 et maintient une communauté Slack de 25 000 membres. Prefect 3.0 (septembre 2024) a introduit la sémantique transactionnelle, open-sourcé son moteur événementiel et réduit la surcharge du moteur de plus de 90 % par rapport à la version 2. C’est l’outil qui ressemble le plus à du Python classique.
Kestra est le nouvel entrant à la croissance la plus rapide. Après avoir sécurisé 8 M$ de financement en seed en septembre 2024, avec des investisseurs comme Tristan Handy de dbt Labs et Michel Tricot d’Airbyte, il a lancé Kestra 1.0 le 9 septembre 2025. Parmi ses clients enterprise : Apple, Toyota, Bloomberg et JPMorgan Chase. Ses 20 000+ étoiles GitHub en font le projet d’orchestration à la croissance la plus rapide en 2024 par vélocité d’étoiles, bien que le praticien Daniel Beach ait noté que l’adoption en production pourrait être en retard sur le décompte d’étoiles.
En déclin : Luigi n’a reçu que des correctifs mineurs en 2024. Azkaban n’a eu aucune activité de code. Oozie est un vestige de l’ère Hadoop. Mage (v0.9.79, ~8 500 étoiles) existe toujours mais les inquiétudes grandissent quant à moins de 5 contributeurs actifs, soulevant des questions de pérennité.
Le virage qui change tout : des tâches aux assets
Au-delà de toute release individuelle, la tendance déterminante est un changement d’abstraction fondamentale : des tâches vers les assets.
Dans un modèle basé sur les tâches (Airflow traditionnel), vous définissez quelles tâches exécuter et dans quel ordre. L’orchestrateur n’a aucune connaissance des données produites. Vous pouvez voir qu’une tâche a réussi à 8h03. Vous ne pouvez pas savoir si les données qu’elle a produites sont fraîches, correctes ou complètes.
Dans un modèle basé sur les assets (les Software-Defined Assets de Dagster), vous définissez quels produits de données doivent exister et comment ils doivent être produits. L’orchestrateur suit automatiquement le lineage, la fraîcheur et les états de matérialisation. On ne demande plus « est-ce que la tâche a tourné ? » mais « est-ce que cette table est à jour ? »
Cela correspond directement à la façon dont les analytics engineers pensent déjà. Chaque modèle dbt est conceptuellement un asset : une table avec des dépendances en amont (ref()) et une logique de transformation (SQL). Le graphe d’assets de Dagster est le DAG dbt, étendu. Les sources d’ingestion, les transformations Python, les modèles ML et les rafraîchissements de tableaux de bord BI peuvent tous participer au même graphe de dépendances.
L’introduction des Assets dans Airflow 3.0 (évolution des Datasets d’Airflow 2.4) valide ce changement de paradigme. Mais comme l’a noté un praticien : « Je ne crois pas qu’on puisse simplement passer d’une orientation tâches aux assets. C’est un changement bien plus profond, difficile à intégrer pour Airflow. Dagster a encore des kilomètres d’avance. » Le concept d’asset dans Airflow semble ajouté après coup. Dans Dagster, c’est l’abstraction fondatrice sur laquelle tout le reste repose.
Kestra aborde le problème différemment, en défendant l’orchestration déclarative via YAML. Son CEO Emmanuel Darras argumente que « dbt a prouvé le modèle déclaratif au niveau de la couche de transformation. Ce même modèle s’étend maintenant à l’ensemble de la stack d’orchestration. » Que les définitions YAML ou les décorateurs Python remportent la guerre du déclaratif reste à voir, mais la direction est claire : l’industrie s’éloigne des graphes de tâches impératifs.
La fusion Fivetran–dbt Labs et ses implications
Le 13 octobre 2025, Fivetran et dbt Labs ont annoncé une fusion en actions, créant une entité combinée approchant les 600 M$ d’ARR sous la direction du CEO George Fraser, avec Tristan Handy comme Président. Leur objectif affiché : une « infrastructure de données ouverte » unifiant le mouvement des données, la transformation, les métadonnées et l’activation. Fivetran a également acquis Census (reverse ETL, mai 2025) et Tobiko Data/SQLMesh (septembre 2025).
Cette consolidation affecte directement les choix d’orchestration. La roadmap de dbt Cloud est désormais liée à la stratégie de plateforme plus large de Fivetran. Les équipes qui veulent une indépendance d’orchestration — la capacité de choisir librement leurs outils d’ingestion, de transformation et de restitution — ont besoin d’une couche d’orchestration qu’elles contrôlent.
La fusion rend en fait l’orchestration externe plus stratégiquement importante. Dagster et Prefect se positionnent tous deux comme la couche neutre de « colle » entre les meilleurs outils de chaque catégorie. Pour les clients en consulting, c’est un argument clé. Recommander Dagster ou Airflow comme couche d’orchestration offre aux clients une optionalité fournisseur qu’une approche uniquement dbt Cloud ne peut pas garantir.
Avez-vous vraiment besoin d’un orchestrateur ?
Pour les équipes qui ne font que des transformations dbt sur un seul projet, un orchestrateur complet introduit une complexité qui ne se justifie pas forcément. Il existe un écart de coût spectaculaire entre les solutions simples (0–5 €/mois) et les orchestrateurs managés (250–500+ €/mois).
Un dbt build quotidien déclenché par Cloud Scheduler + Cloud Run coûte 0–3 €/mois sur le free tier GCP. GitHub Actions peut planifier des runs dbt dans ses 2 000 minutes gratuites/mois pour les dépôts privés. Le scheduler intégré de dbt Cloud gère la planification cron, les vérifications de fraîcheur des sources et les builds CI sur les PR. Ces solutions fonctionnent réellement.
Déclencheurs concrets pour passer à la vitesse supérieure : 5+ sources de données interconnectées, besoins de collaboration inter-équipes, engagements de SLA/fraîcheur, planification événementielle (pas seulement temporelle), environnements multiples (dev/prod), ou exigences de conformité et d’audit. En dessous de ces seuils, la simplicité l’emporte.
Mais attention à ce que j’appelle le pattern d’érosion de la confiance. L’orchestration simple ne casse pas de façon catastrophique. La confiance s’érode par petits décalages. La finance obtient des chiffres techniquement corrects mais fonctionnellement faux. Les pipelines se terminent « avec succès » mais livrent les insights trop tard. Le monitoring affiche du vert pendant que les parties prenantes voient des données obsolètes. Quand les rustines lâchent, la migration vers un vrai orchestrateur devient urgente plutôt que planifiée.
La progression est prévisible. Étape 1 : un seul cron job, dbt run && dbt test. Étape 2 : scripts multiples, monitoring manuel. Étape 3 : alertes Slack et gestion d’erreurs basique. Étape 4 : les dépendances inter-pipelines se multiplient. Étape 5 : vous regrettez de ne pas avoir migré six mois plus tôt.
Si vous êtes aux étapes 1–2, restez simple (voir quand cron suffit). Si vous reconnaissez l’étape 3, commencez à évaluer.
Choisir l’outil adapté à l’équipe
Le choix de l’orchestrateur doit correspondre à la façon dont votre équipe pense les données, pas au dernier fil Hacker News. Pour une évaluation côte à côte plus détaillée, consultez mon framework de décision.
Analytics engineers → Dagster
Les analytics engineers pensent en modèles, refs et tables. Ils veulent des jobs dbt planifiés, la gestion des dépendances entre modèles, le suivi de fraîcheur et le lineage visuel. Leur approche préférée est déclarative : ils se soucient de quelles données doivent exister, pas de comment les tâches s’exécutent.
Le modèle centré sur les assets de Dagster correspond directement à ce modèle mental. Chaque modèle dbt devient un asset Dagster avec lineage automatique, des asset checks issus des tests dbt, et un suivi de fraîcheur. Les 50 % de chevauchement dbt parmi les utilisateurs de Dagster Cloud en disent long sur le product-market fit.
La courbe d’apprentissage est raide, cependant. Les décorateurs Python, la configuration des ressources, la gestion du manifest et la mise en place des environnements demandent un investissement. Dagster University (gratuit) et le framework Components réduisent cet écart.
Data engineers → Airflow
Les data engineers pensent en infrastructure, fiabilité et coordination inter-systèmes. Ils veulent une définition de workflows en Python, l’orchestration de conteneurs, des déclencheurs événementiels et une large intégration avec les services cloud. Les 90+ packages de providers d’Airflow, ses 80 000+ organisations et sa réputation éprouvée en font le choix sûr pour les infrastructures hétérogènes.
C’est aussi le pari de carrière le plus sûr : 94 % des utilisateurs d’Airflow déclarent que la connaissance d’Airflow a un impact positif sur leur carrière. Pour les équipes enterprise avec une capacité DevOps, il reste le choix par défaut.
Python-first et rapidité → Prefect
Prefect l’emporte quand la rapidité de mise en place est déterminante et que votre équipe valorise l’écriture de Python classique sans abstractions de framework. Les flows sont de simples fonctions décorées. Les tests se font avec pytest standard. Le free tier de Prefect Cloud permet de démarrer sans carte bancaire.
Endpoint Closing a obtenu une réduction de 73,78 % des coûts de facturation en passant d’Astronomer à Prefect. LiveEO a rapporté avoir triplé sa vitesse de développement après adoption. Pour les équipes petites à moyennes (2–10) qui privilégient la vélocité de développement plutôt que l’orchestration data-aware, Prefect est difficile à battre.
YAML déclaratif → Kestra (avec réserves)
L’approche YAML-first de Kestra séduit les équipes qui veulent de l’orchestration sans écrire de Python. Il est agnostique en termes de langage, supporte plus de 600 plugins, et son UI permet de construire des workflows visuellement. La liste de clients enterprise est impressionnante pour un outil qui n’a atteint la version 1.0 qu’en septembre 2025.
Les preuves d’adoption en production à petite et moyenne échelle restent minces, cependant. Les 20 000 étoiles sont encourageantes, mais les étoiles ne valent pas des déploiements en production. J’observerais cet espace encore 6 à 12 mois avant de le recommander pour des workloads critiques.
Ce qu’il faut surveiller pour le reste de 2026
La maturation des assets dans Airflow 3.x. Le décorateur @asset est livré, mais Airflow peut-il faire de la pensée centrée sur les assets une expérience de premier plan, ou restera-t-elle une fonctionnalité greffée sur un paradigme basé sur les tâches ? Le cycle de releases 3.x apportera la réponse.
Le test de réalité de l’adoption en production de Kestra. Les 20 000 étoiles doivent se traduire en études de cas en production, à l’échelle où les analytics engineers opèrent réellement. Si ces preuves se concrétisent, Kestra devient un concurrent sérieux pour les équipes centrées sur dbt qui préfèrent le YAML au Python.
La roadmap d’intégration Fivetran–dbt. L’entité combinée va-t-elle créer un jardin clos qui rend l’orchestration externe plus difficile, ou une plateforme ouverte qui la rend optionnelle ? La réponse détermine si le scheduler intégré de dbt Cloud est « suffisant » ou stratégiquement risqué.
Les Components de Dagster pour abaisser la barrière d’entrée. Le framework Components (GA en 1.12) et le CLI dg sont conçus pour rendre Dagster accessible aux analytics engineers SQL-first qui trouvent la surcharge Python intimidante. S’ils réussissent, l’objection de la courbe d’apprentissage de Dagster s’affaiblit considérablement.