On a porté un pipeline Airflow sur Kestra : retour de chantier

Pourquoi ce chantier

Nous opérons Apache Airflow en production chez plusieurs clients depuis des années. Airflow est l'orchestrateur de référence du marché — celui sur lequel s'appuient la plupart des plateformes data sérieuses, celui que les équipes connaissent, celui qui a fait ses preuves.

Depuis quelques mois, une question revient régulièrement, chez nos clients comme dans les conversations de couloir : Kestra, ça vaut quoi ? C'est une plateforme d'orchestration open-source plus jeune, qu'on présente souvent comme « le Airflow déclaratif » — du YAML à la place du Python, une expérience développeur plus moderne, des intégrations cloud natives. Pour répondre avec autre chose qu'une opinion, nous avons porté un vrai pipeline de production sur Kestra, en parallèle de la prod, sur le même cluster, avec les mêmes binaires applicatifs.

Voici ce qu'on en tire. Pas un benchmark, pas un guide d'installation — un retour de chantier destiné à toute équipe ou direction qui se demande s'il faut évaluer Kestra, et dans quels cas.

Pendant les premières heures d'exploration, une formulation s'est imposée : « Kestra est à Airflow ce que Terraform est à Ansible ». Plus déclaratif, plus moderne dans son cycle d'itération, plus orienté cloud-native. L'analogie a ses limites, mais elle cadre bien la nature du déplacement qu'on observe.

Quand Kestra a du sens, quand Airflow reste préférable

Avant d'entrer dans le chantier, posons le décor. Ce qu'on a constaté nous fait dire que le choix entre les deux dépend très largement du contexte :

Contexte	Notre lecture après le chantier
Nouveau projet, équipe à former, besoin d'itérer vite	Kestra a un vrai avantage
Plateforme Airflow stable, équipe formée, patterns custom déjà construits	Airflow reste préférable (capital existant)
Pipelines simples et déclaratifs avec beaucoup d'intégrations standards	Kestra (écosystème de plugins natif large)
Pipelines à logique applicative complexe (ML, transformations avancées)	Airflow (Python natif, plus puissant)
Multi-tenant fort, audit, gouvernance large attendue	Airflow (communauté plus large, écosystème commercial multi-vendor)

Notre objectif n'est pas de trancher abstraitement, mais de savoir ce qu'on fait dans chaque cas. Ce qui suit raconte concrètement le chantier qu'on a mené pour valider cette lecture.

Étape 1 — Tester en conditions réelles, sans toucher la prod

Première contrainte qu'on s'est imposée : ne pas créer un environnement de test « jouet » à côté. On voulait reproduire les conditions réelles d'un éventuel déploiement chez un client, pas une démo de salon. La méthode :

• Kestra déployé sur le même cluster que la production Airflow.
• Isolation par les données uniquement : base et stockage objet dédiés à l'environnement de test.
• Zéro modification du code applicatif de production. Les mêmes binaires sont exécutés des deux côtés — Kestra orchestre exactement ce qu'orchestre Airflow, avec d'autres variables d'environnement.
• Édition open-source pure assumée. Aucune fonctionnalité Enterprise dans le périmètre. Ce qu'on déploie, c'est ce qu'on saura redéployer chez un client sans dépendance commerciale.

Cette méthode est reproductible chez n'importe quel client qui veut évaluer un orchestrateur sans risque pour la prod. C'est elle qui permet de comparer ce qui est comparable — les mêmes données passent par deux orchestrateurs différents, et on regarde ce qui sort.

Architecture comparée

L'une des différences les plus immédiatement visibles tient au nombre de composants à opérer :

• Côté Airflow, plusieurs services se partagent les responsabilités : un planificateur, un serveur d'API, un processeur de définitions, un déclencheur d'événements. Chacun s'exécute en parallèle et doit être supervisé.
• Côté Kestra, en édition standalone, un seul service couvre l'ensemble de ces rôles.

Sur ce point on peut être factuel sans extrapoler : moins de pièces à monitorer et à upgrader, c'est observable. Ce qu'on ne peut pas dire à ce stade — et on l'assume — c'est « Kestra consomme moins de ressources » : les conditions de charge de nos deux environnements n'étaient pas équivalentes.

Étape 2 — Le fait dur : Kestra a produit les mêmes données qu'Airflow

Le chantier ne servait à rien si Kestra livrait des résultats différents. On a donc cadré une validation rigoureuse : sur le même périmètre, sur plusieurs journées indépendantes, on compare ligne à ligne ce que les deux orchestrateurs livrent en sortie de pipeline. Les sorties sont strictement identiques. Les contrôles métier appliqués en aval — distributions, totaux, agrégations utilisées par les utilisateurs finaux — donnent les mêmes résultats des deux côtés.

C'est ce qu'on peut affirmer sans nuance après ce chantier : sur ce périmètre, Kestra produit le même livrable qu'Airflow. La transition est techniquement faisable.

Ce que la validation n'a pas tranché. La performance brute sous charge réelle multi-clients, le coût opérationnel à grande échelle, la stabilité sur plusieurs mois. On n'a pas testé ces dimensions honnêtement. À périmètre identique sur le sous-ensemble qu'on a pu mesurer, Airflow garde un léger avantage en temps d'exécution ; l'échantillon est trop petit pour en tirer un chiffre fiable, on ne le chiffre donc pas.

Étape 3 — Une expérience développeur qui change le quotidien

Au-delà du livrable, ce qui compte pour une équipe au quotidien, c'est le temps qu'elle perd à attendre un outil. Sur ce point précis, Kestra a un avantage net.

Modifier un pipeline côté Airflow passe par un cycle Git habituel — commit, push, attente de la synchronisation, attente du re-parsing. Côté Kestra, on édite, on pousse, le pipeline est disponible quasi instantanément. Sur une après-midi d'écriture exploratoire, c'est dix à quinze allers-retours supplémentaires possibles. Sur un débogage à 3 h du matin, c'est tangible.

L'UI de supervision aussi est plus moderne — flux de logs en direct, recherche dans les logs, visualisation des dépendances. Ce n'est pas un argument structurant à lui seul, mais cumulé, ça fait une différence sensible sur le confort d'exploitation.

À garder en tête : en production, le déploiement reste discipliné par GitOps des deux côtés. L'avantage Kestra se ressent surtout en phase exploratoire et en exploitation quotidienne.

Étape 4 — Le match au quotidien

Au-delà du livrable et du cycle d'itération, on a passé en revue les opérations qu'une équipe data fait toutes les semaines. En synthèse :

• Relancer un run qui a échoué la nuit : plus direct côté Kestra (un bouton « Relancer » explicite, là où Airflow utilise un terme moins intuitif pour un nouveau venu).
• Diagnostiquer une panne : avantage Kestra (logs en direct, recherche full-text native).
• Gérer la rotation d'un secret : avantage Kestra (alignement natif sur les mécanismes de sécurité du cluster, plutôt qu'une base interne à l'orchestrateur).
• Notifier une équipe (Slack, Teams, email…) : avantage Kestra (catalogue de plugins natifs très large).
• Onboarder un nouveau collaborateur : avantage Kestra sur les premiers pas (le YAML est plus accessible que le Python pour qui débute). Avantage Airflow dès que la logique se complexifie (transformations avancées, ML).
• Tester et industrialiser le code : avantage Airflow (Python = test unitaire natif, écosystème mature).

En résumé

Critère	Verdict
Équivalence des données produites	Strictement identique
Expérience développeur, cycle d'itération	Kestra
Maturité communauté et gouvernance	Airflow
Nombre de composants à opérer	Kestra (édition standalone très compacte)
Testabilité et industrialisation du code	Airflow
Catalogue d'intégrations cloud natives	Kestra
Onboarding d'une équipe junior	Kestra
Réversibilité et écosystème multi-vendor	Airflow

Ce qu'on retient de Kestra

Sur ce chantier, Kestra a produit le même livrable qu'Airflow. C'est l'argument central, et c'est celui qui retire l'incertitude pour qui se posait la question.

Au-delà de ce fait dur, l'impression dominante après plusieurs jours d'exploration est celle d'une plateforme prometteuse. Plus moderne dans son cycle d'itération, plus directe dans son rapport à Kubernetes, plus accessible pour une équipe qui débute. Sur certaines opérations du quotidien, l'écart avec Airflow est nettement en faveur de Kestra.

Mais c'est aussi une plateforme plus jeune, dont l'écosystème, la communauté et les patterns d'exploitation sont en pleine maturation. Aujourd'hui, pour un client qui dispose d'une production Airflow stable et d'une équipe formée, le retour sur investissement d'une migration ne se justifie pas par défaut. Le coût de migration dépasserait le bénéfice à court terme.

Notre conviction après ce chantier : Kestra a tout pour devenir un acteur de référence de l'orchestration open-source dans les prochaines années. On attend avec impatience que son écosystème se densifie, que ses patterns d'exploitation à grande échelle se stabilisent, que sa communauté grandisse. À mesure que ces éléments s'installeront, le choix entre les deux deviendra de moins en moins évident — et de plus en plus contextuel.

D'ici là, Datakhi continue d'opérer Airflow en production chez ses clients existants, et tient Kestra en veille active pour les démarrages, les équipes en formation, et les contextes où son catalogue de plugins natifs apporte une vraie valeur immédiate. Nous savons désormais le déployer proprement et faire éviter les frictions habituelles d'une plateforme en pleine évolution.

Vous évaluez Kestra, Airflow ou un autre orchestrateur ? Vous voulez tester un orchestrateur en parallèle de votre production sans risque, et savoir ce que ça donne sur vos données réelles ? Datakhi a porté un vrai pipeline Airflow vers Kestra et structuré la méthode en étapes reproductibles. Discutons-en.

Pour aller plus loin

• Notre précédent retour d'expérience sur la même infrastructure : « De MinIO à Garage : benchmark, migration et premiers retours en production »
• Site officiel Kestra : kestra.io
• Documentation Airflow : airflow.apache.org