Human in the Loop

Le bloc Human in the Loop met en pause un workflow en cours et attend qu'une personne prenne une décision. Le relecteur voit la sortie du workflow jusqu'ici, puis approuve (le workflow reprend) ou rejette (le workflow s'arrête). Utilisez-le pour les validations, les approbations, et toute étape où un humain doit décider avant que l'automatisation continue.

Quand l'utiliser

• Approbations — un remboursement, un contrat, une étape de publication qui exige une validation.
• Contrôles qualité — une personne vérifie un brouillon généré par l'IA avant son envoi.
• Conformité — une décision humaine requise est enregistrée avant que le processus continue.

Ce que l'auteur configure

Choisir les relecteurs à l'exécution

Parfois, les bons relecteurs ne sont connus qu'au moment de l'exécution : les experts de la juridiction de ce contrat, ou les responsables du système concerné. Calculez la liste dans un bloc précédent (un bloc Function, un Agent, un appel d'API) et transmettez-la au bloc Humain dans la boucle :

1. Déclarez le vivier comme d'habitude : Specific Approvers, ou un Reviewer Role (admin ou member). C'est l'ensemble le plus large de personnes pouvant examiner cette étape.
2. Activez Narrow reviewers at runtime.
3. Renseignez Runtime reviewer selection avec la sortie en amont, par exemple <pick_reviewers.result>. La valeur doit être une liste d'identifiants d'utilisateurs, comme ["user_123", "user_456"].

Lorsque le bloc se met en pause, seules les personnes sélectionnées sont notifiées, et elles seules peuvent le résoudre.

La sélection peut uniquement restreindre le vivier. Le bloc échoue avec une erreur explicite, et personne n'est notifié, lorsque :

• un utilisateur sélectionné ne fait pas partie du vivier déclaré. Une valeur fournie à l'exécution ne peut jamais ajouter un approbateur que le modèle n'a pas déclaré ;
• la sélection désigne l'utilisateur de l'exécution elle-même ou l'utilisateur qui a démarré l'instance de processus. Une exécution ne peut pas se choisir elle-même comme approbateur ;
• un utilisateur sélectionné n'est pas membre de l'organisation ;
• la sélection est vide ou mal formée : une référence non résolue, un identifiant seul au lieu d'une liste, un objet, ou plus de 50 identifiants. Il n'y a aucun repli sur l'ensemble du vivier ; corrigez plutôt le bloc en amont.

Si l'appartenance à l'organisation ne peut pas être vérifiée à ce moment-là, la mise en pause est réessayée au lieu d'échouer.

Approvals required est plafonné au nombre de personnes réellement sélectionnées : un point de contrôle qui demande trois validations et reçoit deux relecteurs se libère dès que les deux ont approuvé. Il ne reste jamais bloqué.

Chaque sélection et chaque refus sont enregistrés dans le journal d'audit de l'organisation (workflow.hitl.reviewers_selected et workflow.hitl.reviewer_selection_refused). Chaque entrée indique le vivier, les relecteurs choisis et les identités de l'exécution qui ont été exclues. Si la sélection ne peut pas être enregistrée, le bloc ne se met pas en pause.

Ce que voit le relecteur

Lorsqu'un relecteur ouvre un workflow en pause, le panneau de revue affiche, dans l'ordre :

Approuver ou rejeter

• Approuver / Reprendre — le workflow continue là où il s'était arrêté. Les valeurs du formulaire de reprise sont transmises aux blocs en aval.
• Rejeter — la porte refuse. Lorsque le refus tranche la porte (voir ci-dessous), le workflow s'arrête et ne peut pas être poursuivi : le statut devient Rejected et le workflow ne reprendra pas. Vous pouvez ajouter une raison facultative, enregistrée avec la décision.

Quand un seul rejet arrête-t-il le workflow ?

Cela dépend de la règle d'approbation, et la réponse est la lecture littérale de la règle choisie :

Une porte à quorum se ferme aussi lorsque les approbations nécessaires ne peuvent plus arriver. Avec 2 sur 3 requis et deux relecteurs qui rejettent, une approbation est le maximum possible — la porte se résout donc comme rejetée à ce moment-là, plutôt que d'attendre une troisième réponse qui ne peut pas changer le résultat. Le relecteur qui n'avait pas répondu est informé que la revue est close, exactement comme lorsqu'un quorum est atteint tôt.

Options de décision

Approuver / Rejeter répond à une question fermée. Beaucoup de décisions n'en sont pas une : go, no go ou reporter ; une gravité faible, moyenne ou élevée. Decision Options vous permet de déclarer les choix, et chacun dit comment la porte doit le compter :

Chaque option est une ligne à trois colonnes :

Déclarez au moins deux options — une seule option n'est pas un choix. Il n'y a pas de pondération : le vote de chaque relecteur compte une fois. Déployer un workflow avec une option invalide (une seule option, une valeur incorrecte, une issue inconnue, un doublon) échoue avec un message qui nomme l'option ; un bulletin sans option approve est permis mais signalé, car cette porte ne peut jamais être approuvée. Laissez le tableau vide pour garder Approuver / Rejeter.

Comment une décision à options est libérée

• Approvals required = 1 — le premier vote décide. Un vote other libère la porte avec le verdict undecided, et le workflow continue.
• Tous les approbateurs doivent approuver — un vote reject la tranche comme un refus, et un vote other la tranche comme undecided : dans les deux cas, tout le monde n'a pas approuvé.
• Un nombre défini doit approuver (2 ou plus) — seuls les votes approve comptent pour ce nombre. Lorsque suffisamment de votes reject et other sont arrivés pour que ce nombre ne puisse plus être atteint, la porte se ferme : comme rejetée si quelqu'un a choisi une option reject (le workflow s'arrête), sinon comme undecided (le workflow continue).

Aiguillez sur le résultat avec un bloc Condition ou Router : <gate.verdict> vaut approve, reject ou undecided, et <gate.aggregate.byOption.defer> est le nombre de relecteurs qui ont choisi Reporter — 0 si personne ne l'a fait.

Qui sont les relecteurs

Le Reviewer Role est toujours un rôle d'organisation, admin ou member. Il ne peut pas désigner une persona personnalisée d'un flux de processus. Une persona peut être assignée par le workflow en cours d'exécution lui-même : une porte relue par une persona laisserait donc le workflow choisir qui l'approuve. Une porte dont le rôle de relecteur est autre chose est refusée au build et à l'import de l'extension, au déploiement du workflow, et encore à l'exécution de la porte.

Hors d'un flux de processus, les relecteurs sont les membres de ce rôle d'organisation.

Dans un flux de processus, les relecteurs sont résolus dans cet ordre :

1. les personnes assignées à une persona du même nom (admin ou member) sur cette instance du flux de processus ;
2. sinon, les membres du rôle d'organisation lui-même.

Les administrateurs de l'organisation ne servent pas de repli ici. Les relecteurs sont les personnes autorisées à reprendre le workflow, ce qui est une autorité d'approbation, et seul un titulaire de la persona la donne. Si personne n'est résolu, la pause échoue avec une erreur de configuration au lieu d'attendre une liste de relecteurs vide. Assignez quelqu'un à la persona, puis relancez le workflow.

Quand un relecteur est vérifié

Un rôle de relecteur qui n'est pas un rôle d'organisation est refusé avant l'ouverture de la porte. La vérification s'exécute à chacun de ces moments :

Un rôle d'organisation est uniquement admin ou member. L'ancien rôle owner ne correspond à personne.

Ouvrir une revue

Les relecteurs reçoivent une notification lorsqu'un workflow se met en pause. Ouvrir la notification vous amène directement au workflow avec le panneau de revue ouvert, où vous pouvez lire le contexte et décider.

Plusieurs relecteurs

Avec All must approve ou Quorum, le workflow reste en pause jusqu'à ce que suffisamment de relecteurs aient répondu. L'avis IA est généré une fois par pause et partagé entre tous les relecteurs — tout le monde voit la même synthèse.

Seuls les relecteurs de la porte comptent pour son seuil. Une personne ayant accès en modification au workflow sans être relecteur — typiquement son propriétaire — peut tout de même répondre ; sa réponse est conservée dans responses, mais elle ne compte pas parmi celles des relecteurs : elle ne vaut pas approbation, n'occupe pas la place d'un relecteur dans un quorum et ne clôt pas à elle seule une porte All must approve. Avec une validation unique (First claim, ou Approvals required = 1), toute réponse autorisée tranche, comme avant.

Quand un quorum se ferme tôt

Une porte Quorum se libère dès que le nombre requis de relecteurs a répondu — c'est tout son intérêt. Les relecteurs qui n'avaient pas encore répondu sont notifiés que la revue est close, pour que personne ne le découvre en essayant de soumettre.

Si une réponse arrive après la fermeture de la porte, elle est enregistrée, pas écartée. Le relecteur est informé que la revue était déjà close et que sa réponse n'a pas changé l'issue, et la réponse est conservée dans l'enregistrement de l'exécution en pause, à côté des réponses qui ont compté. Les réponses tardives ne modifient jamais la décision libérée et ne relancent jamais le workflow.

Ce que les blocs en aval peuvent lire

Chaque porte libérée porte les mêmes sorties, quelle que soit la règle d'approbation :

responses et aggregate n'apparaissaient auparavant que lorsque plus d'une validation était requise, donc un design à plusieurs relecteurs réglé sur Approvals required = 1 ne gardait que la première réponse et perdait silencieusement les autres. Ils sont désormais toujours présents.

Noms de champs réservés dans le formulaire de reprise

Ces noms appartiennent à la sortie du bloc et sont écrasés à l'exécution, donc un champ du formulaire de reprise ne doit pas les utiliser :

approved · decision · reason · verdict · responses · aggregate · submission · response · url · option