Liste de contrôle de la documentation technique

Une documentation technique efficace couvre les exigences du règlement européen sur l'IA et relie chaque affirmation à la version du système et à la preuve correspondante. Le fournisseur d'un système d'IA à haut risque doit préparer le dossier avant la mise sur le marché ou la mise en service, le tenir à jour et le rendre assez clair pour permettre aux autorités compétentes et organismes notifiés d'évaluer la conformité.

L'article 11 et l'annexe IV forment la structure de base. Le règlement (UE) 2026/1744 conserve l'annexe IV comme socle minimal, tout en permettant aux PME, y compris les jeunes pousses, et aux petites entreprises à moyenne capitalisation d'utiliser un formulaire simplifié de la Commission lorsqu'il sera disponible. La présentation est simplifiée, pas l'obligation de démontrer la conformité. Cette liste vise les fournisseurs ; confirmez d'abord la limite du système, le rôle de l'entreprise et la classification.

Périmètre et maîtrise

• [ ] Attribuer un identifiant stable, identifier le fournisseur et fixer la version de production couverte.
• [ ] Décrire finalité, utilisateurs, personnes concernées, contexte et usages exclus.
• [ ] Justifier le rôle et la classification à haut risque au regard de l'annexe I ou III.
• [ ] Nommer un responsable global et un propriétaire factuel pour chaque preuve.
• [ ] Créer un index indiquant exigence, source, version, état, réviseur et déclencheur de mise à jour.

Commencez par l'index, non par un modèle narratif. Il révèle les lacunes et empêche le dossier de diverger du produit.

Système, développement et architecture

• [ ] Consigner finalité, fournisseur, versions, formes de distribution et conditions d'exploitation.
• [ ] Recenser matériel, logiciels, micrologiciels, interfaces, dépendances et composants d'IA externes.
• [ ] Versionner architecture, méthodes de développement, décisions de conception et travaux de tiers.
• [ ] Décrire acquisition, préparation, étiquetage, qualité et gouvernance des données lorsque pertinent.
• [ ] Expliquer résultats, limites, qualité attendue et influence sur les décisions.
• [ ] Documenter les changements de développement et le processus contrôlé des changements ultérieurs.

Les schémas doivent porter date et version. La brochure d'un fournisseur ne prouve pas le fonctionnement de votre configuration.

Performances, risques et contrôles

• [ ] Décrire capacités, limites, exactitude, robustesse et cybersécurité.
• [ ] Conserver métriques, seuils, données et conditions de test, résultats et exclusions connues.
• [ ] Évaluer les risques prévisibles pour la santé, la sécurité et les droits fondamentaux.
• [ ] Consigner contrôles, risque résiduel, responsables et autorité d'acceptation.
• [ ] Expliquer surveillance humaine, alertes, possibilités d'intervention et escalade.
• [ ] Définir journalisation, conservation, accès et traçabilité.
• [ ] Relier les articles 8 à 15 aux contrôles et aux preuves.

Un taux d'exactitude sans tâche, population, version des données, métrique et date de test est incomplet. Le registre des risques explique la décision ; tests, approbations, instructions et journaux prouvent son exécution.

Conformité et cycle de vie

• [ ] Identifier normes harmonisées ou spécifications appliquées, avec édition et périmètre.
• [ ] Justifier écarts et preuves alternatives.
• [ ] Conserver évaluation de conformité, déclaration UE et informations sur l'organisme notifié, le cas échéant.
• [ ] Tenir l'historique des changements et confirmer à chaque version que le dossier correspond à la production.
• [ ] Enregistrer surveillance après commercialisation, plaintes, incidents, dérive et mesures correctives.
• [ ] Faire des changements fournisseurs, retrait, retour arrière et conservation des déclencheurs de révision.

Pour chaque changement important, demandez s'il modifie finalité, classification, données, architecture, performances, risques, contrôles, instructions, surveillance ou suivi. Si oui, mettez à jour les éléments concernés avant la livraison.

Contrôle qualité final

• [ ] Chaque affirmation possède une source maîtrisée ou est signalée comme analyse.
• [ ] Les versions concordent entre architecture, tests, risques, instructions et livraison.
• [ ] Chaque lacune a un responsable, un contrôle provisoire, une décision de risque et une échéance.
• [ ] Les liens fonctionnent et les réviseurs disposent d'un accès approprié.
• [ ] Une personne indépendante peut reproduire les conclusions principales depuis l'index.

L'obligation porte sur le système complet dans son contexte, pas seulement sur le modèle. Une politique ne prouve pas l'exécution et le dossier ne s'arrête pas au lancement : il doit suivre les changements et les signaux post-commercialisation.

Questions fréquentes

Quand l'obligation concerne-t-elle une équipe SaaS ?

L'article 11 vise les fournisseurs de systèmes d'IA à haut risque. Une entreprise SaaS peut être déployeur ou utiliser une IA qui n'est pas à haut risque. Une documentation volontaire reste utile pour la gouvernance et les clients, sans devoir être présentée comme une obligation légale.

Quand les règles à haut risque s'appliquent-elles ?

Après le règlement (UE) 2026/1744, les règles concernées s'appliquent aux systèmes autonomes de l'annexe III à partir du 2 décembre 2027 et aux systèmes intégrés aux produits de l'annexe I à partir du 2 août 2028. Vérifiez les dispositions transitoires propres au système.

Sources

• Règlement (UE) 2024/1689, notamment articles 9, 11, 16 à 18 et 72, et annexe IV.
• Règlement (UE) 2026/1744, notamment la modification de l'article 11 et le calendrier.
• Commission européenne, « Navigating the AI Act ».