Définition en une phrase
Diseño que reserva a una persona una revisión, decisión o autorización dentro de un proceso automatizado.
Définition : une intervention humaine à un point défini
L’humain dans la boucle, ou *human-in-the-loop* (HITL), est un modèle de conception dans lequel une personne participe à une étape définie du fonctionnement d’un système automatisé. Elle peut examiner des informations, classer un cas, corriger un résultat, autoriser une action ou fournir un retour d’expérience. Le terme décrit la participation humaine au processus, mais ne détermine pas, à lui seul, la tâche de la personne ni l’étendue de son autorité.
Dire qu’un système est HITL ne signifie donc pas nécessairement qu’une personne examine chaque entrée et chaque résultat. L’intervention peut être réservée aux cas incertains, avoir lieu avant une action précise ou fournir des informations destinées à une étape ultérieure. Pour comprendre la conception, il faut préciser le point d’intervention, les choix offerts à la personne et ce qu’il advient de sa décision.
Les définitions générales consultées décrivent HITL comme une participation humaine au cycle de vie de l’apprentissage automatique, ou au fonctionnement, à la supervision et à la prise de décision d’un processus. Ce sont des formulations générales, et non une spécification technique unique ni une garantie de qualité.
À quels moments une personne peut-elle intervenir ?
L’intervention peut se situer à différentes étapes. Lors de l’examen des entrées, la personne vérifie ou complète des données avant leur traitement par le système. Lors de l’examen des résultats, elle évalue une recommandation ou une classification avant son utilisation. Dans le cadre d’une autorisation préalable, elle décide si une action peut être exécutée. Pendant le fonctionnement, elle peut surveiller le processus et agir lorsqu’une exception survient. Enfin, son retour d’expérience peut servir à réviser des règles ou à préparer des améliorations ultérieures.
Ces fonctions ne sont pas interchangeables. Examiner une réponse ne signifie pas avoir le pouvoir de la bloquer ; approuver une transaction n’équivaut pas à vérifier comment ses données ont été extraites ; et recevoir une notification ne signifie pas disposer du temps et des moyens nécessaires pour intervenir. Une conception claire distingue la tâche humaine de la tâche automatisée et précise le résultat produit par chacune.
Il faut également définir ce qui se passe si la personne n’est pas disponible, ne répond pas ou conteste la décision du système. Si l’opération se poursuit automatiquement après un délai, cette règle fait partie de la conception. Si elle est suspendue, il faut indiquer qui est chargé de débloquer la situation. Sans ces précisions, l’expression HITL laisse de côté une question pratique importante.
Cartographie des décisions possibles
| Point d’intervention | Actions possibles de la personne | Éléments à préciser |
|---|---|---|
| Avant le traitement | Examiner ou compléter une entrée | Quelles données sont visibles et quelles modifications peuvent être enregistrées |
| Avant l’utilisation d’un résultat | Corriger, accepter ou rejeter une recommandation | Le système attend-il la décision ou poursuit-il son exécution ? |
| Avant l’exécution d’une action | Autoriser, refuser ou demander un examen supplémentaire | Quelle est l’autorité de la personne et comment sa décision est-elle consignée ? |
| Lorsqu’une exception survient | Enquêter, arrêter ou transmettre le cas | Quels signaux déclenchent l’intervention et qui doit répondre ? |
| Après le résultat | Fournir un retour sur le cas | Le retour modifie-t-il une règle, un processus ou un modèle ? |
Comment fonctionne le cycle d’intervention ?
Un cycle HITL doit pouvoir être décrit de bout en bout. D’abord, le système repère le cas qui nécessite une intervention humaine, ou présente tous les cas si telle est la politique retenue. Ensuite, il fournit à la personne les informations nécessaires pour évaluer la situation. Celle-ci dispose d’une ou plusieurs actions précises. Enfin, le système applique, consigne ou transmet la décision selon des règles définies à l’avance.
L’interface et le contexte comptent autant que l’existence d’une étape d’examen. Si la personne ne voit qu’un score sans explication de ses limites, si des données importantes manquent ou si la différence entre une recommandation et une décision déjà prise n’est pas claire, elle risque de ne pas être en mesure d’évaluer le cas. La conception devrait permettre de comprendre ce qui est proposé, ce qui reste en suspens et les conséquences d’une acceptation ou d’un refus.
Une mise en œuvre technique peut suspendre une exécution dans l’attente d’une décision humaine. Par exemple, la documentation de LangChain décrit un mécanisme capable de mettre en pause des appels à des outils jusqu’à ce qu’une personne prenne une décision. Ce mécanisme illustre une façon précise d’introduire une pause ; il ne définit pas universellement HITL et ne démontre pas, à lui seul, que l’examen convient à tous les processus.
Processus à documenter
- 01Définir l’événement qui déclenche l’intervention : tous les cas, une exception ou un seuil déterminé.
- 02Préciser quelles informations sont communiquées à la personne et quels éléments peuvent manquer ou être incertains.
- 03Énumérer les actions autorisées : accepter, corriger, rejeter, transmettre, arrêter ou annuler.
- 04Expliquer ce que fait le système après chaque action et ce qui se passe en l’absence de réponse.
- 05Consigner qui a pris la décision, à quel moment et à partir de quelles informations.
Trois exemples concrets
Les scénarios suivants sont des exemples de conception et ne décrivent pas le fonctionnement d’un service particulier. Dans chacun d’eux, le travail automatisé est distingué de la décision qui reste du ressort d’une personne. Cette distinction permet de vérifier si l’intervention est réelle ou si elle se limite à la possibilité formelle de transmettre un cas.
blocks
Notions proches à distinguer
HITL est une étiquette générale qui désigne la participation humaine à un processus. Il ne faut pas automatiquement la traiter comme un synonyme de la supervision humaine au sens réglementaire. La supervision peut être soumise à des exigences particulières selon le contexte et le cadre applicable ; les sources examinées ici ne suffisent pas à décrire des obligations juridiques précises. Cette fiche présente donc un modèle de conception, et non une détermination de conformité réglementaire.
On rencontre aussi les expressions *human-on-the-loop* pour décrire une personne qui observe le fonctionnement et peut intervenir, et *human-out-of-the-loop* pour un processus qui fonctionne sans intervention humaine individuelle à cette étape. Ces expressions servent de repères généraux, mais leur usage n’est pas uniforme. Dans une mise en œuvre concrète, il est plus précis de décrire les actions, l’autorité et le moment de l’intervention que de s’en remettre au seul nom du modèle.
L’intervention en production doit être distinguée des retours humains utilisés pour développer ou ajuster un modèle. Dans le RLHF — l’apprentissage par renforcement à partir de retours humains — la contribution humaine intervient pendant une phase d’entraînement ou d’ajustement. Le fait que des personnes aient fourni des retours à ce stade ne signifie pas qu’une personne examine chaque décision du système en cours d’utilisation. À l’inverse, une personne peut intervenir en production sans que sa décision serve à entraîner un modèle.
L’apprentissage actif est lui aussi distinct : il désigne, de manière générale, une stratégie de sélection d’exemples susceptibles de bénéficier d’un étiquetage ou d’un examen. Cette sélection peut faire appel à des personnes, mais ne détermine pas, à elle seule, qui a autorité sur une action opérationnelle. Les sources vérifiées pour cette fiche ne proposent pas de comparaison technique détaillée entre l’apprentissage actif et le RLHF ; ces distinctions sont donc des repères conceptuels et non une taxonomie complète.
Ne pas confondre présence humaine et fonction humaine
| Notion | Question à laquelle elle répond | Ce qu’elle ne permet pas de conclure à elle seule |
|---|---|---|
| HITL | À quel moment une personne participe-t-elle ? | Qu’elle examine chaque cas ou dispose d’une autorité suffisante |
| Supervision humaine | Comment un système est-il supervisé, et sous quelles conditions ? | Qu’un modèle unique s’applique à tous les contextes |
| RLHF | Des retours humains sont-ils utilisés pendant l’entraînement ou l’ajustement ? | Qu’il existe un examen humain de chaque résultat en production |
| Apprentissage actif | Quels exemples sont sélectionnés pour être examinés ou étiquetés ? | Que la personne autorise les actions du système |
Limites et erreurs fréquentes
La présence d’une étape humaine ne garantit pas, à elle seule, qu’un système soit sûr, précis, efficace ou conforme à une règle. Pour repérer un problème, une personne doit disposer d’informations pertinentes, de temps, de compétences adaptées et de l’autorité nécessaire pour agir. Si l’un de ces éléments manque, l’intervention peut figurer dans le schéma du processus sans fonctionner comme une vérification effective.
Un risque de conception consiste à supposer qu’une personne détectera toutes les erreurs simplement parce qu’elle peut examiner une recommandation. Elle peut manquer de contexte, devoir traiter trop de cas ou ne pas disposer d’une option claire pour refuser la recommandation. Il peut aussi exister une pression à accepter le résultat automatisé, ou une procédure de transmission qui ne débouche sur aucune résolution. Ce sont des limites possibles à évaluer dans chaque environnement ; les sources consultées ne permettent ni d’en mesurer la fréquence ni d’en quantifier les effets.
Une autre erreur consiste à utiliser l’examen humain comme une étiquette générale sans en préciser la portée. « Une personne est dans la boucle » ne dit pas si elle voit tous les cas, uniquement les exceptions ou un échantillon ; si elle intervient avant ou après l’action ; ni qui répond d’une décision. Cela ne précise pas non plus comment corriger un résultat erroné ni si une action peut être annulée.
Enfin, il faut éviter de confondre supervision et approbation. Une personne qui peut observer un écran sans pouvoir arrêter une action n’a pas le même rôle qu’une personne dont l’autorisation est nécessaire. De même, une personne disponible pour recevoir un cas transmis n’équivaut pas à une personne désignée, informée et capable de le résoudre.
Critères pratiques pour décrire une conception HITL
Pour évaluer ou documenter un système, indiquez le point précis où la personne intervient et l’événement qui déclenche cette intervention. Précisez si sa participation est obligatoire, sélective ou postérieure à l’action. Si seuls les cas exceptionnels sont examinés, expliquez comment ils sont identifiés et quels cas risquent d’échapper à l’examen.
Précisez les informations visibles par la personne, les options dont elle dispose et l’autorité qui soutient ces options. Une recommandation pouvant être acceptée, corrigée ou rejetée nécessite des contrôles différents d’une alerte qui peut seulement être acquittée. Il est également utile d’indiquer qui peut suspendre le processus, demander un second examen ou annuler une action.
Décrivez ce qui se passe si la personne ne répond pas, n’est pas disponible ou n’est pas d’accord avec le système. Définissez des délais de réponse adaptés au processus, sans supposer qu’un délai unique convienne à tous les contextes. Consignez les décisions et les changements de façon à pouvoir reconstituer qui est intervenu, sur la base de quelles informations et avec quel résultat.
Dans l’ensemble, une description utile répond à six questions : où la personne intervient-elle ? Que voit-elle ? Que décide-t-elle ? Que peut-elle modifier ? Que se passe-t-il en cas d’exception ou d’absence de réponse ? Comment vérifie-t-on si le mécanisme fonctionne comme prévu ? Ces questions rendent explicites les responsabilités que l’étiquette, à elle seule, ne précise pas.
Liste de vérification
- 01Point : à quelle étape du processus l’intervention a-t-elle lieu ?
- 02Contexte : quelles informations et quelles limites sont présentées à la personne chargée de l’examen ?
- 03Autorité : peut-elle corriger, rejeter, autoriser, arrêter ou annuler ?
- 04Exceptions : que se passe-t-il en cas de désaccord ou d’absence de réponse ?
- 05Traçabilité : la décision et son résultat sont-ils consignés ?
- 06Évaluation : quels éléments permettraient de vérifier si l’examen atteint son objectif ?
Portée des sources
Les sources vérifiées pour cette fiche comprennent des explications générales de HITL, une publication institutionnelle sur les mécanismes d’intervention et la documentation technique d’un mécanisme précis qui suspend des appels à des outils dans l’attente d’une décision humaine. Leur portée diffère : une définition introductive n’équivaut pas à une norme, et la documentation d’un produit ne prescrit pas la conception de tous les systèmes.
Aucune source réglementaire n’a été fournie pour résumer des obligations juridiques précises, et aucun élément ne mesure l’efficacité des exemples hypothétiques ou la fréquence des risques décrits. La fiche ne prétend donc pas qu’une conception HITL satisfait à des exigences réglementaires, ni que la participation humaine améliore nécessairement les résultats. Les catégories et les exemples servent à formuler des questions de conception auxquelles il faut répondre en s’appuyant sur des éléments adaptés au contexte.
