Concevoir un Human-in-the-Loop (HITL) efficace : modèles de validation pour agents IA

Le Human-in-the-Loop (HITL) désigne l'intégration délibérée de validations humaines dans la chaîne d'actions d'un agent IA. Lorsqu'une action est irréversible, coûteuse ou juridiquement sensible, une personne la vérifie et l'approuve avant que l'agent n'agisse. Le HITL est la mise en œuvre opérationnelle du contrôle humain exigé par l'article 14 du règlement européen sur l'IA et, en même temps, une contre-mesure centrale face au risque agentique OWASP ASI09 (Human-Agent Trust Exploitation).

• Quand le HITL est nécessaire : avant les actions irréversibles, coûteuses ou juridiquement sensibles, pas avant chaque étape.
• Quels modèles existent : Pre-Action Approval, Checkpoint Approval et Escalation-on-Anomaly, le plus souvent combinés.
• Ce qui tourne mal le plus souvent : le point de validation dégénère en validation les yeux fermés (biais d'automatisation). L'UX et l'audit doivent l'empêcher activement.

Pourquoi l'autonomie naïve est un problème de sécurité

Les systèmes agentiques planifient, raisonnent, choisissent des outils et agissent avec un minimum de confirmations humaines étape par étape. C'est précisément cette autonomie qui élargit la surface d'attaque. L'entrée OWASP ASI02 (Tool Misuse & Exploitation) cite les modes d'auto-approbation, ou modes « YOLO », qui désactivent les boîtes de dialogue de confirmation, comme un vecteur d'attaque à part entière. Notre recommandation : désactive l'auto-approbation pour tout outil qui touche aux bases de données, aux paiements, à la communication ou aux déploiements, et remplace-la par des points de validation Human-in-the-Loop.

Le HITL n'est donc pas un confort d'UX, mais un contrôle de sécurité. Il limite les dégâts lorsqu'un détournement d'objectif (ASI01), une mémoire empoisonnée (ASI06) ou une chaîne d'approvisionnement compromise (ASI04) pousse un agent à agir contre l'intention de ses opérateurs.

Quand une validation humaine est-elle nécessaire ?

La décision « point de validation ou non » ne devrait pas se prendre au coup par coup, mais découler d'une classification des risques documentée. Trois critères couvrent l'essentiel des cas :

• Irréversibilité. L'action est-elle impossible à annuler, ou seulement au prix d'un effort important ? Suppressions, paiements, envois à des clients, consignes de production.
• Coûts. L'action engendre-t-elle des coûts importants ou difficiles à plafonner ? Appels d'API massifs, commandes, provisionnement d'infrastructure.
• Portée juridique. L'action produit-elle un effet juridique ou concerne-t-elle des données personnelles ? Contrats, décisions de crédit ou de prestations, déclarations de soupçon, export de données de référence.

À l'inverse, les opérations en lecture seule ou les actions facilement réversibles dans une sandbox n'ont en général pas besoin de point de validation. Sinon s'installe une « fatigue de validation », et les contrôleurs valident tout par lassitude.

Modèles HITL : Pre-Action, Checkpoint, Escalation

Trois modèles de base couvrent la plupart des architectures et se combinent en pratique.

Pre-Action Approval. L'agent s'arrête juste avant une action critique isolée. L'action prévue et ses arguments passent dans une file de validation ; l'exécution n'a lieu qu'après accord humain. Adapté aux opérations isolées à haut risque (déclencher un paiement, envoyer un contrat).

Checkpoint Approval. Dans les plans en plusieurs étapes, un humain contrôle à des jalons définis avant le lancement du segment suivant. Adapté aux workflows longs dont chaque étape, prise isolément, est anodine, mais dont le chemin cumulé devient critique. Ce modèle répond au schéma de la « grenouille ébouillantée » décrit par OWASP, où chaque étape est plausible mais la trajectoire globale nuisible.

Escalation-on-Anomaly. L'agent travaille de façon autonome et ne fait appel à un humain que lorsque des seuils ou des détecteurs d'anomalies se déclenchent : fréquences inhabituelles d'appels d'outils, opérations destructrices peu après l'ingestion de contenus externes, dépassements de rate limits. Techniquement, cela peut se mettre en œuvre via du policy-as-code (par ex. avec Open Policy Agent (OPA) ou Cedar) sous la forme d'un point de validation de l'usage des outils.

Une architecture HITL efficace gradue la confiance : les décisions à fort impact exigent davantage de contrôleurs ou des preuves plus solides (« graduated trust »). Selon OWASP, l'essentiel est que le point de validation exige une vérification indépendante des éléments de preuve, et pas seulement la recommandation de l'agent.

La matrice action-risque-HITL

La matrice suivante montre, à titre d'exemple, comment classer les actions. Elle est conçue comme un modèle ; chaque organisation doit adapter les seuils concrets à son appétence au risque.

L'erreur la plus fréquente : le point de validation se dégrade

Le plus grand risque n'est pas l'absence de point de validation, mais son érosion insidieuse. OWASP en fait un risque à part entière de son Top 10 : ASI09 (Human-Agent Trust Exploitation). Les agents produisent des réponses soignées, au ton qui fait autorité ; les humains ont tendance à les reprendre telles quelles. La couche de supervision conçue comme contrôle de sécurité devient ainsi elle-même le point faible.

Les mécanismes en jeu :

• Biais d'automatisation : la réponse est acceptée sans examen critique.
• Déférence à l'autorité : le ton assuré décourage les questions.
• Escalade progressive de la confiance : l'agent gagne en crédibilité avec des réponses correctes avant que des réponses manipulées ne suivent.
• Surcharge cognitive : le volume et la complexité dépassent la capacité d'examen humaine.
• « Hallucination soignée » : une réponse sûre d'elle, fausse et convaincante.

Signaux de détection permettant de mesurer la dégradation : le temps de décision des contrôleurs diminue alors que la complexité des tâches reste constante, et les validations sont extrêmement corrélées à la recommandation de l'agent. Les deux indiquent une validation les yeux fermés.

Un design UX qui force l'examen

Le HITL ne vaut que ce que vaut son interface. Un simple bouton « Approuver » invite à valider sans lire. Les patterns de force engagement, qui imposent un véritable examen, y remédient :

• Rendre le raisonnement visible. Afficher la justification, la provenance des sources et les intervalles de confiance, ne pas les masquer. Selon OWASP, masquer la trace de raisonnement dans l'interface produit précisément un signal de détection d'ASI09.
• Mise en évidence des sorties adverses. Des avertissements du type « cette réponse pourrait être influencée par des contenus externes » lorsque des contenus proviennent de sources non fiables.
• Délai imposé. Pour les validations à haut risque, imposer un délai délibéré afin d'empêcher les confirmations réflexes.
• Formation au biais d'automatisation pour les contrôleurs et injections de test périodiques (« exercices incendie ») qui vérifient si le HITL fonctionne encore.

Scénario d'exemple : la cascade des achats

Un scénario rend la défaillance du HITL concrète. Supposons qu'un agent d'achats soit progressivement convaincu, sur trois semaines, que son plafond de validation s'élève à 500 000 USD. L'attaquant passe ensuite, en dix transactions, de fausses commandes pour un total de 5 millions USD. Le validateur humain croit l'agent, qui affirme avec de plus en plus d'insistance être habilité pour des montants plus élevés. Un cas d'école d'ASI09, aggravé par des défaillances en cascade (ASI08).

En pseudocode, un point de validation Pre-Action efficace pourrait s'esquisser ainsi :

```text
on agent_action(action):
risk = classify(action) # réversibilité, coûts, droit
if risk in {ÉLEVÉ, CRITIQUE}:
evidence = gather_provenance(action) # sources, confiance, raisonnement
approver = route_by_amount(action) # >plafond -> quatre yeux / escalade
decision = require_human(evidence,
enforce_delay=True,
show_reasoning=True)
audit_log.write_worm(action, evidence, decision) # signé
if not decision.approved: abort()
execute(action)
```

Important : le plafond (route_by_amount) se trouve en dehors de la mémoire de l'agent et est protégé contre la manipulation. Sinon, l'agent réapprend son propre plafond, comme dans l'exemple.

Audit : sans journalisation, pas de contrôle

Le contrôle humain n'est solide que s'il est prouvable. Le minimum forensique à journaliser pour chaque action de l'agent : prompt complet (utilisateur, système, contexte injecté), version du modèle et hash de configuration, séquence d'appels d'outils avec leurs arguments, requêtes de retrieval et identifiants de documents, réponse et justification de la décision, événements d'intervention humaine, opérations de lecture et d'écriture en mémoire, ainsi que coûts et latence.

Les journaux WORM (write-once-read-many) et une signature cryptographique qui rend les manipulations détectables ont fait leurs preuves. Pour la conservation, le règlement européen sur l'IA fixe un plancher pour les systèmes à haut risque : fournisseurs et déployeurs doivent conserver les journaux générés automatiquement, dans la mesure où ils sont sous leur contrôle, pendant au moins six mois (art. 19, art. 26, paragraphe 6), sauf disposition contraire du droit de l'Union ou du droit national. Si un agent déclenche des opérations commerciales, comme des commandes ou des paiements, les durées de conservation du droit commercial s'appliquent en outre aux pièces comptables et à la correspondance commerciale, en Autriche sept ans selon le § 212 UGB. Ces journaux sont aussi ta preuve, face aux auditeurs, que le HITL fonctionne en pratique.

Lien avec la réglementation (pas un conseil juridique)

L'article 14 du règlement européen sur l'IA exige un contrôle humain effectif pour les systèmes d'IA à haut risque. Le paragraphe 4, point b), cite expressément le biais d'automatisation, c'est-à-dire précisément le mécanisme derrière OWASP ASI09. Cette obligation de conception incombe au fournisseur : il doit construire le système, interface humain-machine comprise, de sorte que les personnes chargées du contrôle puissent détecter le biais d'automatisation et intervenir. Le déployeur doit, selon l'article 26, paragraphe 2, désigner des personnes chargées du contrôle disposant de la compétence, de la formation et de l'autorité nécessaires. Qui conçoit et déploie ses propres agents cumule les deux rôles.

En complément, le BSI et l'ANSSI française ont publié en août 2025 le document Design Principles for LLM-based Systems with Zero Trust. Il traite notamment de l'authentification et de l'autorisation, du sandboxing et de la surveillance, et exige dans les cas critiques le consentement de l'utilisateur en tant que Human-in-the-Loop.

Remarque : cet article propose une analyse technique et ne remplace pas un conseil juridique. Pour savoir si ton système concret est considéré comme une IA à haut risque au sens du règlement européen sur l'IA et quelles obligations en découlent, fais appel à un conseil juridique qualifié.

Pour les agences et les décideurs B2B

Qui conçoit des agents pour des clients ou les utilise dans sa propre entreprise devrait traiter le HITL non comme une fonctionnalité ajoutée après coup, mais comme une décision d'architecture. Concrètement : une matrice action-risque dans chaque conception d'agent, des validations graduées plutôt qu'une auto-approbation généralisée, des interfaces de type force engagement contre le biais d'automatisation et des journaux d'audit infalsifiables dès le départ. Blck Alpaca, basé à Vienne, aide les entreprises de toute l'Europe à concevoir des workflows agentiques où autonomie et contrôle humain trouvent le bon équilibre : sûrs, prouvables et compatibles avec le règlement européen sur l'IA et l'OWASP Agentic Top 10.