Documentation technique AI Act : préparer le dossier
Article 11, annexe IV, pièces du fournisseur et accès du client : structurez une documentation technique IA vérifiable et tenue à jour.
- Ce qu’il faut retenir
- Vérifier le rôle, le périmètre et la date d’application
- Une structure fidèle aux neuf rubriques de l’annexe IV
- Préparer les éléments transmis par les fournisseurs tiers
- Articuler les documents sans confondre leurs destinataires
- Organiser les mises à jour et la conservation
- Des simplifications qui conservent l’exigence de preuve
- Questions fréquentes
La documentation technique constitue l’un des piliers de la conformité des systèmes d’IA à haut risque. Elle doit permettre d’évaluer le système réellement commercialisé : sa finalité, ses limites, ses données, ses contrôles et les preuves des mesures annoncées. Un dossier générique décrivant une famille de modèles ne suffit pas à expliquer une version précise utilisée pour une décision précise.
Le fournisseur porte l’obligation de l’article 11. Le client qui utilise un système n’a pas, pour cette seule raison, à reconstruire l’intégralité du dossier du fournisseur. Il doit toutefois obtenir les informations nécessaires à ses propres obligations, et examiner si ses modifications le font changer de rôle.
Ce qu’il faut retenir
- L’article 11 et l’annexe IV organisent la documentation du fournisseur d’un système à haut risque ; la notice destinée au déployeur répond à un objet distinct.
- Le calendrier modifié en juillet 2026 reporte les sections 1 à 3 du chapitre III au 2 décembre 2027 pour l’annexe III et au 2 août 2028 pour l’annexe I, sous les règles de champ et de transition pertinentes.
- Les neuf rubriques de l’annexe IV incluent les changements du système, les indicateurs, les normes et la surveillance après commercialisation.
- Le dossier technique, les journaux et les données d’entraînement n’ont pas automatiquement la même durée de conservation.
- Le secret des affaires appelle des garanties de confidentialité ; il ne permet pas de refuser toute information à une autorité compétente.
Vérifier le rôle, le périmètre et la date d’application
L’article 11(1) exige une documentation établie avant la mise sur le marché ou la mise en service, puis tenue à jour. Elle contient au minimum les éléments de l’annexe IV et doit démontrer la conformité aux exigences de la section 2 du chapitre III. Pour les produits de l’annexe I, section A, l’article 11(2) prévoit un ensemble documentaire unique comprenant aussi les informations exigées par la législation sectorielle. AI Act, art. 11(1) et 11(2).
Au 26 septembre 2026, il faut lire cette obligation avec le règlement modificatif 2026/1744 : les sections 1 à 3 du chapitre III sont applicables 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. Les produits de l’annexe I, section B, relèvent du champ limité prévu par l’article 2(2). Les systèmes déjà mis sur le marché ou en service doivent aussi être examinés au regard de l’article 111(2), modifié, notamment en cas de changements significatifs de conception. Règlement 2026/1744, art. 1(2), 1(39) et 1(40).
Commencez donc par votre analyse de qualification d’IA à haut risque, et consignez la date et le fondement de l’obligation retenue. Le calendrier de l’article 11 ne reporte pas les obligations RGPD déjà applicables ni toutes les autres dispositions de l’AI Act.
Un déployeur peut devenir fournisseur dans les situations prévues par l’article 25(1), notamment certaines modifications substantielles ou certains changements de destination. L’étiquette contractuelle « client » ne suffit alors pas à déterminer ses responsabilités. AI Act, art. 25(1).
Une structure fidèle aux neuf rubriques de l’annexe IV
Le tableau suivant constitue un plan de travail. Les pièces sont à adapter au système concerné ; une rubrique inapplicable mérite une justification, plutôt qu’un document artificiellement rempli. AI Act, annexe IV, points 1 à 9.
| Rubrique | Informations à réunir | Pièces opérationnelles possibles |
|---|---|---|
| 1. Description générale | Destination, fournisseur, version et relation aux versions antérieures, interfaces, matériel, forme de distribution et notice | Fiche de version, schéma d’architecture, notice |
| 2. Développement | Méthodes, composants tiers, choix de conception, architecture, données, contrôle humain, modifications prédéterminées, validation et cybersécurité | Dossiers de conception, fiches de données, rapports d’essai datés et signés |
| 3. Fonctionnement et contrôle | Capacités, limites, exactitude selon les groupes pertinents, résultats non intentionnels, risques, entrées et contrôle humain | Tableau des limites d’usage et mesures opérationnelles |
| 4. Indicateurs | Adéquation des métriques au système et à sa destination | Justification du choix des indicateurs et seuils |
| 5. Gestion des risques | Système de gestion des risques de l’article 9 | Analyse des risques et suivi des mesures |
| 6. Modifications | Changements pertinents pendant le cycle de vie | Historique des versions et décisions associées |
| 7. Normes et solutions | Normes harmonisées appliquées, ou solutions retenues pour satisfaire aux exigences | Matrice exigences, solutions et preuves |
| 8. Déclaration | Copie de la déclaration UE de conformité | Déclaration liée à la version concernée |
| 9. Surveillance | Dispositif et plan de surveillance après commercialisation | Plan de collecte des retours, incidents et performances |
Les données d’entraînement, de validation et de test doivent être décrites selon les rubriques pertinentes, avec leur provenance, leurs caractéristiques et les procédures suivies. Documenter ces éléments ne signifie pas recopier toutes les données personnelles dans le dossier. Les rapports doivent permettre de relier les résultats présentés à une version, une méthode et un responsable.
Une précision globale isolée est rarement une preuve suffisante de pertinence. Par exemple, pour un outil évaluant des candidatures, décrivez les populations et situations couvertes par les essais, les limites connues et les mesures de contrôle. L’annexe IV exige notamment la justification des indicateurs et les informations pertinentes sur les incidences discriminatoires ; elle ne demande pas une simple affirmation d’« absence de biais ». AI Act, annexe IV, points 2(g), 3 et 4.
Préparer les éléments transmis par les fournisseurs tiers
Lorsqu’un système repose sur un modèle à usage général, distinguez la documentation du modèle et celle du système construit autour. L’article 53(1)(b) impose aux fournisseurs de modèles concernés des informations permettant aux intégrateurs de comprendre les capacités et limites du modèle et de respecter leurs obligations ; l’annexe XII précise le contenu minimal. L’article 53(2) comporte une exception pour certains modèles libres et ouverts, exclue en cas de risque systémique. AI Act, art. 53(1)(b), 53(2) et annexe XII.
Le nouvel article 25(4) prévoit un accord écrit entre le fournisseur du système à haut risque et le tiers qui fournit le système, modèle, outil, service, composant ou processus intégré. Cet accord précise les informations, capacités, accès techniques et autres formes d’assistance nécessaires. L’exception concernant certains composants libres et ouverts ne couvre pas les modèles à usage général. Règlement 2026/1744, art. 1(12).
Dressez la liste des informations manquantes avant de choisir le modèle. Pour chacune, attribuez un responsable, un moyen d’obtention et une conséquence si elle reste indisponible. Mentionner une lacune ne démontre pas, à lui seul, la conformité. Une limite documentaire peut imposer un autre fournisseur, des vérifications complémentaires ou une restriction du projet.
Articuler les documents sans confondre leurs destinataires
La notice de l’article 13 fournit au déployeur des informations accessibles et compréhensibles sur les capacités, limites et conditions d’utilisation. Le dossier technique de l’article 11 a notamment pour destinataires les autorités compétentes et les organismes notifiés. Un acheteur peut négocier des informations supplémentaires, sans présumer un droit général à toutes les pièces confidentielles du fournisseur. AI Act, art. 11(1) et 13(2)–(3).
L’AIPD relative au traitement d’IA répond à l’article 35 du RGPD : elle est obligatoire lorsque le traitement est susceptible d’engendrer un risque élevé, selon les critères applicables. La présence de données personnelles dans un système qualifié à haut risque par l’AI Act ne dispense pas de cette analyse propre au RGPD. Les pièces peuvent se référencer mutuellement ; le dossier technique ne remplace ni la base légale, ni l’information, ni l’exercice des droits. RGPD, art. 35(1) à 35(4).
Votre inventaire des systèmes d’IA peut indiquer où se trouvent le dossier technique, la notice, les contrats et les analyses. Il faut le distinguer de la base européenne des articles 49 et 71, dont l’enregistrement dépend du rôle et du système.
Organiser les mises à jour et la conservation
Chaque version du système doit être associée à une version du dossier. Tracez l’auteur, la date, le changement, sa justification et les pièces remplacées. Les modifications prédéterminées par le fournisseur et documentées dans l’évaluation initiale des systèmes continuant à apprendre ne sont pas toutes des modifications substantielles nécessitant une nouvelle procédure. L’article 43(4) doit être appliqué aux circonstances exactes du changement. AI Act, art. 43(4) et annexe IV, point 2(f).
L’article 18(1) prévoit que le fournisseur tient notamment la documentation technique, les pièces du système qualité et la déclaration de conformité à disposition pendant une période prenant fin dix ans après la mise sur le marché ou en service. Cette règle ne constitue pas une durée générale de conservation de toutes les données d’entraînement. Les journaux sous le contrôle du fournisseur obéissent à l’article 19, avec une période adaptée d’au moins six mois, sous réserve des autres règles applicables, notamment de protection des données. AI Act, art. 18(1) et 19(1).
Pour préparer un contrôle de conformité IA, conservez un index des pièces et une procédure d’accès sécurisé. L’article 21(1) exige une langue aisément compréhensible par l’autorité, parmi les langues officielles de l’Union indiquées par l’État membre concerné : l’anglais n’est pas une réponse universellement acquise. L’article 74(13) permet, sous conditions et sur demande motivée, un accès au code source lorsque nécessaire et après épuisement ou insuffisance des autres moyens de vérification. Les obligations de confidentialité de l’article 78 restent applicables. AI Act, art. 21(1), 74(13) et 78.
Des simplifications qui conservent l’exigence de preuve
Le règlement 2026/1744 étend la documentation simplifiée de l’article 11 aux PME et aux petites entreprises à moyenne capitalisation, dites SMC. Le fournisseur qui choisit cette voie doit utiliser le formulaire prévu par la Commission. La simplification porte sur la présentation des éléments, sans supprimer les exigences de fond. L’article 11(3) prévoit par ailleurs une modification de l’annexe IV par actes délégués. Règlement 2026/1744, art. 1(10) ; AI Act, art. 11(3).
Pour éviter une accumulation de documents inutilisables, gardez une structure modulaire : finalité et contexte, conception et preuves, exploitation et surveillance. Automatisez la capture des versions et résultats lorsque cela aide votre équipe. Une PME peut utiliser un dispositif documentaire simple s’il assure la traçabilité et l’accès aux pièces. Notre guide AI Act pour les PME précise les conditions des allègements.
Questions fréquentes
Le client doit-il recevoir tout le dossier technique ?
Pas automatiquement. Il doit disposer de la notice et des informations requises pour ses obligations de déployeur. Des accès complémentaires peuvent résulter du contrat ou d’une autre règle applicable. L’article 11 organise notamment l’accès des autorités et organismes notifiés.
Une documentation simplifiée dispense-t-elle des essais ?
Non. La présentation peut être simplifiée dans le cadre prévu par l’article 11, mais il faut toujours démontrer les exigences applicables au système. Un formulaire renseigné sans éléments probants ne remplace pas les vérifications nécessaires.
Le secret des affaires interdit-il l’accès au code source ?
Non. L’article 74(13) encadre cet accès par l’autorité, notamment par la nécessité et une demande motivée. La confidentialité et la protection des secrets restent garanties, mais ne constituent pas une immunité documentaire.
Faut-il conserver toutes les données personnelles dix ans ?
Non. La durée de l’article 18 concerne les documents énumérés. La conservation des données personnelles doit être justifiée séparément, selon leur finalité et les règles applicables.
Recevez nos analyses pratiques de conformité dans la newsletter.
À propos de l’auteur. Thiébaut Devergranne est docteur en droit privé, titulaire du CAPA et fondateur de Legiscope. Il travaille depuis plus de vingt ans sur le droit des technologies et la protection des données.