Les orchestrateurs traditionnels comme Airflow définissent quelles tâches exécuter et dans quel ordre. L’orchestrateur ne sait pas quelles données ces tâches produisent. Une exécution de tâche réussie signifie que le code s’est exécuté sans erreurs — cela ne dit rien sur la correction, la fraîcheur ou même la présence des données. L’orchestrateur suit l’état d’exécution, pas l’état des données.
L’orchestration centrée sur les assets inverse cela. Vous définissez quelles données doivent exister et comment les produire. Chaque asset est un objet de données persistant — une table BigQuery, un fichier GCS, un modèle dbt — avec une fonction qui le crée ou le met à jour. L’orchestrateur suit quand chaque asset a été matérialisé pour la dernière fois, s’il est frais, et si ses dépendances en amont ont changé depuis la dernière matérialisation.
Dagster est l’implémentation la plus claire de ce modèle. Son abstraction centrale est le Software-Defined Asset, et chaque autre concept de la plateforme — planifications, capteurs, politiques de fraîcheur — opère en termes d’assets plutôt que de tâches.
Pourquoi la Distinction est Importante
La différence entre l’orchestration par tâches et l’orchestration par assets apparaît le plus clairement dans les scénarios de débogage et de monitoring.
Débogage
Dans un système par tâches, « le pipeline a réussi à 8h » vous dit que des tâches ont été exécutées. Cela ne vous dit pas :
- Les données amont sont-elles réellement arrivées avant l’exécution de la transformation ?
- La table
mrt__finance__revenueest-elle à jour ? - Toutes les dépendances amont ont-elles d’abord été complétées, ou la tâche s’est-elle exécutée sur des entrées périmées ?
Vous devez reconstruire les réponses à partir des logs, des horodatages et d’investigations manuelles. L’orchestrateur a exécuté votre code avec succès ; si les données résultantes sont correctes, c’est votre problème.
Dans un système centré sur les assets, vous pouvez directement demander : « mrt__finance__revenue est-il à jour ? Quand a-t-il été matérialisé pour la dernière fois ? Toutes les assets amont ont-elles été complétées d’abord ? » Le système connaît les réponses parce qu’il suit l’état des données, pas seulement l’état d’exécution. L’interface Dagster affiche des indicateurs de santé sur chaque asset — matérialisé, périmé, échoué, frais — afin que vous puissiez évaluer la santé des données d’un coup d’œil sans lire des logs.
Monitoring
Le monitoring par tâches répond à : « Le job de 6h a-t-il réussi ? » Le monitoring par assets répond à : « Les données sont-elles suffisamment fraîches pour leurs consommateurs ? » Ce sont des questions fondamentalement différentes.
Un pipeline peut s’exécuter à l’heure chaque matin mais traiter systématiquement des données déjà périmées de 4 heures parce que la source amont était en retard. Le monitoring par tâches rapporte du vert. Le suivi de fraîcheur par assets rapporte que les données ne répondent pas à leur SLA de fraîcheur, même si l’exécution était techniquement réussie.
Conception des Pipelines
Dans l’orchestration par tâches, vous définissez un DAG d’opérations : « exécuter la tâche A, puis la tâche B, puis la tâche C ». La dépendance est entre les opérations, et les données qu’elles produisent sont un effet secondaire que l’orchestrateur ne voit pas.
Dans l’orchestration par assets, vous définissez un graphe d’objets de données : « l’asset X dépend de l’asset Y, qui dépend de l’asset Z ». Les opérations qui produisent chaque asset sont attachées à l’asset lui-même. Le graphe de dépendances est entre les données, pas entre les exécutions de code. C’est une correspondance naturelle pour les analytics engineers qui pensent déjà en termes de tables, modèles et dépendances ref().
L’Adéquation Naturelle avec dbt
Si vous travaillez avec dbt, vous faites déjà de la pensée centrée sur les assets sans l’appeler ainsi. Chaque modèle dbt produit une table (un asset). Chaque appel ref() déclare une dépendance entre assets. Chaque dbt build matérialise les assets dans l’ordre des dépendances.
L’écart est que le planificateur intégré de dbt (dbt Cloud) et la plupart des orchestrateurs externes (Airflow, Cloud Run cron, Cloud Workflows) pensent encore en tâches. Ils exécutent dbt build comme une tâche et rapportent le succès ou l’échec au niveau de la tâche. Ils ne savent pas quels modèles individuels ont été matérialisés, lesquels sont périmés, ou lesquels ont des tests en échec.
Dagster comble cet écart. L’intégration dagster-dbt lit votre manifest.json et crée un asset Dagster par modèle dbt. Vos appels ref() deviennent des arêtes dans le graphe d’assets Dagster. Chaque modèle obtient un suivi individuel de matérialisation, un historique de fraîcheur et des vérifications de qualité depuis vos tests dbt. L’orchestrateur voit enfin ce que dbt a toujours construit : pas des tâches, mais des assets de données.
Tâches vs. Assets : Comparaison
| Aspect | Par tâches (Airflow, cron) | Par assets (Dagster) |
|---|---|---|
| Abstraction centrale | Tâche (unité d’exécution de code) | Asset (objet de données persistant) |
| Graphe de dépendances | Entre opérations | Entre objets de données |
| « Succès » signifie | Le code s’est exécuté sans erreurs | Les données sont à jour et correctes |
| Monitoring | Horodatages d’exécution, statut des tâches | Fraîcheur, historique de matérialisation, badges de santé |
| Débogage | Lire les logs, corréler les horodatages | Cliquer sur un asset, voir son état complet et sa lignée |
| Adéquation dbt | Exécute dbt build comme une seule tâche | Chaque modèle dbt est un asset suivi |
| Ré-exécution sélective | Ré-exécuter la tâche en échec | Rematérialiser l’asset en échec et ses successeurs |
Quand l’Orchestration par Tâches Reste Suffisante
L’orchestration centrée sur les assets ajoute une surcharge conceptuelle. Si votre pipeline est « cron déclenche dbt build, dbt écrit dans BigQuery, l’outil BI lit BigQuery », un job Cloud Run sur un déclencheur cron le gère bien. L’état des données est suffisamment simple pour que vous puissiez l’inférer à partir des horodatages d’exécution.
Le modèle par assets justifie sa complexité quand :
- Plusieurs systèmes doivent se coordonner (ingestion, transformation, traitement Python, rafraîchissement BI)
- La fraîcheur des données est une exigence métier avec des SLAs, pas seulement une hypothèse
- Vous devez rematérialiser des assets individuels sans tout ré-exécuter
- La lignée inter-systèmes est importante pour le débogage et l’analyse d’impact
La comparaison Dagster vs. dbt Cloud et le cadre de décision d’orchestration GCP couvrent la décision pratique sur le moment d’adopter un orchestrateur centré sur les assets versus des alternatives plus simples.
La Tendance Générale
Dagster n’est pas seul à reconnaître ce changement. Airflow 3.0 a ajouté son propre décorateur @asset, signalant que même l’orchestrateur par tâches le plus établi voit la valeur de la conscience des assets. La différence est que Dagster a été construit nativement autour des assets depuis le début, tandis qu’Airflow greffe des concepts d’assets sur une fondation par tâches. Si cela a une importance pratique dépend de la profondeur à laquelle vous souhaitez que la sémantique des assets imprègne votre couche d’orchestration.
Le modèle centré sur les assets est passé de niche à courant dominant dans les évaluations d’outils d’orchestration de 2026, particulièrement pour les équipes avec des SLAs de fraîcheur des données.