Dagster self-hosted : orchestration moderne — déploiement Coolify (2026)

Introduction

Vous avez mis en place Airbyte pour extraire vos données depuis des APIs tierces et dbt-core pour les transformer en modèles analytiques propres. Il vous manque maintenant la pièce centrale : un orchestrateur qui décide quand, dans quel ordre et avec quelle logique de reprise chaque pipeline s’exécute. C’est exactement le rôle de Dagster.

Apache Airflow a longtemps été la référence incontestée de l’orchestration data. Mais Airflow raisonne en termes de tâches et de DAGs temporels — il faut écrire beaucoup de code de plomberie pour savoir ce que produit chaque tâche et comment les données circulent entre elles. Dagster adopte un paradigme radicalement différent : les software-defined assets. Plutôt que de définir des tâches, vous déclarez des actifs de données — une table Postgres, un fichier Parquet, un modèle dbt — et Dagster infère automatiquement le graphe de dépendances. Le résultat : une observabilité native, un lineage visuel sans plugin supplémentaire, et une ergonomie bien plus proche de la façon dont un data engineer pense son travail.

Dans ce tutoriel, vous allez installer Dagster depuis zéro, créer vos premiers assets, configurer des schedules et sensors, puis déployer le daemon et le webserver sur Coolify — la plateforme self-hosted qui simplifie le déploiement Docker Compose sur votre VPS. Vous connecterez ensuite dbt-core via dagster-dbt pour orchestrer vos transformations, et vous explorerez l’interface Asset Lineage qui rend votre pipeline compréhensible en un coup d’œil.

Prérequis

• Python 3.10 ou 3.11 (Dagster 1.9+ supporte 3.10–3.12 ; éviter 3.13 en production début 2026)
• PostgreSQL 14+ pour le storage backend de Dagster (événements, runs, schedules)
• Coolify installé sur un VPS avec au moins 2 vCPU / 4 Go RAM (8 Go recommandés si dbt tourne en même temps)
• pip / virtualenv ou uv (plus rapide) pour gérer l’environnement Python
• Une connaissance basique de Docker Compose
• Temps estimé : 25 à 35 minutes pour l’installation locale + 15 minutes pour le déploiement Coolify

Étape 1 — Le concept des software-defined assets

Avant d’installer quoi que ce soit, il est important de comprendre pourquoi Dagster raisonne différemment d’Airflow. Dans Airflow, vous décrivez un workflow : « lance la tâche A, puis B, puis C ». La question « qu’est-ce que B a produit comme donnée ? » n’est pas native — il faut gérer ça soi-même via XComs ou des conventions de nommage.

Dagster inverse la perspective. Vous déclarez d’abord ce que vous voulez produire — un asset — puis vous décrivez comment le produire. Un asset peut être n’importe quelle donnée persistante : une table dans Postgres, un fichier CSV sur un bucket S3 compatible, un modèle dbt, un snapshot d’API. Chaque asset a un nom unique (asset key), des métadonnées, des dépendances sur d’autres assets, et un historique de matérialisations.

Cette approche a des conséquences concrètes. Quand vous matérialisez (terme Dagster pour « exécuter ») un asset, Dagster sait automatiquement quels assets en dépendent et lesquels sont potentiellement obsolètes. Si votre table de transactions Wave n’a pas été mise à jour depuis 20 minutes et que votre rapport quotidien en dépend, Dagster peut vous alerter ou déclencher automatiquement la rematérialisation. C’est ce que Dagster appelle la data-awareness — l’orchestrateur ne coordonne plus de tâches abstraites, il gère l’état réel de vos données.

Le graphe de dépendances entre assets est calculé statiquement à partir de votre code Python — aucune configuration YAML séparée n’est nécessaire. C’est la raison pour laquelle le lineage UI de Dagster est exact et toujours à jour : il reflète littéralement votre code.

Étape 2 — Installer dagster et dagster-webserver

L’installation de Dagster se fait entièrement via pip. Il est fortement recommandé de travailler dans un environnement virtuel dédié pour éviter les conflits de dépendances, en particulier si vous avez dbt-core installé par ailleurs.

Commencez par créer et activer un environnement virtuel, puis installez les paquets principaux :

# Créer l'environnement virtuel
python3.11 -m venv .venv
source .venv/bin/activate

# Installer Dagster, le serveur web et le support Postgres
pip install dagster dagster-webserver dagster-postgres

# Vérifier l'installation
dagster --version
# Attendu : dagster, version 1.9.x

Le paquet dagster contient le coeur du framework : le moteur d’exécution, le modèle de définition des assets, et les APIs Python. Le paquet dagster-webserver ajoute l’interface web (Dagit, rebaptisé webserver depuis la 1.x) qui permet de visualiser vos assets, lancer des runs manuellement et consulter les logs. Le paquet dagster-postgres fournit le connecteur pour utiliser PostgreSQL comme storage backend — indispensable en production car le backend SQLite par défaut ne supporte pas les accès concurrents entre daemon et webserver.

Si vous utilisez uv (recommandé pour sa rapidité sur les machines avec peu de bande passante) :

uv pip install dagster dagster-webserver dagster-postgres

Étape 3 — Premier projet et premier asset

Dagster fournit une commande dagster project scaffold pour créer la structure de base d’un projet. Cette commande génère les fichiers de configuration essentiels et un exemple d’asset prêt à l’emploi. C’est le point de départ recommandé plutôt que de partir d’une feuille blanche.

# Scaffolder un nouveau projet
dagster project scaffold --name mon_pipeline_data
cd mon_pipeline_data

# Structure générée :
# mon_pipeline_data/
#   mon_pipeline_data/
#     __init__.py      ← définitions Dagster (assets, jobs, schedules)
#     assets.py        ← vos assets
#   dagster_home/
#     dagster.yaml     ← config du storage backend
#   pyproject.toml
#   setup.py

Ouvrez le fichier mon_pipeline_data/assets.py et remplacez son contenu par un premier asset concret. Cet exemple charge des transactions depuis une API fictive et les matérialise comme une table Postgres :

import pandas as pd
import requests
from dagster import asset, MaterializeResult, MetadataValue

@asset(
    description="Transactions Wave Mobile Money des 15 dernières minutes",
    group_name="ingestion",
    tags={"source": "wave_api", "frequence": "15min"},
)
def wave_transactions_raw(context) -> pd.DataFrame:
    """
    Récupère les transactions Wave depuis l'API interne.
    En production, remplacer l'URL par le vrai endpoint.
    """
    context.log.info("Début ingestion transactions Wave...")

    # Appel API (simulé ici)
    response = requests.get(
        "https://api.interne.example.com/wave/transactions",
        params={"window": "15min"},
        timeout=30,
    )
    response.raise_for_status()
    data = response.json()

    df = pd.DataFrame(data["transactions"])
    context.log.info(f"{len(df)} transactions récupérées")

    # Émettre des métadonnées qui apparaîtront dans le lineage UI
    return MaterializeResult(
        metadata={
            "nb_lignes": MetadataValue.int(len(df)),
            "date_debut": MetadataValue.text(data.get("window_start", "")),
            "date_fin": MetadataValue.text(data.get("window_end", "")),
        }
    )


@asset(
    description="Transactions Wave agrégées par type et par heure",
    group_name="transformation",
    deps=[wave_transactions_raw],  # Dépendance déclarée explicitement
)
def wave_transactions_agregees(context, wave_transactions_raw: pd.DataFrame) -> pd.DataFrame:
    """
    Agrège les transactions par type (envoi, retrait, paiement marchand)
    et par heure. Cet asset dépend de wave_transactions_raw — Dagster
    le saura et refusera de le matérialiser si le parent est obsolète.
    """
    df_agg = (
        wave_transactions_raw
        .groupby(["type", pd.Grouper(key="created_at", freq="1h")])
        .agg(montant_total=("amount", "sum"), nb_transactions=("id", "count"))
        .reset_index()
    )
    context.log.info(f"Agrégation terminée : {len(df_agg)} lignes")
    return df_agg

Remarquez comment la dépendance entre les deux assets est déclarée directement dans la signature de la fonction Python : wave_transactions_agregees reçoit wave_transactions_raw comme paramètre. Dagster lit cette signature et en déduit que le second asset dépend du premier — sans configuration supplémentaire, sans YAML, sans graphe dessiné à la main. C’est l’un des avantages majeurs de l’approche assets-first : le code est la source de vérité.

Pour démarrer le serveur de développement et visualiser vos assets :

dagster dev

Ouvrez http://localhost:3000 dans votre navigateur. Vous verrez les deux assets apparaître dans l’interface, reliés par une flèche indiquant la dépendance. Vous pouvez dès maintenant cliquer sur « Materialize All » pour exécuter le pipeline manuellement et observer les logs en temps réel.

Étape 4 — Schedules et sensors

Dagster propose deux mécanismes pour déclencher automatiquement la matérialisation d’assets : les schedules (déclenchement temporel, équivalent cron) et les sensors (déclenchement conditionnel, basé sur un état externe). Les deux sont définis en Python dans votre projet et pris en charge par le dagster-daemon en production.

Pour ingérer les transactions Wave toutes les 15 minutes — cas typique pour les données Mobile Money en Afrique de l’Ouest — créez un schedule dans assets.py :

from dagster import (
    asset, define_asset_job, ScheduleDefinition,
    AssetSelection, SensorDefinition, RunRequest, sensor
)

# Définir le job qui matérialisera les deux assets d'ingestion
ingestion_job = define_asset_job(
    name="wave_ingestion_job",
    selection=AssetSelection.groups("ingestion") | AssetSelection.groups("transformation"),
)

# Schedule toutes les 15 minutes
wave_schedule = ScheduleDefinition(
    name="wave_15min_schedule",
    job=ingestion_job,
    cron_schedule="*/15 * * * *",  # Toutes les 15 minutes
    execution_timezone="Africa/Dakar",  # Fuseau horaire explicite
)


# Sensor qui déclenche le pipeline quand un nouveau fichier CSV arrive dans un dossier
@sensor(
    job=ingestion_job,
    minimum_interval_seconds=120,  # Vérifie toutes les 2 minutes
    description="Surveille les dépôts de fichiers CSV Mobile Money",
)
def csv_deposit_sensor(context):
    import os
    watch_dir = "/data/incoming/mobile_money"
    fichiers = [f for f in os.listdir(watch_dir) if f.endswith(".csv")]
    if fichiers:
        context.log.info(f"{len(fichiers)} fichier(s) CSV détecté(s)")
        yield RunRequest(
            run_key=fichiers[0],  # Clé unique pour éviter les doublons
            run_config={"ops": {"source_file": fichiers[0]}},
        )

Le paramètre execution_timezone est crucial en contexte ouest-africain : il garantit que le schedule s’exécute à l’heure locale correcte même si votre VPS est configuré en UTC. Les fuseaux horaires de la région (GMT, GMT+1) sont supportés nativement par la librairie pytz qu’utilise Dagster en interne.

Pour que les schedules et sensors fonctionnent, le dagster-daemon doit tourner en parallèle du webserver. En développement, dagster dev lance les deux automatiquement. En production, ils doivent être des processus séparés — c’est là qu’intervient Coolify.

Étape 5 — Déployer Dagster Daemon + Webserver via Coolify

Coolify est une plateforme self-hosted qui expose une interface web pour gérer des applications Docker Compose sur votre VPS. Elle gère automatiquement le réseau Docker, les certificats SSL via Let’s Encrypt, les variables d’environnement et les redémarrages en cas de crash — tout ce dont vous avez besoin pour un déploiement production fiable sans opérer Kubernetes.

Commencez par créer votre fichier docker-compose.yml de production. Dagster en production nécessite trois services distincts : le webserver, le daemon, et une base Postgres dédiée :

version: "3.9"

services:
  dagster_postgresql:
    image: postgres:16-alpine
    container_name: dagster_postgresql
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${DAGSTER_PG_USER}
      POSTGRES_PASSWORD: ${DAGSTER_PG_PASSWORD}
      POSTGRES_DB: dagster
    volumes:
      - dagster_pg_data:/var/lib/postgresql/data
    networks:
      - dagster_network

  dagster_webserver:
    image: mon_pipeline_data:latest  # Votre image Docker custom
    container_name: dagster_webserver
    restart: unless-stopped
    command: dagster-webserver -h 0.0.0.0 -p 3000
    environment:
      DAGSTER_POSTGRES_USER: ${DAGSTER_PG_USER}
      DAGSTER_POSTGRES_PASSWORD: ${DAGSTER_PG_PASSWORD}
      DAGSTER_POSTGRES_DB: dagster
      DAGSTER_POSTGRES_HOST: dagster_postgresql
      DAGSTER_HOME: /opt/dagster/dagster_home
    volumes:
      - dagster_home:/opt/dagster/dagster_home
    ports:
      - "3000:3000"
    depends_on:
      - dagster_postgresql
    networks:
      - dagster_network

  dagster_daemon:
    image: mon_pipeline_data:latest
    container_name: dagster_daemon
    restart: unless-stopped
    command: dagster-daemon run
    environment:
      DAGSTER_POSTGRES_USER: ${DAGSTER_PG_USER}
      DAGSTER_POSTGRES_PASSWORD: ${DAGSTER_PG_PASSWORD}
      DAGSTER_POSTGRES_DB: dagster
      DAGSTER_POSTGRES_HOST: dagster_postgresql
      DAGSTER_HOME: /opt/dagster/dagster_home
    volumes:
      - dagster_home:/opt/dagster/dagster_home
    depends_on:
      - dagster_postgresql
    networks:
      - dagster_network

volumes:
  dagster_pg_data:
  dagster_home:

networks:
  dagster_network:
    driver: bridge

Le fichier dagster.yaml placé dans DAGSTER_HOME doit pointer vers Postgres pour le storage backend. Créez-le ainsi :

# dagster_home/dagster.yaml
storage:
  postgres:
    postgres_url:
      env: DAGSTER_POSTGRES_URL

run_launcher:
  module: dagster.core.launcher
  class: DefaultRunLauncher

telemetry:
  enabled: false  # Désactiver la télémétrie en production

Dans Coolify, créez une nouvelle « Resource » de type « Docker Compose », collez votre fichier docker-compose.yml, puis renseignez les variables d’environnement (DAGSTER_PG_USER, DAGSTER_PG_PASSWORD, DAGSTER_POSTGRES_URL) dans l’onglet Variables. Coolify génèrera automatiquement un sous-domaine HTTPS pour le webserver sur le port 3000 — vous pourrez accéder à votre interface Dagster depuis n’importe où avec une URL sécurisée.

Après le déploiement, vérifiez que le daemon est actif depuis l’interface webserver : allez dans Deployment > Daemon — vous devez voir le statut « Running » en vert. Si le daemon n’est pas détecté, les schedules et sensors ne se déclencheront pas.

Étape 6 — Connecter dbt-core via dagster-dbt

L’intégration entre Dagster et dbt-core est l’une des plus utilisées de l’écosystème Dagster. Le paquet dagster-dbt charge automatiquement tous vos modèles dbt comme des assets Dagster natifs, en respectant le graphe de dépendances défini dans votre projet dbt. Vous obtenez ainsi un lineage unifié qui couvre l’ingestion (Airbyte), la transformation (dbt) et tous vos assets downstream — le tout dans une seule interface.

Installez le paquet :

pip install dagster-dbt dbt-postgres
# ou dbt-duckdb, dbt-bigquery selon votre adapter

Dans votre projet Dagster, chargez le projet dbt en utilisant DbtProject et dbt_assets :

from pathlib import Path
from dagster_dbt import DbtProject, dbt_assets, DbtCliResource
from dagster import Definitions

# Pointer vers votre projet dbt (peut être dans un sous-répertoire)
DBT_PROJECT_DIR = Path(__file__).parent.parent / "dbt_project"

dbt_project = DbtProject(
    project_dir=DBT_PROJECT_DIR,
    packaged_project_dir=DBT_PROJECT_DIR,  # Pour la production packagée
)
dbt_project.prepare_if_dev()  # Génère les manifests en mode développement


@dbt_assets(
    manifest=dbt_project.manifest_path,
    project=dbt_project,
    dagster_dbt_translator=None,  # Utilise le translator par défaut
)
def dbt_pipeline_assets(context, dbt: DbtCliResource):
    """
    Cet asset reprend TOUS les modèles dbt du projet et les expose
    comme assets Dagster individuels. Chaque modèle dbt devient
    un nœud dans le lineage graph.
    """
    yield from dbt.cli(["build"], context=context).stream()


# Enregistrer dans les Definitions du projet
defs = Definitions(
    assets=[wave_transactions_raw, wave_transactions_agregees, dbt_pipeline_assets],
    schedules=[wave_schedule],
    sensors=[csv_deposit_sensor],
    resources={
        "dbt": DbtCliResource(project_dir=dbt_project),
    },
)

La commande dbt.cli(["build"]) exécute dbt build — elle compile, teste et matérialise tous les modèles dans l’ordre correct. Le flux yield from ... .stream() remonte les événements dbt au runtime Dagster ligne par ligne, ce qui permet de voir les logs dbt directement dans l’interface webserver sans devoir consulter les fichiers de log séparément.

Pour déclencher les assets dbt uniquement après que wave_transactions_agregees soit matérialisé, déclarez une dépendance d’asset entre vos assets Python et vos modèles dbt en utilisant AssetSelection dans votre schedule :

full_pipeline_job = define_asset_job(
    name="full_data_pipeline",
    # Exécute d'abord l'ingestion Wave, puis les modèles dbt downstream
    selection=AssetSelection.all(),
)

Étape 7 — Asset Lineage UI

L’Asset Lineage UI est l’interface qui rend Dagster visuellement supérieur à Airflow pour la plupart des équipes data. Pour y accéder, allez dans l’onglet Assets du webserver, puis cliquez sur n’importe quel asset et sélectionnez View in Asset Lineage. Vous verrez immédiatement un graphe interactif représentant l’intégralité de votre pipeline.

Chaque nœud du graphe représente un asset. La couleur indique son état : vert pour « matérialisé récemment », orange pour « en attente de rematérialisation » (un parent amont a été mis à jour depuis la dernière matérialisation), gris pour « jamais matérialisé ». En cliquant sur un nœud, vous accédez à l’historique complet des matérialisations : date, durée, métadonnées émises (le nombre de lignes, les statistiques de qualité que vous avez ajoutées via MetadataValue), et les logs complets de chaque run.

Quand vous avez connecté dbt via dagster-dbt, les modèles dbt apparaissent comme des nœuds dans le même graphe que vos assets Python. Vous pouvez ainsi tracer le chemin complet d’une donnée : depuis l’API Wave brute (wave_transactions_raw), à travers l’agrégation Python (wave_transactions_agregees), puis à travers les modèles dbt de staging et de présentation, jusqu’au rapport final. C’est le niveau d’observabilité que seule une architecture assets-first peut fournir nativement.

Erreurs fréquentes

Adaptation au contexte ouest-africain

Dagster est particulièrement bien adapté aux contraintes du data engineering en Afrique de l’Ouest, à condition de configurer correctement deux aspects critiques : les retry policies et l’observabilité asynchrone.

Pour l’orchestration des APIs Mobile Money (Wave, Orange Money, MTN MoMo), la fenêtre de 15 minutes est standard mais les API peuvent présenter des latences élevées ou des timeouts intermittents, surtout en soirée quand les volumes de transactions piques. Dagster permet de définir des retry policies directement sur les assets :

from dagster import asset, RetryPolicy, Backoff

@asset(
    retry_policy=RetryPolicy(
        max_retries=4,
        delay=30,          # 30 secondes entre chaque tentative
        backoff=Backoff.EXPONENTIAL,  # 30s, 60s, 120s, 240s
        jitter=True,       # Ajoute un jitter pour éviter les tempêtes de retry
    ),
    description="Soldes Mobile Money via API (retry pour réseau intermittent)",
)
def mobile_money_balances(context):
    # ...
    pass

Le backoff exponentiel avec jitter est la stratégie recommandée pour les réseaux intermittents : elle évite de surcharger une API déjà sous stress en espaçant progressivement les tentatives. Avec 4 retries et un délai initial de 30 secondes, vous avez jusqu’à 7 minutes de window avant qu’un asset soit marqué comme échoué — suffisant pour traverser la plupart des coupures réseau momentanées courantes dans la région.

Pour l’observabilité des runs, Dagster supporte nativement les alertes via des sensors de run qui se déclenchent sur des événements de pipeline (échec, succès, début). Configurez un sensor d’alerte Telegram ou Slack pour être notifié immédiatement sans avoir à ouvrir l’interface webserver :

import requests
from dagster import run_failure_sensor, RunFailureSensorContext

@run_failure_sensor(
    name="telegram_failure_alert",
    monitor_all_code_locations=True,
)
def telegram_alert_on_failure(context: RunFailureSensorContext):
    """
    Envoie une alerte Telegram quand un run Dagster échoue.
    Configurer TELEGRAM_BOT_TOKEN et TELEGRAM_CHAT_ID en variables d'env.
    """
    import os
    message = (
        f"Pipeline Dagster — ECHEC\n"
        f"Job : {context.dagster_run.job_name}\n"
        f"Erreur : {context.failure_event.message[:300]}\n"
        f"Run ID : {context.dagster_run.run_id[:8]}"
    )
    requests.post(
        f"https://api.telegram.org/bot{os.environ['TELEGRAM_BOT_TOKEN']}/sendMessage",
        json={"chat_id": os.environ["TELEGRAM_CHAT_ID"], "text": message},
        timeout=10,
    )

Ce sensor surveille tous les jobs de tous vos code locations. En cas d’échec d’un run d’ingestion Wave, votre équipe data reçoit une notification Telegram en moins de 2 minutes — sans avoir à garder l’interface webserver ouverte en permanence. La même approche fonctionne avec l’API Slack via requests.post vers https://hooks.slack.com/services/....

Sur la question du VPS, Dagster + Postgres + le daemon tiennent confortablement sur un VPS Hetzner CAX11 (2 vCPU ARM, 4 Go RAM, ~3,5 €/mois) ou sur un serveur OVH Starter (2 Go RAM, 10 Go SSD, disponible en facturation mensuelle sans engagement). Si votre équipe traite des volumes modestes (moins de 10 millions de lignes par jour), ce profil suffit amplement pour les pipelines de données de PME.

Tutoriels frères

• Airbyte self-hosted : ingestion de données via Coolify (2026) — configurer les connecteurs source pour alimenter vos assets Dagster
• dbt-core self-hosted : transformation SQL moderne (2026) — construire les modèles dbt que Dagster orchestrera via dagster-dbt

Pour aller plus loin

• Retour au pilier : Data engineering self-hosted 2026 : Airbyte, dbt, Dagster, Iceberg
• Documentation officielle : docs.dagster.io — référence complète software-defined assets, concepts, intégrations
• Intégrations Dagster : docs.dagster.io/integrations — liste complète des connecteurs (dbt, Airbyte, Spark, Pandas, Polars, etc.)
• Prochain tutoriel dans le cluster : Apache Iceberg self-hosted — tables analytiques versionnées sur stockage objet MinIO

FAQ

Q : Dagster peut-il remplacer complètement Airflow dans une équipe existante ?
R : Oui, pour la grande majorité des cas d’usage data. La migration est progressive : Dagster peut coexister avec Airflow pendant la transition, et le paquet dagster-airflow permet même d’importer des DAGs Airflow existants comme point de départ. La bascule complète est recommandée pour les nouvelles équipes ou lors d’une refonte de pipeline — les équipes qui migrent reportent systématiquement un gain en observabilité et une réduction du temps de débogage.

Q : Quelle est la différence entre un job Dagster et un asset ?
R : Un asset représente une donnée persistante (ce que vous produisez) ; un job est une opération de matérialisation (l’acte de produire). Un job peut matérialiser un ou plusieurs assets sélectionnés. En pratique, vous définissez vos assets d’abord, puis vous créez des jobs pour regrouper des sélections d’assets à exécuter ensemble. Les schedules et sensors déclenchent des jobs, pas directement des assets.

Q : Le dagster-daemon est-il vraiment indispensable en production ?
R : Absolument. Sans le daemon, les schedules et sensors ne se déclenchent pas automatiquement — vous devez lancer les runs manuellement depuis l’interface. Le daemon est le processus qui surveille les horloges, interroge les sensors à intervalles réguliers et soumet les runs au run launcher. En développement, dagster dev le lance automatiquement. En production Coolify, il doit être un service Docker dédié avec sa propre politique de restart.

Q : Comment gérer les secrets (tokens API, mots de passe) dans Dagster ?
R : Dagster recommande de passer les secrets via des variables d’environnement et de les consommer dans les ressources via EnvVar("NOM_VARIABLE") plutôt que d’utiliser os.environ directement dans les assets. Dans Coolify, définissez vos secrets dans l’onglet Variables de votre service — ils sont injectés comme variables d’environnement dans les conteneurs et n’apparaissent jamais dans les logs ou les fichiers de configuration versionnés.

Q : Dagster supporte-t-il l’exécution distribuée sur plusieurs workers ?
R : Oui, via le CeleryExecutor (avec Redis ou RabbitMQ comme broker) ou via le DockerExecutor qui lance chaque run dans un conteneur Docker isolé. Pour les PME traitant des volumes modérés, le DefaultRunLauncher (exécution locale dans le daemon) est suffisant et ne requiert aucun middleware supplémentaire. L’exécution distribuée devient pertinente quand vous avez plusieurs pipelines lourds qui doivent tourner en parallèle sans se bloquer mutuellement.

Q : Comment surveiller l’état de santé des assets sur la durée ?
R : Dagster propose les asset checks (depuis la version 1.5) : des fonctions Python que vous attachez à un asset et qui s’exécutent après chaque matérialisation pour valider des invariants (unicité d’une clé, absence de valeurs nulles, plage de dates cohérente). Les résultats des checks apparaissent directement sur les nœuds du lineage graph avec un indicateur vert/rouge. Cela permet de détecter immédiatement une dégradation de la qualité des données sans attendre qu’un utilisateur final remonte une anomalie.