Actions utilisateur
Une action utilisateur est un node de processus qui attend une interaction humaine structurée : saisir une information, confirmer une lecture, choisir une option ou accomplir une étape dans une expérience dédiée. Le node définit le contrat d’orchestration ; le parcours utilisateur est l’une des surfaces capables de présenter cette interaction.
Un point d’attente explicite dans le processus
Le node crée ou réutilise une action en attente. La réponse de l’utilisateur complète cette action, produit les sorties du node et permet au processus de continuer.
Lorsqu’un node a réellement besoin d’une interaction, Ormuz matérialise une
process_user_action rattachée à l’instance et au node courant. Tant que cette action reste
pending, l’instance attend sa résolution au lieu de considérer le node comme terminé.
Si la même étape est réévaluée alors qu’une action pending existe déjà pour ce node et cette
instance, Ormuz réutilise cette action au lieu d’en créer une seconde. Les nodes hybrides peuvent aussi se
terminer immédiatement lorsqu’aucune interaction n’est nécessaire ; dans ce cas, aucune attente durable
n’est imposée au participant.
Le node appartient à la définition du processus. La process_user_action est le fait observable
créé pendant une instance. Le parcours utilisateur est une interface capable de présenter l’action au
participant. Ne confondez pas ces trois niveaux.
Cycle de vie d’une action
| État | Signification |
|---|---|
pending | L’interaction est encore ouverte. C’est le seul état dans lequel une réponse peut être soumise. |
completed | La réponse a été validée et enregistrée ; les sorties du node sont disponibles pour la continuation du processus. |
cancelled | L’action a été interrompue sans réponse utilisable, par exemple parce que l’interaction a échoué ou parce que l’instance a été arrêtée. Cet état ne signifie donc pas, à lui seul, que l’instance est en échec. |
La complétion d’une action émet process.user_action.completed. Une annulation ne doit pas être
interprétée comme une décision utilisateur : elle indique seulement que cette interaction ne peut plus être
complétée dans son état courant.
Actions Core
Ormuz propose actuellement 16 actions utilisateur. Cette page les regroupe par intention ; leurs paramètres, sorties et routes exacts restent documentés dans les fiches de nodes.
Collecter des informations
Saisies simples ou formulaires dont la réponse devient une sortie typée du node.
Obtenir une décision
Interactions qui produisent directement une route du graphe à partir du choix du participant.
Présenter une information
Étapes de lecture ou d’acquittement qui n’inventent pas une décision métier supplémentaire.
Vérifier ou poursuivre ailleurs
Interactions de vérification ou de navigation dont le résultat reste observable par le processus.
Une extension peut fournir un node d’action spécialisé — paiement, signature, KYC, vérification bancaire, etc. La page Orchestration reste volontairement générique : consultez la fiche du node dans Intégrations pour le contrat propre au provider.
Les actions routeuses n’ont pas besoin d’un gateway séparé pour exprimer leur décision. Par exemple,
collect_choice produit directement les routes correspondant à ses choix, et
accept_terms expose les routes
accepted / refused.
Formulaire persistant ou formulaire dynamique ?
| Besoin | Node | Contrat de sortie |
|---|---|---|
| Réutiliser un schéma de formulaire connu à la conception | custom_form | form_id, values |
| Construire les questions pendant l’exécution | dynamic_form | values |
custom_form référence une ressource Form réutilisable. dynamic_form reçoit au runtime
une common.form_spec puis fige cette spécification dans l’action : la soumission est validée contre
le snapshot réellement présenté au participant. Le formulaire dynamique ne crée pas une ressource Form
temporaire et ne réémet pas sa spécification dans ses outputs.
Données collectées et protection
Les valeurs soumises par une action conservent la classification issue de leur contrat et de leurs sources.
Une donnée sensitive ou secret reste donc protégée lorsqu’elle devient une sortie du
node ou qu’elle est câblée vers les étapes suivantes.
Les surfaces d’observabilité masquent les valeurs protégées par défaut. Cela n’empêche pas un node aval de les utiliser lorsque le processus les lui transmet explicitement et que son autorité le permet.
Voir Protection des données dans les processus pour les règles de propagation, de downgrade et de reveal ciblé.
Parcours utilisateur
Le parcours utilisateur d’Ormuz peut présenter l’action actuellement destinée au participant, collecter sa réponse et poursuivre le parcours sans frontend spécifique. Elle n’expose que les données nécessaires à l’interaction autorisée.
La Console expose ces actions pour l’observabilité et permet d’ouvrir le parcours utilisateur du participant,
mais elle ne complète pas elle-même l’interaction. L’API publique process-user-actions reste une
surface de lecture : la réponse du participant passe par le parcours utilisateur afin de conserver le même
contrat de présentation, de validation et d’accès participant pour tous les types d’action.
Une interaction peut confirmer que l’utilisateur a vu un écran, choisi une option ou été redirigé. Elle ne prouve pas qu’un paiement, une signature ou une opération réalisée dans un système externe a effectivement abouti. Utilisez le contrat provider ou l’événement métier correspondant pour cette garantie.
Approbation humaine ≠ action utilisateur
Une approbation interne utilise le modèle canonique
approval_request et ses
approval_assignment. Elle peut suspendre un processus comme une action utilisateur, mais elle
représente une décision agrégée d’approbateurs désignés, pas une interaction du participant courant dans son
parcours hébergé.
Conservez donc ces modèles séparés : action utilisateur pour l’interaction du participant ; demande d’approbation pour une décision humaine interne avec politique d’agrégation, échéance et approbateurs propres.
Reprise du processus
Quand une action pending est complétée, sa sortie devient la sortie du node correspondant et le
processus poursuit le graphe depuis cette étape. Les nodes déjà terminés avant l’attente ne sont pas rejoués
simplement parce qu’une réponse utilisateur arrive.
Pour une action routeuse, la route sélectionnée fait partie du résultat du node lui-même. Les branches non retenues restent non exécutées, avec les mêmes conséquences de binding que pour les autres routeurs. Voir Routage et décisions.