Supervision humaine : la concevoir, pas la promettre

« 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.

Voir et comprendre sont des problèmes d'interface, et ils se règlent. Avoir le temps est un problème de dimensionnement, et c'est celui qu'on néglige.

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.

Le règlement européen exige, pour les systèmes à haut risque, que la supervision humaine soit effective, que la personne puisse comprendre les capacités et limites du système, rester attentive au biais d'automatisation, et décider de ne pas l'utiliser.

Ce qu'il 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.

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.

Les deux se tiennent. Un périmètre trop large produit un volume de validation ingérable, qui vide la supervision de son contenu. Restreindre le périmètre, c'est aussi rendre la supervision possible. Voir le périmètre avant l'autonomie.

Des cas où un humain a effectivement refusé une proposition du système, avec la trace de ce refus. 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é. La méthode de collecte figure dans préparer un contrôle de conformité en deux semaines.

La troisième condition, avoir le temps, se vérifie par un calcul simple : nombre de dossiers par jour multiplié par le temps nécessaire pour juger. Si le produit dépasse la journée de travail, la supervision est fictive.

Ce calcul est rarement fait, et il tranche immédiatement. Un gestionnaire qui traite quarante dossiers par jour dispose de quelques minutes par dossier, tout compris. Une supervision qui demande dix minutes d'examen n'est pas tenable.

Deux issues alors : réduire le volume soumis à validation en n'y faisant remonter que les cas incertains, ou augmenter les moyens. La première est presque toujours la bonne, et elle suppose que le système sache dire quand il doute, le sujet de le refus de répondre est une fonctionnalité.

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.