Workflows : vue d'ensemble

Un workflow est un pipeline d'orchestration (type ORCH) : au lieu de transformer des données, il enchaîne des exécutions : lancer des sous-pipelines, brancher selon des conditions, boucler, paralléliser, réagir aux erreurs et notifier. Il s'édite dans le même éditeur visuel que les pipelines de données, avec sa propre palette de composants.

Un workflow dans l'éditeur : une brick Déclencheur en entrée, puis des bricks d'orchestration (sous-pipelines, conditions, notifications).

Pipeline ou workflow ?

	Pipeline (DATA)	Workflow (ORCH)
Rôle	Transformer des données	Orchestrer des exécutions
Ce qui circule	Des DataFrames	Des signaux de déclenchement
Point d'entrée	Une source (Source fichier, Source base de données…)	Une brick Déclencheur
Palette	Sources, transformations, chargeurs	Déclencheurs, contrôle de flux, actions

Un workflow ne lit pas de données lui-même : il pilote des pipelines de données via la brick Exécuter un pipeline.

Où vivent les workflows

Les workflows appartiennent au projet, comme les pipelines. On les retrouve :

• dans l'onglet Workflows d'un projet (/projets/<projet>/workflows), avec recherche, tri et filtres par type de déclencheur (Cron, Webhook, Manuel) ;
• dans le Studio, sur une copie de travail, où ils s'éditent (Nouveau workflow crée un workflow vide) ;
• dans le sous-onglet Workflows d'un environnement (/projets/<projet>/environnements/<env>/workflows), la vue opérationnelle : déclencheurs, activation, « Lancer maintenant ».

Lecture seule côté projet société

Comme les pipelines, les workflows d'un projet société ne s'éditent pas directement : passez par une copie de travail dans le Studio.

Déclarer ici, planifier par environnement

C'est le point clé du modèle. La brick Déclencheur, placée en entrée du workflow, déclare ses déclencheurs : une liste d'entrées nommées, chacune avec une clé stable et un type (manuel, cron ou webhook). Cette déclaration est versionnée avec le workflow : elle voyage dans les commits et les releases.

En revanche, aucune valeur de planification n'est saisie dans l'éditeur. Le runtime de chaque déclencheur (expression cron, secret webhook, activation, runner cible) se configure par environnement, dans le sous-onglet Workflows de l'environnement. Ainsi :

• le même workflow peut tourner toutes les heures en dev et une fois par nuit en prod ;
• un déclencheur peut être actif en prod et désactivé en dev ;
• la clé stable fait que la configuration d'un environnement survit aux montées de version du workflow.

Voir Configurer les déclencheurs.

Le cycle de vie d'un workflow

1. Éditer le workflow dans le Studio (copie de travail) et déclarer ses déclencheurs dans la brick Déclencheur ;
2. Commit puis push : les changements deviennent une release du projet (voir Studio : copies de travail) ;
3. Déployer la release sur un environnement (voir Environnements et déploiement) ;
4. Configurer et activer les déclencheurs de l'environnement : le workflow s'exécute alors sur le runner de l'environnement.

Suivre les exécutions

Chaque déclenchement produit une exécution, visible dans le monitoring, y compris les exécutions des sous-pipelines lancés par le workflow.

Et ensuite ?

• Configurer les déclencheurs : cron, webhook, manuel, par environnement.
• Orchestrer des pipelines : sous-pipelines, conditions, boucles, erreurs.
• Référence des composants d'orchestration : tous les paramètres.