Un modèle géant qui écrit des slogans reste hors catégorie. Un score rudimentaire qui trie des candidatures bascule au haut risque. Voici comment se décide le classement, qui porte quelles obligations et à quelle date.
Un système d’IA est à haut risque dans deux cas : il est un composant de sécurité d’un produit déjà réglementé (annexe I), ou il sert l’un des huit domaines listés à l’annexe III, parmi lesquels l’emploi, l’éducation, le crédit, l’assurance, la biométrie et la police. Le fournisseur doit alors tenir sept exigences techniques, faire évaluer la conformité, apposer le marquage CE et enregistrer le système. Le déployeur porte des obligations propres, plus légères mais réelles. L’échéance a été reportée au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I.
Une direction des ressources humaines compare deux projets. Le premier branche un très grand modèle de langage sur la rédaction des offres d’emploi et des messages d’approche. Le second remplace le tri manuel des candidatures par un score calculé sur l’historique des recrutements passés, une régression logistique de quelques dizaines de variables, tenue par un stagiaire dans un tableur.
L’intuition classe le premier projet comme sensible et le second comme anodin. Le règlement européen fait l’inverse. Le premier relève du risque minimal et n’appelle aucune obligation particulière. Le second est un système d’IA à haut risque, avec gestion des risques documentée, gouvernance des données, contrôle humain, marquage CE et enregistrement dans une base européenne.
Cette inversion est le cœur du texte. Le règlement ne mesure pas la sophistication, il mesure ce que la décision fait à une personne. Comprendre la catégorie « haut risque » demande donc de savoir par quelles portes on y entre, ce qu’on y trouve, et qui porte le fardeau.
La première porte est l’annexe I. Elle vise l’IA qui est un composant de sécurité d’un produit déjà couvert par une réglementation européenne d’harmonisation, ou qui est elle-même un tel produit, lorsque ce produit doit faire l’objet d’une évaluation de conformité par un tiers. Machines, jouets, ascenseurs, équipements de protection individuelle, dispositifs médicaux, véhicules, aéronefs : la logique est celle de la sécurité des produits, développée dans la présentation générale du règlement.
La seconde porte est l’annexe III, la plus fréquente hors industrie. Elle liste huit domaines d’usage.
Le domaine de l’emploi mérite une lecture attentive : il couvre non seulement le recrutement, détaillé du côté de l’IA dans le recrutement, mais aussi tout ce qui touche à l’évaluation des salariés en poste et à l’attribution du travail.
Figurer dans un domaine de l’annexe III ne suffit pas toujours. Le règlement prévoit une soupape : un système listé n’est pas à haut risque s’il ne présente pas de risque important pour la santé, la sécurité ou les droits fondamentaux, ce qui vise quatre situations. Une tâche procédurale étroite. L’amélioration du résultat d’une activité humaine déjà achevée. La détection de constantes de décision ou d’écarts par rapport à des décisions antérieures, sans vocation à remplacer l’appréciation humaine sans réexamen. Une tâche purement préparatoire.
Le verrou tient en une phrase du même article : un système qui effectue un profilage de personnes physiques est à haut risque en toutes circonstances, sans exception possible. En pratique, la soupape se referme sur la majorité des usages ressources humaines, bancaires et assurantiels, qui reposent précisément sur du profilage.
Le fournisseur qui se prévaut de la dérogation doit documenter son évaluation avant la mise sur le marché et la tenir à disposition des autorités. Le règlement omnibus de juillet 2026 a supprimé l’obligation d’enregistrer ces systèmes prétendument hors catégorie dans la base européenne, ce qui allège la formalité sans supprimer la charge de la preuve.
Le chapitre technique du règlement s’organise autour de sept exigences, à satisfaire sur tout le cycle de vie du système, et non le jour du lancement.
La gestion des risques est un processus continu et itératif : identifier les risques prévisibles pour la santé, la sécurité et les droits fondamentaux, les évaluer, adopter des mesures, tester. La gouvernance des données impose des jeux d’entraînement, de validation et de test pertinents, suffisamment représentatifs, et dans la mesure du possible exempts d’erreurs et complets, avec un examen des biais possibles. C’est l’exigence la plus exigeante en pratique, pour les raisons exposées à propos de l’origine des biais d’un modèle.
La documentation technique suit un contenu minimal fixé en annexe et doit être conservée dix ans après la mise sur le marché. La journalisation impose un enregistrement automatique des événements pendant le fonctionnement. La transparence prend la forme d’une notice d’utilisation remise au déployeur : caractéristiques, limites, niveau d’exactitude attendu, mesures de contrôle humain.
Le contrôle humain doit être rendu possible par la conception : le système est construit pour être effectivement supervisé, ce qui suppose de pouvoir en interpréter les sorties, de savoir passer outre et de connaître le biais d’automatisation, cette tendance à faire confiance à une sortie affichée avec assurance que décrit le dossier sur les hallucinations de l’IA. L’exactitude, la robustesse et la cybersécurité ferment la liste, avec une attention particulière aux attaques par empoisonnement des données, terrain que recoupe le socle de sécurité d’une petite structure.
S’y ajoutent un système de gestion de la qualité, une surveillance après commercialisation, la déclaration des incidents graves aux autorités, et des actions correctives immédiates en cas de non-conformité. Ce réflexe de déclaration ressemble à celui qui prévaut en matière de données personnelles, avec la notification de violation.
C’est le point qui surprend le plus les lecteurs habitués à penser le marquage CE comme un agrément délivré par un organisme public. Pour la majorité des systèmes de l’annexe III, la procédure d’évaluation de la conformité est le contrôle interne : le fournisseur vérifie lui-même, rédige sa documentation, signe une déclaration UE de conformité, appose le marquage et enregistre le système dans une base de données européenne.
L’intervention d’un organisme notifié est réservée à certains cas, notamment biométriques, et aux produits de l’annexe I qui relevaient déjà d’un contrôle par tiers. Le contrôle a posteriori par les autorités de surveillance du marché est donc la véritable contrepartie de cette souplesse, ce que détaille l’inventaire des autorités compétentes en France.
Une organisation qui utilise un système à haut risque sous sa propre autorité porte des obligations propres, souvent ignorées parce qu’elles ne figurent pas dans le contrat avec l’éditeur.
| Obligation | Fournisseur | Déployeur |
|---|---|---|
| Gestion des risques et gouvernance des données d’entraînement | Oui, sur tout le cycle de vie | Non, sauf données d’entrée qu’il maîtrise |
| Documentation technique et déclaration de conformité | Oui, conservée dix ans | Non |
| Marquage CE et enregistrement du système | Oui | Non, sauf autorité publique qui enregistre son usage |
| Respect de la notice d’utilisation | Il la rédige | Il doit s’y conformer |
| Contrôle humain confié à des personnes formées et habilitées | Il le rend possible par conception | Il le met en place réellement |
| Conservation des journaux | Quand ils sont sous son contrôle | Au moins six mois |
| Information des représentants du personnel et des salariés | Non | Oui, avant la mise en service au travail |
| Analyse d’impact sur les droits fondamentaux | Non | Organismes publics, services publics, crédit, assurance vie et santé |
Deux lignes de ce tableau méritent d’être détachées. L’information préalable des représentants du personnel et des salariés concernés est une obligation autonome, qui s’ajoute aux procédures de consultation prévues par le code du travail français et ne s’y substitue pas. C’est l’une des raisons pour lesquelles une charte d’usage de l’IA gagne à être construite avec les instances représentatives plutôt que présentée une fois l’outil installé.
Seconde ligne : l’analyse d’impact sur les droits fondamentaux ne concerne pas tous les déployeurs. Elle vise les organismes de droit public, les entités privées fournissant des services publics, et les déployeurs de systèmes d’évaluation de solvabilité ou de tarification en assurance vie et santé. Elle se distingue de l’analyse d’impact relative à la protection des données, qui répond à une autre logique, exposée à propos du RGPD et de l’intelligence artificielle. Les deux documents se nourrissent l’un l’autre sans se confondre.
Trois gestes ordinaires font basculer un déployeur dans le rôle de fournisseur, avec la totalité des obligations correspondantes. Apposer son nom ou sa marque sur un système à haut risque déjà sur le marché. Le modifier substantiellement. Modifier la destination d’un système qui n’était pas classé à haut risque de telle sorte qu’il le devienne.
Le deuxième cas mérite une vigilance particulière dans les organisations qui intègrent elles-mêmes des briques logicielles : réentraîner un modèle sur ses propres données, changer ses seuils de décision ou étendre son périmètre d’application peut constituer une modification substantielle. La question se pose aussi lors des montées de version, terrain où ce que contient une mise à jour compte autant que sa fréquence.
Les obligations du chapitre haut risque s’appliqueront 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, après le report opéré par le règlement omnibus du 8 juillet 2026. Les systèmes déjà en service dans des autorités publiques avant l’échéance générale disposent d’un délai courant jusqu’au 2 août 2030.
Ce délai supplémentaire ne dispense de rien d’immédiat. Les pratiques interdites le sont depuis février 2025. Les obligations de transparence sont exigibles depuis le 2 août 2026. Le RGPD s’applique sans attendre, y compris l’encadrement de la décision individuelle automatisée. Et les travaux de normalisation technique, qui conditionnent la présomption de conformité, prennent des années : une organisation qui attend 2027 pour ouvrir le dossier découvrira que l’inventaire des systèmes et la reconstitution de l’historique des jeux de données sont, à eux seuls, des chantiers de plusieurs mois.
La première question n’est pas « quel modèle utilisons-nous » mais « quelle décision concernant une personne ce système prépare-t-il, et cette décision figure-t-elle dans l’annexe III ». Si la réponse est oui, deuxième question : le système profile-t-il des personnes physiques, auquel cas la soupape de l’article 6 est inutilisable. Troisième question : quel rôle tenez-vous, et quel geste banal pourrait vous transformer en fournisseur.
Le réflexe qui fait gagner le plus de temps est l’inventaire. Recenser les systèmes, leur finalité réelle, leur fournisseur et leur usage effectif coûte quelques semaines et détermine tout le reste. Pour un cas limite, vérifiez auprès de l’autorité sectorielle concernée plutôt que de trancher seul sur la foi d’une plaquette commerciale.
Probablement pas, mais l’analyse se fait en deux temps. Il faut d’abord que l’outil réponde à la définition d’un système d’IA, qui suppose une capacité à inférer, à partir des entrées reçues, la manière de produire ses sorties. Les lignes directrices publiées par la Commission européenne début février 2025 excluent les systèmes qui se bornent à exécuter des règles entièrement définies par des personnes physiques. Un moteur de règles pur sort donc du champ. Un moteur de règles dont les seuils sont appris sur des données historiques y rentre.
Le fournisseur, c’est-à-dire celui qui met le système sur le marché sous son nom ou sa marque. En tant que déployeur, vous n’apposez rien. Attention toutefois au basculement prévu à l’article 25 : si vous rebaptisez l’outil à votre marque, si vous le modifiez substantiellement ou si vous l’employez pour une finalité à haut risque qui n’était pas la sienne, vous devenez fournisseur et héritez de la totalité des obligations, marquage compris.
Le 2 décembre 2027 pour les systèmes relevant de l’annexe III et le 2 août 2028 pour ceux de l’annexe I, depuis le règlement omnibus du 8 juillet 2026. Les systèmes déjà en service dans des autorités publiques avant l’échéance générale bénéficient d’un délai jusqu’au 2 août 2030. Ces dates concernent les obligations du chapitre haut risque ; les interdictions et les obligations de transparence, elles, sont déjà applicables.
Oui, dans un cadre précis. Lorsqu’une décision produisant des effets juridiques ou l’affectant de manière significative repose sur les sorties d’un système à haut risque de l’annexe III, la personne concernée peut obtenir du déployeur des explications claires sur le rôle du système dans la procédure et sur les principaux éléments de la décision. Ce droit se cumule avec ceux du RGPD sur la décision automatisée, détaillés dans les huit demandes que vous pouvez faire.
Rarement pour l’annexe III. La procédure de droit commun y est le contrôle interne : le fournisseur vérifie lui-même la conformité, rédige la documentation technique, signe une déclaration UE de conformité, appose le marquage CE et enregistre le système dans la base européenne. L’intervention d’un organisme tiers est requise dans certains cas, notamment biométriques, et systématiquement pour les produits de l’annexe I qui y étaient déjà soumis avant le règlement sur l’IA.
Les liens ci-dessus renvoient vers les textes et les organismes cités. Les dates de consultation sont celles de la dernière relecture, le 13 septembre 2026.
Dans ce thème
Dans la rubrique
Modèles de langage, IA générative, deepfakes et règlement européen sur l’IA, expliqués sans hype ni panique.