Article 14 du règlement européen sur l'IA : les exigences de contrôle humain expliquées

Mise à jour du 2 octobre 2026 — correction. Les versions précédentes citaient les obligations des déployeurs comme relevant de l'article 29 (il s'agit de l'article 26) et le droit à l'explication comme relevant de l'article 72 (il s'agit de l'article 86), présentaient le human-in-the-loop, le human-on-the-loop et le human-in-command comme des types nommés par l'article 14 (ils proviennent des lignes directrices en matière d'éthique publiées en 2019 par le groupe d'experts de haut niveau), et affirmaient que les systèmes déjà déployés doivent être conformes d'ici au 2 décembre 2027, ce que l'article 111, paragraphe 2, ne dit pas.

Mise à jour du 4 août 2026 — changement d'échéance. Le Digital Omnibus (adopté par le Parlement européen le 16 juin 2026 et par le Conseil le 29 juin 2026) a reporté les obligations relatives aux systèmes à haut risque de l'annexe III du 2 août 2026 au 2 décembre 2027. Les obligations de transparence de l'article 50 n'ont pas été reportées et s'appliquent depuis le 2 août 2026. Le présent article a été corrigé en conséquence.

Si votre système d'IA est classé à haut risque au titre du règlement européen sur l'IA, l'article 14 vous impose de le concevoir de manière que des humains puissent effectivement en contrôler le fonctionnement. Ce n'est pas une case à cocher — c'est une exigence architecturale fondamentale qui influe sur la façon dont vous construisez, déployez et surveillez votre système.

L'article 14 impose que les systèmes d'IA à haut risque soient conçus pour permettre un contrôle humain au moyen de mesures appropriées. Ces mesures doivent permettre à des humains de comprendre les sorties du système, d'en interpréter les résultats et d'intervenir lorsque cela est nécessaire. Ces obligations s'appliquent à compter du 2 décembre 2027 pour les systèmes de l'annexe III — avec un plafond légal de 15 millions d'euros ou 3 % du chiffre d'affaires annuel mondial au titre de l'art. 99, paragraphe 4, et, pour les PME, le plus faible des deux montants.

Ce guide explique ce qu'exige l'article 14, quelles mesures de contrôle satisfont au règlement et comment mettre en place un contrôle humain qui fonctionne en pratique.

Ce qu'exige l'article 14

L'article 14 s'applique aux fournisseurs de systèmes d'IA à haut risque (ceux classés à haut risque au titre de l'article 6, en vertu de l'annexe I ou de l'annexe III). Il exige que les systèmes soient conçus et développés de manière à pouvoir être effectivement contrôlés par des personnes physiques pendant leur utilisation (règlement (UE) 2024/1689, article 14).

Obligations fondamentales de contrôle humain

Le contrôle humain doit viser à prévenir ou à réduire au minimum les risques pour la santé, la sécurité ou les droits fondamentaux qui peuvent apparaître lorsqu'un système d'IA à haut risque est utilisé conformément à sa destination ou dans des conditions de mauvaise utilisation raisonnablement prévisible.

Au titre de l'article 14, paragraphe 4, le système doit être fourni de telle manière que les personnes chargées de son contrôle soient en mesure, de manière appropriée et proportionnée, de :

1. Comprendre correctement les capacités et les limites pertinentes du système d'IA à haut risque et surveiller correctement son fonctionnement, y compris en vue de détecter et de traiter les anomalies, les dysfonctionnements et les performances inattendues
2. Rester conscientes de la tendance possible à se fier automatiquement ou excessivement aux sorties produites par un système d'IA à haut risque (biais d'automatisation)
3. Interpréter correctement les sorties du système, en tenant compte, par exemple, des outils et méthodes d'interprétation disponibles
4. Décider de ne pas utiliser le système ou d'ignorer, d'écarter ou d'inverser autrement la sortie dans une situation donnée
5. Intervenir dans le fonctionnement du système ou l'interrompre au moyen d'un bouton « arrêt » ou d'une procédure similaire permettant de l'arrêter dans un état sûr

En outre, les mesures de contrôle doivent être proportionnées aux risques, au niveau d'autonomie et au contexte d'utilisation, et doivent être soit identifiées et intégrées au système par le fournisseur avant sa mise sur le marché, lorsque cela est techniquement possible, soit identifiées comme appropriées pour une mise en œuvre par le déployeur — ou les deux (article 14, paragraphe 3).

Trois manières d'organiser le contrôle

L'article 14 ne nomme pas de types de contrôle. Une manière courante d'organiser les mesures qu'il exige emprunte trois schémas aux Lignes directrices en matière d'éthique pour une IA digne de confiance publiées en 2019 par le groupe d'experts de haut niveau sur l'IA : human-in-the-loop, human-on-the-loop et human-in-command. Il s'agit d'une lecture de l'article 14, et non de catégories définies par le règlement.

1. Human-in-the-Loop (HITL)

Le système d'IA formule une recommandation, mais un humain prend la décision finale avant toute action.

Exemple : un système d'IA recommande de rejeter une demande de prêt, mais un chargé de prêt humain doit examiner la recommandation et approuver le rejet avant que le demandeur ne soit informé.

Quand cela convient : décisions à fort enjeu concernant des personnes (recrutement, crédit, admissibilité à des prestations). L'article 14 ne prescrit lui-même une vérification humaine précise que dans un seul cas : pour les systèmes d'identification biométrique à distance (annexe III, point 1 a)), aucune mesure ou décision ne peut être prise sur la base d'une identification sans que celle-ci ait été vérifiée et confirmée séparément par au moins deux personnes physiques disposant des compétences nécessaires, sous réserve d'exceptions dans les domaines répressif, de la migration, du contrôle aux frontières et de l'asile (article 14, paragraphe 5).

2. Human-on-the-Loop (HOTL)

Le système d'IA fonctionne de manière autonome, mais un humain surveille son fonctionnement en temps réel et peut intervenir si nécessaire.

Exemple : un véhicule autonome se conduit seul, mais un opérateur de sécurité surveille le système et peut en reprendre le contrôle à tout moment.

Quand cela convient : systèmes en temps réel où le human-in-the-loop introduirait une latence inacceptable, mais où l'intervention humaine doit rester possible.

3. Human-in-Command (HIC)

Un humain supervise le fonctionnement global du système d'IA, y compris la possibilité de le désactiver ou de l'arrêter.

Exemple : un administrateur d'hôpital peut désactiver un outil de diagnostic fondé sur l'IA s'il commence à produire des résultats peu fiables.

Quand cela convient : comme socle minimal pour tout système à haut risque. L'article 14, paragraphe 4, point e), exige que les personnes chargées du contrôle puissent intervenir dans le système ou l'interrompre au moyen d'un bouton « arrêt » ou d'une procédure similaire, de manière appropriée et proportionnée.

La plupart des systèmes d'IA à haut risque exigent plusieurs couches de contrôle — par exemple, du human-in-the-loop pour les décisions individuelles et du human-in-command pour le contrôle au niveau du système.

Liste de contrôle de conformité à l'article 14

Voici ce que vous devez mettre en œuvre et documenter :

Exigence	Ce que vous devez mettre en œuvre	Preuves nécessaires
Compréhension des capacités et des limites	Supports de formation, documentation du système, communication des performances	Manuel d'utilisation, attestations de formation suivie, notice d'utilisation (article 13)
Conscience du biais d'automatisation	Avertissements, formation aux risques de dépendance excessive, fonctions imposant une décision	Avertissements dans l'interface, supports de formation, journaux d'audit des décisions
Outils d'interprétation	Fonctions d'explicabilité, scores de confiance, importance des variables	Rapports d'explicabilité, captures d'écran de l'interface, guide d'interprétation
Capacité d'écarter ou d'ignorer	Bouton de dérogation, flux d'examen manuel, mécanisme de rejet	Documents de conception de l'interface, journaux de dérogation, diagrammes de flux
Capacité d'intervenir ou d'arrêter	Bouton d'arrêt d'urgence, procédure d'arrêt du système, chaîne d'escalade	Architecture technique, conception du bouton d'arrêt, plan de réponse aux incidents
Attribution du rôle de contrôle	Qui contrôle le système, qualifications requises, hiérarchie d'escalade	Définitions de rôles, matrice RACI, exigences de formation

Exemple pratique : un outil de recrutement fondé sur l'IA

Supposons que vous fournissiez un système d'IA qui trie des CV et recommande des candidats pour des entretiens — un système à haut risque au titre de l'annexe III, point 4 a).

Étape 1 : identifier le type de contrôle requis

Votre système oriente des décisions qui affectent sensiblement l'accès des personnes à l'emploi. L'article 14 ne prescrit pas de schéma pour ce cas ; il exige des mesures proportionnées aux risques, au niveau d'autonomie et au contexte d'utilisation. Pour un outil de tri de CV, le contrôle human-in-the-loop est le schéma le plus adapté : un humain examine et approuve chaque décision de recrutement avant que les candidats ne soient informés.

Étape 2 : concevoir des outils d'interprétation

Vous mettez en place des fonctions d'explicabilité pour que les responsables du recrutement comprennent pourquoi le système a recommandé ou rejeté un candidat :

• Scores d'importance des variables : « Ce candidat a été bien classé en raison de : expérience pertinente (35 %), correspondance du niveau d'études (28 %), adéquation des compétences (22 %), autres facteurs (15 %) »
• Score de confiance : « Confiance : 78 % (confiance moyenne — examen manuel recommandé) »
• Vue comparative : comparaison côte à côte des meilleurs candidats, avec mise en évidence des principaux facteurs de différenciation

Étape 3 : mettre en place un mécanisme de dérogation

Vous construisez un flux de travail dans lequel les responsables du recrutement peuvent :

• Accepter la recommandation de l'IA (le candidat passe à l'étape de l'entretien)
• Rejeter la recommandation de l'IA (le candidat est examiné manuellement par un recruteur senior)
• Signaler pour examen (le dossier est transmis au comité de recrutement)

Chaque dérogation est consignée avec un code de motif (p. ex. « l'IA n'a pas vu une expérience pertinente », « le candidat a un parcours atypique », « soupçon de biais »).

Étape 4 : atténuer le biais d'automatisation

Vous ajoutez des avertissements dans l'interface pour éviter la dépendance excessive :

• Invite imposant une décision : « Avant d'accepter cette recommandation, avez-vous examiné le CV complet du candidat ? »
• Examen manuel aléatoire : 10 % des recommandations de l'IA sont signalées pour examen manuel obligatoire, même si le responsable du recrutement est d'accord avec l'IA
• Obligation de formation : tous les responsables du recrutement doivent suivre une formation de 30 minutes sur le biais d'automatisation avant d'utiliser le système

Étape 5 : prévoir un contrôle au niveau du système

Vous mettez en place un contrôle human-in-command :

• L'administrateur du système (le directeur des ressources humaines) peut désactiver le système d'IA à tout moment
• Un tableau de bord des performances affiche en temps réel l'exactitude, les indicateurs de biais et les taux de dérogation
• Déclencheurs d'arrêt automatique : le système se désactive si l'exactitude tombe sous 80 % ou si les indicateurs de biais dépassent des seuils prédéfinis

Étape 6 : tout documenter

Vous rédigez un document de conception du contrôle qui comprend :

• Les définitions de rôles (qui contrôle quoi)
• Les flux de contrôle (diagrammes des chemins de décision)
• Les outils d'interprétation (captures d'écran, guide d'utilisation)
• Les mécanismes de dérogation (conception technique, journaux)
• Les exigences de formation (programme, suivi des formations suivies)
• Les contrôles au niveau du système (procédures d'arrêt, chaînes d'escalade)

Ce document devient une partie de votre documentation technique au titre de l'article 11 et nourrit votre notice d'utilisation au titre de l'article 13.

Lacunes courantes et comment les combler

Lacune 1 : aucune fonction d'explicabilité

Problème : votre système produit des recommandations, mais les utilisateurs ne comprennent pas pourquoi.

Correctif : mettez en place des outils d'interprétation :

• Scores de confiance (quel est le degré de certitude du système ?)
• Importance des variables (quels facteurs ont déterminé cette décision ?)
• Explications contrefactuelles (que faudrait-il changer pour obtenir un autre résultat ?)
• Vues comparatives (comment ce cas se compare-t-il à des cas similaires ?)

Lacune 2 : le mécanisme de dérogation existe mais n'est pas utilisé

Problème : les utilisateurs peuvent écarter le système, mais en pratique ils ne le font presque jamais (biais d'automatisation).

Correctif : mettez en place des fonctions imposant une décision :

• Exigez des utilisateurs qu'ils confirment activement les décisions (et pas seulement qu'ils cliquent sur « tout accepter »)
• Rendez aléatoires les examens manuels obligatoires
• Suivez les taux de dérogation et enquêtez s'ils sont trop faibles
• Formez les utilisateurs sur les cas et les modalités de dérogation

Lacune 3 : aucune capacité d'arrêt au niveau du système

Problème : les utilisateurs individuels peuvent rejeter des recommandations, mais personne ne peut arrêter l'ensemble du système s'il commence à dysfonctionner.

Correctif : mettez en place des contrôles human-in-command :

• Désignez un responsable du système disposant du pouvoir d'arrêt
• Construisez un mécanisme d'arrêt d'urgence (p. ex. un tableau de bord d'administration avec un bouton « désactiver le système »)
• Définissez des déclencheurs d'arrêt automatique (seuils d'exactitude, seuils de biais, signalements d'incidents)
• Documentez les procédures d'escalade (qui est informé, dans quel délai, ce qui se passe ensuite)

Lacune 4 : les rôles de contrôle ne sont pas définis

Problème : on ne sait pas clairement qui est responsable du contrôle du système, quelles qualifications sont nécessaires, ni ce que ces personnes sont censées faire.

Correctif : définissez les rôles et responsabilités en matière de contrôle :

• Qui examine les décisions individuelles ? (p. ex. responsable du recrutement, chargé de prêt)
• Qui surveille les performances au niveau du système ? (p. ex. responsable conformité, ingénieur ML)
• Qui a le pouvoir d'arrêter le système ? (p. ex. directeur technique, directeur de la conformité)
• Quelles qualifications sont requises ? (p. ex. formation suivie, expertise métier)
• Comment les activités de contrôle sont-elles consignées et auditées ?

Comment l'article 14 s'articule avec d'autres articles

Les exigences de contrôle de l'article 14 recoupent plusieurs autres obligations :

• Article 9 (gestion des risques) : les risques identifiés dans votre évaluation au titre de l'article 9 déterminent les mesures de contrôle nécessaires au titre de l'article 14.
• Article 13 (transparence) : les mesures de contrôle que vous mettez en œuvre au titre de l'article 14 doivent être décrites dans votre notice d'utilisation au titre de l'article 13.
• Article 26 (obligations incombant aux déployeurs de systèmes d'IA à haut risque) : les déployeurs doivent confier le contrôle humain à des personnes physiques disposant de la compétence, de la formation et de l'autorité nécessaires, ainsi que du soutien nécessaire (article 26, paragraphe 2) — ce qui suppose que vous (le fournisseur) ayez conçu le système pour permettre un contrôle effectif.
• Article 86 (droit à l'explication des décisions individuelles) : une personne concernée par une décision qu'un déployeur prend sur la base des sorties d'un système à haut risque de l'annexe III (autre que ceux du point 2), et qui produit des effets juridiques ou l'affecte de manière significative de façon similaire, a le droit d'obtenir du déployeur des explications claires et pertinentes sur le rôle du système d'IA et les principaux éléments de la décision. Le déployeur ne peut donner cette explication que si les sorties de votre système peuvent être interprétées — une raison de plus d'y intégrer des outils d'interprétation.

Ce que les régulateurs examineront

Lorsqu'une autorité de surveillance du marché examinera votre système d'IA à haut risque, attendez-vous à des questions telles que :

1. Montrez-moi comment des humains contrôlent ce système. (Quels flux, outils et contrôles existent ?)
2. Comment les personnes chargées du contrôle comprennent-elles ce que fait le système ? (Des fonctions d'explicabilité sont-elles intégrées ?)
3. Les personnes chargées du contrôle peuvent-elles écarter ou rejeter les sorties du système ? (Existe-t-il un mécanisme de dérogation documenté ?)
4. Comment prévenez-vous le biais d'automatisation ? (Quelles formations, quels avertissements ou quelles fonctions imposant une décision existent ?)
5. Qui peut arrêter le système en cas de dysfonctionnement ? (Y a-t-il un responsable désigné disposant du pouvoir d'arrêt ?)
6. Comment savez-vous que le contrôle fonctionne ? (Les taux de dérogation, les délais d'examen et les signalements d'incidents sont-ils suivis ?)

Si vous ne pouvez pas démontrer un contrôle effectif à l'aide de documents et de journaux, le système ne semble pas satisfaire à l'article 14.

Calendrier et application

Date	Étape
2 août 2025	Les obligations relatives aux modèles d'IA à usage général et le régime de sanctions s'appliquent
2 août 2026	Les obligations de transparence de l'article 50 s'appliquent (non reportées)
2 décembre 2027	Les obligations de l'article 14 s'appliquent aux systèmes d'IA à haut risque de l'annexe III
2 août 2028	Les obligations relatives aux systèmes à haut risque de l'annexe I s'appliquent (IA intégrée à des produits réglementés)

Si votre système d'IA à haut risque a déjà été mis sur le marché ou mis en service avant sa date d'application, les exigences applicables aux systèmes à haut risque ne l'atteignent que si sa conception subit des modifications importantes à compter de cette date (article 111, paragraphe 2, tel que remplacé par le Digital Omnibus). Les systèmes destinés à être utilisés par des autorités publiques font exception : leurs fournisseurs et déployeurs doivent se mettre en conformité d'ici à une échéance distincte fixée à l'article 111, paragraphe 2, que la conception change ou non. Si vous construisez un nouveau système, l'article 14 s'applique dès la phase de conception.

---

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil juridique. Consultez un professionnel du droit qualifié pour toute question relative à votre situation particulière.