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

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 — avec des amendes pouvant atteindre 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 énumérés à l'annexe III ou classés au titre de l'article 6). 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.

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.

Les mesures de contrôle doivent permettre aux personnes concernées de :

1. Comprendre pleinement les capacités et les limites du système d'IA à haut risque
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 de ses caractéristiques et 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

En outre, les mesures de contrôle doivent être identifiées et intégrées au système par le fournisseur avant sa mise sur le marché, ou elles doivent être identifiées comme appropriées pour une mise en œuvre par le déployeur.

Les trois types de contrôle humain

L'article 14 reconnaît trois schémas de contrôle, selon le niveau de risque et le contexte de déploiement :

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 c'est exigé : décisions à fort enjeu concernant des personnes (recrutement, crédit, admissibilité à des prestations).

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 c'est exigé : 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 c'est exigé : tous les systèmes à haut risque (socle minimal). Les humains doivent toujours conserver la capacité d'arrêter le système.

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 prend des décisions qui affectent sensiblement l'accès des personnes à l'emploi. Vous avez besoin d'un contrôle human-in-the-loop : un humain doit examiner et approuver 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 29 (obligations des déployeurs) : les déployeurs doivent confier le contrôle à des personnes disposant de la compétence, de la formation et de l'autorité nécessaires — ce qui suppose que vous (le fournisseur) ayez conçu le système pour permettre un contrôle effectif.
• Article 72 (droit à une explication) : les personnes affectées par des décisions prises par une IA à haut risque ont le droit d'obtenir une explication — ce qui suppose que vos outils de contrôle comportent des fonctions d'explicabilité.

Ce que les régulateurs examineront

Lorsqu'une autorité de surveillance du marché auditera votre système d'IA à haut risque, elle demandera :

1. Montrez-moi comment des humains contrôlent ce système. (Quels flux, outils et contrôles existent ?)
2. Comment les utilisateurs comprennent-ils ce que fait le système ? (Des fonctions d'explicabilité sont-elles intégrées ?)
3. Les utilisateurs peuvent-ils é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, vous n'êtes pas en conformité.

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 est déjà déployé, vous devez mettre en place des mesures de contrôle conformes d'ici au 2 décembre 2027. Si vous construisez un nouveau système, l'article 14 s'applique dès la phase de conception.

Comment Vigilia vous aide

L'audit du règlement européen sur l'IA proposé par Vigilia comprend une analyse des écarts au titre de l'article 14 :

• Nous évaluons si votre système comporte les mesures de contrôle exigées par l'article 14
• Nous identifions les capacités manquantes (outils d'explicabilité, mécanismes de dérogation, contrôles d'arrêt)
• Nous fournissons une feuille de route de remédiation assortie de modifications de conception et d'exigences documentaires précises

L'audit prend 20 minutes et coûte 499 € — contre 5 000 à 40 000 € pour un audit de conformité traditionnel.

Prêt à vérifier votre conformité à l'article 14 ? Générez votre rapport prêt pour l'audit sur www.aivigilia.com. Vous obtiendrez une analyse détaillée des écarts couvrant les articles 9, 10, 12, 13, 14 et 52, ainsi qu'une feuille de route de remédiation que vous pourrez transmettre à vos équipes d'ingénierie et de conformité.

---

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.