Documentation technique : guide pratique pour les équipes SaaS

La documentation technique d'un système d'IA n'est pas un résumé d'architecture rédigé à la fin du projet. C'est le dossier contrôlé qui explique la finalité du système, sa construction, ses données et modèles, ses performances, ses risques, les contrôles associés et la gestion des changements après mise en production.

Pour les fournisseurs de systèmes d'IA à haut risque, l'article 11 de l'AI Act exige que ce dossier soit constitué avant la mise sur le marché ou la mise en service, tenu à jour et suffisamment clair pour permettre aux autorités et organismes notifiés d'évaluer la conformité. L'annexe IV en fixe le contenu minimal. Une équipe SaaS doit donc réunir les preuves produit, ingénierie, données, sécurité, juridique et qualité pendant le développement, et non les reconstruire lors d'un audit.

Cette obligation ne vise pas automatiquement chaque fonctionnalité d'IA. Son périmètre dépend de la classification du système et du rôle de l'entreprise. Commencez par documenter ces deux points, puis adaptez le dossier aux obligations et risques réels.

Pourquoi ce dossier compte

Une bonne documentation permet de vérifier que les tests correspondent à la finalité prévue, de rattacher une réponse client à une preuve contrôlée et de décider si un changement de modèle, données, seuil ou workflow impose une réévaluation. Elle donne aussi à l'évaluateur une histoire cohérente plutôt qu'un ensemble de captures sans contexte.

Elle relie exigences produit, schémas d'architecture, model cards, lignage des données, évaluations, registre des risques, tests de sécurité, supervision humaine, logs, incidents, validations de versions et surveillance après commercialisation. Un index central peut pointer vers ces sources sans tout dupliquer.

Ce travail répond aussi aux nouvelles attentes de gouvernance de l'IA pour les éditeurs SaaS.

Confirmer le périmètre

Déterminez si le logiciel est un système d'IA, s'il est à haut risque et quel rôle joue l'entreprise. Une entreprise qui développe et commercialise un système sous son nom peut être fournisseur. Celle qui utilise le système d'un tiers peut être déployeur, mais un changement substantiel, une nouvelle marque ou une nouvelle finalité peuvent modifier l'analyse.

Le haut risque peut résulter de l'article 6, paragraphe 1, et de l'annexe I pour certains produits réglementés ou composants de sécurité, ou d'un cas d'usage de l'annexe III selon l'article 6, paragraphe 2. Les projets de lignes directrices publiés par la Commission en mai 2026 sont utiles mais ne sont pas juridiquement contraignants.

Le règlement (UE) 2026/1744 a aussi modifié le calendrier : les sections 1, 2 et 3 du chapitre III, dont l'article 11, s'appliquent à partir du 2 décembre 2027 aux systèmes de l'annexe III et du 2 août 2028 à ceux de l'annexe I. D'autres lois, contrats ou engagements clients peuvent exiger des preuves comparables plus tôt.

Ne confondez pas ce dossier avec les obligations séparées des fournisseurs de modèles d'IA à usage général au titre de l'article 53 et de l'annexe XI. Les informations du fournisseur de modèle sont une entrée ; le fournisseur SaaS doit documenter le système complet, l'intégration, la finalité, les contrôles et les performances évaluées.

Ce qu'attend l'annexe IV

Utilisez l'annexe comme matrice de couverture :

1. Identité et finalité : fournisseur, nom, version, utilisateurs, but, modes de livraison, interfaces, dépendances et interface utilisateur.
2. Développement : méthodes, composants tiers ou préentraînés, choix du modèle, objectifs, hypothèses et décisions importantes.
3. Architecture : composants, interactions, ressources de calcul et justification des choix.
4. Données : provenance, sélection, annotation, nettoyage, gouvernance, limites et jeux d'entraînement, validation, test ou retrieval.
5. Capacités et limites : métriques, précision, robustesse, cybersécurité, résultats indésirables prévisibles et conditions de dégradation.
6. Tests : protocoles, données, seuils, dates, versions, résultats, échecs et corrections.
7. Risques et supervision : gestion des risques, mesures, risque résiduel, supervision humaine et instructions aux déployeurs.
8. Cycle de vie : versions, journalisation, changements, maintenance, incidents et suivi post-commercialisation.
9. Conformité : normes, spécifications, déclaration UE de conformité et documents de l'organisme notifié si nécessaire.

Chaque affirmation doit mener à une preuve précise. Une référence à un rapport, une métrique approuvée, un dataset, une version et une limite résiduelle est vérifiable ; « le système est robuste » ne l'est pas.

Workflow opérationnel

1. Créer un index contrôlé

Prévoyez une ligne par élément de l'annexe IV avec exigence, applicabilité, source, responsable, version, validation, dernière revue et prochain déclencheur. « Non applicable » doit être justifié et approuvé. Contrôle d'accès, historique et références stables sont essentiels.

2. Attribuer les preuves à leurs producteurs

Produit couvre finalité, utilisateurs, contexte et mauvais usages prévisibles. Ingénierie couvre architecture, dépendances, versions et changements. Data ou ML couvre lignage, développement, évaluations et limites. Sécurité couvre menaces, accès, résilience et vulnérabilités. Juridique et conformité couvrent classification, rôles, mapping réglementaire et gouvernance documentaire. Un responsable central coordonne sans réécrire des faits qu'il ne peut vérifier.

3. Fixer la baseline avant les tests

Définissez finalité et version avant d'accepter un résultat. Conservez identifiants des modèles, prompts pertinents, sources de retrieval, feature flags, seuils, dépendances et environnement. Pour un système probabiliste, gardez version du jeu de données, méthode, seuil d'acceptation, date et résultats reproductibles, avec les limites.

4. Relier risques, contrôles et tests

Chaque risque matériel mène à une mesure, un responsable et une preuve d'efficacité. Si le contrôle est humain, précisez qui vérifie, avec quelles informations, avec quel pouvoir d'annulation, quelle escalade et quelle preuve d'exécution.

5. Intégrer le dossier aux releases

Chaque version majeure doit évaluer son impact documentaire. Une modification de finalité, modèle, données, seuil, utilisateurs, pays, intégration, supervision ou sécurité peut imposer de nouveaux tests et des mises à jour des risques, instructions et analyses de conformité.

Checklist minimale

L'équipe doit pouvoir retrouver : description et classification approuvées ; architecture et flux de données versionnés ; registre des modèles, bibliothèques, API et dépendances ; provenance et gouvernance des données ; plans, métriques, seuils, résultats et limites d'évaluation ; risques reliés aux contrôles et approbations ; preuves de supervision humaine ; dossiers de sécurité, robustesse, logs, incidents et monitoring ; instructions alignées sur le système testé ; historique des releases et documents de conformité.

Erreurs fréquentes

Un modèle de conformité vide produit souvent des généralités sans preuves. Une model card ne décrit pas le workflow SaaS complet. Les documents d'un fournisseur sont des entrées, pas un substitut à l'analyse de l'intégration. Cacher les limites est moins défendable que les expliquer avec leurs contrôles. Un calendrier seul ne suffit pas : releases, incidents, nouvelles données, nouveaux usages et évolutions réglementaires déclenchent une revue. Enfin, questionnaires clients, pages produit, instructions, risques et dossier doivent décrire le même système.

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

Pour une fonction qui classe des candidatures, le dossier couvre finalité, usages non pris en charge, workflow client, personnes concernées, données, logique de classement, versions, groupes évalués, métriques, seuils, contrôle humain, logs, sécurité et monitoring.

Si une évaluation révèle un rappel inférieur pour un groupe pertinent, conservez le résultat, l'analyse, la mesure, le nouveau test et la décision de risque résiduel. Un changement ultérieur de modèle ou de seuil doit rouvrir ces éléments.

FAQ

Toute entreprise SaaS a-t-elle besoin d'un dossier annexe IV ?

Non. L'article 11 et l'annexe IV concernent les systèmes à haut risque et la responsabilité principale du fournisseur. Un dossier proportionné reste utile pour la gouvernance et les clients.

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

Oui, s'ils sont contrôlés et actuels, avec un index démontrant la couverture. Évitez les copies divergentes.

Qui en est responsable ?

Un responsable nommé coordonne le dossier ; produit, ingénierie, ML/data, sécurité, juridique et conformité restent propriétaires de leurs preuves.

Quand faut-il l'actualiser ?

Lorsque finalité, versions, données, intégrations, utilisateurs, performance, risques, contrôles ou résultats de monitoring changent, avant une release majeure et après un incident.

Le formulaire simplifié PME est-il disponible ?

L'article 11 prévoit un formulaire simplifié. Vérifiez les ressources officielles actuelles avant d'utiliser un modèle. En attendant un formulaire applicable, maintenez une matrice complète de l'annexe IV avec des preuves proportionnées.

Sources

• Règlement (UE) 2024/1689, notamment articles 6, 9 à 17 et 43, et annexe IV.
• Règlement (UE) 2026/1744 et calendrier modifié.
• Projet de lignes directrices de la Commission sur les systèmes à haut risque, mai 2026.
• Lignes directrices de la Commission pour les fournisseurs de modèles d'IA à usage général.