Documentation des systèmes d’IA : ce qu’exige le règlement IA

L’essentiel

• La documentation d’un système d’IA est l’ensemble des preuves qui montrent qu’un système a été conçu, testé et surveillé de façon responsable. Ce n’est pas la même chose que rédiger de la documentation à l’aide de l’IA.
• Sous le règlement IA, la documentation technique est obligatoire pour les systèmes d’IA à haut risque. L’article 11 l’exige avant la mise sur le marché, et elle doit rester à jour.
• L’annexe IV définit neuf sections que cette documentation doit contenir, de la description générale du système au plan de surveillance après commercialisation.
• Des artefacts déjà connus (fiches de modèle, fiches de jeux de données, journaux) répondent directement à ces obligations : l’essentiel du travail consiste à organiser des preuves que vous devriez déjà produire.
• Une base de preuves bien structurée satisfait à la fois le règlement IA, l’ISO/IEC 42001 et le cadre NIST AI RMF, d’où l’intérêt de traiter la documentation comme un processus de gouvernance et non comme un dossier de dernière minute.

Documentation IA et documentation des systèmes d’IA : deux sujets distincts

Cherchez « documentation intelligence artificielle » et la plupart des résultats parlent de logiciels : des outils qui lisent des documents (Document AI, traitement intelligent de documents) ou des outils qui rédigent la documentation à votre place. Ce sens existe, mais ce n’est pas ce dont une équipe conformité ou risques a besoin. Ce guide traite de l’autre sens : la documentation des systèmes d’IA, c’est-à-dire le dossier structuré qui décrit le fonctionnement d’un système d’IA précis, les données qui l’ont entraîné, la manière dont il a été testé, les risques qu’il porte et la façon dont il est supervisé. C’est la trace écrite (de plus en plus numérique) qui permet à un auditeur, à un régulateur ou à votre propre conseil de confirmer que le système fait ce que vous annoncez, sans causer de préjudice. La distinction compte, car les publics diffèrent. Un rédacteur technique veut produire un manuel plus vite. Le fournisseur d’un système d’IA à haut risque doit prouver, sur demande, que le système respecte des exigences légales. Comme le résume l’autorité américaine NTIA, la documentation constitue un intrant essentiel à la transparence et à l’évaluation, qu’elle soit interne ou externe, volontaire ou imposée. Qui est concerné ? Sous le règlement IA, les fournisseurs et les déployeurs de systèmes à haut risque portent les obligations les plus lourdes, et les fournisseurs de modèles d’IA à usage général (GPAI) ont leurs propres devoirs documentaires. Si vous concevez, vendez ou déployez de l’IA dans un secteur régulé, ce sujet vous concerne, et la plateforme AI Sigil est conçue pour structurer précisément ces preuves.

Pourquoi la documentation des systèmes d’IA est désormais une obligation légale

Pendant des années, documenter l’IA relevait de la bonne pratique. Le règlement IA en a fait une obligation. L’article 11 impose que la documentation technique d’un système à haut risque soit établie avant sa mise sur le marché ou sa mise en service, et qu’elle soit tenue à jour. Elle doit fournir aux autorités nationales et aux organismes notifiés une information suffisante, sous une forme claire et complète, pour évaluer la conformité. Ce dernier point change toute la logique de l’exercice. La documentation n’est pas rédigée pour vos utilisateurs : elle est rédigée pour qu’un tiers puisse vérifier la conformité. Si un évaluateur ne parvient pas à suivre vos preuves, le système n’est pas démontrablement conforme, quelle que soit la qualité de son ingénierie. Deux facteurs rendent le sujet pressant. D’abord le calendrier : les obligations documentaires des systèmes à haut risque listés à l’annexe III s’appliquent à partir du 2 août 2026, donc les preuves doivent exister avant le lancement, pas après un incident. Ensuite la responsabilité : comme le souligne le rapport de la NTIA, une tenue de registres intégrée à l’évaluation est le fondement d’une responsabilité de bout en bout. La documentation est ce qui relie une décision de conception à un résultat de test, puis à un comportement en production. AI Sigil a été bâti pour cette discipline de traçabilité.

Ce qu’exige l’annexe IV du règlement IA (les neuf sections)

L’annexe IV est la liste de référence. Elle fixe, au minimum, neuf domaines que la documentation technique doit couvrir pour un système à haut risque.

1. Description générale. La finalité prévue du système, le fournisseur, les versions, les interactions avec le matériel et les logiciels, et la notice d’utilisation.
2. Processus et éléments de développement. Spécifications de conception, architecture du système, exigences relatives aux données, méthodologie d’entraînement, évaluation de la supervision humaine, procédures de validation et de test.
3. Surveillance, fonctionnement et contrôle. Capacités et limites du système, exactitude attendue pour des groupes précis, résultats non intentionnels prévisibles, et mesures techniques de supervision humaine.
4. Métriques de performance. Pourquoi les indicateurs retenus sont appropriés pour ce système.
5. Système de gestion des risques. Le processus de gestion des risques exigé par l’article 9, avec les risques identifiés et les mesures d’atténuation.
6. Modifications au fil du cycle de vie. Un relevé des changements apportés au système durant sa vie.
7. Normes appliquées. Les normes harmonisées appliquées ou, à défaut, les solutions retenues pour satisfaire aux exigences.
8. Déclaration UE de conformité. La déclaration formelle visée à l’article 47.
9. Plan de surveillance après commercialisation. Le dispositif de suivi des performances après déploiement, conformément à l’article 72.

Les petits fournisseurs bénéficient d’un allègement. Le règlement autorise les PME et les jeunes entreprises à fournir les éléments de l’annexe IV sous une forme simplifiée, et la Commission doit publier un modèle simplifié à destination des micro et petites entreprises. L’allègement porte sur la forme, pas sur le fond : les mêmes questions doivent recevoir une réponse, ce qui rend le rattachement de chaque section à un contrôle réutilisable particulièrement rentable.

La chaîne de dépendances documentaires

L’annexe IV ressemble à neuf livrables séparés. En pratique, chaque section est alimentée par une autre obligation que vous devez déjà satisfaire. Comprendre cette chaîne évite d’écrire deux fois la même documentation.

• La gouvernance des données (article 10) alimente la section 2. Vos descriptions de jeux de données, vos relevés de provenance et vos contrôles qualité deviennent la partie « données » du dossier de développement.
• La gestion des risques (article 9) alimente la section 5. Le registre des risques et les preuves d’atténuation constituent la section « gestion des risques », et non une note distincte.
• La tenue de registres (article 12) alimente la section 3. L’article 12 impose aux systèmes à haut risque de conserver des journaux automatiques tout au long de leur vie ; ces journaux sont la preuve opérationnelle de la surveillance et du contrôle.
• La transparence (article 13) alimente la section 1. L’article 13 exige une notice d’utilisation claire, et ce même contenu ancre la description générale.
• La supervision humaine (article 14) alimente les sections 2 et 3. La manière dont une personne peut intervenir, passer outre ou arrêter le système relève à la fois du dossier de conception et de la description du contrôle.

La leçon est simple : la documentation est un sous-produit d’une gouvernance bien menée. Si les articles 9, 10, 12, 13 et 14 sont correctement traités, l’annexe IV relève surtout de l’assemblage plutôt que de la rédaction.

Les artefacts documentaires clés

Inutile d’inventer des formats. Le domaine dispose déjà d’artefacts éprouvés, et chacun répond aux obligations ci-dessus.

• Fiches de modèle (model cards). Introduites par Mitchell et ses coauteurs en 2019, une fiche de modèle résume l’usage prévu d’un modèle, ses performances par groupe, ses limites et ses considérations éthiques. Elle appuie les sections 1, 3 et 4 de l’annexe IV.
• Fiches de jeux de données (datasheets). Proposées par Gebru et ses coauteurs en 2018, une fiche documente la motivation, la composition, le processus de collecte et les usages recommandés d’un jeu de données. Elle appuie la section 2 et la gouvernance des données sous-jacente.
• Fiches de système (system cards). Une vue au niveau du système, décrivant comment les composants se combinent, utilisée par plusieurs grands fournisseurs. Elle appuie les sections 1 et 3.
• Analyses d’impact relatives à la protection des données. Lorsque des données personnelles sont en jeu, l’AIPD (attendue par la CNIL) relie la documentation IA aux obligations du RGPD.
• Journaux et relevés de modifications. Les journaux automatiques (article 12) et un journal des changements versionné appuient les sections 3 et 6.

Pour l’IA à usage général, le code de bonnes pratiques GPAI du Bureau de l’IA prévoit un engagement de documentation et un formulaire de documentation de modèle, offrant aux fournisseurs GPAI un modèle prêt pour les informations que les déployeurs en aval réclameront. Le rapport de la NTIA regroupe ces outils et recommande que les fiches de modèle, de jeux de données et de système deviennent une pratique standard comme intrants de responsabilité.

Une seule base de preuves, trois cadres

Les mêmes preuves répondent à plus d’un cadre. C’est l’idée la plus utile pour une équipe conformité sous tension. L’ISO/IEC 42001, la norme de système de management de l’IA, comporte des exigences omniprésentes d’« informations documentées » à la clause 7.5 et un ensemble de mesures en annexe A (analyses d’impact, politiques, registres). Le cadre NIST AI RMF demande des profils documentés qui saisissent le contexte, la mesure et la surveillance. Le règlement IA demande l’annexe IV. Mis côte à côte, ces textes se recoupent fortement. Une fiche de jeu de données satisfait une partie de la section 2 de l’annexe IV, une partie des mesures de gestion des données de l’ISO 42001 et une partie de la fonction « Map » du NIST, en même temps. Constituez la preuve une fois, rattachez-la à chaque cadre, puis réutilisez-la. Dupliquer la documentation par cadre est le gaspillage le plus courant et le plus évitable en gouvernance de l’IA ; AI Sigil rattache un seul jeu de contrôles à plusieurs cadres pour que la preuve ne soit saisie qu’une fois.

Maintenir une documentation prête pour l’audit

Produire la documentation une fois n’est pas l’objectif. La maintenir exacte l’est. L’annexe IV impose de tenir le dossier à jour, et les obligations de conservation courent plusieurs années après le retrait d’un système. Quelques pratiques distinguent les équipes prêtes pour l’audit.

• Traiter la documentation comme une preuve vivante. La mettre à jour quand le modèle, les données ou le profil de risque changent, et non selon un rythme annuel.
• Tout versionner. Un évaluateur doit voir quelle version du modèle correspond à quel résultat de test et à quel déploiement.
• Tenir une matrice de traçabilité. Rattacher chaque section de l’annexe IV (et chaque mesure ISO ou NIST) à l’artefact exact qui la satisfait, afin que les manques soient visibles avant qu’un audit ne les trouve.
• Attribuer une responsabilité. Chaque artefact a besoin d’un propriétaire nommé, sinon il se périme.
• Planifier la conservation. Garder les registres pendant la durée exigée par la loi, qui peut dépasser largement la vie active du système.

C’est là qu’un dossier de PDF montre ses limites et qu’une plateforme de gouvernance prend sa place. Quand la documentation vit dans le même système que les contrôles, les risques et les preuves, la tenir à jour devient un flux de travail plutôt qu’une course. Découvrez comment la plateforme AI Sigil s’en charge.

Questions fréquentes

Qu’est-ce que la documentation d’un système d’IA ? C’est le dossier structuré qui décrit comment un système d’IA a été conçu, entraîné, testé et surveillé, et quels risques il porte. Sous le règlement IA, on l’appelle documentation technique, et elle est obligatoire pour les systèmes à haut risque. Son but est de permettre à un régulateur ou à un auditeur de confirmer la conformité, ce qui diffère d’un manuel utilisateur comme des outils d’IA qui rédigent de la documentation. La documentation IA est-elle obligatoire ? Pour les systèmes d’IA à haut risque sous le règlement IA, oui. L’article 11 exige une documentation technique avant la mise sur le marché, tenue à jour. Les fournisseurs de modèles d’IA à usage général ont aussi des devoirs documentaires. Les systèmes hors des catégories à haut risque peuvent relever d’une documentation plus légère ou volontaire, mais la tendance des réglementations et des normes va vers davantage d’exigences, non l’inverse. Que doit contenir la documentation technique du règlement IA ? Au minimum, les neuf domaines de l’annexe IV : description générale, processus et éléments de développement, surveillance et contrôle, justification des métriques, système de gestion des risques, modifications du cycle de vie, normes appliquées, déclaration UE de conformité et plan de surveillance après commercialisation. Quelle différence entre une fiche de modèle et la documentation technique ? Une fiche de modèle résume l’usage prévu, les performances et les limites d’un modèle. La documentation technique du règlement IA est plus large : elle couvre l’ensemble du système, ses données, sa gestion des risques et ses preuves de conformité. La fiche de modèle est un composant utile de la documentation, pas un substitut. Quand ces obligations documentaires s’appliquent-elles ? Les obligations documentaires des systèmes à haut risque listés à l’annexe III s’appliquent à partir du 2 août 2026. Comme la documentation doit exister avant la mise sur le marché, les équipes doivent la construire pendant le développement, pas après le lancement. Les petites entreprises peuvent-elles documenter plus simplement ? Oui. Le règlement IA permet aux PME et aux jeunes entreprises de fournir les éléments de l’annexe IV sous une forme simplifiée, et la Commission doit publier un modèle simplifié pour les micro et petites entreprises. La simplification porte sur la forme et l’effort, pas sur l’omission des questions de fond.

Conclusion

La documentation d’un système d’IA n’est pas une tâche de rédaction ajoutée à la fin. C’est la preuve qui transforme des affirmations sur un système en quelque chose qu’un régulateur, un auditeur ou un conseil peut vérifier. Le règlement IA la rend explicite par l’article 11 et les neuf sections de l’annexe IV, mais ces mêmes registres répondent aussi à l’ISO/IEC 42001 et au NIST AI RMF. Les équipes qui construisent la documentation comme un sous-produit d’une bonne gouvernance, versionnée, attribuée et réutilisée, sont prêtes lorsqu’une évaluation arrive. Celles qui la traitent comme de la paperasse ne le sont pas. Voyez comment AI Sigil transforme la documentation IA en flux de gouvernance.