L'éditeur visuel

Un pipeline betool est un graphe de nœuds que vous assemblez dans l'éditeur visuel. Chaque type de nœud déclare côté serveur sa configuration et les clés qu'il produit ; l'éditeur valide le graphe et la configuration avant de le laisser publier.

Anatomie d'un pipeline

[Start]──▶[agent]──▶[router]──┬──▶[agent]
                              └──▶[webhook_action]

• Le nœud Start est créé automatiquement avec le modèle ; il porte les récepteurs (canaux d'entrée) qui déclenchent le pipeline. Un même Start peut en déclarer plusieurs.
• Chaque nœud aval lit les clés produites par les nœuds amont dans le contexte d'exécution.
• Un routeur ou des filtres créent des branches ; chaque exécution laisse une trace consultable.

Concepts essentiels

Clé de flux

Une clé est une donnée nommée qui circule entre les nœuds. Exemple : un nœud agent peut écrire sa sortie sous exchange.intent, et un nœud aval (filtre, routeur) teste cette clé.

Ce qu'un nœud produit est déclaré par son contrat, sous deux formes :

• Clé fixe (fixed_key) — toujours la même, définie par le type de nœud (ex. input.entry_kind pour le Start).
• Clé configurable (configurable_key) — choisie dans la configuration du nœud (ex. la clé de sortie d'un agent).

Ce qu'un nœud lit se règle dans sa configuration (le champ testé par un filtre, les entrées d'un agent…).

Contrat

Chaque type de nœud expose un contrat déclaré côté serveur : ses champs de configuration (type, valeurs autorisées, champs requis, valeurs par défaut) et les clés qu'il produit. L'éditeur s'appuie sur ce contrat pour construire le panneau de configuration et valider ce que vous saisissez.

Configuration

Un nœud a aussi des paramètres statiques (sa configuration) — par exemple, pour un nœud agent : son rôle, sa mission, ses tools, son modèle LLM.

Créer un pipeline

1. Modèles → Nouveau — dans betool, un modèle porte votre pipeline.
2. Le canvas s'ouvre avec un nœud Start. Configurez-le pour choisir le ou les canaux d'entrée.
3. Ajoutez des nœuds avec le bouton Ajouter un nœud au survol d'un lien, ou par clic droit sur un nœud (Ajouter un nœud avant / après), puis choisissez leur type dans le catalogue de modules (recherche par nom).
4. Reliez les nœuds entre eux. Le pipeline est un arbre : chaque nœud a un seul parent.
5. Cliquez sur un nœud pour ouvrir sa configuration dans l'inspecteur.
6. Lancer un test — exécutez la version publiée sur un payload saisi librement, en mode réel ou en mode simulation (les nœuds à effet externe sont sautés).
7. Publier — un message de commit est obligatoire ; le pipeline est validé, puis la nouvelle version devient celle exécutée par le runtime.

Versionnage

Chaque publication crée une version. Depuis Versions, vous pouvez :

• Comparer une version à l'état courant (nœuds et liens ajoutés, retirés, modifiés).
• Recharger une version dans l'éditeur (le brouillon est réécrit, sans publier).
• Republier une version antérieure (rollback).

Depuis l'historique, une exécution passée issue d'un récepteur peut aussi être rejouée sur la version publiée, avec un payload éventuellement modifié et en mode simulation si besoin.

Validation

À la publication, un validateur contrôle le graphe :

• Bloquant — cycle dans le graphe ; nœud avec plusieurs parents ; sortie obligatoire non câblée (le corps d'une boucle foreach, les enfants d'un parallel, chaque route déclarée d'un router) ; nombre de Start incorrect ; erreurs propres à un type de nœud (ex. rôle ou mission d'agent inexistant).
• Avertissement (non bloquant) — nœud non atteignable depuis le Start ; écart d'une configuration existante avec le contrat de son nœud.

Lors de l'écriture d'une configuration (éditeur, propositions, API), une valeur hors des valeurs autorisées ou un champ requis manquant sont refusés, avec la correction attendue.

Conséquence : un pipeline publié a passé ces contrôles structurels. Les erreurs restantes relèvent de l'exécution (un appel API tiers qui échoue, un parsing inattendu).