Apache Airflow

Un traitement de données isolé se planifie avec une tâche programmée. Une chaîne de vingt traitements qui dépendent les uns des autres, dont certains échouent une nuit sur dix et doivent être rejoués sur une période précise, demande autre chose.

Airflow est cet autre chose, et il l’est depuis assez longtemps pour être devenu le choix par défaut. Sa force n’est pas d’être le plus élégant, c’est d’être partout : les intégrations existent, les problèmes ont déjà été rencontrés, et l’on trouve des gens qui savent s’en servir.

On décrit en Python un graphe de tâches et leurs dépendances. Airflow le lit, calcule ce qui peut tourner en parallèle, déclenche selon le calendrier fixé, et garde la trace de chaque exécution.

Trois composants font tourner l’ensemble. Le planificateur relit les fichiers de définition et décide de ce qui doit démarrer. Les exécutants font le travail, sur la même machine pour les petites installations, sur un parc de conteneurs pour les grandes. Une base de métadonnées conserve l’historique, l’état de chaque tâche et les paramètres.

Cette base est le point sensible de l’architecture. Elle grossit vite, et un Airflow qui ralentit après quelques mois a presque toujours une base de métadonnées qu’on a oublié de purger.

La version 3, sortie en 2025, a modernisé l’interface, revu la façon dont les tâches s’exécutent et introduit le versionnement des graphes, ce qui règle un vieil inconfort : jusque-là, modifier une chaîne réécrivait l’histoire des exécutions passées.

Elles sont assez universelles pour qu’on puisse les annoncer avant même de regarder votre installation.

La première est de faire transiter des données par le mécanisme d’échange entre tâches. Il est prévu pour de petites valeurs, un identifiant, un chemin de fichier, un compteur. Y faire passer un tableau de plusieurs milliers de lignes remplit la base de métadonnées et finit par tout ralentir. La bonne pratique consiste à écrire les données quelque part et à ne transmettre que leur emplacement.

La deuxième est de placer du code coûteux directement dans le fichier de définition, en dehors des tâches. Ce fichier est relu très fréquemment par le planificateur, pas seulement au moment de l’exécution. Une requête de base de données écrite au mauvais niveau se retrouve donc lancée en boucle toute la journée, sans que personne comprenne d’où vient la charge.

La troisième tient à la notion de date. Une exécution planifiée porte la date de la période qu’elle traite, et se déclenche à la fin de cette période. Le traitement du 1er du mois démarre donc à la fin du 1er, pas à son début. C’est logique une fois compris, et cela produit des décalages d’un jour dans les rapports tant que ça ne l’est pas.

Airflow est gratuit et c’est ce qui trompe. L’installation est simple, l’exploitation l’est beaucoup moins.

Il faut maintenir le planificateur, les exécutants et la base de métadonnées, purger l’historique, gérer les montées de version, surveiller que le planificateur ne prend pas de retard, et prévoir ce qui se passe quand la machine redémarre. Sur une petite équipe sans profil d’exploitation, cela finit par occuper quelqu’un une demi-journée par semaine.

Des offres managées existent chez les grands fournisseurs de cloud et chez des éditeurs spécialisés. Elles coûtent un abonnement mensuel et suppriment l’essentiel de ce travail. Pour une PME, c’est presque toujours le calcul le plus honnête : le temps d’ingénieur économisé dépasse le coût de l’abonnement.

Quand vous orchestrez des choses hétérogènes. C’est là qu’il reste imbattable : un traitement SQL, puis un appel d’API, puis un fichier déposé chez un partenaire, puis une notification. Les orchestrateurs plus récents sont meilleurs sur la donnée pure, moins à l’aise sur ce mélange.

Quand vous avez besoin de rejouer l’historique. Relancer une chaîne sur trois mois passés, période par période, est un cas prévu par l’outil et non un contournement.

Et quand la disponibilité des compétences compte. C’est l’orchestrateur que les gens connaissent, ce qui pèse au recrutement comme le jour où il faut de l’aide.

Quand il vaut mieux autre chose

Pour trois scripts quotidiens sans dépendances, une simple tâche programmée fera l’affaire. Installer Airflow pour ça revient à monter une infrastructure pour éviter d’écrire trois lignes.

Si vous n’orchestrez que des transformations de données et que vous utilisez dbt, Dagster sera plus confortable : il suit chaque modèle individuellement, là où Airflow déclenche généralement dbt comme une commande unique et perd la granularité.

Enfin, Airflow n’est pas fait pour le temps réel. Il déclenche par lots, à intervalles. Un flux continu relève d’une autre famille d’outils.

Nous concevons des chaînes qui tiennent : découpage en tâches rejouables, gestion des échecs, alertes qui partent au bon endroit, et surtout la capacité à relancer une seule période sans tout reprendre.

Nous reprenons aussi des installations existantes qui se sont dégradées. Dans presque tous les cas, le diagnostic tourne autour des mêmes points : base de métadonnées jamais purgée, code coûteux au mauvais niveau, données volumineuses qui transitent là où elles ne devraient pas.

Nous vous aidons enfin à trancher entre auto-hébergement et offre managée, en chiffrant le temps d’exploitation plutôt qu’en comparant seulement des factures. Et quand un autre outil conviendrait mieux, nous le disons.

À quoi sert Apache Airflow ?

Airflow orchestre des chaînes de traitements qui dépendent les uns des autres. On décrit en Python un graphe de tâches et leurs dépendances, et l’outil calcule ce qui peut tourner en parallèle, déclenche selon le calendrier fixé, conserve l’historique de chaque exécution et permet de rejouer une période précise. Une simple tâche programmée suffit pour un traitement isolé ; Airflow devient utile dès qu’il y a des dépendances et des reprises après échec.

Pourquoi mon installation Airflow ralentit-elle avec le temps ?

Le plus souvent parce que la base de métadonnées n’a jamais été purgée : elle conserve l’historique de toutes les exécutions et grossit continuellement. Deux autres causes fréquentes sont le passage de données volumineuses par le mécanisme d’échange entre tâches, prévu pour de petites valeurs seulement, et du code coûteux placé au niveau du fichier de définition, relu très fréquemment par le planificateur au lieu de ne s’exécuter que dans les tâches.

Pourquoi mes rapports Airflow ont-ils un jour de décalage ?

Parce qu’une exécution planifiée porte la date de la période qu’elle traite et se déclenche à la fin de cette période, pas à son début. Le traitement de la journée du 1er démarre donc à la fin du 1er. C’est cohérent une fois compris, mais cela produit systématiquement des décalages d’un jour dans les rapports tant que la logique n’est pas intégrée.

Airflow ou Dagster ?

Airflow reste préférable quand l’orchestration mêle des choses hétérogènes, un traitement SQL puis un appel d’API puis un dépôt de fichier, et quand la disponibilité des compétences compte. Dagster prend l’avantage lorsque l’on orchestre uniquement des transformations de données, en particulier avec dbt, puisqu’il suit chaque modèle individuellement là où Airflow déclenche généralement dbt comme une commande unique.

Faut-il héberger Airflow soi-même ou prendre une offre managée ?

Airflow est gratuit mais son exploitation ne l’est pas : maintenir le planificateur, les exécutants et la base de métadonnées, purger l’historique, gérer les montées de version et surveiller les retards occupe facilement une demi-journée par semaine sur une petite équipe. Pour une PME, une offre managée est presque toujours le calcul le plus honnête, car le temps d’ingénieur économisé dépasse le coût de l’abonnement.

• Dagster, l’alternative orientée actifs de données, et quand elle prend l’avantage.
• dbt, la couche de transformation qu’Airflow déclenche le plus souvent.
• Azure Data Factory, pour l’ingestion depuis des sources sur site.
• Snowflake ou Databricks, l’entrepôt en aval de la chaîne.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : architecture, XComs, bonnes pratiques.