Anatomie d'un workflow
Un workflow est un graphe lisible d'un coup d'œil : des boîtes qui font chacune une chose, des fils qui les relient. Cette page nomme les pièces — exactement à la profondeur qui change ce que vous faites sur le canvas. Si vous n'en avez pas encore construit, commencez par Créer votre premier workflow, puis revenez.
L'ordre d'exécution vient de l'épine dorsale Exec. Tout le reste de cette page découle de ce fait.
Le graphe
Chaque node est une étape : lire un fichier, appeler un modèle, attendre votre approbation, écrire un résultat. Chaque node porte deux pins d'exécution, in et out. Enchaînez out vers in et vous obtenez l'épine dorsale Exec — le fil qu'un run suit du premier node au dernier. Quand vous vous demandez « qu'est-ce qui tourne ensuite ? », suivez l'épine dorsale, pas la mise en page.
La palette propose 138 types de nodes répartis en 17 catégories — voir La palette de nodes pour l'index complet. Les constructions de contrôle — gates, branches, boucles, fan-out — sont des tuiles structurelles qui ont leur propre page : Flux de contrôle.
Les pins transportent des données typées
Autour des pins d'exécution, les nodes portent des pins de données. Chaque pin a un kind, et les fils ne relient que des kinds compatibles — l'éditeur ne vous laissera pas brancher un String dans un Bool.
Six kinds sont en usage :
| Kind | Sens |
|---|---|
Exec | Rien — uniquement l'ordre d'exécution. |
Context | Le contexte de travail de la mission, consommé par les nodes génératifs. |
String | Du texte brut. |
Bool | Vrai ou faux. |
Json | Des données structurées — le cheval de trait. |
Artifact | Un livrable produit (la sortie d'un coder, un rapport compilé), passé par référence. |
Une convention à connaître : 125 des 138 types de nodes exposent un pin de sortie result de kind Json qui porte l'issue du node. Câblez-le vers l'étape suivante quand vous en avez besoin ; le laisser non câblé est parfaitement valide.
Les trois primitives génératives
Exactement trois primitives génératives appellent un modèle pour produire du nouveau :
- llm — un tour borné : entrée, réponse, terminé. Il n'a aucun outil, donc il ne peut que répondre — il ne peut toucher ni votre workspace ni quoi que ce soit d'autre.
- agent — une boucle multi-tours avec un jeu d'outils explicite et un budget obligatoire. Plusieurs flows intégrés
sys-s'appuient désormais dessus — le flow d'onboarding par aspects en dépêche à lui seul dix. Pour vos propres graphes, llm ou coder reste le premier réflexe le plus simple. - coder — une session de code complète dans son propre conteneur, travaillant dans un workspace qui n'existe que le temps du run.
Sur la palette, ces trois primitives correspondent à plus de trois tuiles : le coder existe en tuile synchrone et asynchrone, et les sites d'appel de modèle à saveur métier — décomposition de mission, review — sont des configurations d'un site, jamais de nouvelles primitives.
La règle qui les relie : les primitives proposent, les verbes engagent. Un node génératif n'écrit jamais rien de durable par lui-même. Les écritures passent par des nodes d'action séparés, et chaque chemin vers une écriture traverse une gate — rien de ce qu'un modèle produit n'atterrit sans un point de décision devant.
Les outcome arms
La plupart des nodes ont un seul pin out : ils réussissent et continuent, ou ils échouent. Un node fait exception. Le coder asynchrone se termine de l'une de trois façons — Success, Failure ou Refusal — et chacune est son propre pin d'exécution, un outcome arm (« bras d'issue ») : onSuccess, onFailure, onRefusal. Vous câblez chaque arm vers ce qui doit se passer dans ce cas-là.
Une règle change votre façon de dessiner : les arms ne reconvergent jamais. Les chemins en aval de deux arms restent séparés ; le validateur rejette un câblage qui les refusionne.
En pratique, câblez chaque arm vers une étape explicite — chaque template intégré qui utilise le coder asynchrone route les trois.
Deux nodes portent aujourd'hui des outcome arms — le coder asynchrone et service:mission:integrate ; vous ne rencontrerez pas d'arms sur d'autres tuiles.
Les sous-workflows
Un workflow peut embarquer un autre workflow publié comme un seul node — une tuile FlowRef. Sur le canvas, c'est une seule boîte. Le workflow enfant décide quelles entrées et sorties exposer ; cette petite surface de pins est sa tunnel signature, et vous la câblez comme les pins de n'importe quel autre node.
Un sous-workflow partage le run de son parent et l'acceptation de son parent. C'est de la composition, pas un appel : pas de second run à accepter, pas de seconde branche à surveiller.
Les tuiles sys- de la palette — sys-research-codebase, sys-decompose-propose et consœurs — sont des blocs de construction publiés, conçus exactement pour ça. Voir Templates système.
Params et slots
Deux mécanismes gardent un graphe réutilisable. Les paramètres de run sont déclarés sur le workflow et liés à des valeurs au démarrage d'un run — même graphe, entrées différentes à chaque run.
Un slot est un trou typé que vous déclarez là où la génération a le droit de remplir de la structure. La génération remplit le trou et rien d'autre : elle ne réécrit jamais la topologie autour, et la structure que vous avez déjà posée reste intouchable.
Ce que la publication fige
Quand vous cliquez sur Publish (« Publier ») sur un brouillon, le graphe est figé : une version publiée est immuable et protégée par une somme de contrôle, et personne — ARDS compris — ne peut la modifier en douce. À l'exécution, chaque node reçoit aussi son propre instantané d'exécution figé : rejouer une étape ré-exécute exactement cet instantané au lieu de le renégocier.
Les conséquences au quotidien sont sur la page cycle de vie ; la mécanique complète est dans le chapitre architecture.