Humain dans la boucle

Objectif

La conception de l'humain dans la boucle place une décision humaine dans un processus où un système d'IA lit, classe, propose ou agit. Elle tranche, pour chaque fonction d'une décision, s'il faut l'automatiser et dans quel mode avant que l'équipe écrive les exigences de la solution. Elle nomme aussi la personne qui répond du résultat quand une erreur échappe au contrôle.

Le livrable est un registre des décisions. Chaque ligne porte une fonction d'une décision du processus. Ses colonnes donnent le coût d'une erreur, la fiabilité mesurée, le mode de contrôle, le temps par cas, le relecteur et le redevable. Le registre alimente les exigences de la solution et la matrice RACI du processus. Un plan de test de la supervision et une liste d'indicateurs de la revue humaine l'accompagnent.

La technique remplace une phrase courante des cahiers des charges: «une personne valide le résultat». Cette phrase ne dit ni quels cas, ni avec quoi, ni en combien de temps. Elle produit deux défauts connus. Le relecteur approuve par habitude ce qu'un système fiable lui présente. La signature humaine rend acceptable un système défaillant et déplace la faute sur la personne qui signe. Le registre transforme la phrase en une conception que l'équipe peut tester.

Usage

Quand l'utiliser

• Nouveau processus assisté par l'IA: fixer où une personne décide avant de spécifier les exigences de la solution.
• Agent qui agit dans un système: placer l'approbation avant l'écriture, l'envoi ou le paiement qu'il déclenche.
• Décision qui touche une personne: remboursement, candidature, crédit; prévoir la revue que la personne peut demander.
• Système classé à haut risque: concevoir le contrôle humain que l'AI Act impose au déployeur.
• Revue humaine qui approuve presque tout: vérifier qu'elle décide encore quelque chose.
• Mise à jour du modèle ou changement de fournisseur: retester la supervision sur le nouveau système.
• Volume en hausse sans relecteurs supplémentaires: recalculer le temps disponible par cas et revoir le mode.

Quand ne pas l'utiliser

• Assistant personnel sans effet hors de son utilisateur: l'auteur relit son brouillon; une politique d'usage suffit.

Description

La décision et ses quatre fonctions

Parasuraman, Sheridan et Wickens (2000) décrivent l'automatisation par fonction plutôt que par système. Leur modèle distingue quatre classes de fonctions. L'exemple suit une caisse maladie qui traite une facture de physiothérapie.

• Acquisition de l'information: le système lit la facture et en extrait les positions tarifaires, le nombre de séances et la date de la prescription.
• Analyse de l'information: il compare ces données à la prescription et à l'historique de l'assuré, puis estime la probabilité d'une erreur.
• Choix de la décision: il décide de payer la facture ou de la faire contrôler.
• Exécution de l'action: il déclenche le paiement ou envoie la lettre qui refuse une partie du montant.

Chaque fonction se place sur un continuum qui va du manuel à l'automatique. Un même système peut automatiser les quatre fonctions à des degrés différents. Le découpage montre où l'erreur naît et où une personne la rattrape au moindre coût. Une erreur de lecture se détecte sur un échantillon. Une lettre de refus mal fondée se corrige avant l'envoi.

Les modes de contrôle

Aucune norme ne nomme les modes de contrôle. Ils vont de l'approbation de chaque cas à l'absence d'étape humaine par cas. La personne qui fait tout le travail reste une option: le système ne reçoit alors aucune fonction.

Les modes se combinent sur une même décision. Le renvoi des cas signalés appelle presque toujours une revue d'échantillon parmi les cas non signalés. Sans elle, personne ne voit les erreurs que le système ne signale pas. Vous trouverez un exemple de ce défaut dans la fiche AI Canvas.

Choisir le mode: le coût d'une erreur et la fiabilité

Parasuraman et ses coauteurs donnent deux niveaux de critères. Le critère premier est l'effet de l'automatisation sur le travail de la personne. Les critères secondaires sont la fiabilité de l'automatisation et le coût des conséquences d'une décision ou d'une action.

Le coût d'une erreur se chiffre par ce qu'un cas faux coûte quand il échappe au contrôle: un montant en CHF, un délai, une atteinte à une personne. L'analyste demande aussi si l'effet se défait avant de nuire. Un document placé dans la mauvaise file se transfère en deux minutes. Une lettre de refus envoyée à un assuré ne se reprend pas.

La fiabilité se mesure sur un échantillon de cas réels. Quand le seuil doit tenir pour chaque langue, région ou type de document, elle se mesure pour chacun. Une fiabilité que personne n'a mesurée ne compte pas. La décision reste alors en approbation avant l'action jusqu'à la mesure. Vous trouverez comment établir ces chiffres dans la page Mesurer le succès d'une solution IA.

Le critère premier vérifie que le mode laisse à la personne un travail qu'elle peut faire. Le calcul multiplie le nombre de cas par jour par le temps de lecture d'un cas, puis compare le résultat au temps des relecteurs. Une caisse maladie reçoit 5'000 documents par jour. À 30 secondes par document, approuver chaque tri demande près de 42 heures par jour. Les trois collaborateurs de la réception disposent de 24 heures de revue par jour. Le calcul écarte ce mode avant la mise en service. Si aucun mode ne laisse un travail faisable, la décision d'automatiser retourne à l'analyse des risques.

Le niveau de risque du système entier fixe un plancher. Le registre choisit les modes fonction par fonction au-dessus de ce plancher. Vous trouverez comment établir ce niveau dans la page Évaluer les risques de l'IA. Vous trouverez quand la loi impose un contrôle humain dans la page AI Act: classer le risque.

Le relecteur et le redevable

La sous-catégorie GOVERN 3.2 du NIST AI RMF attend des politiques qui définissent et distinguent les rôles dans les configurations entre personnes et IA. Son Playbook sépare les personnes qui supervisent le système de celles qui l'utilisent. Vous trouverez une présentation du cadre dans la page ISO/IEC 42001 et NIST AI RMF. Le terme de supervision traduit l'oversight du NIST. L'AI Act nomme la même chose «contrôle humain». Le registre nomme deux rôles par ligne.

Le relecteur examine un cas ou un échantillon et décide: il accepte, corrige ou rejette. MAP 3.4 prend l'exemple des médecins. Ces experts du métier travaillent avec l'IA sans connaître l'apprentissage automatique. Le relecteur juge le contenu du cas. Il ne juge pas le modèle.

Le redevable répond du résultat de la décision. Il choisit le mode, fixe les seuils, lit les indicateurs de la revue humaine et peut arrêter le système. Il répond aussi des erreurs dans les cas que personne n'a relus. Le relecteur ne porte que les cas qu'il a vus. Une matrice RACI enregistre ces deux rôles: le relecteur y est R, le redevable A.

Le relecteur reçoit le droit de refuser. Le texte de GOVERN 1.5 cite le recours et l'annulation manuelle d'une décision du système parmi les processus qui laissent une personne trancher. Un rejet motivé compte comme du travail normal. Le relecteur ne doit pas justifier un rejet plus longuement qu'une approbation.

Ce que reçoit le relecteur

MAP 3.5 demande que la documentation permette au personnel de supervision de décider en connaissance de cause. La revue de Goddard, Roudsari et Wyatt (2012) retient 74 études de plusieurs domaines et se concentre sur l'aide à la décision clinique. Elle étudie le biais d'automatisation: la tendance à suivre la proposition d'un système sans la vérifier. Elle range parmi ses parades la formation, la responsabilité de l'utilisateur, la place de la recommandation à l'écran, un niveau de confiance mis à jour et l'information donnée à la place d'une recommandation. Faas et ses coauteurs (2025) ajoutent, sur un petit échantillon d'ateliers, que le relecteur doit comprendre sa tâche et voir sur quoi l'IA fonde sa sortie.

Le dossier de revue réunit l'entrée, les faits que le système en a tirés avec leur source et sa proposition. Il affiche la confiance du système quand elle est mesurée. Il permet de rejeter avec un motif. Les faits viennent avant la proposition: le relecteur lit la facture et la prescription avant de lire «faire contrôler». Vous trouverez les erreurs qu'il cherche dans les pages Les hallucinations et Les biais.

Le temps fait partie du dossier. Goddard et ses coauteurs rangent la charge de travail, la complexité de la tâche et la contrainte de temps parmi les facteurs qui renforcent ce biais. Le registre fixe un temps par cas et la file de revue le respecte.

Les étapes

1. Lister les décisions du processus. Partir du modèle du processus et marquer chaque point où le système lit, classe, propose ou agit. Découper chaque décision en quatre fonctions. La modélisation des décisions fournit la liste quand elle existe.
2. Chiffrer le coût d'une erreur et la fiabilité. Le métier chiffre le coût. L'équipe données mesure la fiabilité sur un échantillon. Une valeur absente reste marquée «à mesurer».
3. Choisir le mode de chaque fonction. Appliquer les critères secondaires, puis vérifier le critère premier en calculant le temps de revue.
4. Nommer le relecteur et le redevable. Les inscrire dans le registre et dans la matrice RACI du processus.
5. Spécifier le dossier de revue. Écrire ce que le relecteur voit, dans quel ordre, avec quel temps par cas et quel motif de rejet.
6. Former les relecteurs. GOVERN 3.2 et MAP 3.5 demandent de former les personnes qui supervisent aux performances du système, au contexte d'usage, aux limites connues et aux effets négatifs connus. Vous trouverez comment préparer les équipes dans la page La conduite du changement.
7. Tester la supervision avant la mise en service. MAP 3.5 demande de tester la supervision dans des conditions proches de l'exploitation et d'évaluer sa validité et sa fiabilité. Pour un système critique ou à haut risque, le Playbook place cette évaluation avant le déploiement.
8. Suivre la revue humaine en exploitation. GOVERN 1.5 demande de surveiller la gestion des risques en continu, de la revoir à une fréquence fixée et d'en définir les responsabilités. Le redevable lit les indicateurs chaque mois. Il fait refaire le test après chaque changement de modèle, de données ou de fournisseur.
9. Documenter. Le registre, les résultats du test et les décisions du redevable forment la documentation que GOVERN 3.2 et MAP 3.5 demandent.

L'ordre des étapes est une synthèse. Les étapes 1 à 3 viennent de Parasuraman et de ses coauteurs. Les étapes 4 à 7 et 9 viennent du Playbook du NIST. L'étape 8 applique GOVERN 1.5. Ses indicateurs et le nouveau test après un changement de modèle relèvent de notre jugement. Goddard et ses coauteurs complètent l'étape 5. Vous trouverez la place du test de l'étape 7 dans la page Du prototype à la production.

Tester la supervision sur des cas à erreur connue

Un test de supervision mesure si les relecteurs attrapent les erreurs. Le redevable fait glisser dans la file de revue des cas à erreur connue: une facture qui dépasse la prescription, un document mal classé, une lettre qui cite le mauvais article. Les relecteurs ne savent pas lesquels. La part de ces cas que les relecteurs rejettent mesure la supervision. Le redevable fixe avant le test la part minimale. Vous trouverez comment écrire ce seuil dans la fiche Critères d'acceptation et d'évaluation. Une faible part de ces cas reste dans la file en exploitation.

Suivre la revue humaine

Une revue humaine se dégrade sans bruit. Les indicateurs du tableau la rendent visible. Aucune source ne fixe de seuil d'alerte. Le redevable fixe les siens à partir des premières semaines d'exploitation.

Ce qui fait échouer l'exercice

L'approbation par habitude

Bainbridge (1983) décrit l'ironie de l'automatisation. Le système existe parce qu'il fait le travail mieux que l'opérateur. L'opérateur doit pourtant vérifier qu'il fonctionne. Les études de vigilance qu'elle cite montrent qu'une personne ne garde pas son attention au-delà d'une demi-heure environ sur une source où il se passe peu de chose. Approuver chaque cas d'un système fiable produit donc des approbations sans lecture. Le remède réduit le nombre de points d'approbation, les réserve aux cas coûteux et ajoute des cas à erreur connue.

L'humain comme alibi

Green (2022) examine 41 politiques qui prescrivent une supervision humaine des algorithmes publics. Il relève deux défauts. Les données suggèrent que les personnes ne remplissent pas les fonctions de supervision attendues. Les politiques rendent des algorithmes défaillants acceptables et laissent les fournisseurs et les administrations se décharger de leur responsabilité. L'étude porte sur le secteur public. Le mécanisme vaut partout où une personne signe les résultats d'un système dont personne n'a justifié l'emploi. Le registre confie le résultat à un redevable distinct du relecteur. Le test sur des cas à erreur connue mesure si la revue attrape des erreurs.

La perte de compétence

Bainbridge note que les compétences manuelles se perdent quand elles ne servent plus. L'opérateur qui reprend la main sur une situation anormale a besoin de plus de compétence. Il a pourtant perdu la pratique. Un relecteur qui ne traite plus aucun dossier en entier ne sait plus juger le dossier douteux. Le registre prévoit une part de cas traités à la main ou une rotation entre la revue et le traitement manuel.

Le relecteur sans les moyens de juger

Un relecteur qui voit la proposition sans la source, sans le temps ou sans la formation approuve ce qu'il ne peut pas vérifier. MAP 3.5 et les besoins que listent Faas et ses coauteurs visent ce défaut. Le dossier de revue et le temps par cas le corrigent. Un rejet qui demande trois écrans de justification le fait revenir.

Le point de contrôle mal placé

Anthropic décrit des agents qui s'arrêtent pour un retour humain à des points de contrôle ou devant un blocage. Placer une approbation à chaque étape d'un agent produit l'approbation par habitude. Vous trouverez dans la page Chatbot, assistant, agent où placer la validation d'un agent.

Considérations IA

Un assistant conversationnel produit une première liste des décisions à partir d'une description du processus. Il propose le découpage de chaque décision en quatre fonctions et remplit les colonnes descriptives du registre. Il rédige des cas à erreur connue à partir de cas réels anonymisés: une facture qui dépasse la prescription, une lettre qui cite une disposition fausse. Il regroupe les motifs de rejet d'un mois de revue et signale ceux qui se répètent.

Le coût d'une erreur reste une saisie du métier. Vous trouverez pourquoi dans la fiche AI Canvas. L'assistant ne choisit ni le relecteur ni le redevable. Il ignore la charge des équipes et le temps dont elles disposent. La confiance qu'un modèle de langage exprime sur sa propre réponse ne remplace pas une fiabilité mesurée sur un échantillon.

Nous rangeons un second modèle qui vérifie le premier parmi les contrôles automatiques. Le registre inscrit alors la fonction sous «Aucune étape humaine par cas». Nous lisons aussi comme une recommandation l'explication qu'un modèle rédige pour sa propre proposition. Suivant la parade de Goddard et de ses coauteurs, le dossier de revue montre les faits extraits et leur source plutôt que cet argumentaire. Les cas réels et les motifs de rejet contiennent des données d'assurés. L'analyste ne les soumet qu'à un assistant que son organisation a validé.

Exemples

Une caisse maladie de Suisse romande trie ses documents entrants et contrôle ses factures avec des modèles. Le registre montre deux décisions du même modèle de tri avec deux modes différents. Les lignes 3a à 3d reprennent les quatre fonctions de la grille. Les valeurs sont inventées.

La cheffe du service juridique répond aussi des oppositions que personne n'a relues. Vous trouverez la revue d'une décision individuelle automatisée que la LPD accorde à l'assuré dans la page Spécifier les exigences d'une solution IA.

Visualisations

Le registre des décisions est un tableau: une ligne se lit pour une fonction d'une décision, une colonne pour comparer les modes ou les redevables. La grille des fonctions se dessine, parce qu'elle montre qu'une même décision occupe quatre positions différentes sur l'axe qui va du manuel à l'automatique. L'écran du relecteur se dessine aussi. L'ordre de ses blocs porte une parade au biais d'automatisation: les faits avant la proposition.

Coût

Outils

Un tableur suffit pour le registre et pour calculer le temps de revue. Dans un outil de modélisation BPMN, chaque approbation devient une tâche utilisateur. Un événement de bordure de type minuterie sur cette tâche fait remonter le cas qui attend au-delà du délai que fixe le redevable. Le temps par cas du registre devient la durée de la tâche quand l'outil simule le processus.

La file de revue est un outil de flux de travail ou de tickets. Elle doit enregistrer la décision, le motif de rejet et le temps passé par cas. Sans ce journal, les indicateurs de la revue humaine ne se calculent pas.

Les kits de développement d'agents fournissent le mécanisme d'approbation. Dans l'Agents SDK d'OpenAI, un outil marqué comme soumis à approbation met l'exécution en pause. L'appel en attente montre l'agent, l'outil et ses arguments. La personne approuve ou rejette l'appel. Un rejet peut porter un message. L'état de l'exécution se sauvegarde et reprend: le relecteur peut décider des heures après la pause.

Sources

Aucun référentiel ne décrit cette technique sous un nom unique. La procédure est une synthèse de sources primaires: le modèle de Parasuraman, Sheridan et Wickens pour la place et le degré du contrôle, le NIST AI RMF et son Playbook pour les rôles, le test, le suivi et la documentation. Les noms des modes de contrôle, l'ordre des étapes, le test sur des cas à erreur connue, les indicateurs de suivi et le nouveau test après un changement de modèle relèvent de notre jugement.

• Parasuraman, R., Sheridan, T. B. et Wickens, C. D. (2000), A model for types and levels of human interaction with automation, IEEE Transactions on Systems, Man, and Cybernetics, Part A, 30(3), p. 286-297: les quatre classes de fonctions, le continuum du manuel à l'automatique, le critère premier et les critères secondaires.
• NIST (2023), Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1: le cadre dont le Playbook détaille les actions.
• NIST, AI RMF Playbook, GOVERN: GOVERN 3.2 pour les rôles, la formation et les configurations entre personnes et IA; GOVERN 1.5 pour la surveillance continue, la revue périodique et le recours contre une décision du système.
• NIST, AI RMF Playbook, MAP: MAP 3.5 pour la définition, le test et la documentation de la supervision humaine; MAP 3.4 pour les experts du métier qui travaillent avec l'IA.
• Goddard, K., Roudsari, A. et Wyatt, J. C. (2012), Automation bias: a systematic review of frequency, effect mediators, and mitigators, JAMIA, 19(1), p. 121-127: les facteurs du biais d'automatisation et ses parades; la revue porte surtout sur l'aide à la décision clinique.
• Bainbridge, L. (1983), Ironies of automation, Automatica, 19(6), p. 775-779: la surveillance d'un système fiable et la perte des compétences manuelles dans l'industrie de procédés.
• Green, B. (2022), The flaws of policies requiring human oversight of government algorithms, Computer Law & Security Review, 45, 105681: les deux défauts des politiques de supervision humaine dans le secteur public.
• Faas, C., Kerstan, S., Uth, R., Langer, M. et Feit, A. M. (2025), Design considerations for human oversight of AI, arXiv:2510.19512, prépublication: les besoins des relecteurs selon quatre ateliers de co-conception.
• Anthropic, Building effective agents: les points de contrôle humains d'un agent.
• OpenAI, Agents SDK, Human-in-the-loop: la pause d'une exécution en attente d'approbation et sa reprise.