Le human-in-the-loop (HITL) est un patron de conception dans lequel un système ne peut pas franchir un certain point sans une intervention humaine explicite. La personne examine, approuve, corrige ou rejette, et le système continue en fonction de cette réponse.
Origine du terme
L'expression vient des systèmes de contrôle et de l'apprentissage automatique, où un humain était nécessaire pour étiqueter des données ou valider les sorties d'un modèle. Dans le développement logiciel moderne, elle a été adoptée plus largement pour décrire tout flux de travail où l'automatisation est délibérément interrompue pour une revue humaine.
Pourquoi les systèmes sont conçus ainsi
L'automatisation complète n'est pas toujours appropriée. Les raisons d'insérer une étape humaine entrent généralement dans quelques catégories :
- Risque : la conséquence d'une action erronée est suffisamment élevée pour justifier le coût d'une pause. Un paiement au-dessus d'un seuil, un déploiement en production, une suppression d'enregistrements.
- Incertitude : le système a peu de confiance dans sa sortie et le signale plutôt que de supposer.
- Réglementation : certains domaines exigent une décision humaine par la loi ou par politique. Décisions de crédit, recommandations médicales, certaines opérations de traitement de données.
- Cas limites : l'entrée sort de la plage que le système a été conçu pour traiter de façon fiable.
Ce patron accepte un débit moindre en échange d'un taux d'erreur réduit sur les décisions importantes.
Le HITL dans les systèmes assistés par l'IA
À mesure que davantage de logiciels en production intègrent des sorties générées par des modèles, qu'il s'agisse de suggestions, de résumés, de classifications ou d'actions, le HITL est devenu une préoccupation architecturale standard plutôt qu'un cas limite.
Un agent de codage IA peut proposer une pull request, mais un humain la relit et la fusionne. Un pipeline RAG peut retourner une réponse, mais un agent support la lit avant de l'envoyer. Un flux de travail agentique peut exécuter une séquence d'étapes, mais requiert une confirmation avant des effets de bord tels que l'envoi d'e-mails ou la modification d'une base de données.
La question de conception est de savoir à quel endroit du flux placer les humains et quelles informations leur donner à ce moment-là. Y avoir recours ou non est rarement le sujet.
Ce qui rend une étape HITL utile ou inutile
Un point de contrôle humain ne fonctionne que si la personne qui l'examine peut réellement évaluer ce qui se trouve devant elle. Cela semble évident, mais cela échoue en pratique lorsque :
- La sortie est trop longue ou trop complexe pour être lue dans le temps disponible.
- Le relecteur n'a pas les connaissances du domaine pour repérer les erreurs.
- L'approbation est devenue une formalité et les personnes valident sans lire.
- Le système ne fournit aucune explication sur la façon dont il est parvenu à son résultat, ce qui ne laisse rien sur quoi s'appuyer au relecteur.
Lorsque le HITL devient un simple tampon, il donne l'apparence d'une supervision sans en avoir la substance. Il s'agit d'un problème d'ingénierie et d'organisation à part entière, pas seulement d'un problème d'UX.
Schémas d'implémentation
Les approches courantes comprennent :
- Files d'approbation : le système inscrit une action proposée dans une file ; un humain traite les éléments de la file avant leur exécution.
- Seuils de confiance : le système achemine automatiquement les résultats à haute confiance et signale les résultats à faible confiance pour révision.
- Chemins d'escalade : le système tente une résolution de façon autonome et fait appel à un humain uniquement lorsqu'il ne peut pas avancer.
- Journaux d'audit avec retour arrière : le système agit immédiatement mais enregistre tout et permet une annulation dans un délai donné. Il s'agit d'un HITL après les faits plutôt qu'avant.
Le bon schéma dépend de la tolérance à la latence, du niveau de risque et du volume de décisions que le système traite.
Le lien avec la revue de code
La revue de code est elle-même un mécanisme HITL appliqué aux modifications logicielles. À mesure que le code généré par l'IA représente une part croissante de ce qui est intégré, l'étape de révision devient plus importante, et non moins. Le relecteur est l'humain dans la boucle pour le résultat de l'agent de codage. Ce que cela exige des ingénieurs a quelque peu évolué ; voir ce qui a changé dans la revue de code pour plus de détails.
Ce que nous évaluons
La conception HITL reflète le jugement d'un ingénieur sur l'endroit où l'automatisation doit s'arrêter et ce qu'un relecteur a réellement besoin de voir. Notre sélection porte directement sur cet aspect. Lors de la session 1, la priorisation et la compréhension technique révèlent si quelqu'un est capable de structurer un problème avant de le traiter. Lors de la session 2, la vérification des sorties IA et le jugement par niveau de risque montrent si la personne ralentit de manière appropriée lorsqu'un agent produit quelque chose de conséquent, plutôt que de l'approuver parce que cela fonctionne. Voir how we vet.
Réponses courtes
L'humain dans la boucle est-il la même chose que l'apprentissage supervisé ?
Pas exactement. L'apprentissage supervisé utilise des données étiquetées par des humains pour entraîner des modèles. Le HITL en ingénierie désigne des flux de travail en production où une personne doit agir avant que le système ne poursuive. Les concepts se recoupent dans les pipelines d'apprentissage actif, mais sont par ailleurs distincts.
L'ajout d'une étape humaine rend-il un système plus sûr ?
Seulement si le relecteur est en mesure d'évaluer la décision de façon significative. Un point de contrôle où les personnes approuvent systématiquement sans lire n'offre qu'une protection limitée. La qualité de l'étape humaine compte autant que sa présence.
Quand un système devrait-il supprimer une étape HITL qu'il possédait auparavant ?
Lorsqu'il existe des preuves, généralement issues des journaux d'audit ou des taux d'erreur, que l'étape humaine ajoute de la latence sans détecter d'erreurs. Ces preuves doivent provenir de mesures, et non d'hypothèses.
