Le contrôle humain doit arrêter physiquement l’action
Ce que je ferais si l’IA rédigeait une proposition commerciale, appliquait une remise et l’envoyait au client. Je séparerais la préparation de l’exécution : le modèle propose, une personne confirme un payload précis.
L’erreur que j’éliminerais d’abord : Si l’approval vit dans un workflow long, un timeout ou un redémarrage peut perdre l’état. Il est plus fiable de séparer l’enregistrement de la proposition de la reprise après décision.
Quoi préparer et quel résultat attendre
- Résultat : L’équipe ne revoit que les cas à haut risque, et après une pause le workflow reprend au même point.
- Définissez les actions qui exigent une approval : envoyer, rembourser, supprimer, publier, changer des permissions et opérations financières.
- Conservez les données sources et les droits d’accès séparément du résultat pour pouvoir vérifier ce qu’a fait le workflow human-in-the-loop.
- Arrêtez le scénario à l’approval, rejetez l’action, approuvez-la quelques minutes plus tard et vérifiez le log.
Construire un flux d’approval vérifiable
- Séparer la proposition de l’action
L’IA crée un draft_action, le workflow le montre à une personne, et une étape Execute distincte ne s’exécute qu’après approve.
Проверьте: Le bouton approve ne change pas seulement le statut : c’est la condition d’exécution.
Если не сработало: Retirez l’outil d’écriture à l’IA et ne le laissez que dans la branche finale.
- Persister l’état
Enregistrez run_id, action, payload, requester, approver, status et expires_at. Pour une approval complexe, utilisez un nœud Wait ou un webhook resume.
Проверьте: Après une pause, vous pouvez continuer le même run_id.
Если не сработало: Découpez le workflow en start et resume au lieu de garder un long processus en mémoire.
- Montrer le contexte à une personne
La carte d’approval doit inclure la demande d’origine, les données trouvées, la proposition de l’IA, le risque et les boutons approve/reject/ask_more.
Проверьте: On peut décider sans chercher dans cinq systèmes.
Если не сработало: Réduisez l’écran aux données qui changent la décision.
- Gérer le rejet et le timeout
Reject envoie la tâche à l’owner ou renvoie le brouillon pour édition. Un expires_at expiré ne doit pas auto-exécuter l’action.
Проверьте: Une demande rejetée n’atteint jamais le client et reste visible dans le log.
Если не сработало: Ajoutez une liste quotidienne des approvals bloquées.
Les états que je mettrais en place
Machine d’états minimale : received → drafted → waiting_approval → approved/rejected → executed → failed. Stockez sur l’enregistrement input_snapshot, proposed_action, reviewer_id, reviewed_at, rejection_reason et execution_id. Après approved, le workflow revérifie que l’entrée n’est pas obsolète.
Pour un e-mail ou un changement CRM, séparez en deux opérations : la première enregistre le brouillon et envoie un bouton de confirmation ; la seconde exécute via approval_id. Ainsi le processus survit à un redémarrage et ne renvoie pas.
- Reject doit expliquer la raison, pas seulement effacer le statut.
- Si la confiance est faible, mettez review_required plutôt qu’une boucle de clarification sans fin.
Ce qui doit figurer sur l’écran d’approval
Montrez le texte source, le résultat proposé, les champs qui changeront, un lien vers la source, le risque et les boutons approve/reject. Si une personne ne comprend pas la décision en une minute, l’écran est surchargé ou l’IA a apporté trop peu de contexte.
Deux chaînes plutôt qu’un workflow bloqué
Workflow A : `Trigger → Get context → AI draft → Validate → proposal_id → action_hash → Save approval → Slack/Gmail`. Workflow B : `Approval webhook → Verify approver → Get proposal → Compare action_hash → Check expiry → Execute once → Audit log`.
États : `pending → approved/rejected/edited → executed/failed/expired`. Sur l’enregistrement, stockez `proposal_id`, `target_id`, `payload`, `action_hash`, `state_version`, `approver_role`, `expires_at`, `rejection_reason` et `execution_id`.
{
"action": "send_quote",
"target_id": "deal_456",
"payload": {"amount": 150000, "discount": 10},
"requires_approval": true,
"expires_at": "2026-08-05T12:00:00Z"
}Ce qu’une personne doit voir
Destinataire, montant, remise, champs qui changeront, aperçu du texte, source des données et heure d’expiration. Le bouton ne doit pas exécuter l’action directement depuis l’URL : il ne transmet que `proposal_id`, et le serveur revérifie le rôle, le hash et le statut `executed`.
Où une personne doit décider, et où une règle suffit
| Critère | Question | Bon signe |
|---|---|---|
| Entrée | Qu’est-ce qui entre exactement dans le workflow human-in-the-loop ? | Définissez les actions qui exigent une approval : envoyer, rembourser, supprimer, publier, changer des permissions et opérations financières. |
| Action | Que le système a-t-il le droit de faire seul ? | Uniquement des actions prélistées, sans accès à tout le compte |
| Vérification | Comment savoir que le résultat est acceptable ? | Arrêtez le scénario à l’approval, rejetez l’action, approuvez-la quelques minutes plus tard et vérifiez le log. |
| Échec | Où vont les cas peu clairs ? | Persistez l’état dans une table ou une base et fixez une échéance d’escalade pour qu’une approval bloquée ne se perde pas. |
Ce qui doit changer après la mise en place
L’équipe ne revoit que les cas à haut risque, et après une pause le workflow reprend au même point.
Pourquoi le « human in the loop » n’existe souvent qu’en mots
Traiter l’approval comme une instruction textuelle dans le prompt.
Ne pas stocker l’état entre le démarrage et la confirmation.
Ne montrer au personnel que le résultat sans la demande d’origine.
Exécuter automatiquement l’action après un timeout.
Quand l’approval a besoin d’un état séparé
Faites appel à un spécialiste si l’approval implique de l’argent, des actes juridiques, plusieurs rôles ou de longs processus avec beaucoup d’état.
Ce qui doit figurer sur l’écran de confirmation
À qui s’adresse cette approche de workflow human-in-the-loop ?
Dans un scénario d’IA human-in-the-loop, le contrôle humain n’est pas une ligne du prompt. Le système doit s’arrêter, enregistrer l’état, montrer l’entrée et la proposition de l’IA, attendre une décision, puis seulement exécuter l’action.
Par où commencer si tout est encore manuel ?
Définissez les actions qui exigent une approval : envoyer, rembourser, supprimer, publier, changer des permissions et opérations financières.
Comment vérifier que le setup ne vous nuira pas ?
Arrêtez le scénario à l’approval, rejetez l’action, approuvez-la quelques minutes plus tard et vérifiez le log.
Et si le résultat n’est pas clair ?
Persistez l’état dans une table ou une base et fixez une échéance d’escalade pour qu’une approval bloquée ne se perde pas.
