Quand la documentation technique s'applique et que faire ensuite

La documentation technique constitue une obligation précise de l'AI Act lorsqu'une entreprise est fournisseur d'un système à haut risque. L'article 11 impose de la préparer avant la mise sur le marché ou en service, de la maintenir à jour et de permettre aux autorités et organismes notifiés d'évaluer la conformité. L'annexe IV fixe le contenu minimal.

Toute entreprise SaaS utilisant une API d'IA n'a donc pas besoin d'un dossier complet. La réponse dépend du périmètre du système, du rôle de l'entreprise et de la classification. Même sans obligation directe, un dossier proportionné facilite gouvernance produit, contrôle fournisseur, demandes clients, incidents et réévaluations.

Confirmer le système, le rôle et la classification

Décrivez le système entier : finalité, utilisateurs, personnes concernées, entrées, sorties, intégrations, contexte et influence du résultat. Un modèle tiers peut n'être qu'un composant du produit SaaS.

Déterminez ensuite le rôle. L'entreprise qui développe et commercialise sous son nom un système à haut risque est généralement fournisseur ; un client peut être déployeur. Changement de marque, modification substantielle ou nouvelle finalité peuvent déplacer les responsabilités. Évaluez enfin les deux voies principales de l'article 6 : produits réglementés de l'annexe I et usages de l'annexe III. Consultez le guide destiné aux fournisseurs SaaS.

Quand l'article 11 s'applique

L'article 11 et l'annexe IV régissent la documentation des systèmes à haut risque et placent l'obligation principale sur le fournisseur. Après le règlement (UE) 2026/1744, les règles visant les systèmes de l'annexe III s'appliquent le 2 décembre 2027 et celles des systèmes intégrés aux produits de l'annexe I le 2 août 2028.

Il ne faut pas attendre. Droit sectoriel, protection des données, contrats, sécurité et contrôles clients peuvent déjà demander des preuves similaires. Commencer tôt évite de reconstituer versions, données, tests et décisions.

Si le système n'est pas à haut risque ou si l'entreprise n'est que déployeur, un dossier complet peut ne pas être requis. Consignez néanmoins décision, faits, réviseur et déclencheurs de réexamen. Nouvelle finalité sensible, changement important de modèle ou de données, nouveau marché ou effet accru sur les personnes doivent rouvrir l'analyse.

Ce que le dossier doit couvrir

L'annexe IV exige au minimum :

1. Identité, finalité, versions, utilisateurs et conditions d'exploitation.
2. Développement, architecture, composants et choix de conception.
3. Provenance des données, validation, tests et limites de performance.
4. Risques, contrôles, supervision humaine, journaux et escalade.
5. Robustesse, cybersécurité et résultats indésirables prévisibles.
6. Changements, incidents et suivi après commercialisation.
7. Normes, voie de conformité et approbations.
8. Traçabilité de chaque affirmation vers une source contrôlée.

Le dossier peut être un index renvoyant vers les registres contrôlés. Liens stables, autorisations, versions et conservation comptent davantage que le nombre de pages.

Processus pratique

1. Approuver le périmètre : consigner identifiant, finalité, frontière, rôle, classification et hypothèses.
2. Créer l'index de l'annexe IV : indiquer source, propriétaire, version, statut, réviseur et déclencheur.
3. Conserver la preuve chez son propriétaire réel : produit possède la finalité ; ingénierie, l'architecture ; données ou ML, les évaluations ; sécurité, les contrôles ; conformité, le mapping.
4. Combler d'abord les lacunes critiques : classification, performances, risques, supervision et approbation de version.
5. Relier les changements : finalité, modèles, données, seuils, utilisateurs, intégrations ou contrôles doivent déclencher mise à jour et nouveaux tests si nécessaire.
6. Tester la récupération : un réviseur indépendant doit pouvoir suivre une affirmation de performance, un contrôle, un parcours de supervision et une version jusqu'aux preuves.

La liste de contrôle de documentation technique fournit une structure détaillée. Les réponses clients doivent aussi correspondre aux contrôles d'IA demandés par les acheteurs.

Erreurs courantes

• Commencer par un modèle avant de fixer périmètre et preuves.
• Documenter le modèle plutôt que le système complet.
• Traiter la documentation fournisseur comme preuve de sa propre configuration.
• Ne jamais réexaminer une conclusion de risque faible.
• Maintenir un dossier d'audit séparé des versions et changements.

Exemple : présélection assistée de candidats

Pour une fonction classant des candidatures, l'équipe doit définir finalité, fournisseur, frontière et analyse de l'annexe III. Si elle fournit un système à haut risque, le dossier couvre versions en production, données, parcours client, évaluations par groupes, métriques, limites, contrôle humain, journalisation, sécurité et suivi. Un changement de modèle ou de seuil doit rouvrir les éléments liés.

FAQ

Quand l'obligation concerne-t-elle les équipes SaaS ?

L'article 11 concerne les fournisseurs de systèmes à haut risque. Confirmez frontière, rôle et classification avant de considérer le dossier complet comme juridiquement obligatoire.

Que faut-il documenter en premier ?

Finalité, périmètre, rôle, classification, version de production, architecture, risques, évaluations, contrôles, instructions et propriétaires.

Peut-on réutiliser les documents d'ingénierie ?

Oui. Reliez des sources contrôlées et actuelles et indiquez dans l'index l'exigence et la version couvertes.

Sources

• Règlement (UE) 2024/1689, articles 6 et 11 et annexes I, III et IV.
• Règlement (UE) 2026/1744 sur la documentation et les dates d'application.
• Commission européenne, « AI Act », calendrier actuel de mise en œuvre.