Human in the loop: designer la supervision des agents IA

HITL: supervision, pas build

Human in the loop, c'est décider où l'humain reste dans la boucle d'un système automatisé. Le build (flux, outils, KPI métier) est dans comment créer un agent IA. Ici: files, seuils, charge mentale, capitalisation.

Trois intentions se mélangent souvent: sécurité (bloquer une action dangereuse), qualité avant envoi client, apprentissage (labels pour améliorer le système). Si tu ne les sépares pas, tu sur-valides tout ou tu laisses passer le risque.

L'autonomie n'est pas un switch. C'est un curseur: de la suggestion pure à l'action auto sur un sous-ensemble strictement défini. Beaucoup d'agents métier sérieux tournent entre 20 et 60% d'autonomie effective sur le volume au début.

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

Où placer l'humain dans le flux

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

Cartographie chaque action: lire (souvent auto), brouillon (souvent auto), envoyer (HITL au début), écrire CRM (HITL puis auto sur cas verts), supprimer / payer / signer (HITL permanent ou interdit).

Le risque n°1 est la fatigue de revue. Si 100% des sorties demandent validation, l'équipe finit par tout cliquer sans lire. N'envoie en revue que les cas orange et rouge, avec un diff clair: ce qui a changé, sources, score.

Même logique côté code: la revue IA accélère le premier passage; l'humain garde l'ownership sur auth et 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: montant au-dessus d'un seuil, client VIP, langue non couverte, document manquant, PII détectée, outil hors allowlist.

Calibre sur un échantillon annoté (50 à 200 cas). Mesure précision et rappel de la classe vert. Trop bas: file saturée. Trop haut: erreurs qui passent. Recalibre après chaque changement de prompt ou de modèle.

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

Versionne la politique comme du code: date, auteur, raison, métrique impactée.

Capitaliser les validations

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

Exploite le journal pour few-shot corrigés, classes d'erreurs récurrentes, candidats à l'autonomie (cas toujours acceptés sans edit), formation des validateurs.

RGPD: minimiser la PII dans les logs, fixer une rétention, restreindre l'accès. Le HITL n'excuse pas un lac de données non gouverné.

Mettre le HITL en place en 30 jours

Semaine 1: cartographie des actions et classification du risque. Semaine 2: UI de validation minimale et logs. Semaine 3: calibration des seuils sur corpus réel. Semaine 4: métriques et premier élargissement des cas verts.

Rôles: owner métier (règles), owner tech (outils et logs), validateurs formés avec une checklist courte.

Santé HITL: temps médian de revue, % verts, % edits, incidents post-action, charge mentale. Si la charge explose, réduis le scope auto.

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