L'humain dans la boucle n'est pas un contrôle. C'est une discipline de conception.

La validation qui n'en était pas une

Chez Marrowfield Specialty Risk, l'audit de tri des sinistres mené ce printemps a donné lieu à un échange bref et gênant. Le courtier, environ 150 personnes sur un marché placé sous supervision, exploitait un système de signalement par IA depuis dix-huit mois. Mariela Okafor, responsable des opérations sinistres, occupait le poste depuis douze ans. Les gestionnaires traitaient plus de 200 dossiers par jour ; le modèle en signalait environ 8 %. L'audit a fait remonter deux chiffres : 96 % d'approbation sur les dossiers signalés par l'IA, 23 secondes de temps de revue moyen. La personne en charge de la conformité a demandé : « Quels seuils avez-vous réglés ? » Réponse : « Aucun. J'approuve simplement ce que l'IA m'envoie. »

Marrowfield Specialty Risk est une entité composite, construite à partir d'entretiens avec des courtiers spécialisés du marché intermédiaire et de la littérature de conformité de la BoE, de la FCA et du règlement IA. Les noms sont anonymisés ; les indicateurs illustrent des tendances relevées dans les enquêtes citées.

Aux yeux des régulateurs de trois continents, cet échange se lit désormais comme la preuve d'un contrôle absent. La date d'application du règlement IA — août 2026 — met un calendrier sur ce défaut de conception, mais le défaut est plus ancien que le calendrier.

§1 — La validation passive est un théâtre d'audit, pas un contrôle

Le modèle mental par défaut — « l'IA signale, l'humain approuve » — est structurellement indistinguable d'une absence de contrôle. Une interface à un bouton, sans données d'entrée, sans raisonnement du modèle, sans score de confiance, produit exactement les indicateurs qu'a fait remonter Marrowfield. La signature opérationnelle est celle d'un processus entièrement automatisé avec une personne en attente.

Les données de supervision le confirment à l'échelle de la population. L'enquête AI in UK Financial Services 2024 de la BoE et de la FCA a établi que « 55 % de tous les cas d'usage de l'IA comportent un certain degré de prise de décision automatisée, dont 24 % sont semi-autonomes, c'est-à-dire qu'ils peuvent prendre seuls toute une gamme de décisions tout en étant conçus pour faire intervenir un contrôle humain sur les décisions critiques ou ambiguës » [9]. L'implication, cohérente avec la façon dont NIST AI 600-1 cadre le risque de configuration humain-IA : l'essentiel de la population concernée par la décision automatisée n'offre aucun point d'intervention réel.

Les régulateurs ont entrepris de combler l'écart. La position de l'ICO est sans ambiguïté : une décision ne sort pas du champ de l'article 22 du UK GDPR « du simple fait qu'un humain l'a "validée d'un coup de tampon" » [2]. La même orientation est plus tranchante sur la preuve opérationnelle : des relecteurs qui « approuvent systématiquement les sorties du système d'IA et ne peuvent démontrer qu'ils les ont réellement examinées » peuvent être réputés relever de la seule automatisation au titre du UK GDPR [3]. Le règlement IA pose un critère parallèle à l'article 14, exigeant des systèmes « conçus et développés de manière à pouvoir être effectivement contrôlés par des personnes physiques » [1]. Le mot effectivement porte tout le poids, dans l'une et l'autre tradition juridique. La question de conception n'est plus « un humain est-il présent ? » mais « la conception permet-elle à un humain de détecter, de déroger et d'interrompre — et le ferait-il ? »

§2 — Le HITL est un système de seuils, pas une étape de revue

L'humain dans la boucle, pris au sérieux, est un système : seuils de confiance explicites, trois voies de décision, surcouche de pondération par le risque, et politique de file d'attente. Le modèle renvoie un score de confiance sur la plage 0,0–1,0, et trois seuils s'appliquent : refus automatique sous la borne basse, revue humaine dans la bande médiane, approbation automatique au-dessus de la borne haute. Pour un processus réglementé, des points de départ prudents tournent autour de 0,3 / 0,95 ; des opérations modérées, autour de 0,5 / 0,9 ; une classification à faible risque, autour de 0,7 / 0,95. Les seuils sont délibérément asymétriques : faux positifs et faux négatifs n'ont pas le même coût, et le système de seuils inscrit cette asymétrie au lieu de l'enfouir dans un chiffre unique. NIST AI RMF 1.0 aboutit au même point — sa fonction MANAGE « consiste à allouer régulièrement des ressources de gestion du risque aux risques cartographiés et mesurés » [5], et les seuils sont précisément ce mécanisme d'allocation, dimensionné selon le risque plutôt que selon la commodité.

Une surcouche pondérée par le risque vient s'ajouter. La confiance se multiplie par un indice de gravité du risque métier — montant du sinistre, irréversibilité de la décision, exposition réglementaire — pour produire une matrice de routage 3×3. Un dossier à haut risque et faible confiance remonte au superviseur ; un dossier à haut risque et forte confiance passe tout de même par la revue HITL standard plutôt que par l'approbation automatique. Le choix entre deux et trois paliers compte : un système à deux paliers déverse chaque dossier incertain dans une seule file, la file déborde, les gestionnaires basculent vers l'approbation en masse — le schéma qui a produit le taux de 96 % chez Marrowfield. Un système à trois paliers donne un rôle productif au refus automatique. Le routage suppose une stratégie d'IA centralisée^EN reposant sur une pile d'outils homologuée qui produit un score de confiance cohérent ; une prolifération d'outils ad hoc rend toute discipline de seuils impossible, car les scores de modèles différents ne sont pas comparables.

§3 — Les voies de repli se conçoivent, elles ne se sous-entendent pas

Le « repli » n'est pas de la gestion d'erreur. C'est la branche explicite empruntée par le système quand l'IA hésite, et il lui faut une voie, une personne, un SLA. Trois conceptions couvrent le terrain.

Conception A — humain dans la boucle, synchrone : l'IA suspend et renvoie le dossier dans une file, avec l'enregistrement d'entrée, le raisonnement et la confiance attachés, contre un SLA de 2 à 4 heures ; adaptée aux décisions quasi temps réel. Conception B — mise en file pour traitement par lot, asynchrone : l'IA renvoie une réponse provisoire, puis la fait remonter dans un lot quotidien ou hebdomadaire avec une fenêtre de dérogation rétroactive ; adaptée au travail non urgent. Conception C — escalade vers un expert, hiérarchique : routage selon l'incertitude de l'IA et la gravité du risque vers un vivier de relecteurs à plusieurs niveaux (standard → expert → superviseur), avec des SLA de 4 h / 24 h / 72 h ; adaptée à la décision réglementée — renvois en souscription, tri médical, signalements de conformité.

Chaque repli exige un responsable nommé et un SLA documenté. Le AI Playbook du DSIT britannique le pose en termes opérationnels — « des processus de revue et d'escalade clairement documentés [...] et un comité de revue de l'IA ou un comité au niveau du programme » [4] — et la fonction MANAGE du NIST AI RMF porte la même consigne sous un autre angle, en exigeant un suivi post-déploiement assorti de canaux de retour nommés. L'anti-modèle d'audit est constant : une file « revue humaine » fourre-tout, sans SLA ni responsable, où la file enfle et où la recommandation de l'IA devient la décision de fait. Chez Marrowfield, la refonte a affecté chaque repli : les petits sinistres sous un seuil de matérialité sont traités automatiquement ; les dossiers de bande médiane suivent la conception A sur un SLA de 4 heures ; les dossiers de bande haute et ceux passant sous le seuil suivent la conception C avec des souscripteurs nommés. Les files ont cessé d'être un unique canal de débordement pour devenir trois lignes de production, chacune dotée de ses propres indicateurs et de son responsable.

§4 — Le journal de dérogation est l'artefact de conformité

Ce que les auditeurs inspectent réellement, c'est le journal de dérogation. Pas de journal, ou un journal dépourvu de motif structuré, et le test échoue avant même qu'une défense narrative soit entendue. L'artefact minimal, par décision HITL, est un schéma figé : case_id, confiance de l'IA, recommandation de l'IA, identifiant du relecteur, durée de revue en secondes, décision humaine, motif de dérogation, horodatage, policy_version. Sans policy_version, la piste devient inexploitable un an plus tard, car les seuils auront bougé. L'article 14, paragraphe 4, du règlement IA exige que les relecteurs puissent « intervenir sur le fonctionnement [...] ou interrompre le système » [1] — et le corollaire opérationnel est que cette capacité doit laisser une trace, faute de quoi elle n'a pas existé. NIST AI 600-1 le situe au niveau de l'action : « Surveiller et documenter les cas où des opérateurs humains ou d'autres systèmes dérogent aux décisions de l'IA générative » [6]. Le journal est la preuve centrale d'une revue effective.

La responsabilité se joue en amont du journal. L'AI Update de la FCA pose le principe : « des lignes de responsabilité claires, établies sur l'ensemble du cycle de vie de l'IA » [10]. Les entreprises britanniques relevant du SM&CR rattachent la pile IA et opérations à la fonction Chief Operations ; les entreprises américaines pilotent des comités IA au niveau du conseil ; les entreprises de l'UE suivent les orientations de l'EBA et de la BCE sur la responsabilité de la direction générale. Le principe est transposable d'une tradition à l'autre, ce qui rend la construction d'une gouvernance de l'IA dès le premier jour moins coûteuse que la mise en conformité après coup. ISO/IEC 42001:2023 cadre l'ensemble de contrôles plus large comme « une approche intégrée de la gestion des projets d'IA, de l'appréciation du risque au traitement effectif de ces risques » [8].

Les auditeurs guettent les signaux inverses. Une durée de revue inférieure à 10 secondes se lit comme une validation au tampon. Un taux d'approbation au-dessus de 98 % se lit comme une absence de revue. Un champ de motif vide se lit comme une revue effective non documentée. Plus de 200 décisions par jour et par relecteur se lit comme de la fatigue. Chacun est un constat à lui seul.

§5 — Comment le réglage trimestriel maintient-il le HITL honnête ?

Les seuils ne se règlent pas une fois pour toutes. Les modèles dérivent, les règles métier changent, des cas limites émergent. Un cycle trimestriel est la discipline la moins coûteuse pour empêcher un système HITL bien conçu de régresser vers le théâtre, et il pèse d'un poids égal selon les juridictions : le critère de contrôle « effectif » de l'article 14 est insatisfiable sans lui, et la fonction MANAGE du NIST AI RMF attend des « plans de priorisation du risque ainsi qu'un suivi et une amélioration réguliers » [5].

Mois un — mesurer la base de référence : volume HITL par semaine, taux de dérogation par bande de confiance, distribution des délais de décision, taux d'escalade par palier. Mois deux — repérer les signaux de dérive : les bandes où la dérogation dépasse 20 % signifient que le modèle n'est pas fiable et que la bande HITL doit s'élargir, ou que le modèle doit être réentraîné ; les bandes sous 2 % peuvent se resserrer sans danger ; des dossiers de conception B non revus dans la fenêtre signifient que le traitement par lot est défaillant. Mois trois — ajuster et documenter : mettre à jour les définitions de seuils, incrémenter policy_version avec le motif du changement, informer les opérations, réinitialiser la base de référence.

Le cycle suppose une culture des relecteurs qui soutient la dérogation. L'ICO est explicite : une revue effective exige que « les relecteurs aient le pouvoir de déroger à la sortie produite par le système d'IA et soient assurés de ne pas être sanctionnés pour l'avoir fait » [3]. La même attente figure dans la commande publique américaine au titre du NIST AI RMF et dans les règles de responsabilité de l'UE relevant de l'EBA et de la BCE — juridictions différentes, critère opérationnel identique. Là où la culture punit l'écart, les taux de dérogation s'effondrent pour des raisons culturelles et non techniques, et les données dont dépend le cycle deviennent inexploitables. Le Playbook du DSIT britannique désigne le responsable : un comité de revue de l'IA ou un comité au niveau du programme pilote le cycle [4]. La réponse type du marché intermédiaire à la question « qui en est responsable ? » est une promotion interne — voir l'argument selon lequel le meilleur recrutement de responsable IA^EN se trouve déjà dans la maison.

§6 — Quels cinq anti-modèles échouent à un audit au titre de l'article 14 ?

Les mêmes cinq modes de défaillance reviennent à chaque audit.

Interface accepter/refuser à un bouton. Le relecteur ne voit que la décision. Symptôme : taux d'approbation au-delà de 95 %, revues de moins de 10 secondes. Correctif : exposer la confiance, l'enregistrement d'entrée et les facteurs d'incertitude énoncés. L'article 14, paragraphe 4, point b), est explicite sur le biais d'automatisation — les relecteurs doivent « rester conscients de la tendance possible à se fier ou à se fier exagérément automatiquement à la sortie produite par un système d'IA à haut risque » [1].

Relecteur unique, sans rotation. Un seul responsable des opérations relit chaque dossier HITL. Symptôme : goulots d'étranglement le week-end, erreurs de fatigue en fin de journée, point de défaillance unique. Correctif : un vivier formé de 3 à 5 relecteurs sur un calendrier de rotation documenté.

Seuil réglé une fois, jamais ajusté. Les valeurs par défaut du fournisseur restent inchangées. Symptôme : volume HITL très éloigné de la bande ; taux de dérogation suspectement bas ou chroniquement au-dessus de 20 %. Correctif : le cycle trimestriel du §5.

Aucun recueil du motif de dérogation. Les relecteurs peuvent déroger, mais le champ de motif est facultatif ou vide. Symptôme : la revue effective ne peut être démontrée. Correctif : un recueil structuré — liste déroulante des trois principaux motifs et champ libre, les deux obligatoires.

File de repli sans SLA. Les dossiers sont dirigés vers la « revue humaine » sans responsabilité d'apurement dans une fenêtre définie. Symptôme : longueur de file croissant de mois en mois, relecteurs sautant les entrées les plus anciennes. Correctif : un SLA explicite par repli et un tableau de bord de suivi de file avec un responsable nommé. La responsabilité diffuse est le risque structurel ; l'enquête de la BoE et de la FCA note que la responsabilité « est souvent éclatée, la plupart des entreprises déclarant trois personnes ou organes responsables, voire davantage » [9], et l'article 14 du règlement IA place le contrôle sur une « personne physique » nommée [1].

§7 — L'article 14 et le calendrier d'août 2026

Le cadre de conformité n'est pas un théâtre propre à une seule juridiction. Plusieurs régulateurs convergent vers le même critère opérationnel ; le règlement IA y attache l'échéance la plus visible. L'article 113 fixe la date d'application des obligations relatives au haut risque — y compris l'article 14 — au 2 août 2026 [1]. À compter de cette date, les entreprises déployant de l'IA dans les périmètres à haut risque de l'annexe III (emploi, solvabilité, infrastructures critiques, données répressives) en assument l'obligation.

L'article 22 du UK GDPR est déjà contraignant, et son critère est celui d'un « apport humain significatif » [3] — pouvoir, compétence, prise en compte des données d'entrée et des alternatives, culture de soutien, et absence de sanction pour avoir dérogé au modèle. Là où l'article 22 s'applique — partout où une décision produit un effet juridique ou un effet de portée comparable — la « validation au tampon » échoue au critère [2]. La position américaine n'est pas en reste : des lois au niveau des États (Colorado AI Act, NYC AEDT, projet de règles ADMT de Californie) et une application sectorielle (la FTC sur la décision automatisée, le NIST AI RMF comme référence d'achat pour l'usage fédéral) poussent la même discipline. ISO/IEC 23894:2023 normalise l'approche sous-jacente de gestion du risque comme « des orientations sur la manière dont les organisations [...] peuvent gérer le risque spécifiquement lié à l'IA » [7] — l'ancrage non réglementaire le plus net pour les marchés dont les lois propres à l'IA ne sont pas encore entrées en vigueur, et l'ossature de toute politique opérationnelle multijuridictionnelle.

Les régulateurs sectoriels renforcent le constat : la FCA est neutre sur le plan technologique [10], ses équivalents de l'UE relevant de l'EBA et de la BCE s'alignent sur la responsabilité de la direction générale, et l'enquête 2024 de la BoE et de la FCA montre une responsabilité le plus souvent fragmentée entre trois parties responsables ou plus dans la majorité des entreprises sondées [9].

Les questions de conception des §§2 à 5 sont les questions de conformité dans les trois traditions juridiques. Concevoir le HITL ainsi se paie une fois ; le remettre en conformité après un échec d'audit se paie chaque trimestre.

§8 — À quoi ressemble le sprint de conception HITL de quatre semaines ?

La refonte est bornée : un sprint piloté par la fonction de responsable des opérations, pas un programme.

Semaine 1 — Mesurer l'état actuel. Recenser chaque étape de « revue humaine ». Extraire les taux d'approbation, les distributions de durée de revue, l'état du recueil des dérogations, les longueurs de file. Signature de la validation passive : taux d'approbation élevé, durée de revue faible, aucun motif de dérogation structuré.

Semaine 2 — Concevoir les voies de décision. Fixer les seuils de confiance par processus à partir des points de départ du §2. Concevoir les voies de repli selon le §3. Définir le schéma du journal de dérogation selon le §4. Documenter la policy_version v1.0 avec les valeurs de seuils, les responsables et les SLA.

Semaine 3 — Mettre en œuvre, former, collecter les données. Mettre en œuvre les modifications d'interface — exposer le raisonnement et la confiance du modèle sur l'écran du relecteur. Former le vivier de relecteurs sur des exemples traités. Lancer l'exploitation réelle avec une journalisation d'audit complète dès le premier jour.

Semaine 4 — Première revue de réglage et documentation prête pour l'audit. Dérouler le cycle du §5 sur les données de la semaine 3 ; les signaux de dérive évidents apparaissent même sur une courte fenêtre. Assembler le dossier d'artefacts : définitions de seuils, tableau de bord du taux de dérogation, inventaire des voies d'escalade, cartographie des responsabilités. Le résultat est la position à confronter aux 50 questions que les décideurs posent avant un déploiement d'IA^EN, qui couvrent les questions Q3.10, Q5.4, Q5.5 et Q5.7.

Fourchette de coût : 20 à 40 heures de temps de responsable des opérations. Résultat : un protocole de contrôle prêt pour l'article 14, une position de « revue effective » défendable au titre de l'article 22, et une fonction MANAGE alignée sur le NIST AI RMF.

De la validation à la discipline

Quatre semaines après la refonte, le tableau opérationnel a changé. Le volume HITL sur le processus de sinistres a baissé de 70 %, parce que le refus automatique fait un vrai travail sur la bande passant sous le seuil. Le temps de revue moyen, sur les dossiers qui atteignent effectivement le HITL, est monté à environ quatre minutes — le temps que prend réellement une revue structurée. Le taux de dérogation s'est stabilisé à 14 %, dans la bande saine de 5 à 20 %, chaque dossier ayant fait l'objet d'une dérogation portant un motif structuré. La question de la personne en charge de la conformité a désormais une réponse, avec des numéros de version à l'appui.

La différence entre théâtre d'audit et contrôle défendable en audit ne tient pas au sérieux avec lequel une entreprise parle de revue humaine. Elle tient à ce que la revue soit un système de seuils conçu ou une approbation en un clic. L'un passe l'article 14. L'autre non.

Pour situer la conception du HITL dans l'ensemble des processus réglementés d'une organisation, easy-audit.ai la cartographie en deux heures de questions structurées.

Résumé

HITL — designed oversight, not passive sign-off
│
├─ The failure · audit theatre
│   ├─ Passive sign-off — one-click approve, no reasoning shown
│   └─ Rubber-stamp test — >98% approve, <10s review fails it
│
├─ The system · thresholds & routes
│   ├─ Three routes — auto-reject / HITL review / auto-approve
│   ├─ Risk overlay — confidence × severity sets escalation
│   └─ Fallback paths — named owner, SLA, override audit log
│
└─ The discipline · stays honest
    ├─ Healthy band — 5–20% override; outside it, tune or retrain
    └─ Quarterly cycle — measure, spot drift, re-version, document