Dagster

Les orchestrateurs classiques raisonnent en tâches : exécuter ceci, puis cela, dans cet ordre. Le planificateur sait ce qui a tourné et à quelle heure. Il ne sait pas ce qui existe à l’arrivée.

Dagster inverse la formulation. On y déclare des actifs de données, une table, un modèle, un fichier, et la façon de les produire. L’orchestrateur en déduit lui-même l’ordre d’exécution, et il sait à tout moment quel actif est à jour, lequel est périmé et lequel a échoué.

La nuance a l’air théorique. Elle se sent le jour où un directeur financier demande d’où sort un chiffre et combien de temps il faut pour répondre.

Chaque actif déclare ses dépendances, et Dagster construit le graphe tout seul. Trois choses en découlent sans travail supplémentaire.

La traçabilité devient native. On voit d’où vient chaque table, ce qui l’alimente et ce qu’elle alimente. Sur un orchestrateur de tâches, cette information se documente à la main, donc elle se périme, généralement dans les six mois.

Le recalcul devient ciblé. Quand une source change, on relance les actifs concernés et leurs descendants, pas la chaîne entière. Et l’état devient visible : l’interface montre la fraîcheur de chaque actif, si bien que la question « ce chiffre est-il à jour » se répond en regardant, sans ouvrir les journaux.

La question se pose systématiquement, et la bonne réponse n’est pas que l’un remplace l’autre.

Airflow a pour lui une maturité considérable, un écosystème d’intégrations très large, une présence installée dans la plupart des grandes organisations et un vivier de compétences disponible. C’est le choix par défaut raisonnable, en particulier quand l’orchestration dépasse la donnée et touche à des traitements métier ou à des tâches d’infrastructure.

Dagster prend l’avantage quand l’objet orchestré est de la donnée, et rien que de la donnée. La traçabilité automatique, le test local des transformations et l’intégration avec les outils de modélisation en font un environnement plus confortable pour une équipe analytique.

Un point pratique pèse souvent plus que le reste dans l’arbitrage. Un projet dbt s’importe dans Dagster, et chaque modèle devient un actif orchestré individuellement, avec sa fraîcheur et ses dépendances. Sur Airflow, dbt se déclenche généralement comme une commande unique, et la granularité par modèle disparaît.

C’est du Python. Les actifs sont des fonctions décorées, et sans compétence Python dans l’équipe l’outil reste inaccessible. Il n’y a pas d’interface visuelle qui permette de contourner ce point.

Les partitions changent beaucoup de choses au quotidien. Déclarer qu’un actif est partitionné par jour ou par mois permet de recalculer une seule période sans toucher au reste, ce qui rend les reprises supportables sur un historique long. C’est la fonctionnalité que les équipes découvrent en dernier et regrettent de ne pas avoir utilisée dès le départ.

Le test local est un gain réel : on exécute un actif sur son poste avant de le déployer, ce qui raccourcit nettement la boucle par rapport à un orchestrateur qu’il faut interroger à distance. Côté formules, une version ouverte sous licence Apache 2.0 s’héberge soi-même, et une offre commerciale prend en charge l’exploitation. Dernier point à peser, surtout pour le recrutement : la communauté francophone reste plus étroite que celle d’Airflow.

Quand vous orchestrez principalement des transformations de données, quand vous utilisez dbt et voulez suivre chaque modèle individuellement, et quand on vous demande régulièrement d’où vient un chiffre. En contexte réglementé, la traçabilité automatique est un argument sérieux, parce qu’elle ne dépend pas d’une documentation que quelqu’un doit penser à mettre à jour.

Les partitions justifient aussi le choix à elles seules quand l’historique impose des recalculs partiels réguliers.

En revanche, si Airflow est déjà en place et fonctionne, nous déconseillons la migration. Changer d’orchestrateur coûte cher et le confort ne suffit pas à le justifier. Si vous orchestrez autre chose que de la donnée, la maturité d’Airflow reste décisive. Et si l’équipe ne fait pas de Python, un outil visuel ou un service managé sera plus réaliste, quelles que soient les qualités du produit.

Nous concevons le graphe d’actifs : découpage, partitions, dépendances, politiques de fraîcheur. Nous intégrons le projet dbt existant pour l’orchestrer modèle par modèle et obtenir la traçabilité de bout en bout, puis nous déployons, en auto-hébergement ou sur l’offre managée selon vos contraintes.

Nous mettons enfin en place la supervision, les alertes et les contrôles de qualité sur les actifs. Et quand Airflow suffit, nous le disons : c’est souvent la bonne réponse, même si elle est moins vendeuse.

Quelle différence entre Dagster et Airflow ?

Airflow orchestre des tâches : il sait ce qui a tourné et dans quel ordre. Dagster orchestre des actifs de données : on déclare les tables et les modèles à produire, et l’outil déduit l’ordre d’exécution tout en sachant lequel est à jour ou périmé. Airflow garde l’avantage de la maturité, de l’écosystème et des compétences disponibles ; Dagster est plus confortable quand l’objet orchestré est exclusivement de la donnée.

Dagster s’intègre-t-il avec dbt ?

Oui, nativement. Un projet dbt s’importe et chaque modèle devient un actif orchestré individuellement, avec ses dépendances et sa fraîcheur. C’est une différence pratique importante avec Airflow, où dbt est généralement déclenché comme une commande unique, ce qui fait perdre la granularité par modèle.

Qu’est-ce qu’un actif partitionné dans Dagster ?

Un actif dont les données sont découpées par période, par exemple par jour ou par mois. Cela permet de recalculer une seule période sans retraiter tout l’historique, ce qui rend les reprises après incident praticables sur de gros volumes.

Dagster est-il gratuit ?

Une version ouverte sous licence Apache 2.0 est disponible et s’héberge sur votre propre infrastructure. Une offre commerciale hébergée existe également, qui prend en charge l’exploitation, la supervision et le déploiement. Le choix dépend de vos contraintes de souveraineté et de la présence ou non d’une équipe capable d’exploiter le service.

• Airflow, l’alternative de référence et les cas où elle reste préférable.
• dbt, la couche de transformation que Dagster orchestre le mieux.
• Snowflake et BigQuery, les entrepôts en aval.
• Azure Data Factory, pour l’ingestion depuis des sources sur site.

Sources — documentation officielle de l’éditeur, consultée le 22 août 2026 : actifs de données.