Human-in-the-Loop (HITL)

1. Vue d'ensemble du concept et problème systémique

L'autonomie complète des agents (Fully Autonomous Agents) se heurte à une limitation fondamentale : la non-déterminisme des grands modèles de langage (LLM). Même si un modèle affiche une précision de 98 %, la probabilité cumulative d'erreur sur une chaîne d'exécution de 20 étapes s'approche de 33 %. Si l'agent dispose d'un accès direct au shell système, aux bases de données de production, aux API financières ou à l'infrastructure cloud, une simple défaillance ou une hallucination peut entraîner la suppression de données ou des pertes financières considérables.

Human-in-the-Loop (HITL) est un principe architectural pour construire des systèmes agentiques fiables. Au lieu de confier aveuglément tout le processus, du début à la fin, à la machine, le système est conçu pour que les actions les plus risquées nécessitent une vérification consciente par un humain. Le HITL combine la rapidité de l'intelligence artificielle avec la responsabilité et le jugement contextuel d'un senior engineer.

2. Taxonomie architecturale et modèle mental

L'architecture HITL se divise en trois modèles clés d'interaction selon le protocole et la criticité :

┌─────────────────────────────────────────────────────────────┐
│                 TAXONOMIE DES INTERACTIONS HITL             │
├─────────────────────────────────────────────────────────────┤
│ 1. Porte de synchronisation CLI (Blocage sur STDIN : Prompt [y/N]) │
│    Outils locaux pour développeurs (Claude Code, Cline)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Porte asynchrone durable (Point de contrôle d'état / Webhook) │
│    Chaînes de processus longs (LangGraph, Temporal, Inngest)│
├─────────────────────────────────────────────────────────────┤
│ 3. Escalade & Politique RBAC par niveaux                    │
│    • Lecture seule ➔ Approuvé automatiquement (Niveau 0)    │
│    • Mutation locale ➔ Approuvé par le dev (Niveau 1)       │
│    • Production / Argent ➔ Approuvé par le lead / Multi-sig (Niveau 2) │
└─────────────────────────────────────────────────────────────┘

1. Barrière synchrone locale (Synchronous Approval):
   • Utilisé dans les agents CLI et IDE. L'agent bloque le flux d'exécution, affiche dans la console la commande shell prévue ou le diff, et attend une action clavier de l'utilisateur.
2. Barrière asynchrone durable (Durable Asynchronous Gate):
   • Utilisé dans les agents backend. À l'atteinte d'un point critique, l'agent sauvegarde son état de travail dans une base de données (Checkpointer), génère un événement (par exemple, un message Slack ou un email avec des boutons « Approuver » / « Rejeter ») et entre en veille.
3. Matrice granulaire des autorisations (Tiered Action Policies):
   • Les actions sont classées selon leur niveau de risque potentiel (Blast Radius). Les opérations sûres ne nécessitent pas d'approbation, tandis que les opérations irréversibles exigent une confirmation multi-niveaux.

3. Pipeline technique et mécanique interne

Cycle de vie d'un processus asynchrone avec intervention humaine (exemple basé sur LangGraph) :

1. Exécution des étapes jusqu'au point de contrôle : L'agent analyse la requête, élabore un plan et effectue les calculs préparatoires (par exemple, génère une requête SQL de migration de données).
2. Interception d'outil (Tool Interceptor) : La couche de sécurité vérifie l'appel : si l'outil execute_production_migration est invoqué, une interruption interrupt() est déclenchée.
3. Sérialisation et persistance de l'état (State Persisting) : Le graphe de mémoire actuel, l'historique des messages et les arguments de l'appel d'outil sont figés dans le store d'états.
4. Routage vers l'opérateur : Le service envoie un message interactif dans le canal Slack de l'équipe, décrivant les modifications et proposant des boutons de confirmation.
5. Révision et modification humaine : L'ingénieur peut :
   • Approuver : transmettre le signal de reprise de l'exécution.
   • Rejeter : interrompre la session et enregistrer la raison du refus.
   • Corriger (Human-in-the-Edit) : modifier les paramètres (par exemple, réduire la taille du batch de la requête) avant l'exécution.
6. Reprise de l'exécution (Resume Thread) : Le moteur charge l'état depuis la base de données, applique la décision de l'ingénieur et poursuit le cycle autonome.

4. Scénarios d'ingénierie pratiques en production

01. Contrôle des migrations SQL dangereuses sur une base active

L'agent analyse une nouvelle fonctionnalité et propose une modification du schéma PostgreSQL :

• Au lieu d'exécuter directement ALTER TABLE users ADD COLUMN status text NOT NULL, l'agent soumet une demande d'approbation.
• Le DBA constate que l'ajout d'une colonne sans valeur par défaut sur une table de 20 millions de lignes bloquera les lectures. L'ingénieur corrige la commande pour créer le champ avec une clause DEFAULT via un pattern de migration sécurisé et approuve l'exécution.

02. Approbation de la suppression de ressources cloud pour l'optimisation des coûts

Un agent FinOps audite l'infrastructure AWS :

• Il identifie 14 instances RDS et disques EBS inutilisés qui accumulent 2 000 $ de coûts mensuels.
• L'agent ne les supprime pas lui-même, mais envoie un rapport structuré au tech lead via le messager d'entreprise, incluant des liens vers chaque ressource. Le lead ou le CTO clique sur « Terminate All », après quoi l'agent procède au nettoyage.

03. Génération de réponses juridiques ou de conformité personnalisées

L'IA formule des réponses aux demandes des utilisateurs concernant la suppression de données personnelles (GDPR Right to be Forgotten) :

• L'agent localise toutes les entités liées dans les services, prépare un script de suppression et rédige une lettre officielle destinée au client.
• Un membre de l'équipe de sécurité vérifie la conformité documentaire avant l'envoi.

5. Pièges courants, erreurs typiques et sécurité

• Fatigue d'approbation (Approval Fatigue) : Si l'agent demande une validation pour chaque petite étape (par exemple, la lecture de chaque fichier individuel), le développeur cesse de lire attentivement et approuve automatiquement toutes les demandes. Configurez des seuils de sensibilité intelligents.
• Vulnérabilité à la substitution d'intention via Prompt Injection : Si l'agent traite des données externes non vérifiées (par exemple, du texte provenant d'une page web), un attaquant peut forcer le modèle à formuler une description trompeuse de l'action pour l'opérateur (« Mise à jour du cache sécurisée », alors qu'en réalité, un vol de tokens est exécuté sous le capot).
• Perte de transactionnalité lors des timeouts : Si le thread reste suspendu pendant plusieurs heures ou jours en attente d'une réponse humaine, les transactions ouvertes dans les bases de données ou les tokens d'accès temporaires peuvent expirer, provoquant une panne système lors de la reprise.
• Absence de journal d'audit (Audit Logging) : Chaque décision humaine d'approbation ou de rejet des actions de l'agent doit impérativement être enregistrée dans un journal sécurisé, lié à l'ID utilisateur, afin d'assurer la traçabilité et la capacité d'investigation en cas d'incident.