Créer votre premier workflow

Dans ce tutoriel, vous construisez un workflow de cinq nodes en partant de zéro, vous le publiez, puis vous l'exécutez sur une mission. Comptez une vingtaine de minutes ; le seul prérequis est Ce qu'est un workflow — en version courte : un workflow est un graphe d'étapes sauvegardé qui n'exécute rien par lui-même ; une mission le fait tourner, et vous en acceptez le résultat.

Ce que vous allez construire

Un petit pipeline créer-lire-relire-écrire, cinq nodes en ligne :

  1. Un node de création workspace ouvre un workspace propre au run et fournit son handle — chaque lecture et écriture ci-dessous a besoin de ce handle câblé.
  2. Un node de lecture workspace charge un fichier depuis ce workspace.
  3. Un node llm rédige une proposition d'amélioration, en un seul tour de modèle borné.
  4. Un gate met le run en pause pour que vous vérifiiez la proposition.
  5. Un node d'écriture workspace enregistre le texte approuvé.

Le gate est le cœur de l'exercice. Chaque chemin vers une écriture doit passer par un gate. Le validateur applique cette règle — un graphe où du contenu généré peut atteindre une écriture sans point de contrôle humain ne se publie pas.

Créer un brouillon

  1. Ouvrez la page Workflows et cliquez sur New Workflow (« Nouveau workflow »).
  2. Nommez-le — my-first-workflow convient très bien.
  3. L'éditeur s'ouvre : canvas vide, palette sur le côté.

Le brouillon est le seul état éditable, et un brouillon ne peut pas tourner. Rien de ce que vous faites ici n'exécute quoi que ce soit pour l'instant.

Placer et câbler les nodes

  1. Depuis la catégorie Workspace de la palette, ajoutez un node de création de workspace. Il produit le handle de workspace dont les nodes de lecture et d'écriture ont besoin.
  2. Depuis la même catégorie, ajoutez un node de lecture de fichier.
  3. Ajoutez un node llm. Dans son panneau, dites-lui quoi faire — par exemple : « Propose une amélioration concrète de ce fichier, en texte brut. »
  4. Depuis la section Structural (« Structurels ») de la palette, ajoutez une Approval Gate (« Porte d'approbation ») — glissez la tuile sur le canvas, ou cliquez dessus pour l'ajouter. Donnez-lui un libellé (« Relire la proposition ») et des instructions pour la personne qui décidera — c'est-à-dire vous, plus tard.
  5. Ajoutez un node d'écriture de fichier et donnez-lui un chemin cible.

Câblez maintenant le graphe :

  1. Connectez d'abord l'épine dorsale d'exécution : le pin out de chaque node vers le pin in du suivant — création → lecture → llm → gate → écriture. C'est elle qui fixe l'ordre d'exécution.
  2. Câblez le handle de workspace : la sortie workspace du node de création vers le pin workspace du node de lecture et du node d'écriture. Ces pins sont requis — laissez-en un non câblé et le graphe ne se publiera pas.
  3. Connectez les données : le result du node de lecture vers l'entrée du node llm, et le result du node llm vers le contenu du node d'écriture.

Notez où se trouve le gate : entre le modèle et l'écriture, pour que rien de ce que le modèle produit ne soit enregistré sans vous.

Publier — et lire la liste des problèmes

Cliquez sur Publish (« Publier »). Dans l'éditeur, publier est l'étape de validation — l'état vide du panneau Problems le dit lui-même : « Aucun problème. Publiez pour valider. » Le validateur vérifie tout le graphe, et si quelque chose ne va pas, la publication refuse et le panneau Problems signale tous les problèmes d'un coup — une liste exhaustive, pas une boucle corrige-et-réessaie. Entrées typiques d'un premier workflow : un pin requis non câblé, une écriture qu'aucun gate ne garde. Traitez la liste de haut en bas, puis publiez à nouveau ; la publication passe une fois la liste vide. (Les agents peuvent lancer la même vérification à la demande, sans tenter de publication, via l'outil workflow_validate_draft.)

Quand la publication réussit, le graphe se fige : la version 1 est désormais immuable, et chaque run de la version 1 — aujourd'hui ou l'an prochain — exécute exactement ce que vous venez de dessiner. Pour changer quoi que ce soit, vous éditez un nouveau brouillon et publiez une version 2. Détails dans le cycle de vie d'un workflow.

L'exécuter sur une mission

Un workflow n'exécute rien par lui-même : donnez-lui donc une mission.

  1. Ouvrez le tableau de bord Missions et créez une mission.
  2. Le dialogue de création propose un sélecteur de workflow, réglé par défaut sur (New empty workflow) (« (Nouveau workflow vide) »). Choisissez my-first-workflow à la place.
  3. Depuis la page mission, démarrez un run.

mission attach workflow

L'autre sens fonctionne aussi : Invoke (« Lancer ») sur la page du workflow crée une nouvelle mission autour de lui.

Un prérequis : le run a besoin d'un modèle et d'un provider. Si ni le node, ni un preset, ni les défauts configurés de votre tenant n'en désignent un, le run refuse de démarrer.

Le gate se met en pause pour vous

Quand le run atteint votre gate, il s'arrête. Aucun minuteur ne le fait passer outre, et aucun gate ne s'approuve jamais lui-même — l'auto-résolution n'existe que comme opt-in explicite, gate par gate, et vous n'avez pas activé celui-ci.

La pause arrive sous forme de carte dans votre file de Decisions, portant le libellé et les instructions que vous avez écrits, plus la proposition du node llm, figée exactement telle que le run la voit. Lisez la proposition, puis cliquez sur Approve (« Approuver »). Le run reprend et l'écriture s'exécute — dans le workspace isolé du run, pas sur votre dépôt. (Les gates savent aussi capturer des réponses typées, proposer des décisions nommées et expirer — voir les gates.)

Accepter le run

Quand le run se termine, il apparaît sur la page mission en Proposed : travail fait, rien d'atterri. Vous avez deux issues :

  • Accept run (« Accepter le run ») — la fusion est validée mécaniquement avant que quoi que ce soit n'atterrisse ; si le système ne peut pas la vérifier, l'acceptation refuse plutôt que de croire qui que ce soit sur parole. En cas de succès, le run devient un changement sur la branche de la mission.
  • Ne pas l'accepter — rien n'a atterri, donc rien à défaire. Il n'y a pas de bouton pour décliner : vous pouvez simplement laisser la proposition là où elle est, et les agents peuvent l'écarter explicitement avec l'outil mission_run_discard. (L'autre bouton du tableau, Close-out…, relève de l'acceptation — il ouvre la checklist des reliquats qui déverrouille Accept run.)

Voilà la boucle complète : le gate a gardé l'écriture à l'intérieur du run, et l'acceptation a gardé votre mission. Runs, acceptation et changements détaille ce que fait vraiment l'acceptation.

Et ensuite