Erreurs courantes de documentation technique

Les erreurs habituelles ne sont pas des problèmes de format, mais de périmètre, de preuve, de responsabilité et de gestion des changements. Un dossier peut paraître complet tout en restant invérifiable. L'article 11 de l'AI Act impose aux fournisseurs de systèmes à haut risque de préparer la documentation avant leur mise sur le marché ou en service et de la tenir à jour. L'annexe IV fixe le contenu minimal. Le règlement (UE) 2026/1744 simplifie la présentation pour certaines petites organisations, sans réduire la nécessité d'étayer les affirmations.

Toute entreprise SaaS n'est pas fournisseur d'un système à haut risque. Il faut d'abord confirmer la frontière du système, le rôle de l'entreprise et la classification.

1. Documenter le modèle plutôt que le système

Une fiche modèle ou fournisseur ne décrit pas le produit avec ses prompts, flux de données, interfaces, supervision humaine, journaux et actions en aval. Délimitez le système et recensez composants, acteurs, entrées, sorties et contrôles. Distinguez les informations du fournisseur des faits vérifiés en interne. Le guide de l'AI Act pour les fournisseurs SaaS aide à établir rôle et périmètre.

2. Commencer par un modèle narratif

Les grands modèles produisent des textes plausibles sur des tests robustes ou une supervision appropriée avant que les preuves existent. Commencez par un index de couverture : exigence, artefact source, version, propriétaire, réviseur, statut et déclencheur. Rédigez ensuite le récit à partir des sources contrôlées.

3. Confondre politiques et preuves

Une politique décrit ce qui devrait se passer ; une preuve montre ce qui s'est passé pour une version précise. Utilisez exigences approuvées, décisions d'architecture, registres de données, évaluations, modèles de menace, validations de version et revues de suivi. Chaque preuve doit préciser l'affirmation, la source, la date, la version et le responsable.

4. Perdre la traçabilité des versions

Des schémas écrasés, des tests sans version de modèle ou de données et des tableaux de bord évolutifs rompent la traçabilité. Donnez un identifiant stable au système et reliez chaque artefact à la version, au modèle, à la configuration et à la date. Depuis la production, un réviseur doit retrouver exigences, architecture, tests, risques, contrôles, instructions et approbation.

5. Tout confier à la conformité

La conformité coordonne la norme et conteste les affirmations faibles, mais ne doit pas rédiger les faits techniques de seconde main. Produit possède le but ; ingénierie, l'architecture et les changements ; données ou ML, les évaluations ; sécurité, les contrôles ; et la gestion des versions, ce qui a été livré. Un responsable central gère la couverture sans devenir l'auteur de toutes les preuves.

6. En faire un livrable unique au lancement

Modèles, données, fournisseurs et risques changent. Ajoutez un contrôle d'impact lorsqu'évoluent le but, la frontière, le modèle, les données importantes, la performance, la supervision, la sécurité, les instructions ou le suivi. La revue périodique est un filet de sécurité ; le contrôle principal doit être événementiel et intégré au flux produit. Une bonne structure permet aussi d'accélérer les audits.

7. Mesurer l'activité plutôt que la qualité

Le nombre de documents ou tickets fermés ne prouve rien. Mesurez la complétude au premier passage, les lacunes importantes, les exceptions échues, les liens cassés, les écarts de version et le délai de mise à jour. Si un réviseur doit interroger l'auteur pour reproduire une conclusion, la preuve n'est pas autonome.

8. Accepter les affirmations du fournisseur sans examen

Certificats et fiches peuvent viser une autre version, langue, population ou environnement. Enregistrez le document exact, évaluez l'écart avec votre usage et testez le comportement pertinent. Une information indisponible est un risque ou une lacune, pas une invitation à supposer.

9. Masquer les lacunes derrière des exceptions vagues

« À compléter plus tard » n'est pas une décision maîtrisée. Consignez lacune, motif, contrôle provisoire, propriétaire du risque, approbation, correction et échéance. Tout défaut ne bloque pas une version, mais une évaluation absente diffère d'un détail éditorial. Un modèle clair de responsabilité conformité évite les exceptions permanentes.

Processus de revue ciblé

1. Confirmer frontière, rôle, classification, but et version actuelle.
2. Créer l'index de l'annexe IV et relier les sources contrôlées.
3. Échantillonner une affirmation d'architecture, performance, risque, supervision et changement.
4. Vérifier des identifiants cohérents et des résultats reproductibles.
5. Affecter à chaque lacune un responsable, une importance, une action et une date.
6. Intégrer les déclencheurs dans produit, fournisseurs, sécurité et livraison.

FAQ

Quel est le but pratique de la documentation ?

Expliquer de manière traçable ce qu'est le système, comment il a été développé et évalué, quels risques et contrôles s'appliquent et pourquoi les exigences sont considérées respectées.

Quand s'applique-t-elle aux équipes SaaS ?

L'article 11 s'applique aux fournisseurs de systèmes à haut risque. Confirmez frontière, rôle et classification avant de traiter l'annexe IV comme une obligation directe.

Que corriger en premier ?

Le but, la version, l'architecture, l'évaluation, les risques matériels, la supervision humaine, les instructions et l'approbation. Corrigez les contradictions et affirmations importantes non étayées avant la présentation.

Sources

• Règlement (UE) 2024/1689, notamment l'article 11 et l'annexe IV.
• Règlement (UE) 2026/1744, y compris les simplifications de documentation technique.