Contrôle humain de l’IA : guide de l’article 14

L’essentiel

• Le contrôle humain est une exigence obligatoire pour tout système d’IA à haut risque au titre du règlement sur l’IA. L’article 14 dispose que ces systèmes doivent être conçus et développés de manière à permettre un contrôle effectif par des personnes physiques pendant leur période d’utilisation.
• Trois modèles de contrôle humain existent dans la pratique : humain dans la boucle (HITL), humain sur la boucle (HOTL) et humain aux commandes (HIC). Le bon modèle dépend du niveau de risque, de l’autonomie et du domaine du système d’IA.
• Les fournisseurs doivent intégrer les capacités de contrôle dans le système dès la conception. Les déployeurs doivent mettre en place les processus, former le personnel et opérationnaliser ces capacités au moment du déploiement.
• Le biais d’automatisation, la tendance à se fier trop aux sorties de l’IA, est nommé à l’article 14, paragraphe 4, point b), comme un risque que les mesures de contrôle doivent traiter. L’ignorer est un écart de conformité.
• Les personnes chargées du contrôle doivent pouvoir comprendre les capacités du système, interpréter correctement les sorties, décider de ne pas l’utiliser ou d’écarter ses sorties, et interrompre le système entièrement si nécessaire.
• Les obligations à haut risque de l’annexe III, y compris l’article 14, s’appliquent à compter du 2 décembre 2027 (reportées du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour les systèmes de l’annexe I, y compris beaucoup de dispositifs médicaux, l’échéance est le 2 août 2028. Les organisations qui n’ont pas conçu et opérationnalisé le contrôle humain d’ici là s’exposent à des amendes pouvant atteindre 15 millions d’euros ou 3 % du chiffre d’affaires mondial.
• Utilisez l’outil d’évaluation au titre du règlement sur l’IA de Legalithm pour déterminer si votre système qualifie comme à haut risque et quel modèle de contrôle s’applique.

De toutes les obligations du règlement sur l’IA, le contrôle humain est sans doute celle qui façonne le plus directement la façon dont les systèmes d’IA interagissent avec les personnes dans la pratique. La gestion des risques se fait avant le déploiement. La documentation technique repose dans un dépôt. L’évaluation de la conformité est un exercice périodique. Le contrôle humain, lui, a lieu chaque fois qu’un système d’IA à haut risque produit une sortie qui touche la vie de quelqu’un, un diagnostic médical, une décision de crédit, une recommandation d’embauche, une alerte pour les services répressifs.

L’article 14 ne se contente pas d’exiger qu’un humain soit présent. Il exige que cet humain soit capable, habilité et équipé d’exercer un contrôle réel sur le système d’IA. Ce guide explique ce que l’article 14 impose, comment choisir le bon modèle de contrôle, comment construire des processus conformes, et comment éviter le piège le plus fréquent : le biais d’automatisation.

Pourquoi le contrôle humain est une pierre angulaire du règlement sur l’IA

Le règlement sur l’IA repose sur le principe que l’IA doit servir les personnes, et non l’inverse. Le considérant 73 dispose que les systèmes d’IA à haut risque devraient être conçus de manière à ce que des personnes physiques puissent en contrôler le fonctionnement, et que ce contrôle devrait contribuer à prévenir ou à réduire au minimum les risques pour la santé, la sécurité et les droits fondamentaux, y compris lorsque le système est utilisé conformément à sa destination.

Le contrôle humain sert trois finalités fondamentales dans l’architecture du règlement :

1. Filet de sécurité contre les défaillances du système. Aucun système d’IA n’est parfait. Les modèles dérivent, des cas limites apparaissent, et les données d’entraînement ont des angles morts. Le contrôle humain fournit une couche corrective qui rattrape des erreurs que le système lui-même ne peut pas détecter.

2. Protection des droits fondamentaux. Lorsqu’un système d’IA prend des décisions qui touchent des personnes, refuser un crédit, signaler un visage dans une foule, filtrer une candidature, le contrôle humain garantit qu’une personne peut évaluer si la sortie respecte la dignité, la non-discrimination et un procès équitable.

3. Ancre de responsabilité. Les décisions automatisées peuvent brouiller la responsabilité. Le contrôle humain préserve une chaîne claire : quelqu’un observe, quelqu’un peut intervenir, et quelqu’un est responsable.

L’article 14 n’est pas une disposition isolée. Il agit de concert avec les autres obligations à haut risque, le système de gestion des risques (article 9), la gouvernance des données (article 10), la transparence et l’information des déployeurs (article 13), et la surveillance après mise sur le marché (article 72). Un système d’IA qui obtient de bons scores d’exactitude technique mais n’a pas de contrôle humain réel n’est pas conforme. Point.

La date d’application des obligations à haut risque de l’annexe III, y compris l’article 14, est le 2 décembre 2027. Pour les systèmes de l’annexe I, c’est le 2 août 2028. Les systèmes déjà mis sur le marché ou mis en service à ces dates ne sont pas exemptés ; les fournisseurs et les déployeurs doivent rattraper les capacités de contrôle là où elles manquent.

Ce que l’article 14 exige, le cadre juridique

L’article 14 impose un ensemble d’exigences à deux stades : à la conception (responsabilité du fournisseur) et au déploiement (responsabilité du déployeur). Comprendre cette répartition est décisif, parce qu’un échec à l’un ou l’autre stade peut rendre tout le dispositif de contrôle ineffectif. Pour la répartition complète des obligations, voir notre guide fournisseur / déployeur.

Exigences à la conception (obligations du fournisseur)

L’article 14, paragraphe 1, dispose que la conception et le développement des systèmes d’IA à haut risque permettent, notamment au moyen d’interfaces homme-machine appropriées, un contrôle effectif par des personnes physiques pendant leur période d’utilisation.

Cela signifie que le fournisseur doit :

• Intégrer des interfaces de contrôle dans le produit. Un système sans mécanisme permettant à un humain de voir, comprendre et agir sur ses sorties est non conforme dès la conception. Ce n’est pas quelque chose que le déployeur peut greffer plus tard.
• Fournir une notice d’utilisation claire. Au titre de l’article 13, le fournisseur doit fournir une notice qui comporte des indications précises sur les mesures de contrôle humain, qui doit contrôler le système, quelles compétences sont nécessaires, et comment l’interface de contrôle fonctionne.
• Concevoir pour l’interprétabilité. Le système doit présenter ses sorties de façon qu’un humain formé puisse les évaluer réellement, et non se contenter de les entériner.

L’article 14, paragraphe 3, précise que ces mesures sont proportionnées aux risques, au niveau d’autonomie et au contexte d’utilisation, et qu’elles sont assurées par l’un des deux types suivants, ou les deux : des mesures identifiées et, lorsque c’est techniquement possible, intégrées par le fournisseur avant la mise sur le marché ou la mise en service (point a)) ; et des mesures identifiées par le fournisseur et qui se prêtent à une mise en œuvre par le déployeur (point b)).

Exigences au déploiement (obligations du déployeur)

L’article 14, paragraphe 3, point b), et l’article 26 placent des obligations opérationnelles précises sur les déployeurs, les organisations qui mettent des systèmes d’IA à haut risque en œuvre sous leur propre autorité :

• Assigner le contrôle à des personnes compétentes. Le déployeur doit s’assurer que les personnes physiques chargées du contrôle ont la compétence, la formation et l’autorité nécessaires. L’article 14, paragraphe 4, énumère les capacités concrètes que ces personnes doivent posséder (détaillées plus bas).
• Mettre en œuvre les instructions de contrôle du fournisseur. Le déployeur doit suivre la notice d’utilisation fournie par le fournisseur, y compris les procédures de contrôle spécifiées.
• Adapter le contrôle au contexte. Lorsque le contexte d’usage propre au déployeur crée des risques que la notice du fournisseur ne couvre pas entièrement, le déployeur doit mettre en œuvre des mesures de contrôle supplémentaires, proportionnées à ces risques.

L’article 14, paragraphe 5, ajoute une règle plus stricte pour l’identification biométrique visée à l’annexe III, point 1, a) : aucune mesure ou décision du déployeur sur la base de l’identification sans vérification distincte par au moins deux personnes physiques compétentes, sous réserve d’une exception pour certains usages répressifs, migratoires ou aux frontières.

Le principe de proportionnalité

L’article 14, paragraphe 3, introduit un qualificatif important : les mesures de contrôle humain sont proportionnées aux risques, au niveau d’autonomie et au contexte d’utilisation du système d’IA à haut risque. Il n’existe donc pas d’exigence unique. Un système d’IA pleinement autonome qui prend des décisions irréversibles sur des personnes (par exemple l’identification biométrique dans les services répressifs) exige un contrôle plus intensif qu’un système semi-automatisé qui présente des recommandations à un professionnel expérimenté (par exemple un outil d’aide au diagnostic utilisé par un radiologue).

C’est ce principe de proportionnalité qui donne un sens au choix entre HITL, HOTL et HIC, plutôt qu’un débat académique.

Trois modèles de contrôle humain

Le règlement ne prescrit pas un modèle unique de contrôle. L’article 14, paragraphe 3, prévoit deux types de mesures (intégrées par le fournisseur et/ou mises en œuvre par le déployeur), pas trois modèles nommés. L’article 14, paragraphe 4, énumère ensuite cinq capacités que les personnes chargées du contrôle doivent, dans la mesure appropriée et proportionnée, posséder :

• (a) comprendre correctement les capacités et les limites pertinentes du système d’IA à haut risque et être en mesure de surveiller correctement son fonctionnement ;
• (b) avoir conscience d’une éventuelle tendance à se fier automatiquement ou excessivement aux sorties (biais d’automatisation) ;
• (c) interpréter correctement les sorties du système d’IA à haut risque ;
• (d) décider, dans une situation particulière, de ne pas utiliser le système ou d’ignorer, remplacer ou inverser sa sortie ;
• (e) intervenir dans le fonctionnement du système ou l’interrompre au moyen d’un bouton d’arrêt ou d’une procédure similaire permettant un arrêt sécurisé.

Dans ce cadre, trois modèles de contrôle se sont imposés dans la pratique et dans les orientations.

Humain dans la boucle (HITL)

Dans le modèle HITL, chaque décision exige une approbation humaine affirmative avant de produire effet. Le système d’IA génère une recommandation, mais aucune action n’est prise tant qu’un humain ne l’a pas examinée et approuvée.

Comment cela fonctionne : l’IA présente sa sortie, avec le contexte, des scores de confiance et des éléments à l’appui, à un décideur humain. L’humain évalue la sortie, prend en compte des facteurs auxquels le système n’a peut-être pas accès, et décide d’approuver, de modifier ou de rejeter.

Quand le HITL est approprié : les décisions ont un impact élevé, potentiellement irréversible, sur des personnes (justice pénale, diagnostic médical, protection de l’enfance) ; des normes juridiques ou éthiques exigent un examen de chaque dossier ; le système est nouveau ou non éprouvé ; ou une régulation sectorielle impose un examen humain individuel (par exemple l’article 22 du RGPD).

Compromis : contrôle et responsabilité maximaux, mais débit plus lent et risque de biais d’automatisation si l’humain approuve en routine sans examen réel.

Humain sur la boucle (HOTL)

Dans le modèle HOTL, le système d’IA fonctionne de façon autonome pour les décisions courantes, mais un humain surveille en continu et peut intervenir lorsque des anomalies ou des erreurs sont détectées.

Comment cela fonctionne : l’IA traite les entrées et produit des sorties automatiquement. Une personne chargée du contrôle suit des tableaux de suivi, des alertes et des indicateurs de performance. Lorsque le système signale une sortie à faible confiance, ou que la personne identifie un schéma préoccupant, l’humain intervient, arrête le système, fait remonter des dossiers précis, ou ajuste des paramètres.

Quand le HOTL est approprié : le système traite un volume élevé de décisions où l’examen individuel est impraticable (détection de fraude, présélection de CV à grande échelle) ; l’impact individuel est modéré et réversible ; le système a un historique éprouvé ; et des processus d’escalade orientent les cas limites vers un examen humain.

Compromis : il passe à l’échelle et reste efficace, mais exige une infrastructure de suivi robuste et porte un risque de lassitude aux alertes si le système produit rarement des erreurs.

Humain aux commandes (HIC)

Dans le modèle HIC, l’humain conserve un contrôle stratégique sur le périmètre de fonctionnement du système d’IA et l’autorité d’écarter ou d’arrêter le système entièrement. L’humain fixe les limites dans lesquelles le système opère et peut les révoquer à tout moment.

Comment cela fonctionne : l’humain définit les paramètres de fonctionnement, les entrées, le périmètre de décision, les seuils d’escalade. Il réexamine périodiquement la performance agrégée, mène des audits, et conserve une capacité d’arrêt d’urgence.

Quand le HIC est approprié : le système opère dans un domaine borné, bien défini, à paramètres stables ; il a une performance de long terme bien documentée ; des structures de gouvernance organisationnelle (comités d’audit, réexamens de conformité) fournissent un contrôle systémique ; et les décisions font l’objet d’un réexamen en aval.

Compromis : le moins gourmand en ressources au quotidien, mais le plus exposé aux angles morts du contrôle si la gouvernance s’affaiblit ou si le système dérive hors de son mandat d’origine sans être détecté.

Tableau comparatif

Choisir le bon modèle

Il n’existe pas de hiérarchie universelle entre ces modèles. Le bon choix dépend de :

1. Gravité et réversibilité de l’impact. Impact plus élevé, moins réversible → contrôle plus intensif (HITL).
2. Volume de décisions. Volume plus élevé → glissement vers HOTL ou HIC, avec une escalade robuste.
3. Maturité du système. Systèmes nouveaux ou non éprouvés → HITL jusqu’à ce que la confiance se construise.
4. Régulation propre au domaine. Certains secteurs imposent un examen individuel quelle que soit la maturité de l’IA (santé, justice pénale).
5. Capacité organisationnelle. Le HITL exige du personnel formé pour chaque cycle de décision ; les plus petites organisations peuvent combiner HOTL et audits HIC périodiques.

Beaucoup d’organisations utilisent des modèles hybrides : HOTL pour les cas courants, avec escalade automatique vers le HITL pour les cas limites à fort enjeu.

Capacités de contrôle précises exigées par l’article 14

L’article 14, paragraphe 4, énumère cinq capacités précises que le personnel de contrôle doit posséder. Ce ne sont pas des objectifs abstraits, ce sont des exigences fonctionnelles concrètes qui orientent la conception du système, la conception des processus et les programmes de formation.

Comprendre les capacités et les limites du système

L’article 14, paragraphe 4, point a), exige que les personnes chargées du contrôle comprennent correctement les capacités et les limites pertinentes du système d’IA à haut risque et puissent surveiller correctement son fonctionnement.

En pratique, cela signifie :

• Les fournisseurs doivent livrer une documentation claire de ce que le système peut et ne peut pas faire, y compris les modes de défaillance connus, les références de performance, la calibration de la confiance, et les conditions dans lesquelles l’exactitude se dégrade.
• Les déployeurs doivent s’assurer que le personnel de contrôle a lu et compris cette documentation avant de commencer ses fonctions.
• Les programmes de formation doivent couvrir non seulement « comment utiliser le système » mais « quand ne pas lui faire confiance », cas limites, décalages de distribution des données, et scénarios hors de la distribution d’entraînement.

Cette exigence se relie directement aux obligations de documentation technique de l’annexe IV et aux obligations de transparence de l’article 13.

Interpréter correctement les sorties du système

L’article 14, paragraphe 4, point c), exige que les personnes chargées du contrôle puissent interpréter correctement les sorties du système d’IA à haut risque, compte tenu des caractéristiques du système et des outils et méthodes d’interprétation disponibles.

C’est plus exigeant qu’il n’y paraît. « Interpréter correctement » signifie :

• Comprendre ce qu’un score de confiance veut dire (et ce qu’il ne veut pas dire).
• Savoir si la sortie du système est une classification, une probabilité, une recommandation ou une prédiction, et ce que chacune implique.
• Reconnaître quand le format ou la présentation de la sortie peut induire en erreur (par exemple une fausse précision dans un pourcentage).
• Utiliser les fonctions d’explicabilité (importance des variables, explications contrefactuelles, cartes d’attention) que le fournisseur a intégrées.

Les fournisseurs doivent concevoir des sorties qui soutiennent une interprétation correcte. Si un système produit un score de risque de « 87,3 % » sans indiquer ce que ce chiffre représente, l’intervalle de confiance, ou quelles variables l’ont porté, le fournisseur a manqué l’article 14, paragraphe 4, point c), dès la conception.

Détecter et traiter le biais d’automatisation

L’article 14, paragraphe 4, point b), nomme explicitement le biais d’automatisation : les personnes chargées du contrôle doivent avoir conscience d’une éventuelle tendance à se fier automatiquement ou excessivement aux sorties produites par un système d’IA à haut risque.

C’est le seul endroit du règlement où un phénomène cognitif précis est nommé, un signal de la gravité que le législateur attache à ce risque. Le biais d’automatisation est traité en profondeur dans la section suivante.

Capacité d’écarter ou de remplacer les décisions de l’IA

L’article 14, paragraphe 4, point d), exige que les personnes chargées du contrôle puissent décider, dans une situation particulière, de ne pas utiliser le système d’IA à haut risque ou d’ignorer, remplacer ou inverser sa sortie.

Cela a trois implications majeures de conception :

1. Pas de verrouillage. Le système doit permettre à l’humain d’écarter entièrement sa sortie et de décider de façon indépendante. Si le déroulement force l’humain à accepter ou rejeter la sortie de l’IA, sans option de contourner le système, la conception n’est pas conforme.
2. Écarter sans friction. Le mécanisme d’écart doit être accessible, pas enterré dans des sous-menus ni soumis à des chaînes d’approbation qui en découragent l’usage. Si écarter l’IA demande plus d’étapes que d’accepter sa recommandation, le système crée une incitation structurelle au biais d’automatisation.
3. Capacité d’inversion. Lorsque la sortie de l’IA a déjà déclenché une action (par exemple un rejet automatisé), le système doit permettre à la personne chargée du contrôle d’inverser cette action dans un délai raisonnable.

Capacité d’arrêt d’urgence

L’article 14, paragraphe 4, point e), exige que les personnes chargées du contrôle puissent intervenir dans le fonctionnement du système d’IA à haut risque ou l’interrompre au moyen d’un bouton d’arrêt ou d’une procédure similaire qui permet au système de s’arrêter dans un état sûr.

Pour les systèmes en temps réel (identification biométrique, aide à la conduite autonome, assistance à la chirurgie robotique), cette exigence demande un mécanisme d’arrêt d’urgence au sens littéral, qui arrête l’opération de l’IA immédiatement. Pour les systèmes hors temps réel (traitement par lots d’évaluations de solvabilité, recommandations d’embauche périodiques), le mécanisme d’« arrêt » peut être un processus pour suspendre l’usage du système et revenir à un traitement manuel.

Le critère de conformité : le mécanisme d’arrêt doit être effectif, accessible, et testé régulièrement, pas seulement documenté.

Biais d’automatisation, le risque de conformité caché

Le biais d’automatisation est le risque de conformité le plus sous-estimé du cadre de contrôle humain du règlement sur l’IA. C’est aussi le plus difficile à résoudre, parce que c’est fondamentalement un problème de psychologie humaine, pas de conception du système.

Ce qu’est le biais d’automatisation

Le biais d’automatisation est la tendance d’un humain à favoriser les suggestions d’un système automatisé plutôt que son propre jugement, même lorsque la suggestion automatisée est fausse. Il se manifeste sous deux formes :

• Erreurs de commission : agir sur une recommandation d’IA incorrecte (par exemple accorder un prêt parce que l’IA a bien noté le demandeur, malgré des signaux d’alerte visibles dans le dossier).
• Erreurs d’omission : ne pas remarquer ce que l’IA a manqué (par exemple ne pas voir une pathologie sur une radiographie parce que l’IA ne l’a pas signalée).

Pourquoi le biais d’automatisation est dangereux pour la conformité

Le biais d’automatisation transforme le contrôle humain d’un filet de sécurité en un visa de complaisance. Si le personnel de contrôle accepte en routine les sorties de l’IA sans évaluation réelle, l’exigence juridique de contrôle humain est satisfaite en forme et défaite en substance.

Les autorités de surveillance du marché iront au-delà de l’existence d’un processus de contrôle. Elles examineront :

• Les taux d’écart. Si une personne chargée du contrôle approuve 99,8 % des recommandations d’IA sur une période soutenue, cela peut indiquer un biais d’automatisation plutôt qu’une haute exactitude de l’IA.
• Le temps par examen. Si le temps moyen d’examen est de cinq secondes pour une décision qui devrait prendre deux minutes, l’examen est vraisemblablement de pure forme.
• Les schémas de résultats. Si les résultats corrèlent parfaitement avec les sorties de l’IA, sans élément d’un jugement humain indépendant, le contrôle n’est pas « effectif » au sens de l’article 14.

Atténuations techniques du biais d’automatisation

Fournisseurs et déployeurs peuvent mettre en place des contre-mesures au niveau du système :

Atténuations organisationnelles

Les contre-mesures techniques ne suffisent pas. Les organisations doivent aussi :

• Créer une culture où écarter l’IA est acceptable. Si le personnel de contrôle est pénalisé (formellement ou informellement) pour avoir écarté l’IA et ralenti le débit, il cessera d’écarter.
• Protéger les dissidents. Les personnes qui identifient des erreurs du système ou refusent d’accepter des recommandations d’IA doivent être protégées des représailles.
• Fixer des attentes explicites d’écart. Si le taux d’écart attendu pour un système donné est de 5 à 15 %, communiquez clairement cette attente. Un taux d’écart de 0 % devrait déclencher une investigation, pas des éloges.
• Mener une formation régulière de débiaisage. La formation n’est pas un événement unique. Des ateliers continus, des études de cas et des simulations sont nécessaires pour tenir à jour la conscience du biais d’automatisation.

Exigences de formation

L’article 14, paragraphe 4, lu avec l’article 4 (maîtrise de l’IA), exige une formation adéquate du personnel de contrôle. Un programme effectif couvre : la maîtrise du système (capacités et modes de défaillance connus), l’interprétation des sorties (scores, intervalles de confiance, fonctions d’explicabilité), la conscience du biais d’automatisation (études de cas et simulations), les procédures d’écart et d’escalade, et une formation de rappel au minimum annuelle.

Responsabilités fournisseur / déployeur pour le contrôle humain

Le contrôle humain est une obligation partagée, mais le partage est clair. Les fournisseurs construisent les outils ; les déployeurs les utilisent. Un échec d’un côté casse la chaîne. Pour le périmètre complet des obligations selon le rôle, voir le guide fournisseur / déployeur.

Si vous êtes un déployeur utilisant un système d’IA tiers et que le fournisseur n’a pas intégré de capacités de contrôle adéquates dans le produit, vous avez un problème. Vous ne pouvez pas vous acquitter pleinement de vos obligations de l’article 14 sans le fondement technique que le fournisseur est censé fournir. Dans cette situation, documentez l’écart, notifiez formellement le fournisseur, et évaluez si continuer à utiliser le système est conforme.

Guide de mise en œuvre, construire un contrôle conforme

Mettre en œuvre l’article 14 n’est pas un exercice de documentation. Cela exige des changements de conception, des changements organisationnels, et un investissement continu. Les six étapes suivantes offrent un chemin pratique de l’obligation à la conformité.

Étape 1, évaluer le niveau d’autonomie et le risque

Avant de concevoir le contrôle, vous devez comprendre ce que vous contrôlez.

• Cartographiez chaque système d’IA de votre organisation qui peut qualifier comme à haut risque. Utilisez notre guide de classification ou l’outil d’évaluation pour déterminer la classification.
• Pour chaque système à haut risque, documentez : les décisions qu’il prend ou étaye, les personnes concernées, la gravité du préjudice potentiel, la réversibilité de ces décisions, le niveau d’autonomie actuel du système, et le volume de décisions traitées.
• Priorisez les systèmes où l’impact est le plus grave et le contrôle actuel le plus faible.

Étape 2, choisir le bon modèle de contrôle

Utilisez l’évaluation de l’étape 1 pour sélectionner HITL, HOTL, HIC, ou un modèle hybride pour chaque système.

Cadre de décision :

• L’impact est élevé et irréversible ? → Commencez par le HITL. Vous pourrez passer au HOTL une fois que le système aura un historique de performance documenté et une infrastructure de suivi solide.
• Le volume est élevé, avec un impact modéré et réversible ? → HOTL avec escalade vers le HITL pour les dossiers signalés.
• Le système est mature, bien borné, et soumis à une gouvernance organisationnelle ? → HIC avec audits périodiques et un suivi de type HOTL pour la détection d’anomalies.

Documentez le raisonnement de votre modèle choisi. Les autorités de surveillance du marché voudront voir que le choix a été délibéré, fondé sur le risque, et documenté, pas par défaut ou par commodité.

Étape 3, concevoir l’interface de contrôle

Si vous êtes fournisseur, c’est là que la conformité à l’article 14 se joue. L’interface de contrôle doit : présenter les sorties dans un format clair, interprétable, avec des indicateurs de confiance ; fournir l’information contextuelle dont la personne chargée du contrôle a besoin (synthèse des données d’entrée, variables pertinentes, comparaison de base) ; inclure des commandes accessibles d’écart, de rejet et d’escalade ; soutenir une explicabilité adaptée au domaine ; inclure un mécanisme d’arrêt d’urgence ; et journaliser chaque action de contrôle avec horodatage et identifiant de la personne.

Si vous êtes déployeur, évaluez si l’interface du fournisseur répond à ces exigences pour votre contexte. Si ce n’est pas le cas, travaillez avec le fournisseur pour demander des améliorations, ou documentez l’écart et mettez en place des contrôles compensatoires.

Étape 4, établir les processus et procédures

Les procédures écrites doivent couvrir : les rôles et responsabilités (qui exerce le contrôle, qui supervise, qui peut arrêter le système) ; la documentation du déroulement (processus pas à pas pour examiner, écarter, faire remonter et documenter) ; une matrice d’escalade (critères pour orienter les dossiers vers des décideurs seniors, la conformité, ou le juridique) ; la réponse aux incidents (comment des erreurs systémiques déclenchent la suspension du système et l’information des personnes, en lien avec les obligations de surveillance après mise sur le marché) ; et la conservation des enregistrements (combien de temps les journaux sont conservés et comment ils alimentent les audits).

Étape 5, former le personnel de contrôle

La formation n’est pas facultative et doit être documentée. Un programme conforme couvre : (1) formation propre au système, ce que fait l’IA, comment elle a été entraînée, ses limites connues ; (2) interprétation des sorties, exercices pratiques avec les fonctions d’explicabilité ; (3) conscience du biais d’automatisation, études de cas et exercices de simulation ; (4) exercices d’écart et d’escalade, pratique sur scénarios ; (5) contexte juridique et éthique, pourquoi le contrôle compte et les conséquences d’un manquement ; et (6) évaluation et attestation, compétence vérifiée avant l’affectation.

Le personnel qui n’a pas achevé la formation ne doit pas exercer de fonctions de contrôle. Des rappels sont exigés à des intervalles définis et chaque fois que le système d’IA subit des mises à jour significatives.

Étape 6, suivre et améliorer en continu

La conformité n’est pas une case à cocher. Le suivi continu doit tracer :

• Les taux d’écart, par personne, par équipe, et dans le temps. Une chute soudaine des taux d’écart peut signaler un biais d’automatisation.
• Les temps d’examen, temps moyen consacré à chaque décision, avec des alertes pour des examens suspicieusement courts.
• L’exactitude des écarts, les écarts améliorent-ils les résultats ou les dégradent-ils ? Ces données indiquent si le contrôle apporte de la valeur.
• La dérive de performance du système, changements d’exactitude, de calibration ou de schémas d’erreur du système d’IA qui peuvent exiger d’ajuster le modèle de contrôle.
• La rotation du personnel et la fraîcheur de la formation, s’assurer que le personnel de contrôle est à jour et que les départs ne laissent pas de trous.

Alimentez ces données dans votre cadre de gouvernance de l’IA et votre système de gestion de la qualité. Utilisez-les pour itérer : renforcer le contrôle là où les données montrent une faiblesse, et envisager d’assouplir le contrôle (par exemple de HITL vers HOTL) là où les données montrent une fiabilité constante.

Exemples sectoriels

L’article 14 s’applique de façon uniforme, mais sa mise en œuvre pratique varie fortement selon le secteur. Les exemples suivants illustrent comment le contrôle opère dans les domaines où l’IA à haut risque est la plus courante.

Santé, radiologue revoyant un diagnostic assisté par IA

Système : analyse d’IA de radiographies thoraciques qui signale d’éventuels nodules pulmonaires avec un score de probabilité de malignité.

Modèle de contrôle : HITL, le radiologue revoit chaque image signalée par l’IA et contrôle par sondage les images que l’IA a écartées.

Mise en œuvre : l’IA présente des régions mises en évidence, un score de probabilité avec intervalle de confiance, et des cas d’entraînement similaires. Le radiologue examine de façon indépendante, puis considère l’analyse de l’IA. Le compte rendu radiologique reflète le jugement professionnel du radiologue, pas le score de l’IA. Un second radiologue revoit un échantillon aléatoire de 10 % des images écartées par l’IA pour rattraper des erreurs d’omission. Les taux d’écart et de concordance sont réexaminés chaque mois.

Pour plus de détail, voir notre guide de conformité pour la santé et les dispositifs médicaux.

RH, recruteur contrôlant une présélection de CV par IA

Système : outil d’IA qui note et classe les CV, et filtre les candidats pour l’examen du recruteur. Haut risque au titre de l’annexe III, point 4 (emploi et accès à l’activité indépendante).

Modèle de contrôle : HOTL avec escalade, l’IA filtre et classe ; le recruteur surveille les schémas et examine les cas limites.

Mise en œuvre : l’IA présente une liste classée avec des scores et les facteurs clés. Le recruteur examine les candidats les mieux classés et contrôle par sondage près du seuil. Les scores à faible confiance ou les schémas anormaux sur des caractéristiques protégées sont orientés vers un examen HITL obligatoire. Le recruteur peut écarter n’importe quel score ou arrêter la présélection pour un poste. Des analyses hebdomadaires suivent les distributions de scores par groupe démographique pour détecter un biais.

Voir notre guide de conformité RH et recrutement pour le détail.

Finance, chargé de crédit revoyant une évaluation de solvabilité par IA

Système : modèle d’IA générant des scores de risque de crédit pour des demandes de prêt à la consommation. Haut risque au titre de l’annexe III, point 5, b) (accès à des services privés essentiels).

Modèle de contrôle : HOTL pour les acceptations, HITL pour les rejets.

Mise en œuvre : les demandes acceptées sont traitées automatiquement pendant que le chargé de crédit surveille les schémas d’acceptation. Les rejets sont orientés vers le chargé pour un examen individuel, avec le score de l’IA, les facteurs de risque clés, et une comparaison avec des demandeurs similaires acceptés. Le chargé peut écarter (accepter malgré le rejet de l’IA), demander des pièces supplémentaires, ou confirmer le rejet avec un motif documenté. Les demandeurs reçoivent des explications comme l’exigent à la fois le règlement sur l’IA (article 86) et l’article 22 du RGPD. Des audits mensuels analysent les schémas de rejet selon les groupes démographiques.

Services répressifs, agent revoyant une identification biométrique en temps réel

Système : identification biométrique à distance en temps réel dans des espaces publics, dans les étroites exceptions de l’article 5, paragraphe 1, point h), sous réserve d’une autorisation judiciaire ou administrative préalable (article 5, paragraphe 3).

Modèle de contrôle : HITL (obligatoire), aucune action n’est prise sur une correspondance biométrique sans vérification humaine individuelle. L’article 14, paragraphe 5, exige en outre, pour les systèmes visés à l’annexe III, point 1, a), une vérification distincte par au moins deux personnes physiques, sous réserve de l’exception prévue pour certains usages répressifs, migratoires ou aux frontières.

Mise en œuvre : le système signale d’éventuelles correspondances en affichant l’image en direct, l’image de référence et le score de similarité. Un agent formé évalue chaque correspondance de façon indépendante, en tenant compte de facteurs contextuels. Aucune arrestation, aucun contrôle, aucune détention ne peut être engagé sur la seule correspondance de l’IA, une confirmation indépendante est exigée. Un second agent revoit avant toute action (double contrôle). Chaque événement est journalisé avec l’identité de l’agent, l’horodatage et le motif. Le système comporte un arrêt d’urgence accessible, et tous les événements font l’objet d’un réexamen a posteriori par un organe de contrôle indépendant.

Questions fréquentes

L’article 14 s’applique-t-il seulement aux systèmes d’IA à haut risque ?

Les exigences détaillées de l’article 14 s’appliquent spécifiquement aux systèmes d’IA à haut risque classés au titre de l’article 6. Toutefois, l’article 4 établit une obligation générale de maîtrise de l’IA pour toutes les organisations qui déploient de l’IA, et les obligations de transparence de l’article 50 s’appliquent aussi à certains systèmes qui ne sont pas à haut risque. Dans la pratique, mettre en place une forme de contrôle humain pour tout système d’IA qui touche des personnes est une bonne pratique de gestion des risques, même lorsqu’elle n’est pas légalement exigée.

Le contrôle humain peut-il être entièrement automatisé, par exemple une IA qui en surveille une autre ?

Non. L’article 14 exige explicitement un contrôle par des personnes physiques. Un système de suivi automatisé peut compléter le contrôle humain (par exemple en générant des alertes, des tableaux de suivi de performance, ou une détection d’anomalies), mais il ne peut pas le remplacer. L’humain doit conserver une autorité réelle de décision.

Comment prouver aux régulateurs que notre contrôle humain est « effectif » ?

L’effectivité se démontre par des preuves, pas par des assertions. Les preuves clés incluent : des procédures de contrôle documentées, des enregistrements de formation et des attestations de compétence, des journaux d’écart montrant un engagement humain réel (pas un visa de complaisance), des données de suivi montrant que le personnel de contrôle consacre un temps adéquat aux examens, des résultats d’audit montrant que le processus de contrôle rattrape des erreurs, et des enregistrements d’incidents montrant que le mécanisme d’arrêt a été testé et fonctionne. La liste de contrôle de conformité de Legalithm fournit un cadre de preuves détaillé.

Que faire si le système du fournisseur d’IA n’inclut pas de fonctions de contrôle adéquates ?

C’est un problème fréquent, surtout avec des systèmes d’IA développés avant le règlement sur l’IA ou par des fournisseurs hors de l’UE. En tant que déployeur, vous devriez : (1) documenter formellement l’écart, (2) notifier le fournisseur et demander des améliorations, (3) mettre en place des contrôles compensatoires (examen manuel supplémentaire, outils de suivi externes), et (4) évaluer si l’usage continu du système est conforme. Si l’écart ne peut pas être refermé, vous pourrez devoir passer à une alternative conforme.

Combien de personnel faut-il pour le contrôle humain ?

Il n’existe pas de ratio fixe. Le dimensionnement dépend du modèle de contrôle (le HITL exige plus de personnel que le HOTL ou le HIC), du volume de décisions, de la complexité de chaque examen, et du taux d’erreur du système. La notice d’utilisation du fournisseur devrait inclure des recommandations de personnel. Comme point de départ, calculez le nombre de décisions par heure, le temps moyen d’examen par décision, et la profondeur maximale acceptable de file, puis dimensionnez en conséquence, avec une marge pour les absences et les pics.

Le contrôle humain entre-t-il en conflit avec l’efficacité de l’automatisation ?

Il introduit un compromis délibéré : le règlement sur l’IA accepte une réduction de vitesse en échange d’un gain de sécurité, d’exactitude et de protection des droits. Dans la pratique, des systèmes HOTL bien conçus conservent l’essentiel des gains d’efficacité de l’automatisation tout en ajoutant une couche de sécurité réelle. L’enjeu est de choisir le bon modèle de contrôle pour le bon niveau de risque, pas d’appliquer le HITL à chaque système quel que soit le contexte.

Prochaines étapes

Le contrôle humain n’est pas une fonction que l’on greffe la semaine avant l’application. Il exige des décisions de conception, un investissement organisationnel, du personnel formé, et un suivi continu. Commencez maintenant :

1. Classez vos systèmes d’IA avec notre guide de classification des risques ou l’outil d’évaluation.
2. Construisez votre cadre de gouvernance avec le guide de gouvernance de l’IA.
3. Comprenez votre rôle avec le guide fournisseur / déployeur.
4. Testez les biais avec le guide d’examen des biais et d’équité.
5. Vérifiez votre posture de conformité d’ensemble avec la liste de contrôle 2026.

L’échéance de décembre 2027 n’est pas une ligne de départ, c’est une ligne d’arrivée. Les organisations qui traitent le contrôle humain comme une arrière-pensée se trouveront non conformes non parce qu’elles manquent de documentation, mais parce que leurs processus de contrôle ne fonctionnent pas dans la pratique. Le moment de construire un contrôle humain effectif, c’est maintenant.