Supervision humaine : la concevoir, pas la promettre

Une supervision humaine effective sur un système d’IA est un dispositif où une personne voit l’action projetée, dispose du contexte pour la juger et a le temps de la refuser, dans ses conditions réelles de travail. Si l’une de ces trois conditions manque, il reste une étape de validation, pas une supervision.

« Un humain valide avant envoi. » Cette phrase figure dans presque toutes les notes de conception que je relis. Elle ne décrit pourtant aucun dispositif.

La question n’est pas de savoir si une étape de validation existe dans le flux. Elle est de savoir si, dans les conditions réelles de travail, la personne qui valide peut effectivement refuser.

Les trois conditions se formulent simplement :

• Voir : l’action projetée est présentée avant qu’elle ne se produise, et non constatée après coup dans un journal.
• Comprendre : la personne dispose des éléments sur lesquels le système s’est appuyé, la source citée, les données lues, la règle appliquée.
• Avoir le temps : le volume soumis et le temps nécessaire pour juger tiennent dans sa journée de travail, avec ses autres tâches.

Les deux premières relèvent de l’interface. La troisième relève de l’organisation, et c’est elle que les projets oublient.

Le temps disponible est la condition qui casse parce qu’il dépend du volume réel de production, que personne ne mesure au cadrage, alors que voir et comprendre se règlent par l’interface. On dessine un bel écran de validation, et on oublie de compter combien de fois par jour il s’ouvrira.

J’ai vu un dispositif où un opérateur recevait environ deux cent cinquante propositions par jour à valider. Le temps disponible par élément était inférieur à dix secondes. Personne n’a jamais refusé quoi que ce soit : non par négligence, mais parce que refuser exigeait d’ouvrir le dossier, ce qui prenait deux minutes.

Le dispositif était conforme sur le papier et inexistant en pratique.

Une supervision humaine est tenable si le nombre de dossiers soumis par jour, multiplié par le temps nécessaire pour juger chacun, reste nettement inférieur à la journée de travail de la personne qui valide. Si le produit dépasse la journée, la supervision est fictive, quoi qu’en dise la documentation.

La méthode tient en cinq étapes :

1. Compter le volume journalier que le système soumettra à validation, sur la base du flux réel et non d’un échantillon de démonstration.
2. Chronométrer le temps de jugement sur une trentaine de cas réels, avec la personne qui validera, y compris les cas où il faut ouvrir le dossier source.
3. Multiplier, puis comparer au temps que cette personne peut réellement consacrer à la tâche, en retirant ses autres activités.
4. Si le résultat ne tient pas, réduire le volume soumis plutôt que le temps par cas : ne faire remonter que les cas incertains.
5. Rejouer le calcul après la mise en service, car le volume et la difficulté des cas évoluent.

Un gestionnaire qui traite quarante dossiers par jour dispose de quelques minutes par dossier : une supervision qui demande dix minutes d’examen n’est pas tenable. Entre réduire le volume soumis et augmenter les moyens, la première issue est presque toujours la bonne, et elle suppose que le système sache dire quand il doute. C’est le sujet de le refus de répondre est une fonctionnalité.

L’AI Act exige, pour les systèmes à haut risque, une supervision humaine effective : la personne désignée doit comprendre les capacités et limites du système, rester attentive au biais d’automatisation et pouvoir décider de ne pas l’utiliser. Elle doit aussi pouvoir ignorer, corriger ou annuler un résultat, et interrompre le système.

Ce que le règlement ne fait pas, c’est vous dire comment le prouver. C’est là que la journalisation du temps de décision et du taux de refus devient précieuse : ce sont des mesures, pas des déclarations, et ce sont elles qu’on peut présenter.

Deux conséquences pratiques en découlent pour l’ingénieur. D’abord, l’interface doit rendre ces gestes possibles : un refus, une correction, un arrêt, chacun accessible sans détour. Ensuite, la personne qui supervise doit avoir été formée au fonctionnement du système et à ses limites, ce qui rejoint l’obligation de maîtrise de l’IA déjà applicable, décrite dans la littératie IA, l’obligation passée inaperçue.

Le détail de ce qu’il faut livrer côté technique figure dans AI Act en vigueur : ce que l’ingénieur doit livrer. Pour un système existant, un audit IA permet de vérifier si la supervision décrite correspond à celle qui s’exerce.

Pour résister au biais d’automatisation, une supervision ne doit soumettre que les cas incertains, compléter par un contrôle par échantillon et introduire volontairement des cas de contrôle connus. Une personne qui valide cent propositions correctes d’affilée cesse de regarder la cent unième.

Ce biais est documenté et il ne se corrige pas par la consigne. La conception doit en tenir compte. Faire remonter systématiquement tout ce que le système produit garantit l’endormissement. Faire remonter uniquement les cas incertains maintient l’attention, parce que chaque cas soumis mérite réellement un examen.

J’ajoute un contrôle par échantillon sur les cas non soumis, pour vérifier que le système ne se trompe pas là où il est confiant. Ce double dispositif est celui que je décris dans écrire la fiche d’un système d’IA.

Les cas de contrôle sont le troisième levier : des propositions volontairement fausses, glissées dans le flux, dont on vérifie qu’elles sont bien refusées. Une direction des achats peut ainsi mêler quelques rapprochements erronés entre factures et commandes. Un cas de contrôle validé sans objection est un signal plus fiable que n’importe quel questionnaire.

Ces cas de contrôle s’appuient sur le même matériau que l’évaluation continue : un jeu de cas dont la réponse attendue est connue.

Les erreurs qui rendent une supervision humaine fictive sont presque toujours des erreurs de conception : tout soumettre, rendre le refus coûteux, cacher la source, et confier la validation à quelqu’un qui n’a pas l’autorité de refuser. Aucune ne se voit dans la documentation.

• Tout soumettre à validation. Le volume étouffe l’attention et transforme la relecture en geste réflexe.
• Rendre le refus plus coûteux que l’acceptation. Si refuser exige trois écrans et un commentaire libre, la validation l’emporte.
• Présenter la proposition sans ses éléments. Sans la source ou la donnée lue, la personne ne juge que la vraisemblance du texte.
• Désigner un valideur sans autorité. Un opérateur qui ne peut pas bloquer un dossier sans en référer à sa hiérarchie ne supervise pas.
• Mesurer la satisfaction plutôt que les refus. Un relecteur satisfait n’est pas un relecteur attentif ; les indicateurs utiles sont décrits dans mesurer l’adoption, pas la satisfaction.
• Négliger la formation des valideurs. Superviser un système suppose de connaître ses modes d’échec typiques, ce qu’une formation IA orientée exploitation doit couvrir.

Le périmètre d’un agent conditionne la supervision humaine parce qu’il fixe le volume et la nature des actions à valider : un périmètre trop large produit un flux ingérable qui vide la supervision de son contenu. Restreindre le périmètre, c’est aussi rendre la supervision possible.

Cette réflexion est le prolongement direct de celle sur les agents : ce qui n’est pas réversible doit passer par un humain, et cet humain doit avoir les moyens de son rôle. Voir le périmètre avant l’autonomie.

Le classement des actions par réversibilité donne un ordre de priorité. Ce qui se rattrape sans conséquence peut être automatique. Ce qui engage l’organisation doit être validé, avec un dimensionnement réel. Ce qui ne se rattrape jamais ne se délègue pas, comme le développe ce qu’on ne délègue jamais à un modèle.

La preuve qu’une supervision humaine fonctionne, ce sont des cas où un humain a effectivement refusé une proposition du système, avec la trace horodatée de ce refus et de sa raison. C’est ce qu’un contrôle cherche, et cela se collecte plutôt que cela ne se rédige.

Sur un système supervisé traitant plusieurs milliers de dossiers, ces cas existent nécessairement. S’ils n’existent pas, deux explications, toutes deux importantes : soit le système ne se trompe jamais, ce qui est improbable, soit la validation est une formalité.

Dans les deux cas, le constat est plus utile que le document qu’on aurait rédigé. Trois éléments composent le dossier : le journal des décisions avec leur durée, la liste des refus avec leur motif, et les résultats des cas de contrôle. La méthode de collecte figure dans préparer un contrôle de conformité en deux semaines.