Philosophies architecturales des orchestrateurs

Toute comparaison d’orchestrateurs finit par devenir une matrice de fonctionnalités. Airflow a 90+ packages de fournisseurs. Dagster a la lignée d’assets. Prefect a les workflows dynamiques. Tous les trois peuvent planifier dbt, réessayer en cas d’échec, et envoyer des alertes Slack quand quelque chose se casse. La parité des fonctionnalités importe moins que le modèle mental sous-jacent — l’abstraction centrale qui façonne la façon dont vous définissez les pipelines, déboguez les échecs, et réfléchissez à votre plateforme de données.

Une heuristique utile de Branch Boston : “Choisissez le nom qui correspond au vocabulaire de votre organisation. DAGs pour Airflow, flows pour Prefect, assets pour Dagster.”

Orienté processus : Airflow

Airflow est construit autour du processus. Vous écrivez des scripts Python qui définissent des graphes acycliques dirigés (DAGs) de tâches. Le scheduler les prend en charge, les workers les exécutent, et le serveur web vous montre ce qui a tourné et quand. Le modèle central est : décrire 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.

# Airflow : vous définissez les tâches et leur ordre
from airflow.decorators import dag, task
from datetime import datetime

@dag(schedule="@daily", start_date=datetime(2025, 1, 1))
def my_pipeline():
    @task
    def extract():
        # extraire les données depuis une API
        return raw_data

    @task
    def transform(data):
        # nettoyer et remodeler
        return clean_data

    @task
    def load(data):
        # écrire dans BigQuery
        pass

    raw = extract()
    clean = transform(raw)
    load(clean)

Le modèle mental est impératif : d’abord faire ceci, puis faire cela. Quand quelque chose échoue, vous voyez une tâche rouge dans un DAG. Vous savez quelle étape a échoué, mais reconstituer l’impact sur les données — quelles tables sont obsolètes, quels dashboards sont erronés — vous oblige à maintenir ce mapping dans votre tête ou dans la documentation.

Airflow 3.0 (2025) a ajouté un serveur API basé sur FastAPI et une UI React, mais le modèle central n’a pas changé. Le scheduler pense toujours en termes de tâches et d’ordre d’exécution, pas en termes de produits de données et de fraîcheur.

L’avantage de l’écosystème Airflow

Là où le modèle orienté processus gagne vraiment, c’est dans l’étendue de l’écosystème. Avec 80 000+ organisations, 3 600+ contributeurs, et 30M+ téléchargements mensuels sur PyPI, Airflow dispose d’opérateurs et de fournisseurs pour pratiquement tous les systèmes existants. Si vous devez orchestrer sur une infrastructure hétérogène — Snowflake, Databricks, Kubernetes, Spark, APIs personnalisées — l’écosystème de fournisseurs Airflow vous couvre.

L’écosystème n’est pas qu’une question de commodité. Il représente une connaissance opérationnelle accumulée : stratégies de réessai, pooling de connexions, patterns de gestion des erreurs qui ont été éprouvés sur des milliers de déploiements en production. Un nouvel utilisateur de BigQueryOperator bénéficie d’années de gestion de cas particuliers qu’il n’a pas eu à découvrir lui-même.

Orienté données : Dagster

Dagster inverse le modèle. Au lieu de définir des tâches, 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 en amont, une fonction de calcul qui le produit, et des métadonnées que le système suit automatiquement — heure de dernière matérialisation, fraîcheur, état de santé.

# Dagster : vous définissez les produits de données et leurs dépendances
from dagster import asset, AssetExecutionContext

@asset
def raw_events(context: AssetExecutionContext):
    """Extraire les événements depuis l'API et écrire dans BigQuery."""
    data = fetch_from_api()
    write_to_bigquery(data, "raw_events")

@asset(deps=[raw_events])
def clean_events(context: AssetExecutionContext):
    """Nettoyer et dédupliquer les événements."""
    data = read_from_bigquery("raw_events")
    cleaned = deduplicate(data)
    write_to_bigquery(cleaned, "clean_events")

@asset(deps=[clean_events])
def daily_metrics(context: AssetExecutionContext):
    """Agréger en métriques quotidiennes pour les dashboards."""
    data = read_from_bigquery("clean_events")
    metrics = aggregate_daily(data)
    write_to_bigquery(metrics, "daily_metrics")

Quand vous ouvrez l’interface Dagster, vous voyez vos produits de données et leurs états, pas une liste d’exécutions de tâches. Vous voyez que daily_metrics a été matérialisé il y a 2 heures, que son clean_events en amont est frais, et que tous les checks d’assets ont réussi. Quand quelque chose échoue, vous le voyez dans le contexte de votre lignée de données — quelles tables en aval sont maintenant obsolètes, quels SLAs de fraîcheur sont à risque.

Pour les analytics engineers qui pensent en tables, modèles, et fraîcheur, c’est l’attrait central de Dagster. Le vocabulaire correspond. Un modèle dbt qui produit une table BigQuery correspond naturellement à un asset Dagster. L’intégration dagster-dbt rend ce mapping explicite : un asset Dagster par modèle dbt, avec les dépendances depuis ref() devenant des arêtes dans le graphe d’assets.

Orienté fonctions : Prefect

Prefect prend une troisième approche. Des fonctions Python décorées avec @flow et @task deviennent des workflows. Il n’y a pas de fichier de définition DAG séparé, pas de YAML, pas de structure de projet spéciale. Les flows peuvent construire des dépendances dynamiquement à l’exécution en utilisant le flux de contrôle Python ordinaire.

# Prefect : des fonctions Python ordinaires deviennent des workflows
from prefect import flow, task

@task
def extract_data(source: str) -> dict:
    return fetch_from_api(source)

@task
def transform_data(raw: dict) -> dict:
    return clean_and_reshape(raw)

@task
def load_data(data: dict, target: str):
    write_to_bigquery(data, target)

@flow
def my_pipeline(sources: list[str]):
    for source in sources:
        raw = extract_data(source)
        clean = transform_data(raw)
        load_data(clean, f"clean_{source}")

Le flow peut itérer sur une liste dynamique de sources, se ramifier conditionnellement, appeler des sous-flows — tout ce que Python peut exprimer. Les dépendances se construisent à l’exécution, pas au moment de l’analyse. Prefect 3.0 (septembre 2024) a reconstruit le moteur avec une sémantique transactionnelle et réduit la surcharge de plus de 90 %.

L’attrait est la simplicité et la flexibilité. Si la structure de votre pipeline change en fonction des données d’entrée, Prefect gère cela naturellement. Le coût est que Prefect ne connaît pas vos produits de données comme le fait Dagster — il suit l’exécution des flows et des tâches, pas la fraîcheur et la lignée des assets.

Le signal de convergence

Airflow 3.0 a introduit le décorateur @asset, un clin d’œil direct au modèle orienté données de Dagster. C’est significatif car cela reconnaît que le modèle orienté processus a un manque : les opérateurs doivent connaître les données que leurs tâches produisent, pas seulement si les tâches ont réussi.

Mais le concept d’asset semble ajouté par-dessus plutôt que fondamental. Le scheduler, l’interface, et le modèle opérationnel d’Airflow ont été conçus autour de l’exécution des tâches. Ajouter la prise en compte des assets comme une couche supplémentaire est architecturalement différent de la construction de l’ensemble du système autour des assets dès le départ. Le graphe d’assets de Dagster est le modèle de navigation principal dans l’interface. Le graphe d’assets d’Airflow est une vue secondaire aux côtés de la vue principale axée sur l’exécution des tâches.

Cela compte en pratique lors du débogage. Dans Dagster, vous partez de “quel asset est obsolète ?” et remontez en arrière. Dans Airflow, vous partez de “quelle tâche a échoué ?” et progressez vers l’impact sur les données. Pour les analytics engineers dont la question principale est “mes données sont-elles fraîches et correctes ?”, le point de départ orienté données est plus naturel.

Choisir la bonne abstraction

La bonne abstraction dépend de la façon dont votre équipe pense au travail data :

• Si votre équipe pense en tables, modèles et fraîcheur — si la question principale est “ces données sont-elles actuelles et correctes ?” — le modèle orienté assets de Dagster correspond à votre vocabulaire. Les analytics engineers sur dbt tombent dans cette catégorie presque par définition.
• Si votre équipe gère une infrastructure diverse — si le défi principal est de coordonner des tâches sur de nombreux systèmes différents — le modèle orienté processus d’Airflow et son écosystème d’opérateurs vous servent mieux.
• Si votre équipe écrit du Python en priorité et valorise la flexibilité — si vos workflows sont dynamiques, pilotés par événements, et que vous voulez un minimum de surcharge de framework — le modèle orienté fonctions de Prefect ne vous gène pas.

Le pire résultat est de choisir une abstraction qui résiste à la façon naturelle de penser de votre équipe. Une équipe analytics forcée dans le modèle de tâches d’Airflow dépensera de l’énergie mentale à traduire entre “quelle tâche a tourné” et “mes données sont-elles fraîches”. Une équipe plateforme forcée dans le modèle d’assets de Dagster peut le trouver contraignant quand son travail principal est de coordonner une infrastructure hétérogène, pas de suivre la fraîcheur des produits de données.