Cycle de vie d'un workflow

Un workflow est un objet versionné : une identité stable qui possède une série de versions numérotées, chacune traversant les trois mêmes états. Une version publiée ne change jamais — évoluer, c'est toujours publier une nouvelle version. Tout le reste de cette page découle de cette règle.

Trois états, deux transitions

Les deux seules transitions légales sont Draft → Published et Published → Archived. Il n'y a pas de retour en arrière : vous ne pouvez ni dé-publier, ni désarchiver.

Delete (« Supprimer ») n'existe que pour les drafts, et c'est définitif. Une version publiée ne peut jamais être supprimée — si vous voulez l'écarter, vous l'archivez.

Les versions

Les numéros de version montent — 1, 2, 3 — et ne sont jamais réutilisés ni remis en arrière. Pour faire évoluer un workflow publié, vous ouvrez un nouveau draft ; sa publication crée la version suivante.

Plusieurs versions publiées du même workflow peuvent coexister, et chacune reste exécutable. En exécuter une est toujours un choix de version explicite : rien ne substitue silencieusement « la dernière » à la version que vous avez demandée. (Les triggers sont le seul endroit où une politique « dernière version » existe, et là encore c'est un choix que vous déclarez explicitement — voir plus bas.)

La validation se joue à la publication

Il n'y a pas d'étape Valider séparée dans l'éditeur : cliquer sur Publish (« Publier ») exécute les contrôles, et si quelque chose ne va pas, la publication refuse et signale tout d'un coup — erreurs de câblage, pins requis manquants, écritures sans gate en amont — dans une seule liste, pour corriger en une passe au lieu de resoumettre et découvrir le problème suivant. La liste est exhaustive : une fois vide, la publication passe. La liste de problèmes vit dans l'éditeur. Les agents peuvent exécuter les mêmes contrôles en véritable essai à blanc — sans tenter de publication, sans rien figer — via l'outil workflow_validate_draft.

La publication fige le graphe

Publish (« Publier ») valide une dernière fois, puis fige le draft. À partir de là, le graphe est immuable et scellé par un checksum ; chaque run enregistre exactement quel graphe figé il a exécuté — ce que vous avez relu est prouvablement ce qui a tourné.

Une seule chose vit hors du gel : le nom d'affichage. Renommer avec Rename (« Renommer ») touche toutes les versions du workflow et ne modifie jamais un graphe — un renommage est toujours sans risque, même sur des versions publiées.

Pour la mécanique complète du gel, voir le chapitre d'architecture sur les workflows.

Comment un workflow démarre

Un workflow n'exécute rien par lui-même ; chaque démarrage devient une mission. Trois portes :

• Attacher à la création de la mission. Vous créez une mission et choisissez un workflow comme plan. Les runs se déroulent ensuite sur cette mission — voir Runs, acceptation et changements.
• Invoke (« Invoquer »). Vous exécutez le workflow directement avec Invoke ; ARDS crée une nouvelle mission pour lui. Même boucle ensuite.
• Les triggers. Un planning, un webhook ou un événement de la plateforme démarre le workflow automatiquement. Vous les configurez depuis la liste des workflows : Manage triggers (« Gérer les déclencheurs ») ouvre le dialogue où vous choisissez Schedule (« Planification »), Webhook ou Event (« Événement ») et nommez le fournisseur et le modèle, obligatoires. Chaque trigger se lie soit à une version épinglée, soit à la dernière version publiée — vous le déclarez à la création du trigger — et nomme son modèle et son provider d'avance (il n'y a pas de repli silencieux). Un trigger ne contourne jamais un gate : un démarrage automatique s'arrête à chaque approbation où un démarrage manuel se serait arrêté.

Cloner

Cloner produit toujours un nouveau draft qui vous appartient — jamais une version publiée.

• Depuis un template. Les templates système se clonent en un draft éditable ; modifiez-le et publiez-le comme n'importe quel autre.
• Depuis une mission. « Sauvegarder ce run comme workflow. » Si la mission est elle-même née d'un workflow, le graphe source est re-drafté à l'identique. Si c'était une mission organique, décomposée par le planificateur, ARDS reconstruit un graphe à partir de ce qui a réellement tourné — et joint une liste de notes recensant chaque réparation faite en chemin, pour que vous puissiez juger la reconstruction avant de lui faire confiance.

Changer une référence de sous-workflow

Un workflow peut en embarquer un autre par référence (voir Anatomie d'un workflow). Vous pouvez re-lier cette référence — la pointer vers un autre workflow, ou une autre version — mais re-lier invalide toute ratification de gate donnée sur l'ancienne cible. Rien ne se reporte silencieusement : le draft re-lié repasse par votre approbation avant de pouvoir être publié.

Archiver

Archive (« Archiver ») retire une version publiée pour de bon. Elle cesse d'être exécutable, mais elle est conservée pour toujours : les runs passés pointent encore vers elle, et la provenance ne s'évapore jamais.

Un garde-fou : vous ne pouvez pas archiver une version tant qu'un workflow parent publié la référence encore comme sous-workflow. Re-liez ou archivez d'abord le parent. Et comme l'archivage est terminal, le « retour » passe toujours par l'avant — publiez une nouvelle version.