Au premier résultat douteux, qui peut suspendre votre pilote IA ?

01« Quelqu’un relira » ne désigne pas un responsable

« Quelqu’un relira » n’organise aucun contrôle. Cette formule ne dit ni ce qui doit être vérifié, ni selon quelle règle, ni dans quel délai. Elle ne précise pas davantage ce que le relecteur peut faire lorsqu’il juge le résultat inacceptable.

Valider le travail de l’IA suppose qu’une personne désignée puisse examiner le résultat, comprendre son contexte et décider de l’accepter, de le faire corriger ou d’en interdire l’utilisation. Placer quelqu’un à la fin du processus ne suffit pas. Cette personne doit disposer des informations nécessaires, de critères compréhensibles et du temps nécessaire pour les appliquer.

Le règlement européen sur l’intelligence artificielle^[1] donne la mesure de ce que « contrôler » signifie. Pour les systèmes classés à haut risque, la personne chargée du contrôle doit pouvoir comprendre les capacités et les limites du système, rester consciente du risque de se fier automatiquement ou excessivement à ses résultats, décider de ne pas l’utiliser ou d’écarter sa sortie et interrompre le système au moyen d’un bouton d’arrêt.^[2] Le déployeur, de son côté, confie cette surveillance à des personnes physiques disposant des compétences, de la formation, de l’autorité et du soutien nécessaires.^[3] Un pilote hors du champ des systèmes à haut risque n’est pas soumis à ces obligations, mais rien ne justifie de retenir une définition du contrôle moins exigeante que celle du législateur.

Le premier travail consiste à définir ce qui sera validé. Une synthèse documentaire, une recommandation, un classement et une proposition d’action n’ont pas les mêmes conséquences. La fiche de l’essai précise à quoi chaque résultat pourra servir : préparer un brouillon ou une décision, informer un client, mettre à jour un dossier ou déclencher une action. Le niveau de contrôle découle de cet usage, jamais de la nature de l’outil.

Le fonctionnement du pilote en cas d’absence doit être prévu dès le départ. Le pilote attend-il le retour du validateur, la validation est-elle confiée à un remplaçant ou faut-il revenir au processus habituel ? Un remplaçant qui ne connaît ni la règle ni les dossiers ne résout rien. Son rôle, son accès aux informations et son pouvoir se définissent avant le premier incident.

Pour éprouver l’organisation prévue, le validateur contrôle une sortie complète dans les conditions retenues pour l’usage quotidien. Le chronomètre démarre lorsqu’il ouvre le dossier et s’arrête lorsque sa décision est enregistrée. La recherche du contexte, les vérifications, les corrections et la justification du choix doivent être comptées dans le temps de contrôle. Mesurer la seule lecture laisserait ces tâches hors du calcul.

02Un brouillon interne ne se contrôle pas comme une réponse envoyée à un client

Toutes les sorties ne demandent pas la même surveillance. Une erreur repérable avant tout usage n’appelle pas le même contrôle qu’une recommandation susceptible d’influencer une décision concernant une personne. La possibilité de revenir en arrière, la gravité des conséquences et la disponibilité d’une source de vérification déterminent directement le travail du validateur.

Ces paliers organisent le travail ; ils ne remplacent pas la qualification juridique du système. Le règlement européen impose une analyse d’impact avant un traitement susceptible d’engendrer un risque élevé pour les droits et libertés des personnes.^[4] L’examen du pilote porte donc sur sa finalité, les données utilisées, son contexte et ses conséquences possibles afin de déterminer si cette condition est remplie. Lorsque des données personnelles alimentent le test, la finalité doit être définie dès la conception.^[10] L’entreprise doit aussi déterminer sa responsabilité au sens du RGPD.^[10]

Pour les systèmes d’IA à haut risque, la Commission européenne rappelle que le déployeur confie la supervision humaine à une personne de son organisation qui dispose des moyens et des compétences nécessaires pour exercer ce contrôle.^[5] L’organisation s’assure donc que la personne désignée dispose réellement des compétences et des moyens nécessaires et que son rôle ne figure pas seulement dans une fiche de poste.

Les réponses à ces questions déterminent le contrôle à prévoir avant le lancement du pilote.

Cette grille n’apporte pas une conclusion juridique automatique. Elle évite deux erreurs opposées : ignorer une qualification nécessaire ou imposer à toutes les sorties le contrôle le plus lourd. Chaque conclusion doit indiquer son auteur, sa date et le périmètre auquel elle s’applique.

03Qui valide, qui corrige et qui peut arrêter l’essai ?

Quatre responsabilités suffisent à clarifier l’essentiel, à condition de ne pas les confondre. Le validateur examine un résultat. Le responsable métier définit les critères à respecter et les utilisations autorisées. La personne chargée de la maintenance surveille les changements du système et organise les nouveaux essais. Le décideur engage les moyens, accepte les limites et peut suspendre le pilote.

Une même personne peut remplir plusieurs rôles dans une petite structure. Ce cumul doit rester explicite. Il faut vérifier qu’elle possède les compétences nécessaires, qu’elle dispose du temps prévu et qu’elle n’est pas amenée à approuver seule une règle qu’elle a elle-même modifiée lorsqu’une seconde validation est nécessaire.

Cette répartition évite de faire porter au validateur la qualité du système tout entier.

Le validateur n’a pas à résoudre une règle métier ambiguë. Il bloque la sortie et transmet la difficulté au responsable métier. Celui-ci précise le critère, mais ne décide pas seul de poursuivre un pilote dont le risque ou le coût a changé. La personne chargée de la maintenance traite la cause technique éventuelle, sans décider elle-même de ce qui est acceptable pour l’activité. Le décideur intervient lorsque le désaccord concerne plusieurs résultats ou remet en cause les conditions de l’essai.

Un registre léger suffit pendant un pilote. Son but n’est pas de documenter chaque geste, mais de répondre à quatre questions : qu’a-t-on contrôlé, quel écart a été trouvé, quelle décision a été prise et combien de temps l’opération a-t-elle demandé ? Le règlement européen prévoit également, pour les systèmes à haut risque, une durée minimale de conservation : les journaux générés automatiquement sont conservés pendant une durée adaptée à la finalité du système, qui ne peut être inférieure à six mois.^[3] Ces enregistrements servent notamment à identifier les situations où le système présente un risque et à contrôler son fonctionnement.^[1]

Chaque validation est reliée à la version de la règle appliquée. Sinon, une variation du résultat peut provenir du système, de la consigne, des données d’entrée ou du critère métier sans qu’il soit possible de les distinguer. Ce lien devient particulièrement utile après une correction ou une mise à jour.

Le registre sépare cinq types d’entrées.

Un incident n’est pas nécessairement une panne. Une sortie invérifiable, une règle contradictoire, une source indisponible, une erreur répétée ou une modification non testée justifient eux aussi une décision hors du contrôle ordinaire. Le registre indique la conséquence possible et le périmètre touché, sans imposer une échelle de gravité identique à tous les usages.

La mention « résolu » ne suffit pas. Il faut savoir quelle correction a été effectuée, quels essais ont été rejoués et qui a autorisé la reprise. Les contrôles courants, les reprises et les incidents restent séparés dans le suivi : une moyenne unique masquerait les épisodes rares qui mobilisent beaucoup d’expertise.

Cette exigence n’a rien de théorique.

Une organisation incapable de dire qui accède à quoi ne saura pas davantage dire qui a validé quoi.

Lorsque les responsabilités se chevauchent ou que personne ne peut expliquer le contrôle réellement exercé, un audit IA peut établir les usages, les risques et les règles à arbitrer ; il ne remplace ni un audit juridique ni un audit de cybersécurité.

04Le temps de vérification fait partie du coût de l’IA

La charge de contrôle ne se détermine pas à partir d’un pourcentage choisi avant l’essai. Elle se mesure sur les sorties réelles, avec les personnes qui assureront ce rôle après le pilote. La durée n’est qu’une partie du problème : un contrôle court peut rester impraticable s’il exige une compétence rare au moment précis où la sortie doit être utilisée.

1. 01

   Recenser les sorties

   Recensez les types de résultats, leurs usages autorisés et le contrôle prévu pour chacun.

2. 02

   Chronométrer le contrôle complet

   Chronométrez le contrôle depuis l’ouverture du dossier jusqu’à l’enregistrement de la décision, avec le contexte réellement disponible.

3. 03

   Isoler les reprises

   Séparez la vérification ordinaire du temps consacré à corriger ou à refaire une sortie.

4. 04

   Ajouter le temps consacré aux incidents et à la maintenance

   Ajoutez le temps consacré à qualifier les incidents, à effectuer les corrections, à mener les nouveaux essais et à suivre les changements.

5. 05

   Comparer la charge au travail évité

   Comparez la charge complète au temps réellement gagné, jamais à une estimation.

Le gain net correspond au travail évité, dont il faut retrancher le contrôle, les corrections, les incidents, la maintenance et le temps de décision. Il se calcule par type de sortie : un grand nombre de productions simples masquerait autrement quelques cas rares dont la vérification mobilise une expertise importante.

Le suivi indique également qui effectue le contrôle et à quel moment. Si le contrôle doit intervenir avant l’envoi d’un dossier, une disponibilité tardive ne suffit pas. Lorsque la supervision entre en concurrence avec l’activité principale du validateur, ce coût doit être pris en compte dans la décision.

Si le contrôle absorbe le gain annoncé, la réponse n’est pas forcément l’abandon de tout usage de l’IA. L’entreprise peut réduire le périmètre, réserver la sortie à la préparation d’une décision, améliorer les moyens de vérification ou revenir au processus habituel. Le pilote n’est viable que dans la configuration réellement mesurée.

05Simuler une erreur pour voir si chacun sait réagir

Une répartition des responsabilités peut sembler claire tant que rien ne se passe. Une simulation courte montre si elle fonctionne lorsqu’une sortie est contestée. Le scénario reste plausible et porte sur une sortie qui n’a pas encore été utilisée.

Le cas suivant est hypothétique et ne décrit aucune entreprise réelle. Un assistant prépare des réponses types aux réclamations reçues par un service client, sans jamais les envoyer. Le validateur repère une réponse cohérente en apparence, mais dont le montant de garantie cité ne peut être retrouvé dans aucune source interne. Il bloque cette sortie et signale les réponses produites le même jour, susceptibles de présenter le même défaut. Le responsable métier vérifie si la règle d’acceptation précise l’obligation de retrouver toute valeur citée dans une source interne, et la complète si ce n’est pas le cas. La personne chargée de la maintenance recherche un changement du système ou de ses dépendances et prépare les essais nécessaires. Le décideur fixe l’étendue de la suspension si plusieurs sorties ou une activité entière sont concernées.

La simulation échoue si le résultat continue de circuler, si le validateur doit obtenir un accord informel pour le bloquer, si personne ne définit les sorties touchées ou si la reprise intervient avant les nouveaux essais. Chaque échec révèle une correction précise à apporter au pilote.

Le temps consacré à cette séquence doit être compté dans la charge de supervision. L’exclure reviendrait à n’évaluer que les semaines sans difficulté, alors que les incidents sont précisément les moments où l’organisation doit prouver qu’elle garde le contrôle.

Un résultat correct aujourd’hui ne prouve pas que le système fonctionnera aussi bien après une modification. Une règle métier, une source, une consigne, un connecteur ou le modèle utilisé peuvent changer. La personne chargée de la maintenance doit savoir quels signaux surveiller et quels essais rejouer. Le responsable métier intervient si le changement touche les critères d’acceptation ; le décideur intervient s’il modifie le risque, le coût ou le périmètre autorisé.

Les conditions d’arrêt exigent la même précision. « Suspendre en cas de problème » ne désigne ni le problème, ni l’action, ni l’autorité compétente. Une clause utile relie un événement observable à une réponse immédiate et à une condition de reprise.

Chaque condition d’arrêt relie un fait observable à une réponse et à une condition de reprise.

La décision doit être communiquée à toutes les personnes concernées. Une suspension connue du décideur mais ignorée par les utilisateurs ne protège pas l’activité. Le registre précise donc qui diffuse l’information, quelles sorties sont bloquées et comment les dossiers en attente seront traités.

Le retour au processus habituel fait partie du pilote. Les informations à conserver, le traitement des sorties en cours et la personne chargée de confirmer le retour au processus habituel sont définis à l’avance. Si ce retour ne peut pas être exécuté dans les conditions prévues, le pilote ne respecte pas encore sa propre procédure d’arrêt.

06Le gain doit subsister après les vérifications

Le pilote ne peut être généralisé que si chaque type de sortie autorisé est associé à une règle, à un validateur et à une possibilité de blocage, et si le gain subsiste après le temps consacré aux vérifications, aux corrections, aux incidents, à la maintenance et aux décisions.

Avant de généraliser, il faut pouvoir documenter une semaine complète de fonctionnement, un contrôle chronométré et un incident simulé. Le responsable métier définit et approuve les critères d’acceptation. Le validateur les applique à chaque sortie et consigne son verdict. La personne chargée de la maintenance sait détecter un changement et rejouer les essais prévus. Le décideur peut suspendre le périmètre concerné et organiser le retour au processus habituel.

Le cadre de gestion du risque publié par le NIST rappelle que la réponse à un risque peut consister à le réduire, le transférer, l’éviter ou l’accepter.^[9] Le coût de la supervision doit donc être traité comme l’un des risques du pilote. La fréquence des projets engagés ne prouve pas davantage leur solidité. En 2024, 70 % des organismes publics britanniques interrogés par le National Audit Office expérimentaient ou planifiaient des cas d’usage de l’IA.^[12] Ce chiffre renseigne sur les intentions, pas sur le contrôle réellement exercé.

Une condition manquante ne doit pas disparaître dans une appréciation moyenne. Elle impose de corriger le pilote, d’en réduire le périmètre ou d’accepter explicitement une limite. La supervision n’est pas une formalité ajoutée à la fin du projet : elle détermine ce que l’entreprise peut réellement utiliser sans perdre la maîtrise de ses décisions.

Avant de décider de la suite, nommez le validateur, chronométrez un contrôle complet et simulez la suspension de l’usage lorsqu’un résultat est contesté. Si l’un de ces trois gestes reste impossible, le pilote n’est pas prêt à être prolongé.