Documentation technique du règlement sur l’IA : guide de l’annexe IV

Pour un dispositif médical, cela se replie dans votre dossier technique MDR/IVDR existant, voir documentation de l’annexe IV pour l’IA médicale.

L’essentiel, ce qu’il faut savoir sur la documentation de l’annexe IV

• Qui : tout fournisseur d’un système d’IA à haut risque doit établir la documentation technique de l’annexe IV avant de mettre le système sur le marché de l’Union ou de le mettre en service.
• Quoi : neuf rubriques obligatoires : description générale, processus de développement, surveillance, indicateurs de performance, système de gestion des risques, modifications tout au long du cycle de vie, normes harmonisées, déclaration UE de conformité, et surveillance après mise sur le marché.
• Quand : la documentation doit exister avant le début de l’évaluation de la conformité, pas après. Les obligations à haut risque de l’annexe III s’appliquent à compter du 2 décembre 2027 (reportées du 2 août 2026 par le Digital Omnibus, règlement (UE) 2026/1744, en vigueur depuis le 27 juillet 2026). Pour l’annexe I, l’échéance est le 2 août 2028. L’article 50 reste au 2 août 2026.
• Combien de temps : comptez 40 à 60 heures pour un système simple, 60 à 100 heures pour un système de complexité moyenne, et 100 à 200 heures ou plus pour un système complexe. Une documentation rédigée après coup prend deux à trois fois plus longtemps.
• Allègement PME : l’article 11, paragraphe 2 permet aux PME et aux jeunes pousses d’utiliser une forme simplifiée ; les neuf rubriques doivent néanmoins être traitées.
• Document vivant : la documentation de l’annexe IV n’est pas un livrable unique ; elle doit être tenue à jour tout au long du cycle de vie du système d’IA.
• Condition d’accès au marché : sans documentation complète, vous ne pouvez pas passer l’évaluation de la conformité. Sans évaluation de la conformité, vous ne pouvez pas exploiter licitement.

Pourquoi la documentation technique compte

L’article 11 exige que la documentation technique d’un système d’IA à haut risque soit établie avant que ce système ne soit mis sur le marché ou mis en service, et tenue à jour tout au long de son cycle de vie.

La documentation sert deux finalités :

1. Démontrer la conformité aux exigences des articles 8 à 15 : gestion des risques, gouvernance des données, transparence, contrôle humain, exactitude, robustesse et cybersécurité.
2. Fournir aux autorités nationales compétentes toutes les informations nécessaires pour évaluer la conformité du système.

Ce n’est pas une formalité. Lors de l’évaluation de la conformité, qu’elle soit auto-évaluée ou menée par un organisme notifié, l’évaluateur confronte votre documentation aux exigences juridiques. Les lacunes se traduisent directement par des échecs, des retards et, au pire, l’impossibilité de mettre le système sur le marché.

Le lien avec l’évaluation de la conformité est direct : pour les systèmes relevant de l’auto-évaluation au titre de l’annexe VI, l’équipe interne de gestion de la qualité du fournisseur revoit la documentation. Pour les systèmes relevant d’un organisme notifié au titre de l’annexe VII (principalement l’identification biométrique), un évaluateur externe examine chaque rubrique. Dans les deux cas, une documentation incomplète ou vague est de loin la cause la plus fréquente d’échec.

Les neuf rubriques obligatoires de l’annexe IV

Les rubriques ci-dessous reprennent la structure de l’annexe IV du règlement sur l’IA. Pour chacune, nous indiquons ce qu’il faut y mettre, ce qu’il ne faut pas y mettre, et un exemple concret fondé sur un système d’IA d’évaluation de la solvabilité, l’une des classifications à haut risque les plus fréquentes au titre de l’annexe III, point 5, a).

Les intitulés officiels des neuf rubriques sont :

1. une description générale du système d’IA
2. une description détaillée des éléments du système d’IA et de son processus de développement
3. des informations détaillées sur la surveillance, le fonctionnement et le contrôle du système d’IA
4. une description de l’adéquation des indicateurs de performance à ce système d’IA spécifique
5. une description détaillée du système de gestion des risques conformément à l’article 9
6. une description des modifications pertinentes apportées par le fournisseur au système tout au long de son cycle de vie
7. une liste des normes harmonisées appliquées
8. une copie de la déclaration UE de conformité visée à l’article 47
9. une description détaillée du système en place pour évaluer les performances du système d’IA après mise sur le marché conformément à l’article 72

Rubrique 1 : une description générale du système d’IA

À inclure :

• La destination du système, formulée avec précision
• Le nom, l’adresse et les coordonnées du fournisseur
• Le numéro de version du système et les versions précédentes
• La manière dont le système interagit avec du matériel ou des logiciels externes
• Les versions des logiciels ou micrologiciels pertinents, et les exigences de mise à jour
• Toutes les formes sous lesquelles le système est mis sur le marché (SaaS, API, embarqué, sur site)
• Le matériel informatique sur lequel le système est destiné à être exécuté
• Pour les composants de produits : photographies montrant les caractéristiques externes, le marquage et la disposition interne
• Une description de base de l’interface utilisateur fournie au déployeur

À ne PAS inclure : textes marketing, descriptions de fonctionnalités aspirationnelles, ou allégations vagues sur les capacités. Écrivez comme si vous expliquiez le système à une autorité qui ne l’a jamais vu.

Exemple d’évaluation de la solvabilité : « CreditScore Pro v3.2 est un système d’IA qui évalue la solvabilité de personnes physiques demandant un crédit à la consommation entre 1 000 et 50 000 EUR. Il ingère l’historique financier du demandeur, les données d’emploi et les schémas de transactions via une intégration API avec le système bancaire central de la banque qui le déploie. Il produit une note numérique (300-850) et une catégorie de risque (faible / moyen / élevé / très élevé). Il est déployé comme application SaaS hébergée dans le nuage sur AWS eu-west-1. Le système ne prend pas de décisions de prêt autonomes ; il fournit une recommandation qu’un chargé de crédit humain évalue. »

Rubrique 2 : une description détaillée des éléments du système d’IA et de son processus de développement

C’est la rubrique la plus exigeante techniquement. Elle doit couvrir cinq sous-domaines :

Conception et développement :

• Logique générale du système et algorithmes utilisés
• Choix de conception essentiels, y compris le raisonnement et les hypothèses retenues
• Architecture expliquant comment les composants logiciels s’alimentent les uns les autres
• Ressources informatiques utilisées pour le développement, l’entraînement, les essais et la validation
• Outils, bibliothèques ou modèles préentraînés de tiers, avec numéros de version

Pratiques relatives aux données :

• Méthodes et techniques d’entraînement
• Données d’entraînement : description des jeux, provenance, portée, caractéristiques principales
• Comment les données ont été obtenues et sélectionnées
• Procédures d’étiquetage et méthodes de nettoyage
• Évaluation des données sous l’angle de l’adéquation, des biais et des lacunes éventuelles

Contrôle humain :

• Mesures conçues dans le système pour faciliter le contrôle humain au titre de l’article 14

Modifications prédéterminées :

• Toute modification prédéterminée du système et de ses performances, avec le détail des solutions techniques destinées à garantir le maintien de la conformité

Validation et essais :

• Procédures de validation et d’essai, y compris les données utilisées et leurs caractéristiques principales
• Indicateurs utilisés pour mesurer l’exactitude, la robustesse et la conformité
• Journaux d’essai et rapports d’essai datés et signés

Cybersécurité :

• Solutions techniques répondant aux exigences de l’article 15
• Mesures contre les vulnérabilités propres à l’IA : empoisonnement des données, empoisonnement du modèle, exemples adverses

Exemple d’évaluation de la solvabilité, pratiques relatives aux données : « Les données d’entraînement comprennent 2,4 millions de demandes de crédit historiques anonymisées, période 2018-2024, provenant de trois partenaires bancaires de l’Union au titre d’accords de partage de données. Le jeu comporte 43 caractéristiques par demande. Les caractéristiques protégées des demandeurs (sexe, origine ethnique, âge) ont été exclues des entrées du modèle mais conservées dans un jeu d’analyse séparé pour les essais de biais. Étiquetage : chaque demande a été étiquetée avec le résultat réel de remboursement (défaut / pas de défaut) à 12 mois. Nettoyage : 14 200 enregistrements (0,6 %) ont été exclus pour données de remboursement incomplètes. Appréciation des biais : le jeu d’entraînement surreprésente les demandeurs de 30 à 50 ans et sous-représente ceux de moins de 25 ans. Cela a été traité par un échantillonnage stratifié pendant l’entraînement et une calibration a posteriori des notes par tranche d’âge. »

Modèles de tiers et modèles préentraînés : si votre système utilise un modèle que vous n’avez pas entraîné, un modèle de fondation affiné, un modèle de plongement préentraîné, ou une API de classification tierce, vous devez malgré tout documenter les caractéristiques du modèle de base, votre processus d’adaptation, et les limites héritées. « Nous avons utilisé le modèle X » ne suffit pas. Demandez la documentation technique, les fiches de modèle ou les fiches de données à vos fournisseurs. Consignez ce que vous savez, ce que vous ne savez pas, et les mesures prises pour combler les lacunes. Si le fournisseur ne peut pas fournir une documentation adéquate, ce manque est lui-même un risque à documenter et à atténuer.

Rubrique 3 : des informations détaillées sur la surveillance, le fonctionnement et le contrôle du système d’IA

• Les capacités et limites du système sur le plan de la performance, y compris le degré d’exactitude pour des personnes ou des groupes spécifiques
• Les résultats non intentionnels prévisibles et les sources de risques pour la santé, la sécurité et les droits fondamentaux
• Les spécifications de contrôle humain : mesures techniques pour faciliter l’interprétation des sorties
• Les spécifications relatives aux données d’entrée, le cas échéant

Exemple d’évaluation de la solvabilité : « L’exactitude du système (AUC-ROC) est de 0,87 sur la population d’essai générale. Limites connues : l’exactitude tombe à 0,79 pour les demandeurs avec moins de 12 mois d’historique de crédit, et à 0,81 pour les travailleurs indépendants aux revenus irréguliers. Le système peut produire des notes peu fiables pour des demandeurs de pays dont les dispositifs de communication des crédits sont incompatibles. Contrôle humain : le tableau de bord du déployeur affiche la note, les cinq facteurs contributeurs principaux, et un indicateur de confiance. Si la confiance est inférieure à 70 %, le système oriente le dossier vers un examen manuel obligatoire. »

Rubrique 4 : une description de l’adéquation des indicateurs de performance à ce système d’IA spécifique

• Les indicateurs choisis pour mesurer la performance
• Pourquoi ces indicateurs sont adaptés au système et à sa destination
• Le ou les référentiels au regard desquels la performance est mesurée

Exactitude ventilée : le règlement attend que les indicateurs de performance soient ventilés par sous-groupes pertinents, et non rapportés seulement en agrégat. Pour un système d’évaluation de la solvabilité, cela veut dire rapporter l’exactitude, les taux de faux positifs et les taux de faux négatifs ventilés par tranche d’âge, sexe, région géographique et type d’emploi. Un seul chiffre agrégé « 95 % d’exactitude » est insuffisant et sera vraisemblablement contesté lors de l’évaluation de la conformité.

Exemple d’évaluation de la solvabilité : « Indicateur primaire : AUC-ROC, choisi parce qu’il mesure la capacité discriminante sur tous les seuils de classification, ce qui convient à un système de notation où les déployeurs fixent leurs propres seuils d’acceptation. Indicateurs secondaires : taux de faux positifs (FPR) et taux de faux négatifs (FNR), rapportés ventilés par tranche d’âge (moins de 25, 25-35, 35-50, 50-65, 65 et plus), sexe, et type d’emploi (salarié, indépendant, sans emploi). Référentiel : la performance du système est comparée au modèle de régression logistique en place chez le partenaire bancaire principal, sur le même jeu d’essai. »

Rubrique 5 : une description détaillée du système de gestion des risques conformément à l’article 9

• Le système de gestion des risques au titre de l’article 9
• Les risques connus ou prévisibles identifiés
• Les résultats de l’évaluation des risques
• Les mesures de gestion des risques adoptées et l’appréciation du risque résiduel
• La preuve que le processus a été itératif et mené tout au long du cycle de développement

Exemple d’évaluation de la solvabilité : « Le registre des risques compte 23 risques identifiés. Les cinq premiers par gravité : (1) biais systématique contre les jeunes demandeurs au dossier de crédit mince, atténué par une calibration stratifiée par âge et un examen manuel obligatoire pour les moins de 25 ans ; (2) discrimination par procuration via le code postal, atténuée par l’exclusion des caractéristiques géographiques et des essais d’impact disparate ; (3) dérive des données liée à l’évolution des conditions économiques, atténuée par un suivi trimestriel de la performance du modèle et des déclencheurs de réentraînement ; (4) manipulation adverse des données d’entrée, atténuée par la validation des entrées, la détection d’anomalies et la contre-vérification des schémas de transactions ; (5) surconfiance des déployeurs dans les notes automatisées, atténuée par l’exigence d’un examen humain pour toutes les notes limites (plage 550-650). »

Rubrique 6 : une description des modifications pertinentes apportées par le fournisseur au système tout au long de son cycle de vie

• Toutes les modifications pertinentes apportées au système tout au long de son cycle de vie
• Comment les modifications ont été essayées et validées
• Les procédures de contrôle de version et de gestion des changements

Cette rubrique doit être tenue comme un registre vivant. Chaque mise à jour de modèle, réentraînement, ajout de fonctionnalité ou recalibration de performance devrait être consigné avec la date, le motif, les résultats d’essai, et la confirmation du maintien de la conformité.

Rubrique 7 : une liste des normes harmonisées appliquées

• Si des normes harmonisées au titre de l’article 40 ont été appliquées, les lister avec numéros de version
• Là où aucune norme harmonisée n’a été appliquée, décrire les solutions adoptées pour satisfaire au chapitre III, section 2

En avril 2026, le CEN/CENELEC avait publié des projets de normes, mais toutes n’étaient pas encore formellement harmonisées. Consignez les normes que vous avez suivies et, pour les domaines sans norme harmonisée, expliquez comment vous avez satisfait aux exigences juridiques directement à partir du texte des articles 8 à 15.

Rubrique 8 : une copie de la déclaration UE de conformité visée à l’article 47

• Une copie de la déclaration UE de conformité au titre de l’article 47

Cette rubrique est complétée à la fin de la procédure d’évaluation de la conformité. La déclaration vise le système, le fournisseur, les normes harmonisées ou autres spécifications utilisées, et la procédure d’évaluation de la conformité suivie.

Rubrique 9 : une description détaillée du système en place pour évaluer les performances du système d’IA après mise sur le marché conformément à l’article 72

• Le système de surveillance après mise sur le marché au titre de l’article 72
• Comment les données de performance sont recueillies et analysées après le déploiement
• Les seuils et déclencheurs d’action corrective
• Les procédures de signalement d’incidents au titre de l’article 73

Exemple d’évaluation de la solvabilité : « Suivi de la performance : calcul automatisé hebdomadaire de l’AUC-ROC, du FPR et du FNR sur une fenêtre glissante de 90 jours de décisions en production, ventilé par sous-groupe. Seuils d’alerte : si l’AUC-ROC d’un sous-groupe tombe sous 0,80, une investigation est déclenchée sous 48 heures. Si l’AUC-ROC agrégé tombe sous 0,83, le système est marqué pour réentraînement. Boucle de rétroaction : les partenaires de déploiement rapportent chaque trimestre les taux de défaut réels des demandes notées par l’IA, ce qui permet un contre-essai des prédictions. Signalement d’incidents : l’équipe de surveillance après mise sur le marché signale les incidents graves à l’autorité de surveillance du marché compétente dans les 15 jours, conformément à l’article 73. »

Scénarios de documentation dans la pratique

Scénario 1 : IA de dispositif médical (radiologie)

Un fournisseur d’un système d’IA qui aide les radiologues à détecter des nodules pulmonaires sur des scanners (haut risque au titre de l’annexe III, point 1, et potentiellement du règlement relatif aux dispositifs médicaux) fait face aux exigences documentaires les plus lourdes. Une évaluation de la conformité par un tiers, via un organisme notifié, est vraisemblable. La rubrique 2 doit inclure des descriptions détaillées du jeu d’entraînement (des dizaines de milliers de scanners annotés), de la fiabilité inter-annotateurs de l’étiquetage, et de la performance ventilée par taille de nodule, démographie des patients et fabricant de scanner. La rubrique 5 doit traiter le risque de détections manquées (faux négatifs) et de fausses alertes (faux positifs), avec une quantification précise du risque résiduel.

Scénario 2 : outil de présélection RH (recrutement)

Une entreprise de technologies RH qui fournit un système d’IA filtrant les candidatures (haut risque au titre de l’annexe III, point 4, a)) doit documenter, à la rubrique 2, comment les données d’entraînement ont été constituées pour éviter d’encoder des biais d’embauche historiques. La rubrique 3 doit préciser l’exactitude ventilée par sexe, âge, origine ethnique et situation de handicap. La rubrique 5 doit traiter les risques, y compris la discrimination indirecte via des caractéristiques par procuration (nom de l’université comme procuration du statut socio-économique, années sabbatiques comme procuration des responsabilités d’aidant). La rubrique 9 doit décrire comment le fournisseur surveille si les recommandations du système produisent, en production, des résultats disparates entre groupes protégés.

Scénario 3 : surveillance d’infrastructures critiques

Un fournisseur d’un système d’IA qui surveille la stabilité du réseau électrique et déclenche des décisions automatisées de délestage (haut risque au titre de l’annexe III, point 2) doit documenter, à la rubrique 1, l’interaction du système avec les systèmes SCADA et le matériel de réseau. La rubrique 2 doit couvrir les environnements de simulation utilisés pour les essais, les essais sur réseau vivant n’étant pas praticables. La rubrique 5 doit traiter les risques de défaillance en cascade, y compris les scénarios où l’IA déclenche à tort un délestage et provoque des coupures non planifiées touchant hôpitaux et services d’urgence.

Pièges fréquents et comment les corriger

Piège 1 : rédiger la documentation après coup

Le règlement exige que la documentation soit établie pendant le développement, pas une fois le système achevé. Si les choix de conception, les choix de données d’entraînement et les résultats d’essai n’ont pas été consignés au fil de l’eau, les reconstruire est plus difficile et moins crédible pour un évaluateur.

Correction : tenez un journal de documentation dès le premier jour. Consignez les décisions clés, les descriptions de jeux et les résultats d’essai en temps réel. Intégrez les tâches documentaires à votre cycle de développement.

Piège 2 : traiter la documentation comme un livrable unique

La documentation de l’annexe IV est un document vivant. Elle doit être tenue à jour tout au long du cycle de vie. Tout changement significatif, mise à jour de modèle, nouveau jeu d’entraînement, changement de destination, déclenche une mise à jour.

Correction : couplez les mises à jour documentaires à votre pipeline CI/CD. Chaque version qui change le comportement du modèle devrait déclencher une revue documentaire. Utilisez un contrôle de version (Git) pour la documentation, à côté du code.

Piège 3 : ignorer les limites héritées de composants tiers

Si votre système utilise un modèle préentraîné, un jeu de données tiers ou une API externe, vous devez documenter les limites et risques hérités. « Nous avons utilisé GPT-4 pour la couche de plongement » ne suffit pas.

Correction : demandez la documentation technique ou les fiches de modèle à vos fournisseurs. Consignez ce que vous savez et ce que vous ne savez pas. Si un fournisseur ne peut pas fournir une documentation adéquate, documentez cette lacune et expliquez votre stratégie d’atténuation.

Piège 4 : allégations d’exactitude vagues ou seulement agrégées

« Le système atteint 95 % d’exactitude » ne satisfait pas le standard de l’annexe IV. Vous devez préciser :

• L’indicateur utilisé (précision, rappel, F1, AUC-ROC, etc.)
• Le jeu sur lequel il a été mesuré
• Les segments de population pour lesquels il a été mesuré (performance ventilée)
• Les modes de défaillance connus et les chutes de performance dans des conditions précises

Correction : rapportez la performance ventilée sur tous les sous-groupes pertinents. Consignez les jeux, les conditions et les seuils. Soyez explicite sur les endroits où la performance se dégrade.

Piège 5 : documentation de cybersécurité manquante

Beaucoup d’équipes documentent la performance fonctionnelle et négligent la cybersécurité. L’article 15 exige une documentation précise des mesures contre l’empoisonnement des données, l’empoisonnement du modèle, les entrées adverses et l’accès non autorisé.

Correction : menez une modélisation des menaces propre aux vulnérabilités de l’IA. Documentez chaque menace, les mesures d’atténuation et le risque résiduel. C’est distinct de votre posture générale de sécurité informatique.

Piège 6 : pas de contrôle de version ni de piste d’audit

Les évaluateurs chercheront la preuve que la documentation a évolué avec le système. Un unique document Word non daté, sans historique de changements, est un signal d’alerte.

Correction : stockez la documentation dans des dépôts versionnés. Utilisez des validations horodatées. Tenez un journal des changements pour chaque révision majeure.

Allègements PME au titre de l’article 11, paragraphe 2

L’article 11, paragraphe 2 permet explicitement aux PME et aux jeunes pousses de fournir les éléments de l’annexe IV sous une forme simplifiée. La Commission européenne est chargée d’établir un formulaire simplifié de documentation technique, adapté aux besoins des petites et microentreprises.

En avril 2026, la Commission n’avait pas encore publié ce formulaire. L’approche pratique dans l’intervalle :

1. Couvrir les neuf rubriques, la simplification porte sur la profondeur, pas sur le périmètre.
2. Caler le détail sur la complexité du système, un outil de classification simple n’a pas besoin de la même profondeur qu’un système d’IA médicale de diagnostic.
3. Privilégier le fond à la longueur, les évaluateurs jugent si vous avez traité les exigences, pas le nombre de pages.
4. Documenter ce que vous savez vraiment, mieux vaut écrire « nous avons essayé sur un jeu de 5 000 enregistrements et trouvé X » que d’inventer des récits d’essai élaborés.

Exemple : une jeune pousse de cinq personnes qui fournit un système d’IA priorisant des tickets d’assistance (haut risque s’il est utilisé dans des services essentiels) peut documenter son processus de développement en 15 à 20 pages plutôt que les 80 pages ou plus dont un grand fournisseur d’IA médicale pourrait avoir besoin, dès lors que chaque rubrique de l’annexe IV est traitée avec des informations honnêtes et précises.

La documentation comme document vivant

La documentation de l’annexe IV n’est pas un livrable que l’on achève et archive. Le règlement exige qu’elle soit tenue à jour tout au long du cycle de vie. Déclencheurs de mise à jour :

• Réentraînement ou affinage du modèle, mettre à jour les rubriques 2, 4 et 5.
• Nouvelles données d’entraînement, mettre à jour les rubriques 2 et 5.
• Changement de destination ou de contexte de déploiement, mettre à jour les rubriques 1, 3 et 5.
• Nouveaux risques identifiés, mettre à jour la rubrique 5.
• Dégradation de performance détectée, mettre à jour les rubriques 4 et 9.
• Orientations réglementaires ou normes harmonisées publiées, mettre à jour la rubrique 7.
• Incidents après mise sur le marché, mettre à jour les rubriques 5 et 9.

Fixez une cadence de revue : au minimum trimestrielle, ou déclenchée par l’un des événements ci-dessus.

Conseils pratiques sur les outils et le contrôle de version

Une documentation éparpillée dans des documents Word et des fils de courriel ne survivra pas à une évaluation de la conformité. Approches concrètes des premiers adoptants :

1. Documentation dans le code : stockez la documentation en Markdown ou reStructuredText à côté du code, versionnée dans Git. Chaque changement documentaire est une validation avec horodatage et auteur.
2. Canevas structurés : utilisez un canevas cohérent qui reprend les neuf rubriques de l’annexe IV. Cela garantit l’exhaustivité et facilite la revue par l’évaluateur.
3. Capture automatisée des données : tirez les métadonnées d’entraînement, les résultats d’essai et les indicateurs de performance directement de votre pipeline d’apprentissage automatique vers les canevas. Des outils comme MLflow, Weights & Biases ou DVC peuvent automatiser une grande partie des rubriques 2 et 4.
4. Circuits de revue : exigez une validation des changements documentaires, comme pour le code. Cela crée une piste d’audit montrant qui a approuvé quoi, et quand.
5. Source unique de vérité : évitez de dupliquer l’information d’un système à l’autre. Si votre registre des risques vit dans un outil de GRC, référencez-le depuis la documentation plutôt que de le copier.

Liste de préparation

Servez-vous-en pour auditer votre préparation avant de commencer la documentation formelle :

• Description du système et destination définies avec précision
• Schémas d’architecture et inventaire des composants préparés
• Tous les composants tiers identifiés, documentation des fournisseurs obtenue
• Sources des données d’entraînement, critères de sélection et méthodes de nettoyage documentés
• Appréciation des biais des données d’entraînement et d’essai achevée, avec résultats ventilés
• Mesures de contrôle humain spécifiées et essayées
• Indicateurs d’exactitude définis, avec données de performance ventilées par sous-groupes pertinents
• Modélisation des menaces de cybersécurité (propre à l’IA) achevée, atténuations documentées
• Processus de gestion des risques documenté, avec preuves d’itération tout au long du cycle de développement
• Plans d’essai, résultats d’essai et rapports d’essai archivés, datés et signés
• Plan de surveillance après mise sur le marché rédigé, avec seuils et déclencheurs
• Procédures de gestion des changements et de contrôle de version définies
• Documentation stockée dans un dépôt versionné, avec piste d’audit
• Applicabilité de la simplification PME évaluée (le cas échéant)

Estimations de temps et de ressources selon la complexité du système

Ces chiffres supposent que les choix de conception ont été consignés dès le départ. La documentation après coup, reconstruire décisions, résultats d’essai et provenance des données, est constamment la voie la plus chère et la plus sujette à erreur.

Lien avec l’évaluation de la conformité

La documentation technique n’est pas une fin en soi ; c’est l’intrant principal de l’évaluation de la conformité. Le rapport est direct :

• Auto-évaluation (annexe VI) : votre système interne de gestion de la qualité revoit la documentation au regard des articles 8 à 15. Si la documentation est incomplète, l’auto-évaluation ne peut pas aboutir.
• Évaluation par un organisme notifié (annexe VII) : l’organisme notifié examine votre documentation en détail. Attendez-vous à des questions, des demandes de clarification et des audits de suivi. La qualité de votre documentation détermine la vitesse et le coût de l’évaluation.
• Déclaration UE de conformité (article 47) : vous ne pouvez pas signer la déclaration sans évaluation de la conformité achevée, et vous ne pouvez pas achever l’évaluation de la conformité sans documentation complète.

Prochaines étapes

1. Classez votre système d’IA pour confirmer si la documentation de l’annexe IV est requise.
2. Relisez le texte intégral de l’annexe IV pour les exigences juridiques exactes.
3. Utilisez la liste ci-dessus pour auditer vos lacunes documentaires actuelles.
4. Commencez par la rubrique 1 (description générale) et la rubrique 2 (processus de développement), ce sont les plus chronophages.
5. Parcourez la liste de contrôle de conformité complète pour voir comment la documentation s’insère dans le programme plus large.

Lancez l’évaluation gratuite au titre du règlement sur l’IA pour confirmer la classification des risques de votre système et vos obligations documentaires.

Pour le texte juridique complet, voir le guide intégral du règlement sur l’IA.

Questions fréquentes

Quel degré de détail la documentation de l’annexe IV doit-elle atteindre ?

Assez détaillé pour qu’un évaluateur, interne ou organisme notifié, vérifie que votre système satisfait à chaque exigence des articles 8 à 15 sans vous poser de questions complémentaires. Le critère n’est pas un nombre de pages ; c’est l’exhaustivité et la précision. Un document de 30 pages qui traite chaque rubrique avec des preuves concrètes vaut mieux qu’un document de 100 pages en langue générique. Le test clé : un évaluateur qualifié qui n’a jamais vu votre système pourrait-il comprendre, à la seule lecture de la documentation, comment il fonctionne, quels risques il présente, et comment vous les avez atténués ?

Puis-je réutiliser de la documentation ISO ou d’autres référentiels ?

En partie. La documentation existante d’ISO 42001 (systèmes de management de l’IA), d’ISO 27001 (sécurité de l’information) ou d’IEC 62304 (logiciels de dispositifs médicaux) peut fournir des briques, mais aucune de ces normes ne se superpose directement aux neuf rubriques de l’annexe IV. Utilisez l’existant là où il traite les mêmes sujets, mais préparez-vous à combler les lacunes, surtout autour des exigences propres à l’IA : indicateurs de performance ventilés, appréciations des biais, et menaces de cybersécurité propres à l’IA (empoisonnement des données, exemples adverses).

Que faire si mon système utilise un modèle préentraîné et que le fournisseur ne partage pas la documentation complète ?

Documentez ce que le fournisseur a fourni (fiche de modèle, fiche de données, référentiels de performance), ce que vous avez demandé sans l’obtenir, et comment vous avez traité les lacunes documentaires qui en résultent. Menez votre propre évaluation de la performance du modèle dans votre contexte de déploiement. Documentez les risques hérités et votre stratégie d’atténuation. Un évaluateur de la conformité jugera si votre approche est raisonnable au vu des informations disponibles, mais une absence complète de documentation fournisseur est un facteur de risque important, qui doit être traité explicitement.

La documentation doit-elle être rédigée dans une langue précise ?

La documentation doit être établie dans une langue officielle de l’État membre où le système est mis sur le marché ou mis en service. En pratique, l’anglais est largement accepté par les autorités de surveillance du marché dans l’Union, mais confirmez auprès de l’autorité nationale compétente. Si vous opérez dans plusieurs États membres, vous pourrez avoir besoin de traductions des rubriques essentielles.

À quelle fréquence la documentation de l’annexe IV doit-elle être mise à jour ?

Le règlement ne fixe pas de calendrier. L’exigence est que la documentation soit « tenue à jour » tout au long du cycle de vie. En pratique, les mises à jour devraient être déclenchées par tout changement matériel du système (réentraînement, nouvelles données, nouveau contexte de déploiement, incidents identifiés), toute nouvelle information sur les risques, et à des intervalles de revue réguliers (le trimestre est une base raisonnable). Chaque mise à jour devrait être versionnée, avec un journal des changements clair.

Quelles sont les sanctions en cas de documentation technique insuffisante ?

Une documentation insuffisante de systèmes d’IA à haut risque tombe dans la catégorie générale des manquements à haut risque, passibles d’amendes jusqu’à 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Pour les PME, le montant le plus bas s’applique. Au-delà des amendes, la conséquence pratique est que vous ne pouvez pas achever l’évaluation de la conformité, donc que vous ne pouvez pas mettre licitement le système sur le marché de l’Union. Voir le guide des sanctions et amendes pour le détail.

Legalithm est un outil d’accompagnement à la conformité assisté par l’IA, ce n’est pas un conseil juridique. Les décisions finales de conformité doivent être revues par un conseil juridique qualifié.