Qu’est-ce qu’Apache Airflow ?
Apache Airflow est un orchestrateur de workflows open source : il déclenche des tâches dans un ordre défini, gère leurs dépendances, relance celles qui échouent et donne une interface pour suivre l’ensemble. Il ne traite pas les données lui-même, il pilote les outils qui les traitent.
Les workflows s’écrivent en Python sous forme de DAG, pour directed acyclic graph : un enchaînement de tâches sans boucle, où chaque étape sait de quoi elle dépend. Décrire un pipeline revient donc à écrire du code, versionnable et testable comme le reste du projet.
L’outil est né chez Airbnb en 2014, a rejoint la fondation Apache en 2016 et en est devenu un projet de premier plan en 2019. C’est aujourd’hui la référence par défaut de l’orchestration data, au point que la plupart des offres de data engineering le mentionnent.
Airflow ou cron : pourquoi ne pas simplement planifier une tâche ?
Cron lance une commande à une heure donnée. Il ne sait rien du reste : si la tâche échoue, personne n’est prévenu ; si elle dépend d’un fichier pas encore arrivé, elle s’exécute quand même sur des données incomplètes.
Airflow ajoute ce que cron n’a pas : les dépendances entre tâches, les relances automatiques avec délai, les alertes en cas d’échec, l’historique de chaque exécution, la possibilité de relancer une seule étape sans rejouer tout le pipeline, et le rattrapage des périodes manquées.
Le seuil de bascule se situe autour de quelques dizaines de tâches interdépendantes. En dessous, un cron et un script suffisent et coûtent moins cher à exploiter.
À quoi sert Airflow ?
Airflow sert à faire tenir ensemble une chaîne de traitements qui dépendent les uns des autres et s’exécutent sur des systèmes différents.
Le cas type : à deux heures du matin, extraire les commandes de la base de production ; une fois l’extraction terminée, déclencher une transformation dans l’entrepôt ; si elle réussit, rafraîchir les tableaux de bord et prévenir l’équipe. Chaque étape peut échouer, être relancée seule, et bloquer les suivantes sans compromettre le reste du système.
On le retrouve aussi sur le réentraînement périodique de modèles, la synchronisation nocturne entre applications métier et la production d’états réglementaires à date fixe.
Le seuil au-delà duquel il devient utile ne tient pas au volume de données mais au nombre de dépendances. Un traitement lourd mais isolé n’a pas besoin d’Airflow. Quinze traitements légers qui s’attendent, si.
Comment fonctionne Airflow ?
Un DAG est un fichier Python déposé dans un répertoire surveillé. Airflow le lit, en déduit la liste des tâches et leurs dépendances, puis calcule les exécutions à déclencher.
Quatre composants tournent de concert : le scheduler décide de ce qui doit démarrer, l’executor place les tâches sur des workers, une base de métadonnées conserve l’état de chaque exécution, et une interface web permet de suivre, relancer ou mettre en pause.
Chaque tâche s’appuie sur un opérateur : exécuter une commande, appeler une API, lancer un traitement sur Kubernetes, déclencher une requête dans un entrepôt de données. Les capteurs, ou sensors, servent à attendre qu’une condition soit remplie, typiquement l’arrivée d’un fichier.
Deux notions déroutent au début. Une exécution est datée sur la période qu’elle couvre et non sur l’heure à laquelle elle tourne, ce qui rend le rattrapage possible mais surprend au premier usage. Et une tâche doit être idempotente : la rejouer deux fois sur la même période doit produire le même résultat, sans quoi toute relance devient un pari.
Airflow, Dagster, Prefect, dbt : que choisir ?
Airflow raisonne en tâches. Dagster raisonne en actifs de données : on déclare la table ou le fichier à produire, l’outil en déduit l’ordre d’exécution et suit la fraîcheur du résultat. Cette approche parle davantage aux équipes analytics.
Prefect met l’accent sur l’expérience de développement, avec des workflows écrits en Python ordinaire et moins de contraintes de structure. Il séduit les équipes réduites qui veulent éviter l’exploitation d’un cluster Airflow.
dbt n’est pas un orchestrateur. Il transforme les données à l’intérieur de l’entrepôt avec du SQL versionné. La combinaison la plus répandue reste Airflow qui déclenche dbt, pas l’un à la place de l’autre.
Enfin, Airflow ne remplace pas un moteur de traitement comme Spark, ni un outil d’intégration comme Talend ou Fivetran. Il les appelle. Confondre orchestration et transformation conduit à la faute la plus fréquente : charger des gigaoctets de données dans le processus Airflow lui-même au lieu de déléguer le calcul.
Faut-il héberger Airflow soi-même ?
Un Airflow auto-hébergé demande une base de métadonnées, un scheduler, des workers et une supervision. C’est une infrastructure à part entière, qui suppose une équipe capable de la maintenir.
Les offres managées évitent ce coût : Amazon MWAA sur AWS, Cloud Composer sur Google Cloud, Astro chez Astronomer, ainsi que les intégrations proposées par Microsoft. Le service coûte plus cher à l’usage mais supprime l’astreinte, ce qui pèse davantage dans une équipe de trois personnes que dans une plateforme data de cinquante.
Exemples ou cas d’usage concrets
Une entreprise e-commerce lance chaque matin la mise à jour de ses stocks : extraction des ventes de la veille, mise à jour de la base, envoi d’un rapport à la logistique. Si l’extraction échoue, les deux étapes suivantes ne partent pas et l’équipe reçoit une alerte plutôt qu’un rapport faux.
Une équipe data réentraîne chaque semaine un modèle de recommandation. Airflow enchaîne l’agrégation, l’entraînement et l’évaluation, puis conditionne le déploiement au fait que la nouvelle version batte l’ancienne sur la métrique retenue.
Une startup synchronise son CRM et son outil de facturation toutes les nuits. Le pipeline tient en quatre tâches, ce qui ne justifierait pas Airflow à soi seul ; il s’y trouve parce que l’infrastructure existe déjà pour d’autres flux.
Un service financier produit un état réglementaire à date fixe. Ici, la fonction déterminante est le rattrapage : une journée non traitée doit pouvoir être rejouée sans intervention manuelle et sans fausser les périodes voisines.
Quels profils travaillent avec Airflow ?
Airflow apparaît d’abord dans les offres de data engineer, où il figure aux côtés de Python, SQL, dbt et d’un entrepôt de données comme BigQuery, Snowflake ou Redshift. C’est une compétence attendue plutôt qu’une spécialité affichée.
- Data engineer : écrit et maintient les DAG, gère les dépendances entre sources et la reprise après incident.
- Analytics engineer : utilise Airflow pour déclencher ses transformations dbt, sans forcément administrer l’outil.
- MLOps engineer : orchestre les réentraînements de modèles et les évaluations périodiques.
- Platform ou data platform engineer : exploite le cluster Airflow lui-même, dimensionne les workers et surveille la base de métadonnées.
En entretien, la question qui trie le plus n’est pas « savez-vous écrire un DAG » mais « que faites-vous quand un pipeline échoue à trois heures du matin ». Idempotence des tâches, gestion des rattrapages et découpage en étapes rejouables séparent l’usage superficiel de la pratique réelle.