Human in the loop: designer la supervision des agents IA

HITL: supervision, pas build

Le human in the loop consiste à décider où l'humain reste dans la boucle d'un système automatisé. La partie build (le flux, les outils, les KPI métier) est traitée dans comment créer un agent IA. Ici, on parle des files de validation, des seuils, de la charge mentale et de la capitalisation.

Trois intentions se mélangent souvent: la sécurité (bloquer une action dangereuse), la qualité avant un envoi client, et l'apprentissage (produire des labels pour améliorer le système). Si tu ne les sépares pas, tu finis par tout sur-valider ou par laisser passer le risque.

L’autonomie se règle par type d’action : suggestion, brouillon à valider ou exécution sur un périmètre défini. Le niveau acceptable dépend des erreurs observées et de leurs conséquences. Il n’existe pas de pourcentage d’autonomie universel à viser.

Sans la troisième brique (le contrôle), tu as juste un POC / une démo.

Où placer l'humain dans le flux

Place le HITL là où le coût d'erreur multiplié par sa probabilité est maximal. Un mail de relance standard porte un risque bas. Une modification de prix, un envoi juridique ou un client VIP portent un risque haut.

Cartographie ensuite chaque action avec son niveau de supervision:

La fatigue de revue peut conduire à valider sans lire. Réserve l’automatisation aux cas dont le risque est acceptable et conserve une validation obligatoire pour les actions sensibles. La file de revue doit montrer les changements, les sources et la raison de l’escalade.

La même logique vaut côté code: la revue IA accélère le premier passage, et l'humain garde l'ownership sur l'auth et le paiement (voir code review IA).

Seuils et politiques métier

Un score de confiance du modèle ne suffit pas. Combine-le avec des règles déterministes: un montant au-dessus d'un seuil, un client VIP, une langue non couverte, un document manquant, une PII détectée, un outil hors allowlist.

Calibre ces seuils sur un échantillon annoté de 50 à 200 cas, en mesurant la précision et le rappel de la classe verte. Un seuil trop bas sature la file; un seuil trop haut laisse passer des erreurs. Recalibre après chaque changement de prompt ou de modèle.

Écris la politique en langage simple, lisible hors de la tech: « L'agent peut envoyer seul les relances J+7 si le devis est sous 5 k€ et si le client n'est pas VIP. Sinon, validation commerciale. »

Versionne cette politique comme du code, avec la date, l'auteur, la raison et la métrique impactée.

Capitaliser les validations

Chaque acceptation, modification ou rejet est une donnée utile. Stocke l'entrée, la sortie de l'agent, l'action humaine, le commentaire et la durée de revue.

Ce journal sert ensuite à quatre choses:

• Alimenter des exemples few-shot corrigés
• Identifier les classes d'erreurs récurrentes
• Détecter les candidats à l'autonomie, ces cas toujours acceptés sans retouche
• Former les validateurs

Côté RGPD, minimise la PII dans les logs, fixe une durée de rétention et restreins l'accès. Le HITL n'excuse pas un lac de données non gouverné.

Mettre le HITL en place en 30 jours

Le déploiement tient en quatre semaines:

1. Cartographier les actions et classer les risques
2. Poser une UI de validation minimale et les logs
3. Calibrer les seuils sur un corpus réel
4. Suivre les métriques et élargir une première fois les cas verts

Trois rôles suffisent: un owner métier pour les règles, un owner tech pour les outils et les logs, et des validateurs formés avec une checklist courte.

La santé du HITL se lit sur le temps médian de revue, le pourcentage de cas verts, le pourcentage d'édits, les incidents post-action et la charge mentale. Si la charge explose, réduis le scope automatique.

Si vous voulez poser un HITL propre sur un process réel, on peut cadrer en 20-40 minutes.

Questions fréquentes