AI Act : documentation technique d’une IA à haut risque (article 11, annexe IV)

L’article 11 du règlement (UE) 2024/1689 sur l’intelligence artificielle (IA) oblige le fournisseur d’un système à haut risque à établir une documentation technique avant la mise sur le marché, puis à la tenir à jour. L’annexe IV en fixe le contenu minimal en neuf points. Cette page détaille ce contenu, ce qu’il prouve, ce qu’il ne prouve pas et comment l’exploiter sur dix ans sans qu’il diverge du système réel.

→ Lire l’explication complète de la marmotte

Ce que l’article 11 exige du fournisseur

L’article 11, §1 pose quatre exigences, et chacune a une conséquence d’architecture.

Antériorité : la documentation est établie avant la mise sur le marché ou la mise en service. Elle sert d’entrée à l’évaluation de conformité de l’article 43, que l’article 16 impose au fournisseur avant toute commercialisation. Une documentation rédigée après le lancement est donc un défaut de procédure, pas seulement un retard.
Tenue à jour : elle suit le système. Un modèle réentraîné ou un seuil de décision modifié rend la version précédente fausse.
Démonstration : elle doit prouver la conformité aux exigences de la section 2 du chapitre III (articles 8 à 15), « sous une forme claire et intelligible » pour les autorités nationales compétentes et les organismes notifiés.
Plancher : l’annexe IV fixe un minimum, pas un plafond.

Qui lit ce dossier avant la mise sur le marché dépend de la voie d’évaluation (article 43). Pour les systèmes de l’annexe III, points 2 à 8 (emploi, éducation, services essentiels, etc.), c’est le contrôle interne de l’annexe VI, sans organisme notifié : le fournisseur examine lui-même son dossier, et l’autorité de surveillance du marché le lira sur demande. Un organisme notifié intervient pour la biométrie (annexe III, point 1) lorsque les normes harmonisées n’ont pas été appliquées en totalité, et pour les produits de l’annexe I selon la procédure de leur texte sectoriel. Dans tous les cas, le dossier doit pouvoir être lu par un tiers qui n’a pas participé au projet.

L’article 11, §2 traite le cas d’un système intégré à un produit couvert par la législation d’harmonisation de l’annexe I, section A (machines, dispositifs médicaux, jouets, etc.). On produit alors un seul ensemble documentaire, qui fusionne les informations de l’AI Act et celles du texte sectoriel. Maintenir deux dossiers parallèles sur un même produit garantit qu’ils divergeront. L’article 11, §3 permet à la Commission de modifier l’annexe IV par actes délégués (article 97). Il faut donc relire la version consolidée sur EUR-Lex avant chaque nouvelle mise sur le marché.

Côté calendrier, les obligations du haut risque s’appliquent à des dates différentes selon que le système relève de l’annexe III ou de l’annexe I. Le détail est sur la page calendrier de l’AI Act.

La voie simplifiée après l’omnibus numérique

Le règlement (UE) 2026/1744 (« omnibus numérique », en vigueur depuis le 27 juillet 2026) modifie l’article 11, §1. La documentation simplifiée, jusqu’ici réservée aux PME (petites et moyennes entreprises), jeunes pousses comprises, s’ouvre aussi aux petites entreprises de taille intermédiaire (SMC, small mid-caps). Ces dernières sont définies par renvoi à la recommandation (UE) 2025/1099. La lecture courante retient moins de 750 salariés et moins de 150 millions d’euros de chiffre d’affaires, mais ces seuils sont à vérifier dans la recommandation elle-même.

La Commission établit un formulaire simplifié. L’entreprise qui choisit cette voie l’utilise, et les organismes notifiés sont tenus de l’accepter. Avant de planifier quoi que ce soit dessus, il faut vérifier sur le site de la Commission que ce formulaire est effectivement disponible. Par ailleurs, l’omnibus ne paraît pas modifier le contenu de l’annexe IV : la version consolidée sur EUR-Lex fait foi.

La position défendue ici : le formulaire simplifié allège la forme, pas la preuve. Les tests datés et signés, les fiches de données et l’analyse de risques doivent exister de toute façon, puisque les articles 9, 10 et 15 continuent de s’appliquer. Il vaut mieux produire les artefacts complets et choisir la voie simplifiée seulement pour leur présentation. L’inverse revient à découvrir, à la première demande motivée d’une autorité, que le formulaire était court parce que les preuves manquaient.

Les neuf points de l’annexe IV et ce qu’ils prouvent

L’annexe IV se lit mieux comme une table de correspondance que comme une liste. Chaque point existe pour démontrer une exigence précise. Le schéma relie chaque point à l’article qu’il sert à prouver.

Le point 1 (description générale) couvre la destination du système, le fournisseur, la version et sa relation aux versions précédentes, les interactions avec le matériel, les logiciels ou d’autres systèmes d’IA, et les versions des logiciels et micrologiciels avec leurs exigences de mise à jour. Il inclut aussi les formes de mise sur le marché (packs intégrés, téléchargements, API (Application Programming Interface)), le matériel d’exécution, des photos si le système est un composant de produit, la description de base de l’interface fournie au déployeur et la notice d’utilisation. La notice vit donc dans la documentation technique : la générer à part, depuis un autre dépôt, crée deux vérités.

Le point 2 concentre l’essentiel de l’effort. Il couvre les méthodes de développement, y compris le recours à des systèmes ou outils pré-entraînés de tiers et la manière dont ils ont été intégrés ou modifiés (2 a). Il inclut aussi les spécifications de conception (2 b) : logique générale, hypothèses, personnes visées, ce que le système optimise, sorties attendues et compromis retenus. Viennent ensuite l’architecture et les ressources de calcul d’entraînement et de test (2 c), puis les fiches de données (2 d) : provenance, portée, obtention, sélection, étiquetage, nettoyage. Le point 2 e évalue les mesures de contrôle humain (article 14) et les aides à l’interprétation des sorties (article 13, §3, d), et le point 2 f décrit les modifications prédéterminées. Le point 2 g porte sur les procédures de validation et d’essai, les indicateurs d’exactitude et de robustesse, les incidences discriminatoires, ainsi que les journaux et rapports de test datés et signés par les personnes responsables. Le point 2 h, enfin, décrit les mesures de cybersécurité.

Le point 3 exige l’exactitude par groupe de personnes en plus de l’exactitude globale. Une moyenne de 94 % peut masquer un sous-groupe à 70 %, et c’est précisément ce que le texte veut voir. Le point 3 couvre aussi les résultats non intentionnels, les sources de risque et les spécifications des données d’entrée. Les points 5 et 9 renvoient au système de gestion des risques et à la surveillance après commercialisation, détaillés sur la page gestion des risques. Les fiches de données relèvent de la page gouvernance des données. Une nomenclature des composants logiciels, décrite sur la page SBOM, fournit une base vérifiable pour les points 1 c et 2 c.

La phrase « compromis retenus » du point 2 b mérite qu’on s’y arrête. Le texte demande d’écrire noir sur blanc ce qu’on a sacrifié, par exemple du rappel contre de la précision ou de l’explicabilité contre de la performance. C’est souvent la section la plus courte d’un dossier de conception, alors qu’un auditeur la lit en premier.

Prérequis avant d’ouvrir le premier document

La documentation technique ne crée aucune preuve : elle référence des preuves qui existent déjà ailleurs. Avant de la rédiger, plusieurs éléments doivent être en place.

Le rôle de fournisseur, établi selon les critères de la page rôles fournisseur et déployeur. Le déployeur n’établit pas la documentation technique ; il reçoit la notice d’utilisation de l’article 13. Il ne bascule dans l’obligation que s’il devient fournisseur au sens de l’article 25, par exemple en modifiant substantiellement le système ou en changeant sa destination.
La classification haut risque, argumentée au sens de la page classification haut risque. Sans elle, le dossier ne sait même pas quelle destination décrire.
Les accords avec les tiers (article 25, §4) : un accord écrit avec chaque fournisseur de composants, d’outils ou de modèles intégrés, qui précise les informations à transmettre. Sans ce contrat, le point 2 a reste vide. Le Bureau de l’IA peut recommander des clauses types volontaires ; la démarche d’achat se rattache à la gestion des risques liés aux tiers.
Les informations du modèle d’IA à usage général, quand le système en intègre un. Le fournisseur du modèle doit transmettre aux fournisseurs en aval les informations de l’annexe XII (article 53, §1, b). Ces informations alimentent le point 2 a, mais elles ne le remplacent pas.
Un pipeline de développement qui produit des artefacts traçables : versions de jeux de données, empreintes de modèles, rapports de test horodatés. Les pratiques correspondantes sont rassemblées dans la section développement ; la manière dont un auditeur vérifie ces preuves est décrite sur la page preuve de conformité.

Une confusion fréquente doit être levée tôt. La documentation de l’article 53 et des annexes XI et XII concerne le modèle d’IA à usage général et s’adresse au Bureau de l’IA. Celle de l’article 11 et de l’annexe IV concerne le système à haut risque et s’adresse aux autorités nationales et aux organismes notifiés. Il s’agit de deux obligations distinctes. Les cas où le fournisseur consomme un modèle par API sont traités sur la page AI Act et déployeur d’un modèle par API.

Cycle de vie de la documentation technique

Le compromis central se formule ainsi. Une documentation générée depuis le pipeline reste juste, mais elle coûte un investissement d’outillage et rigidifie le processus de livraison. Une documentation rédigée après coup coûte moins au départ, puis diverge du système à la première itération. Pour un système qui évolue (réentraînement, mise à jour de seuils), seule la première approche tient la promesse de l’article 11, §1. Le document rédigé à la main ne reste défendable que pour un système figé, livré une fois et rarement modifié, ce qui décrit peu de systèmes d’apprentissage automatique en production.

Le schéma montre l’ordre imposé par le texte et la branche qui déclenche une nouvelle évaluation de conformité.

Ce qu’il faut y lire : le point 2 f n’est pas décoratif. Toute modification substantielle impose une nouvelle évaluation de conformité (article 43, §4). Pour un système qui continue d’apprendre après sa mise sur le marché ou sa mise en service, le même paragraphe exclut de cette notion les modifications du système et de sa performance déterminées au préalable par le fournisseur lors de l’évaluation initiale et décrites au point 2 f. Un apprentissage continu encadré par un protocole et des seuils d’acceptation décrits à l’avance reste donc dans le périmètre évalué. La même évolution, non anticipée, peut constituer une modification substantielle. Rédiger le point 2 f avec précision est le levier le plus rentable de tout le dossier.

L’article 18, §3 prévoit un cas particulier pour les établissements financiers. Leur documentation s’intègre à celle qu’exige déjà la législation sur les services financiers, sans former un dossier séparé.

Surface d’attaque de la documentation elle-même

Un dossier conforme à l’annexe IV décrit l’architecture, les mesures de cybersécurité (point 2 h), les limites connues (point 3) et les données d’entraînement (point 2 d). Il remet donc une carte complète du système à quiconque y accède, et c’est l’un des documents les plus sensibles qu’un fournisseur possède.

Fuite par sur-partage : le dossier circule vers l’organisme notifié, le mandataire (article 22, pour un fournisseur hors UE (Union européenne)), les intégrateurs et le juridique. Chaque copie hors du dépôt de référence échappe au contrôle d’accès. Contre-mesure : un dépôt unique, des extractions nominatives et journalisées, et une version expurgée pour les tiers qui n’ont besoin que de la notice. Côté autorités, l’article 78 impose la confidentialité, mais il ne protège pas les copies envoyées ailleurs.
Falsification rétroactive : un rapport de test réécrit après un incident pour masquer un biais connu. L’exigence de rapports « datés et signés » (point 2 g) n’a de valeur que si la date et la signature sont vérifiables. Contre-mesure : une signature électronique des rapports avec horodatage, et une empreinte de chaque version du dossier conservée hors de portée des équipes qui le produisent.
Empoisonnement de la source : si le dossier est généré depuis le pipeline, compromettre le pipeline revient à produire une documentation fausse, mais cohérente. Contre-mesure : les mêmes contrôles d’intégrité que pour le code livré, et une revue humaine signée avant chaque génération destinée à une évaluation de conformité.
Perte de disponibilité : dix ans dépassent la durée de vie de la plupart des outils de notebook, des comptes de stockage et des formats propriétaires. Une règle d’expiration automatique sur un compartiment de stockage efface les journaux de test sans bruit. Contre-mesure : un stockage WORM (Write Once Read Many), des formats ouverts et un test de restitution périodique.

Le dossier qui décrit en détail les défenses d’un système finit généralement dans un dossier partagé dont le lien d’accès « toute personne disposant du lien » est la seule défense.

Ce que la documentation technique ne garantit pas

La conformité réelle : le dossier démontre ce qu’il affirme, il ne rend pas le système conforme. Un indicateur d’exactitude mesuré sur un jeu de test non représentatif reste faux, même bien présenté. La qualité de la preuve dépend de l’article 10 et du protocole de test, pas du gabarit.
Les obligations du déployeur : utilisation conforme à la notice, contrôle humain effectif et journalisation côté exploitation (article 26) relèvent du déployeur. Le dossier du fournisseur ne couvre que ce que le fournisseur maîtrise.
Les autres régimes : la documentation exigée par le CRA (Cyber Resilience Act, règlement (UE) 2024/2847) pour un produit comportant des éléments numériques, l’analyse d’impact du RGPD (règlement général sur la protection des données) ou la documentation d’un modèle d’IA à usage général sont d’autres obligations. Elles peuvent partager des artefacts, mais pas se substituer les unes aux autres.
La sécurité du système : décrire des mesures de cybersécurité au point 2 h ne prouve pas leur efficacité. Les tests d’intrusion, le red teaming et la surveillance produisent des preuves que le dossier se contente de référencer.
Un avis juridique : savoir si un système donné est conforme relève d’un organisme notifié, d’une autorité ou d’un avocat. Le texte officiel sur EUR-Lex fait foi.

Une tension mérite d’être signalée. Mesurer l’exactitude par groupe de personnes (point 3) suppose de connaître l’appartenance à ces groupes, parfois des catégories particulières de données. Depuis le règlement (UE) 2026/1744, ce traitement à des fins de détection et de correction des biais relève de l’article 4 bis, qui remplace l’article 10, §5 supprimé, sous conditions strictes (pseudonymisation, suppression une fois le biais corrigé) ; le détail est sur la page gouvernance des données. On conserve la fiche de données et les résultats agrégés, pas nécessairement les attributs sensibles.

Exemple : chaîne de production du dossier d’un système de tri de candidatures

Organisation fictive, construite pour l’illustration : un éditeur fournit un système de présélection de candidatures, qui relève de l’annexe III, point 4 (emploi). Il intègre un modèle de langage tiers consommé par API. Le schéma montre d’où provient chaque pièce du dossier et qui la signe.

Le flux se lit de haut en bas. Aucune pièce n’entre dans le dossier sans passer par le dépôt de référence. Le rapport de test n’y entre que signé, et seulement si les seuils d’acceptation, fixés à l’avance au point 2 f, sont atteints. Un écart d’exactitude entre groupes au-delà du seuil documenté renvoie à l’équipe données au lieu de produire une version « à corriger plus tard ». Le générateur assemble la notice et le dossier depuis la même source, ce qui supprime le risque de deux vérités. Chaque version livrée est figée avec son empreinte : à la demande motivée d’une autorité, on restitue exactement le dossier qui accompagnait la version évaluée, et non l’état courant du dépôt.

Le point faible de l’exemple est volontairement visible : tout repose sur l’accord écrit avec le fournisseur du modèle. Si ce dernier change de version sans prévenir, les points 1 c et 2 a deviennent faux sans qu’aucun commit ne le signale. On épingle donc la version du modèle dans l’appel d’API, et on traite toute dépréciation annoncée comme un déclencheur de mise à jour du point 6.

Conditions d’exploitation sur dix ans

Propriété : un responsable nommé pour le dossier, distinct de l’équipe de développement, qui contresigne chaque version. Sans propriétaire, la tenue à jour de l’article 11, §1 n’a pas de débiteur.
Déclencheurs de mise à jour : nouvelle version du modèle, nouveau jeu de données, changement de seuil, nouvelle dépendance tierce, incident remonté par la surveillance après commercialisation, nouvelle norme harmonisée publiée au JO (Journal officiel de l’Union européenne) applicable au point 7. Chacun produit une entrée datée au point 6.
Conservation : dix ans après la mise sur le marché ou la mise en service (article 18, §1), y compris pour les versions retirées. Le stockage doit survivre à une réorganisation, à un changement de fournisseur cloud et, le cas échéant, à la disparition du fournisseur ; l’article 18, §2 renvoie aux États membres pour ce dernier cas.
Clés et signatures : les clés de signature des rapports ont une durée de vie plus courte que dix ans. On archive les certificats et les chaînes de validation, et on prévoit un horodatage qui reste vérifiable après l’expiration du certificat de signature. Les fondamentaux se trouvent dans la section PKI et TLS.
Restitution : un exercice périodique d’extraction complète, dans une langue aisément compréhensible par l’autorité (article 21), chronométré. Une restitution qui exige de retrouver une personne partie depuis trois ans n’est pas une restitution.
Sauvegarde et reprise : l’archive WORM n’est pas une sauvegarde si elle n’existe qu’à un seul endroit. On prévoit une deuxième copie dans une autre zone de défaillance, avec vérification régulière des empreintes.

🐝 Ce qui arrive si on s’en passe

Sans documentation établie avant la mise sur le marché, l’évaluation de conformité de l’article 43, interne ou par un organisme notifié, n’a rien à examiner : la déclaration UE ne peut pas être signée et le système ne peut pas être commercialisé légalement. Sans tenue à jour, la seule trace de ce qui tournait à une date donnée disparaît. Un écart de performance détecté par la surveillance ne peut plus être rattaché à une version, à un jeu de données ou à un seuil, et toute analyse de cause devient une reconstitution. Sans rapports signés ni empreintes, plus rien ne distingue un résultat de test d’origine d’un résultat réécrit. Sans conservation sur dix ans, une demande motivée d’autorité porte sur des versions dont plus personne ne peut restituer le contenu.

🦫 Explication de la marmotte 🍫

En Europe, une loi appelée règlement sur l’intelligence artificielle classe certains programmes « à haut risque », par exemple ceux qui trient des candidatures d’emploi. L’entreprise qui fabrique un tel programme doit écrire un dossier avant de le vendre. Ce dossier contient neuf parties : à quoi sert le programme, comment il a été construit, quelles données ont servi à l’entraîner, comment il a été testé, quels résultats il obtient pour chaque groupe de personnes, quels dangers ont été repérés, quelles règles de sécurité ont été suivies, une déclaration officielle de conformité et un plan pour surveiller le programme une fois vendu. Les tests doivent porter une date et la signature de la personne responsable. Avant la vente, ce dossier sert à vérifier que le programme respecte la loi : le plus souvent, c’est l’entreprise elle-même qui fait cette vérification en suivant une procédure imposée ; dans quelques cas, un organisme extérieur s’en charge. Chaque fois que le programme change, le dossier doit être corrigé. Si le changement n’avait pas été prévu et décrit à l’avance, un nouveau contrôle peut être nécessaire. Le dossier doit être gardé dix ans et remis à l’autorité qui le demande. Quand le dossier manque, le contrôle est impossible et la vente n’est pas autorisée. Quand il n’est pas mis à jour, plus personne ne peut dire ce que faisait vraiment le programme à une date donnée. Enfin, ce dossier contient des détails sur les défenses du programme : il doit donc lui-même être protégé contre les lectures non autorisées et les modifications.

Pages voisines

La citent

AI Act : documentation technique d'une IA à haut risque (article 11, annexe IV)

Elle cite

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