Human in the Loop

Met un workflow en pause et transmet le contenu aux réviseurs assignés pour approbation avant de continuer

À quoi sert le node Human in the Loop ?#

Le node Human in the Loop met en pause l’exécution du workflow et transmet le contenu à un ou plusieurs réviseurs assignés pour décision avant de reprendre. Chaque réviseur reçoit une demande de revue (email + page de revue) où il lit le contenu et l’approuve ou le rejette. Le workflow ne reprend que lorsque la politique d’approbation configurée est satisfaite — et tout rejet arrête l’étape.

Utilisez-le comme point de contrôle manuel à n’importe quelle étape critique — pour relire du contenu généré par l’IA, valider des données ou approuver des actions avant qu’elles ne s’exécutent en aval.

Cas d’usage typiques :

• Relire des articles ou résumés générés par l’IA avant publication sur un CMS.
• Valider des données extraites avant écriture dans un système externe (CRM, base de données, tableur).
• Contrôler la qualité du contenu d’un email ou d’un message client avant envoi.
• Approuver des opérations sensibles ou irréversibles avant qu’elles ne s’exécutent.

Configuration rapide#

Suivez ces étapes pour ajouter et configurer le node Human in the Loop dans votre workflow :

Paramètres de configuration#

Champs requis#

Champs optionnels#

Modes d’approbation#

Le mode d’approbation détermine combien des réviseurs assignés doivent approuver. Un rejet est toujours une sortie anticipée — un seul rejet arrête l’étape immédiatement, dans tous les modes.

Mode	Réviseurs	Passe quand	Échoue quand
Any of	≥ 1	Le premier réviseur approuve	Le premier réviseur rejette
All of	≥ 2	Tous les réviseurs approuvent	Un réviseur rejette
Quorum (N of M)	≥ 3	N réviseurs approuvent	N approbations deviennent mathématiquement impossibles, ou un réviseur rejette

• Any of — la première décision l’emporte. Idéal pour « toute personne qualifiée peut valider ».
• All of — approbation unanime requise. Idéal pour une revue juridique ou une validation par les pairs.
• Quorum (N of M) — un nombre configurable doit approuver. Se résout dès que N approbations sont atteintes, ou échoue dès que N ne peut plus être atteint. Définissez N avec le champ Required approvals (N) (1 < N < M).

Lorsque la décision d’un réviseur résout l’étape, les autres demandes de revue en attente sont automatiquement clôturées comme « non nécessaires ».

Scoring#

Les scores permettent d’attacher au contenu des notes automatiques basées sur des règles, pour que les réviseurs aient un signal immédiat avant de décider. Chaque score que vous déclarez :

• ajoute un port d’entrée dédié sur le node (à relier à la valeur en amont à évaluer), et
• affiche une carte colorée (good / neutral / bad) sur la page de revue.

Chaque score a un type et jusqu’à trois bandes de règles, évaluées dans l’ordre good → neutral → bad (la première correspondance l’emporte) :

Type	Opérateurs	Bandes
number / percentage	gt, gte, lt, lte, eq, between	good · neutral · bad
string	equals, contains, starts_with, matches (regex), avec sensibilité à la casse optionnelle	good · neutral · bad
boolean	is	good · bad
enum	in, not_in (sur une liste de valeurs autorisées)	good · bad

• La bande good est requise ; neutral et bad sont optionnelles.
• Si une valeur est fournie mais qu’aucune bande déclarée ne correspond, la carte retombe sur bad — un builder qui a défini un seuil « good » attend que tout ce qui en sort soit lu comme un échec.
• Une valeur manquante, ou un score sans règle déclarée, s’affiche comme Unrated.

Les scores sont informatifs — ils guident le réviseur mais n’approuvent ni ne rejettent jamais d’eux-mêmes.

Revue par lot#

Lorsqu’un node Human in the Loop s’exécute dans un Loop, chaque itération crée une demande de revue distincte. Elles sont regroupées dans une page de revue par lot où un réviseur peut traiter efficacement de nombreux éléments :

• Preview — un résumé templatable d’une ligne affiché sous les scores sur chaque carte, pour qu’un réviseur identifie un élément sans l’ouvrir.
• Filters for batch review — des menus déroulants templatables (ex. par catégorie, auteur, statut) dont les options proviennent des valeurs distinctes résolues sur l’ensemble du lot.

Les deux utilisent des placeholders {{variable}}, et chaque variable référencée devient un port d’entrée supplémentaire sur le node.

Que produit le node en sortie ?#

Le node produit le contenu tel qu’approuvé par les réviseurs. Le workflow reste en pause jusqu’à ce que la politique d’approbation soit satisfaite, puis l’exécution continue avec ce contenu comme entrée du node suivant. Si l’étape est rejetée, la sortie ne circule pas et la branche s’arrête là — associez un Fail Node ou un Conditional pour gérer explicitement le rejet.

Comment utiliser la sortie#

Dans Draft & Goal, vous n’avez pas besoin de retrouver un nom de variable complexe généré par le système. Pour utiliser le résultat :

1. Tracez une connexion depuis le port Output du node Human in the Loop.
2. Reliez-la à l’entrée du node suivant.
3. Dans ce node suivant, créez et nommez votre propre variable (par exemple approved_content). La valeur relue y sera injectée automatiquement.

Ports d’entrée#

Le node a toujours un port statique Content. Il gagne des ports supplémentaires dynamiquement :

• un port par score déclaré, et
• un port par {{variable}} utilisée dans Message to reviewer, Preview ou Filters.

Exemples d’utilisation#

Exemple 1 : Approuver un article généré par l’IA avant publication sur Notion#

Assurez-vous qu’un article généré par un LLM est exact et fidèle à la marque avant qu’il n’arrive sur votre CMS.

Workflow :

1. Web Scraper — Récupère une page source utilisée comme matière première.
2. LLM — Génère un article structuré à partir de cette source.
3. Human in the Loop — Content relié à la sortie du LLM. Reviewers = votre responsable éditorial. Approval mode = Any of. Message to reviewer = “Review this article for factual accuracy, tone, and completeness before publishing to Notion”.
4. Notion Database Writer — Reçoit l’article approuvé et le publie.

Exemple 2 : Validation juridique unanime avant l’envoi d’un contrat#

Exigez que chaque réviseur approuve avant qu’un email automatisé ne quitte le système.

Workflow :

1. LLM — Rédige une clause de contrat à partir d’un modèle.
2. Human in the Loop — Content relié au brouillon. Reviewers = juridique + responsable de compte. Approval mode = All of. Un score de type boolean relié à un indicateur de conformité affiche une carte rouge/verte pour accélérer la revue.
3. Email Sender — N’envoie le contrat approuvé qu’après l’approbation des deux réviseurs.

Bonnes pratiques#

• Placez un node Human in the Loop juste avant toute action irréversible — envoi d’emails, écriture en base, publication sur un CMS, mise à jour d’un CRM. Un court contrôle humain coûte bien moins cher que le rollback d’une mauvaise écriture en production.
• Rédigez un message précis : nommez les champs, le ton et les faits exacts à vérifier au lieu de demander une « revue » générique.
• Ajoutez des scores pour tout ce qu’une règle peut pré-vérifier (longueur, présence d’un CTA, un booléen de conformité) afin que les réviseurs consacrent leur attention aux jugements, pas aux vérifications mécaniques.
• Adaptez le mode d’approbation au risque : Any of pour une validation de routine, All of pour les décisions unanimes, Quorum pour une revue équilibrée en comité.
• Ne vous incluez pas dans la liste des réviseurs sur les étapes que vous ne devriez pas pouvoir auto-approuver.

Problèmes courants#

Le workflow est bloqué sur le node Human in the Loop

Cause : Le node fait son travail — il met le workflow en pause jusqu’à ce que la politique d’approbation soit satisfaite. Il n’y a pas de timeout automatique (les rappels sont « coming soon » et pas encore actifs).

Solution : Ouvrez le panneau d’exécution du workflow et cherchez une demande de revue en attente sur ce node. Un réviseur doit l’ouvrir et l’approuver pour que le workflow reprenne. En mode All of, chaque réviseur doit agir ; en mode Quorum, N réviseurs doivent approuver.

Aucun réviseur ne peut être sélectionné / le champ est vide

Cause : Les réviseurs proviennent des utilisateurs de votre organisation. Si le sélecteur est vide, aucun utilisateur éligible n’existe encore dans l’org.

Solution : Invitez ou assignez au moins un utilisateur avec un rôle capable de relire dans User Management, puis rouvrez les paramètres du node.

Le réviseur ne sait pas quoi vérifier

Cause : Le message au réviseur est vide ou trop vague, il ne voit donc que le contenu brut sans critères d’acceptation.

Solution : Remplissez le message avec une instruction précise listant ce qu’il faut vérifier (champs, ton, faits, mise en forme). Référencez les valeurs en amont avec {{variable}} pour le rendre concret.

Aucun contenu n'atteint le réviseur

Cause : L’entrée Content n’est pas connectée, ou le node en amont a produit une sortie vide.

Solution : Vérifiez que le port Content est connecté au bon node en amont. Exécutez le node en amont seul pour confirmer qu’il produit une sortie non vide avant de reconnecter.

Le mode Quorum n'accepte pas ma valeur N

Cause : Le Quorum exige 1 < N < M. N = 1 est identique à Any of, et N = M est identique à All of, les deux sont donc rejetés. Le Quorum nécessite aussi au moins 3 réviseurs.

Solution : Ajoutez des réviseurs jusqu’à en avoir au moins 3, puis définissez N strictement entre 1 et le nombre de réviseurs.

Comment s’intègre-t-il dans un workflow ?#

Human in the Loop agit généralement comme une barrière d’approbation entre la génération de contenu et toute action irréversible en aval. Voici un schéma d’intégration typique pour du contenu généré par l’IA qui aboutit dans un système externe :

graph LR
    Source[Web Scraper / Source de données] --> LLM[LLM génère le contenu]
    LLM --> HITL[Human in the Loop
<br/>les réviseurs approuvent]
    HITL --> Publish[Notion / Email / CRM writer]

Nodes liés#