Proposition : Clarifier la separation Nodes / Actions dans les Routines

Date : 03/02/2026 (mis a jour) Status : REPORTEE AU BACKLOG

Constat

Les routines ont actuellement un node "fetch" qui reconfigure manuellement connecteur/instance/method/path, alors que l'utilisateur a deja des actions (SSH, API, fetch, transform) liees a des instances et testables independamment.

Le node "action" fait deja le lien vers une action existante, mais le node "fetch" fait doublon en mode decouple.

Principe retenu

Separation claire des responsabilites :

Nodes = logique d'orchestration (flux, conditions, boucles, transformations locales)
Actions = execution concrete (SSH, API, fetch, transform) via des instances configurees

Nodes conserves (orchestration)

Node	Role
trigger	Point d'entree (manual, cron, webhook, event)
action	Appeler une action existante (SSH, API, fetch, transform)
condition	Branchement if/else
loop	Boucle for_each / while
transform	Transformation de donnees entre etapes
variable	Stocker/modifier une variable
delay	Pause
output	Resultat final

Node supprime

Node	Raison
~~fetch~~	Doublon avec le node "action" qui reference deja des actions de type api/fetch/ssh

Le node "action" devient le point unique d'execution

L'utilisateur :

Cree ses actions (type ssh, api, fetch, transform) avec instance + config + tests
Les utilise dans ses routines via le node "action" avec un mapping d'inputs

Le node "action" dans le formulaire affiche :

Dropdown des actions existantes (groupees par type : SSH, API, Fetch, Transform)
Mapping des inputs avec expressions {{...}}
Apercu de l'action selectionnee (instance, type, description)

Perimetre technique

Frontend

Fichier	Modification
`NodeConfigForm.tsx`	Supprimer FetchForm. Enrichir ActionForm avec groupement par type et apercu
`routines/new/index.tsx`	Retirer 'fetch' de NODE_TYPES
`routines/[id]/edit/index.tsx`	Idem

Backend

Fichier	Modification
`routineExecutor.ts`	Garder le case 'fetch' pour compatibilite des routines existantes, mais ne plus le proposer a la creation

Migration des routines existantes

Les routines avec des nodes "fetch" continuent de fonctionner (le backend garde le support). Pas de migration forcee.

Avantages

1 seul concept pour "executer quelque chose" : l'action
Les actions sont testables individuellement avant d'etre utilisees dans une routine
Pas de duplication de config (instance, auth, methode)
Les actions de type transform sont aussi utilisables dans les routines
Plus simple a comprendre pour l'utilisateur

Questions ouvertes

Faut-il permettre de creer une action directement depuis l'editeur de routine ? (bouton "+" a cote du dropdown)
Faut-il afficher les derniers resultats de l'action selectionnee pour aider au mapping des inputs ?