AI Act : évaluation de la conformité, déclaration UE et marquage CE d’une IA à haut risque (articles 17, 43 et 49)

Avant qu’un système d’IA (intelligence artificielle) à haut risque soit mis sur le marché ou en service, son fournisseur doit démontrer qu’il respecte les exigences du règlement (UE) 2024/1689, puis le dire par écrit, le marquer et l’enregistrer. La page décrit cette chaîne telle qu’elle se lit dans le texte consolidé après le règlement (UE) 2026/1744 dit « omnibus numérique » : choix de la procédure, système de gestion de la qualité, contrôle interne ou organisme notifié, déclaration, marquage CE, enregistrement et réévaluation.

→ Lire l’explication complète de la marmotte

Où se place l’évaluation de la conformité dans la vie d’un système à haut risque

L’article 16 empile les obligations du fournisseur : système de gestion de la qualité (point c), évaluation de la conformité selon l’article 43 avant mise sur le marché ou mise en service (point f), déclaration UE de conformité (point g), marquage CE (point h), enregistrement (point i) et capacité à prouver la conformité sur demande motivée d’une autorité (point k). Qui porte ce rôle, et quand un déployeur bascule en fournisseur, relève de la page rôles fournisseur et déployeur.

Le compromis central tient en une phrase. Pour l’immense majorité des systèmes de l’annexe III, l’évaluation est un contrôle interne : aucun tiers, aucun délai d’attente, aucun accès extérieur aux données. En échange, toute la charge de la preuve reste chez le fournisseur, sans certificat opposable à brandir le jour où une autorité frappe à la porte. Position de la page : l’auto-évaluation n’est pas une version allégée, c’est une évaluation dont l’auditeur arrive après coup. Elle se construit donc comme un dossier qui doit survivre à une relecture hostile, pas comme une case cochée.

La chaîne complète, avec sa boucle de retour, se lit de gauche à droite puis remonte au système qualité dès qu’une modification substantielle survient :

Prérequis avant d’engager l’évaluation

Aucune évaluation ne démarre sur du vide. Doivent exister avant :

la qualification du système en haut risque, au titre de l’annexe I ou de l’annexe III (voir classification haut risque) ;
un SGQ (système de gestion de la qualité) écrit et appliqué, détaillé plus bas ;
la documentation technique de l’annexe IV (voir documentation technique), qui sera le principal objet examiné ;
les dossiers de gestion des risques, de gouvernance des données, de journalisation, de contrôle humain et de robustesse et cybersécurité ;
la liste des normes harmonisées (art. 40) ou spécifications communes (art. 41) effectivement appliquées, et pour chacune le degré d’application. Leur publication pour les exigences de l’AI Act est à vérifier au Journal officiel au moment de l’évaluation : c’est ce point qui conditionne le choix de procédure en biométrie ;
pour un système de l’annexe III, un compte du fournisseur (ou de son mandataire) dans la base de l’UE prévue à l’article 71.

Les dates d’application (2 décembre 2027 pour l’annexe III, 2 août 2028 pour l’annexe I, article 113 modifié) sont détaillées dans le calendrier. Un SGQ crédible ne s’écrit pas dans le trimestre qui précède : il doit avoir produit des traces, et les traces ont besoin de temps pour exister.

Choisir la procédure : annexe VI, annexe VII ou procédure sectorielle (art. 43)

L’article 43 distingue trois familles. L’arbre suivant se lit de haut en bas ; chaque condition entre crochets est cumulative avec la branche qui la porte.

Trois lectures à retenir. En biométrie, une norme appliquée « presque entièrement » vaut une norme non appliquée : l’annexe VII redevient obligatoire, au moins pour la partie restreinte quand la norme est publiée avec restriction. Pour l’annexe I, le texte modifié précise que le classement en haut risque au titre de l’article 6 §1 ne change pas le choix de procédure offert par la législation sectorielle ; les organismes notifiés de ce texte peuvent contrôler aussi les exigences de l’AI Act. Enfin, l’article 43 §6 permet à la Commission de soumettre, par acte délégué, tout ou partie des points 2 à 8 de l’annexe III à l’annexe VII : un fournisseur qui bâtit son dossier comme s’il devait un jour le montrer à un organisme notifié ne perd rien et couvre ce risque.

Procédure	Qui évalue	Preuve produite
Annexe VI, contrôle interne	Le fournisseur	Dossier interne d’évaluation, déclaration UE, aucun certificat
Annexe VII, organisme notifié	Un seul organisme notifié choisi par le fournisseur (ou l’autorité de surveillance du marché pour les cas listés)	Certificat d’évaluation UE de la documentation technique, rapports d’audit, déclaration UE citant le certificat
Annexe I, procédure sectorielle	Selon le texte sectoriel (fournisseur ou organisme notifié sectoriel)	Preuves prévues par ce texte, une déclaration UE unique pour tous les actes

Le système de gestion de la qualité (art. 17), socle de toute évaluation

L’article 17 §1 exige un SGQ documenté « de manière méthodique et ordonnée » sous forme de politiques, procédures et instructions écrites, couvrant au moins les points a) à m) : stratégie de respect de la réglementation (procédures d’évaluation de la conformité et gestion des modifications comprises), conception et vérification de la conception, développement et assurance qualité, examens, tests et validations avant, pendant et après le développement avec leur fréquence, spécifications techniques et normes appliquées (avec les moyens alternatifs lorsque les normes harmonisées ne sont pas appliquées intégralement), gestion des données, gestion des risques au sens de l’article 9, surveillance après commercialisation (art. 72), signalement des incidents graves (art. 73), communications avec autorités, organismes notifiés et clients, conservation des documents, gestion des ressources y compris sécurité d’approvisionnement, et cadre de responsabilisation de l’encadrement et du personnel.

Depuis le règlement 2026/1744, le §2 prévoit une mise en œuvre proportionnée à la taille du fournisseur, en particulier pour une PME (petite et moyenne entreprise), jeune pousse comprise, ou une SMC (petite entreprise de taille intermédiaire). Proportionné ne veut pas dire facultatif : le degré de rigueur et le niveau de protection restent dus. Un SGQ de dix pages peut suffire s’il est appliqué ; un SGQ de trois cents pages ne sert à rien s’il ne l’est pas.

Deux raccourcis existent. Un fournisseur déjà soumis à un SGQ sectoriel y intègre les points du §1 (§3). Un établissement financier voit sa conformité aux règles de gouvernance interne du droit financier de l’Union valoir SGQ, sauf pour la gestion des risques, la surveillance après commercialisation et les incidents graves (points g, h et i, §4) : ces trois blocs restent à construire, et ce sont précisément ceux qui demandent de l’outillage.

Le piège classique : un SGQ rédigé pour l’évaluation puis rangé. L’annexe VI vérifie la cohérence entre conception, surveillance après commercialisation et documentation ; un manuel qualité dont les procédures ne laissent aucune trace dans les tickets, les pipelines et les journaux échoue à cette vérification. La procédure de gestion des modifications la mieux écrite est trop souvent celle que personne n’a appliquée au dernier changement de modèle.

Contrôle interne de l’annexe VI en pratique

L’annexe VI tient en trois vérifications faites par le fournisseur lui-même : le SGQ est conforme à l’article 17 ; la documentation technique a été examinée au regard des exigences du chapitre III, section 2 ; la conception, le développement et la surveillance après commercialisation sont cohérents avec cette documentation. Rien n’est transmis à personne. Le résultat doit en revanche pouvoir être produit sur demande motivée d’une autorité (art. 16 k).

Recommandations de la page, qui ne sont pas des exigences du texte :

séparer l’évaluateur du développeur : une revue faite par l’équipe qui a construit le modèle est une relecture, pas une évaluation ;
un coffre de preuves : chaque vérification produit un rapport daté, signé et rattaché à une version précise du système, stocké en écriture unique pendant au moins la durée de conservation de la déclaration (dix ans) ;
une grille par exigence : pour chaque exigence de la section 2, la norme ou le moyen alternatif appliqué, la preuve, l’écart restant et sa justification.

L’auto-évaluation a la réputation d’être confortable. Elle l’est jusqu’au jour où une autorité demande pourquoi le jeu de test date d’avant le dernier réentraînement.

Organisme notifié et annexe VII en pratique

Quand l’annexe VII s’applique, le déroulé suit l’ordre ci-dessous ; les points cités sont ceux de l’annexe.

Le point qui pèse sur l’architecture est le 4.3 : l’accès distant aux jeux de données par API (Application Programming Interface). Il faut l’avoir conçu avant la demande, pas l’improviser pendant. Le point 4.7 crée une dépendance d’exploitation : toute modification pouvant toucher la conformité passe par l’organisme, qui décide d’une nouvelle évaluation ou d’un document complémentaire. Un cycle de livraison hebdomadaire sans tri des changements devient vite un échange de courrier hebdomadaire.

Les certificats (art. 44) valent au plus cinq ans pour l’annexe I et quatre ans pour l’annexe III, prolongeables par périodes de même durée après nouvelle évaluation. Ils peuvent être suspendus, retirés ou restreints si le système ne répond plus aux exigences, avec recours possible. L’article 46 prévoit une dérogation exceptionnelle, accordée par l’autorité de surveillance du marché pour une durée limitée pendant la procédure, pour des motifs de sécurité publique, de vie et santé, d’environnement ou d’infrastructures majeures : une soupape, pas un plan de projet.

Déclaration UE de conformité, marquage CE et enregistrement (art. 47 à 49)

Déclaration (art. 47). Une par système, écrite, lisible par machine, signée à la main ou électroniquement, tenue à disposition des autorités pendant dix ans et mise à jour. Son contenu suit l’annexe V : identification du système et du fournisseur, mention de la responsabilité exclusive du fournisseur, conformité au règlement, conformité au RGPD (Règlement général sur la protection des données, 2016/679), au règlement 2018/1725 et à la directive 2016/680 si des données personnelles sont traitées, normes et spécifications appliquées, organisme notifié et certificat le cas échéant, lieu, date et signataire. Une seule déclaration couvre tous les actes d’harmonisation applicables.

Marquage CE (art. 48). Le sigle CE de conformité européenne suit l’article 30 du règlement (CE) n° 765/2008 : visible, lisible, indélébile, à défaut sur l’emballage ou la documentation. Pour un système fourni numériquement, un marquage CE numérique, accessible depuis l’interface ou par un code lisible par machine. Le numéro de l’organisme notifié suit le marquage quand il y en a un, y compris dans la publicité qui vante la conformité. Un seul marquage couvre aussi les autres actes.

Enregistrement (art. 49). Avant mise sur le marché ou mise en service, le fournisseur ou son mandataire s’enregistre et enregistre le système dans la base de l’UE pour l’annexe III, sauf le point 2 (infrastructures critiques), enregistré au niveau national (§5). Un système de l’annexe III que le fournisseur a jugé non à haut risque au titre de l’article 6 §3 s’enregistre aussi (§2) : conclure à l’absence de haut risque ne dispense pas de le déclarer. La proposition omnibus de la Commission visait à alléger cet enregistrement ; le texte consolidé au 27 juillet 2026 maintient le §2, auquel l’article 6 §4 renvoie toujours (voir classification haut risque). Les déployeurs autorités publiques et institutions de l’UE enregistrent leur utilisation (§3, voir obligations du déployeur). Les points 1, 6 et 7 de l’annexe III en domaine répressif, migration, asile et frontières vont dans une section sécurisée non publique (§4). Les systèmes de l’annexe I ne passent pas par l’article 49.

Modification substantielle et apprentissage continu : quand recommencer l’évaluation

L’article 43 §4 impose une nouvelle évaluation en cas de modification substantielle, que le système soit redistribué ou reste chez le déployeur actuel. Pour un système qui continue d’apprendre, les changements prédéterminés par le fournisseur lors de l’évaluation initiale et décrits dans la documentation technique (annexe IV, point 2 f) ne constituent pas une modification substantielle.

C’est le second compromis du sujet : un plan de changements prédéterminés large offre de la vitesse d’itération, mais il doit être assez précis pour être vérifiable, sinon il ne protège rien. Recommandation de la page : décrire les changements par bornes mesurables (familles d’architecture admises, sources de données autorisées, seuils de performance et d’équité à maintenir sur un jeu de test figé) plutôt que par intentions. Tout changement hors bornes déclenche le circuit d’évaluation, sans débat.

Recommandation complémentaire : rattacher chaque déclaration UE à une empreinte de version (hachage SHA-256, Secure Hash Algorithm, des poids du modèle, de l’image de conteneur et de la configuration de seuils). La question « cette version est-elle couverte ? » devient une comparaison d’empreintes, pas une réunion.

Ce que l’évaluation de la conformité ne garantit pas

Pas une homologation de sécurité. Elle vérifie que les exigences de la section 2 sont traitées et documentées ; elle ne prouve pas l’absence de vulnérabilité exploitable. Les tests d’attaque relèvent de la robustesse et cybersécurité et, pour les produits numériques, du Cyber Resilience Act (CRA).
Pas une conformité RGPD. La déclaration affirme la conformité aux textes de protection des données ; elle ne la démontre pas. Base légale, analyse d’impact et droits des personnes restent des chantiers distincts.
Pas une couverture de l’usage. L’évaluation porte sur le système tel que conçu et documenté par le fournisseur. L’usage réel, le contrôle humain effectif et les données d’entrée restent à la charge du déployeur.
Pas une garantie de durée. Un certificat suspendu ou une version hors périmètre retire la couverture, même si le marquage reste affiché.

Un marquage CE sur une interface ne « sécurise pas l’IA » : il atteste qu’un dossier existe, ce qui se vend moins bien sur une diapositive et résiste nettement mieux à un contrôle.

Surface d’attaque du dispositif de conformité

Le dispositif de conformité est lui-même un système, avec ses propres actifs à protéger.

Accès distant de l’organisme notifié (annexe VII, 4.3). Exposer les jeux d’entraînement par API, c’est ouvrir un canal d’exfiltration de données souvent personnelles. Contre-mesures : environnement d’accès dédié et cloisonné du système de production, identité nominative par auditeur, droits en lecture seule limités aux jeux concernés, journalisation de chaque requête avec volume extrait, durée de validité courte et révocation à la clôture de la mission. Le jeton d’accès accordé « pour la durée de l’audit » et jamais révoqué est un classique dont personne ne se vante.

Intégrité de la déclaration et du marquage numérique. Une déclaration lisible par machine se falsifie aussi bien qu’elle se lit. Recommandations : signature électronique avec clé gardée hors des postes de travail, empreinte publiée, chaîne de signature conservée dix ans avec ses certificats de validation. Le code de marquage CE numérique doit pointer vers une ressource sous contrôle du fournisseur, servie en HTTPS (HTTP sécurisé par TLS, Transport Layer Security), dont le nom de domaine est surveillé : un domaine expiré transforme le marquage en lien vers n’importe quoi.

Dérive entre version évaluée et version déployée. Le risque le plus courant n’a rien d’une attaque : un pipeline qui pousse un modèle réentraîné sans passer par le circuit d’évaluation. Contre-mesure : le pipeline de déploiement refuse toute empreinte de version absente du registre des versions couvertes, et alerte sur tout écart constaté en production.

Exploitation. Rotation des clés de signature avec re-signature tracée des déclarations en vigueur, supervision des accès au coffre de preuves, sauvegarde hors ligne de ce coffre et test de restauration : une preuve irrécupérable est juridiquement une preuve absente.

Exemple : outil de notation de crédit évalué en contrôle interne

Un éditeur fictif commercialise un outil de notation de crédit pour particuliers, qui relève de l’annexe III, point 5 b). Procédure : annexe VI, sans organisme notifié. Le schéma suit la version 1 puis la version 2.

En version 1, les réentraînements mensuels restent dans les bornes prévues à l’annexe IV, point 2 f) : même modèle de base, mêmes sources de données, seuils de performance et d’équité vérifiés sur un jeu de test figé. Ils passent sans nouvelle évaluation, mais chacun laisse un rapport de vérification dans le coffre. En version 2, l’éditeur change de modèle de base. Ce changement ne figure pas dans le plan : c’est une modification substantielle au sens de l’article 43 §4, même pour les clients qui gardent l’outil sans redistribution. Le pipeline bloque le déploiement, l’évaluation annexe VI est refaite, une déclaration v2 est signée, le marquage numérique pointe vers elle et l’enregistrement est mis à jour.

🐝 Ce qui arrive si on s’en passe

Un système à haut risque mis sur le marché sans évaluation, sans déclaration ou sans enregistrement manque aux obligations de l’article 16, sanctionnables au titre de l’article 99 §4 jusqu’à 15 M€ ou 3 % du chiffre d’affaires annuel mondial, le plus élevé des deux (le plus faible pour une PME ou une jeune pousse, §6). Au-delà de l’amende, l’absence de dossier rend impossible la preuve exigée sur demande motivée : une version réentraînée ne peut plus être rattachée à aucune évaluation, un incident grave ne peut plus être reconstitué faute de traces de tests datées, et sans empreinte de version personne ne sait quelle version réellement en production a été examinée. Le marquage affiché devient alors une affirmation sans support.

🦫 Explication de la marmotte 🍫

Une loi européenne classe certains programmes d’intelligence artificielle comme « à haut risque », parce qu’ils décident de choses graves pour des personnes : obtenir un prêt, être embauché, être reconnu par une caméra. L’entreprise qui fabrique un tel programme doit suivre un ordre précis avant de le vendre. D’abord, elle écrit ses propres règles de travail : comment elle teste, comment elle gère ses données, comment elle réagit aux problèmes. Ensuite, elle rédige un gros dossier qui décrit le programme. Puis vient la vérification. Pour la plupart des programmes, l’entreprise se contrôle elle-même et garde les preuves pour les montrer plus tard à l’administration. Pour la reconnaissance des personnes, un organisme extérieur agréé doit parfois examiner le dossier, les données et faire ses propres essais. Si tout est bon, l’entreprise signe une déclaration officielle, ajoute la mention CE (visible ou accessible depuis l’écran du logiciel) et inscrit le programme dans un registre européen. Si plus tard elle change profondément le programme, par exemple son modèle de départ, sans l’avoir annoncé dans son dossier, tout recommence. Si elle saute ces étapes, elle risque une forte amende et ne peut plus prouver que la version utilisée est celle qui a été vérifiée. Cette vérification ne prouve pas que le programme est impossible à pirater, ni que l’entreprise cliente l’utilise correctement : ce sont d’autres obligations.

Pages voisines

La citent

AI Act : évaluation de la conformité, déclaration UE et marquage CE d'une IA à haut risque (articles 17, 43 et 49)

Elle cite

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