AI Act : contrôle humain d’une IA à haut risque (article 14)

L’article 14 du règlement (UE) 2024/1689 (AI Act, le règlement européen sur l’intelligence artificielle) impose qu’un système d’IA (intelligence artificielle) à haut risque puisse être effectivement contrôlé par des personnes physiques pendant toute sa période d’utilisation. Le texte ne fixe ni taux de revue, ni délai, ni interface type : il décrit des capacités. Cette page les traduit en exigences d’architecture, d’interface et d’exploitation, et tranche là où le règlement reste muet.

→ Lire l’explication complète de la marmotte

Ce que l’article 14 exige, et à partir de quand

Le texte tient en cinq paragraphes. Le §1 pose l’obligation de conception : le système permet un contrôle effectif par des personnes physiques, « notamment au moyen d’interfaces homme-machine appropriées ». Le §2 en donne la finalité : prévenir ou réduire au minimum les risques pour la santé, la sécurité et les droits fondamentaux, y compris en cas de mauvaise utilisation raisonnablement prévisible, et surtout quand ces risques persistent malgré les autres exigences de la section 2 (articles 9 à 15). Le §3 rend les mesures proportionnées aux risques, au niveau d’autonomie et au contexte d’utilisation. Le §4 liste les capacités du superviseur. Le §5 ajoute une double vérification pour l’identification biométrique à distance.

Le §2 est la clé de lecture : le contrôle humain est le filet sous les autres exigences, pas leur remplaçant. Un risque résiduel accepté dans la gestion des risques (article 9) doit retrouver, dans la conception du contrôle humain, la mesure qui le couvre. Si l’analyse de risque note « biais résiduel sur une sous-population » et que l’interface de revue n’affiche rien qui permette de le repérer, le dossier est incohérent, et ça se voit.

Calendrier : les exigences du chapitre III, section 2, s’appliquent au 2 décembre 2027 pour les systèmes de l’annexe III et au 2 août 2028 pour ceux de l’annexe I (article 113, tel que modifié par l’omnibus numérique, règlement (UE) 2026/1744). L’omnibus ne touche pas l’article 14, ni les articles 13 et 26. Le détail des échéances figure sur la page calendrier, et la question préalable (le système est-il à haut risque ?) sur la page classification haut risque.

Sanctions : un manquement du fournisseur à ses obligations de l’article 16 (dont la conformité à la section 2) ou du déployeur à celles de l’article 26 relève de l’article 99 §4, points a) et e) : jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu ; pour les PME (petites et moyennes entreprises), le plus faible des deux (article 99 §6).

Partage des mesures de contrôle humain entre fournisseur et déployeur

Le §3 coupe les mesures en deux familles. Celles du point a) sont identifiées et, si c’est techniquement possible, intégrées au système par le fournisseur avant la mise sur le marché ou la mise en service : seuils, file de revue, affichage de l’incertitude, coupe-circuit. Celles du point b) sont identifiées par le fournisseur mais se prêtent à une mise en œuvre par le déployeur : désignation des superviseurs, formation, procédures de repli. Le fournisseur décrit l’ensemble dans la notice d’utilisation (article 13 §3 d) et en évalue l’efficacité dans la documentation technique (annexe IV, point 2 e).

Côté déployeur, l’article 26 §1 impose d’utiliser le système conformément à la notice, et le §2 de confier le contrôle humain à des personnes disposant des compétences, de la formation, de l’autorité et du soutien nécessaires. Le §3 laisse le déployeur libre d’organiser ses ressources pour appliquer les mesures indiquées. Le §5 l’oblige à surveiller le fonctionnement et à suspendre l’utilisation en cas de risque. Le détail des rôles est sur la page rôles fournisseur et déployeur.

Le schéma se lit de haut en bas : ce que le fournisseur fige dans le produit, ce qu’il délègue par la notice, ce que le déployeur organise, et la boucle de retour quand le contrôle détecte un risque.

Position : tout ce qui peut être intégré doit l’être. Une mesure renvoyée au déployeur alors qu’elle était codable (un seuil de confiance, un motif obligatoire, un blocage avant exécution) transforme une garantie technique en promesse organisationnelle, et une promesse organisationnelle s’évapore au premier pic de charge. La réserve « lorsque cela est techniquement possible » du §3 a) se défend mal quand le fournisseur n’a simplement pas essayé.

Prérequis avant de concevoir la supervision

Quatre éléments doivent exister avant de dessiner la moindre interface. Une analyse de risques qui nomme les risques résiduels et les populations exposées (article 9), sans quoi on ne sait pas quoi faire surveiller. Une sortie de modèle qui expose une incertitude exploitable : score calibré, intervalle, ou au minimum une classe « indéterminé » ; un modèle qui ne sait produire qu’une réponse binaire rend le §4 c) très difficile à tenir. Une journalisation conforme à l’article 12, dans laquelle s’insèrent les décisions humaines. Et un référentiel d’identités qui distingue les superviseurs habilités des simples utilisateurs, avec des droits différenciés (accepter, modifier, arrêter).

Côté organisation, la maîtrise de l’IA exigée par l’article 4 est la base, mais elle ne suffit pas : l’article 26 §2 vise une formation au système précis, à ses limites documentées et à ses modes de défaillance, pas une sensibilisation générale.

Les cinq capacités du §4 traduites en exigences d’interface

Le §4 décrit ce que le superviseur doit pouvoir faire, « dans la mesure où cela est approprié et proportionné ». Chaque capacité appelle un élément concret, sinon elle reste un vœu.

a) Comprendre, surveiller, détecter les anomalies. L’interface montre les capacités et limites documentées au moment de la décision, pas dans un PDF annexe. Elle expose des indicateurs de fonctionnement : distribution des scores sur la période, taux d’« indéterminé », dérive des entrées. Un superviseur qui ne voit qu’un cas à la fois ne détecte jamais une dérive ; il faut une vue agrégée, et une alerte quand la distribution sort de sa plage habituelle.

b) Conscience du biais d’automatisation. Le texte le nomme explicitement : la tendance à se fier excessivement à la sortie. Un avertissement affiché en bandeau ne sert à rien au bout de trois jours. La seule réponse qui tienne est la mesure, développée plus bas.

c) Interpréter correctement la sortie. Afficher l’incertitude à côté de la proposition, avec la même visibilité. Une interface qui affiche « Refusé » en gros et « confiance 0,54 » en gris clair dans un coin incite à lire une décision là où il y a une hésitation. Les explications (variables influentes, passages sources) doivent indiquer leurs propres limites : une explication post hoc n’est pas le raisonnement du modèle.

d) Ne pas utiliser, ignorer, remplacer ou inverser la sortie. L’action « passer outre » doit coûter autant de clics que « accepter ». Si accepter tient en un bouton et contredire demande un formulaire de six champs, l’interface vote pour le modèle. Par ailleurs, l’option « traiter sans le système » doit exister pour chaque cas, pas seulement au niveau global.

e) Intervenir ou interrompre. Un « bouton d’arrêt » ou une procédure similaire qui mène à un état sûr. Traité en détail plus bas, parce que c’est là que les architectures se trompent le plus souvent.

Humain dans la boucle, sur la boucle, en commande

Trois degrés d’autonomie, à choisir par type de décision et non par système. Humain dans la boucle (human-in-the-loop) : aucune sortie ne produit d’effet sans validation individuelle. Humain sur la boucle (human-on-the-loop) : le système agit, l’humain surveille et peut intervenir ou annuler. Humain en commande (human-in-command) : l’humain décide si, quand et dans quel périmètre le système est utilisé, et peut le retirer.

Le compromis central est là : chaque validation bloquante coûte du débit et alimente la fatigue, et la fatigue fabrique justement le biais d’automatisation que l’article 14 veut combattre. Une revue systématique de tous les cas finit en validation réflexe, ce qui est pire qu’une revue ciblée bien faite, parce qu’elle produit des journaux rassurants sur un contrôle qui n’existe plus.

Recommandation de la page, à ses conditions : revue bloquante sur toute sortie défavorable à une personne et sur toute sortie sous le seuil de confiance ; échantillonnage aléatoire en revue a posteriori sur les sorties favorables et confiantes ; humain en commande au niveau du service, avec pouvoir de retrait. Cette règle tient si les sorties favorables sont réversibles à faible coût. Quand une sortie favorable a elle aussi un effet irréversible (un accès accordé, une ressource attribuée qui en prive un autre), on repasse en revue bloquante intégrale. La question qui tranche est donc : l’effet est-il réversible avant que la personne ne le subisse ?

Le slogan « human-in-the-loop » des plaquettes désigne souvent un humain dont le seul rôle est de porter la responsabilité juridique à la place du modèle ; le règlement demande un humain qui puisse changer le résultat.

Biais d’automatisation : le mesurer plutôt que l’avertir

Le §4 b) exige la conscience du biais ; l’architecture peut en fournir la preuve. Quatre indicateurs, à suivre par superviseur et par équipe :

Taux d’acceptation. Un taux qui tend vers 100 % n’indique pas un modèle parfait, il indique une revue qui ne regarde plus. Le niveau attendu dépend du modèle ; c’est la tendance qui compte.
Taux de désaccord et sa direction. Combien de sorties sont modifiées ou inversées, et dans quel sens. Un désaccord concentré sur une sous-population est un signal de biais du modèle, à remonter à la gouvernance des données.
Temps passé par décision. Une décision validée en moins de temps qu’il n’en faut pour lire les éléments affichés n’a pas été revue. Ce n’est pas un contrôle humain, c’est un clic humain.
Cas pièges injectés. Des cas dont la bonne réponse est connue et contraire à la sortie du modèle, insérés dans la file sans signalement. Le taux de détection de ces cas est la seule mesure directe de la vigilance.

Mise en garde : ces mesures portent sur des salariés. Leur usage pour évaluer individuellement les personnes relève du droit du travail et de la protection des données ; le cadre est détaillé dans la page sur la surveillance des salariés. Le choix défendable : exploiter les indicateurs au niveau du dispositif (calibrage, formation, charge) et non comme outil disciplinaire, et le dire aux superviseurs. Les mécanismes cognitifs en jeu sont décrits dans la page sur les biais cognitifs de l’analyste.

Bouton d’arrêt, arrêt sûr et chaîne de décision

Le §4 e) parle d’interrompre le système par un bouton d’arrêt ou une procédure similaire permettant un arrêt « sécurisé ». Le considérant 73 précise l’intention : des contraintes opérationnelles intégrées que le système ne peut pas ignorer lui-même, et un système qui répond aux ordres de l’opérateur humain. Trois questions à régler avant d’écrire une ligne de code.

Quel est l’état sûr ? Couper le modèle n’est pas un état, c’est une absence. L’état sûr se définit côté métier : file mise en attente, traitement manuel, ou décision par défaut favorable à la personne. Un arrêt qui fait échouer silencieusement les traitements en aval n’est pas sûr.

Qui a le droit d’arrêter ? Tout superviseur habilité, sans validation hiérarchique préalable. La justification vient après. Un bouton d’arrêt qui exige l’accord de trois responsables injoignables le vendredi soir n’est pas un bouton, c’est un formulaire de demande de bouton.

Où s’applique l’arrêt ? Hors du système contrôlé : au niveau de la passerelle qui transmet les sorties à leurs effets, pas dans le modèle ni dans un paramètre qu’il peut lire. Pour un système agentique, c’est la manière la plus sûre de respecter le considérant 73.

Le schéma suivant montre la chaîne complète, avec ses deux points d’arrêt : la décision humaine avant tout effet sur la personne, et le coupe-circuit accessible à tout moment.

Le coupe-circuit se teste comme une sauvegarde : un arrêt jamais exercé est un arrêt dont personne ne connaît l’effet. Un exercice périodique, avec bascule effective en repli manuel et retour, fait partie des conditions d’exploitation.

Double vérification de l’identification biométrique à distance

Pour les systèmes de l’annexe III, point 1 a), le §5 interdit au déployeur toute mesure ou décision sur la base de l’identification sans vérification et confirmation distinctes par au moins deux personnes physiques compétentes, formées et dotées de l’autorité nécessaire. Le droit de l’Union ou national peut écarter cette exigence à des fins répressives, de migration, de contrôle aux frontières ou d’asile, quand il la juge disproportionnée. Le considérant 73 précise que ces vérifications peuvent être enregistrées automatiquement dans les journaux, et que les deux personnes peuvent relever d’une ou plusieurs entités.

« Distinctes » est le mot qui compte. Architecture correspondante : deux identités différentes, chacune authentifiée ; le second vérificateur ne voit pas la conclusion du premier avant d’avoir rendu la sienne (sans quoi la seconde vérification devient une approbation de la première) ; la passerelle d’exécution refuse toute action tant que les deux confirmations concordantes ne sont pas journalisées. Un compte partagé ou une session ouverte au nom d’un collègue annule le dispositif, et c’est un contrôle d’accès à superviser comme tel.

Surface d’attaque du contrôle humain

Le contrôle humain est un mécanisme de sécurité ; il se contourne comme les autres.

Fatigue d’alerte. Un volume de revue trop élevé ou trop de faux positifs pousse à la validation réflexe. Contre-mesure : seuils recalibrés sur les taux de désaccord, plafond de cas par superviseur et par session, et rotation.
Contournement de la file de revue. Une route d’intégration directe, un traitement par lot « temporaire », un compte technique qui valide. Contre-mesure : l’effet ne peut être produit que par la passerelle, qui exige une décision humaine signée ; toute autre route est bloquée au niveau réseau et des droits, pas par convention.
Interface qui masque l’incertitude. Arrondis, couleurs, ordre de tri qui place les cas confiants en tête. Contre-mesure : l’incertitude est une donnée de premier rang de l’interface, vérifiée en recette comme une exigence fonctionnelle.
Manipulation des explications. Une entrée conçue pour produire une sortie voulue accompagnée d’une explication convaincante, ou un document injecté qui influence l’explication générée par un modèle de langage. Contre-mesure : présenter les éléments sources bruts à côté de l’explication, et ne jamais traiter une explication générée comme une preuve.
Agent qui exécute avant validation. Un système agentique qui appelle un outil pendant que la décision humaine est « en attente ». Contre-mesure : les appels d’outils à effet passent par une validation hors du modèle, comme décrit dans la page sur les garde-fous programmatiques, et les arguments sont contrôlés côté serveur (validation du function calling). Les cas des agents outillés sont détaillés sur la page sécurité des agents autonomes.
Usurpation du superviseur. Une décision ne vaut que par l’identité qui la porte. Authentification forte pour les superviseurs, et droit d’arrêt distinct du droit de modifier la configuration du système.

Traçabilité des décisions humaines et conditions d’exploitation

L’article 12 impose l’enregistrement automatique d’événements ; pour la biométrie à distance, il cite explicitement l’identification des personnes ayant vérifié les résultats. Hors biométrie, le texte ne détaille pas le contenu, mais une décision humaine non journalisée est invérifiable, donc indéfendable. Champs minimaux recommandés : référence de la sortie et version du modèle, identité du superviseur, décision, motif structuré (liste fermée plus texte libre), durée de revue, éléments affichés au moment de la décision. Ce dernier point est souvent oublié : sans lui, impossible de prouver que l’incertitude était visible.

Conditions d’exploitation à prévoir :

Secrets et identités. Les décisions sont signées ou au minimum liées à une identité forte ; les comptes de superviseur sont nominatifs, revus périodiquement, et retirés au départ de la personne.
Rotation. Rotation des superviseurs sur les flux pour limiter l’accoutumance ; recalibrage des seuils quand la version du modèle change, puisqu’un score de 0,7 ne signifie plus la même chose.
Supervision. Tableaux de bord des indicateurs de biais d’automatisation et de dérive, avec alertes ; leur intégration à l’observabilité LLM quand le système repose sur un modèle de langage.
Sauvegarde et reprise. Les journaux de décision sont protégés en intégrité et conservés au moins six mois côté déployeur (article 26 §6), sauf disposition contraire ; le repli manuel dispose de ses propres outils, qui ne dépendent pas du système arrêté.

Le stockage et la durée de conservation de ces journaux contiennent des données personnelles des superviseurs et des personnes concernées ; les principes de la page sur les exigences d’architecture du RGPD s’y appliquent.

Ce que l’article 14 ne garantit pas

L’article 14 garantit qu’un humain peut intervenir, pas qu’il intervient bien. Il ne corrige pas un modèle biaisé (article 10), ne remplace pas une analyse de risques (article 9), ne fournit pas de journalisation exploitable (article 12), et ne garantit ni robustesse ni cybersécurité (article 15). Un humain parfaitement attentif face à un modèle empoisonné peut valider des erreurs avec conviction.

Il ne règle pas non plus la question de l’article 22 du RGPD (Règlement général sur la protection des données) sur les décisions fondées exclusivement sur un traitement automatisé. Les lignes directrices européennes sur les décisions automatisées (groupe de travail « Article 29 », reprises par le CEPD) considèrent qu’une intervention humaine de pure forme ne fait pas sortir de ce régime ; un contrôle humain conforme à l’AI Act sur le papier, mais réduit en pratique à une validation réflexe, expose donc sur les deux fronts. L’appréciation d’un cas précis relève d’un juriste, texte en main.

Enfin, l’article 86 ouvre aux personnes concernées un droit à l’explication des décisions individuelles prises sur la base d’un système de l’annexe III (sauf point 2) qui produisent des effets juridiques ou les affectent de manière similaire. Le journal de décision humaine, avec son motif, est la matière première de cette explication ; sans lui, on ne peut expliquer que ce que le modèle a proposé, pas ce que l’humain a décidé.

Exemple fictif : tri de candidatures (annexe III, point 4 a)

Cas fictif, construit pour l’illustration. Un système classe des candidatures à un poste en trois catégories : « à convoquer », « à écarter », « indéterminé ». Il relève de l’annexe III, point 4 a) (systèmes destinés au recrutement ou à la sélection, notamment pour analyser et filtrer les candidatures). L’effet « écarter » est défavorable et, en pratique, peu réversible : un candidat écarté ne revient pas. La règle de la page s’applique donc ainsi : revue bloquante sur toute proposition « à écarter » et sur tout « indéterminé » ; échantillonnage a posteriori sur les « à convoquer », dont l’effet est réversible puisqu’un entretien peut infirmer la proposition.

Ce qu’il faut lire dans ce flux : aucune réponse ne part vers un candidat sans décision humaine journalisée ; les cas pièges mesurent la vigilance des recruteurs sans les noter individuellement ; un désaccord concentré sur une population (par exemple les parcours atypiques) remonte au fournisseur comme signal de biais ; la suspension bascule vers un tri entièrement manuel, outillé indépendamment du système. Le fournisseur aura décrit seuils, catégories et repli dans la notice ; le déployeur aura désigné et formé les recruteurs habilités.

🐝 Ce qui arrive si on s’en passe

Sans file de revue imposée par la passerelle, une intégration directe produit des effets que personne n’a validés, et le journal ne permet plus de distinguer décision humaine et sortie brute. Sans mesure de l’acceptation ni cas pièges, la validation réflexe s’installe sans trace : le dispositif semble fonctionner jusqu’à ce qu’une dérive du modèle soit relayée intégralement aux personnes concernées. Sans état sûr défini, l’arrêt d’urgence bloque les traitements au lieu de les basculer en manuel, ce qui dissuade de s’en servir. Sans motif journalisé, aucune explication au titre de l’article 86 n’est possible, et la responsabilité du déployeur au titre de l’article 26 n’a aucun élément pour se défendre.

🦫 Explication de la marmotte 🍫

Certains logiciels qui « apprennent » à partir d’exemples servent à prendre des décisions graves sur des personnes : trier des candidats à un emploi, reconnaître un visage, accorder un prêt. La loi européenne exige qu’une personne puisse toujours les surveiller et les arrêter. Concrètement, le logiciel ne décide pas seul : il fait une proposition et indique à quel point il est sûr de lui. Quand la proposition est défavorable à quelqu’un, ou quand le logiciel hésite, une personne formée doit la lire avant que quoi que ce soit n’arrive. Elle peut accepter, corriger, refuser ou traiter le dossier sans le logiciel, et doit noter pourquoi. Tout est enregistré : la proposition, la décision, qui l’a prise, combien de temps elle y a passé. L’entreprise qui fabrique le logiciel doit construire ces outils et les expliquer dans son mode d’emploi ; l’organisation qui l’utilise doit choisir des personnes compétentes et leur donner le pouvoir d’agir. Le grand danger est l’habitude : à force, les gens valident sans lire. On le détecte en glissant des dossiers dont on connaît la bonne réponse, pour voir s’ils sont repérés. N’importe quel surveillant doit pouvoir tout arrêter immédiatement, et les dossiers passent alors en traitement à la main. Pour la reconnaissance de visages à distance, deux personnes différentes doivent confirmer chacune de leur côté. Si rien de tout cela n’existe, les erreurs du logiciel touchent directement les gens, sans trace ni explication possible, et l’amende peut atteindre 15 millions d’euros, davantage encore pour les très grandes entreprises.

Pages voisines

La citent

AI Act : contrôle humain d'une IA à haut risque (article 14)

Elle cite

: les deux pages se citent l’une l’autre.