Documents obligatoires ISO 42001 : la liste utile pour la clause 7.5

Ce que dit vraiment la clause 7.5

La clause 7.5 d'ISO/IEC 42001 traite des informations documentées, terme qui recouvre à la fois les politiques et procédures et les enregistrements qui prouvent leur application^[1]. La norme suit la structure harmonisée commune aux systèmes de management ISO, ce qui la rend lisible pour quiconque connaît déjà ISO 27001 ou ISO 9001^[7].

Le point souvent mal compris par les futurs Lead Implementer, c'est que la clause 7.5 ne fournit pas une liste fermée. Elle exige que l'organisme conserve les informations documentées requises par la norme et celles qu'il juge nécessaires à l'efficacité de son SMIA^[1]. La liste réelle se reconstitue en parcourant chaque clause qui contient la formule « informations documentées » ou « conserver des preuves ».

Cette approche est volontaire. Elle laisse à un éditeur logiciel et à une administration cantonale la latitude de formaliser différemment, du moment que les preuves existent et sont maîtrisées. Pour un consultant, l'enjeu pratique est de produire le bon niveau de documentation, ni un classeur creux ni un dossier de cinquante procédures que personne ne lira^[6].

Trois catégories utiles

Pour structurer le corpus, trois catégories suffisent. D'abord les documents de cadrage, politique IA, périmètre, rôles. Ensuite les documents opérationnels, procédures et méthodes pour évaluer les risques et les impacts. Enfin les enregistrements, preuves de réalisation, comptes rendus, journaux, rapports d'audit interne et de revue de direction^[6].

Documents explicitement exigés

La lecture clause par clause de la norme fait apparaître un noyau de documents qu'un auditeur de certification cherchera systématiquement. Les analyses publiées par les organismes spécialisés convergent sur ce noyau, avec quelques nuances de formulation^[2][6].

Sept documents de cadrage que la norme rend incontournables, indépendamment du secteur d'activité.

1Périmètre du SMIA (cl. 4.3)

2Politique IA (cl. 5.2)

3Rôles et responsabilités (cl. 5.3)

4Objectifs IA et plan associé (cl. 6.2)

5Méthodologie d'évaluation des risques (cl. 6.1.2)

6Méthodologie d'analyse d'impact (cl. 6.1.4)

7Déclaration d'applicabilité (cl. 6.1.3)

Sources : rapprochement des analyses d'organismes de certification et de cabinets spécialisés^[2][6].

Périmètre, politique, rôles

Le périmètre du SMIA décrit les frontières du système, systèmes d'IA inclus, sites, fonctions, exclusions justifiées. La politique IA porte l'engagement de la direction et les principes directeurs, alignement avec la stratégie, IA responsable, conformité réglementaire^[3]. Les rôles et responsabilités identifient nominalement qui décide, qui exécute, qui contrôle.

Dans une PME romande qui développe un outil d'aide à la décision pour le tri de dossiers RH, la politique tient en deux pages et nomme un responsable IA rattaché à la direction. Le périmètre se limite au produit concerné et à son cycle de vie, pas à l'ensemble du parc bureautique. C'est ce niveau de précision que l'auditeur cherche, pas une déclaration générique^[4].

Risques, impacts, déclaration d'applicabilité

La méthodologie d'évaluation des risques liés à l'IA et la méthodologie d'analyse d'impact sur les personnes et les groupes sont deux documents distincts dans ISO 42001, ce qui la différencie d'ISO 27001^[5]. L'analyse d'impact regarde l'effet potentiel des systèmes d'IA sur les individus, les communautés et la société, et pas seulement le risque pour l'organisme.

La déclaration d'applicabilité, ou SoA, recense les contrôles de l'annexe A retenus, ceux exclus, et la justification de chaque choix^[2]. C'est l'un des rares documents que l'auditeur lit ligne à ligne lors de l'étape 1, parce qu'il révèle la cohérence entre les risques identifiés et les mesures choisies.

Enregistrements attendus par l'auditeur

Au-delà du cadrage, la norme impose de conserver des preuves de fonctionnement. Ces enregistrements ne sont pas des modèles à pré-remplir, ce sont des traces d'activités réelles que l'organisme produit en exploitant son SMIA^[1].

Enregistrements clés et clause d'origine

Compétences et sensibilisation	cl. 7.2 et 7.3, dossiers de formation et preuves de qualification[6]
Résultats d'évaluation des risques	cl. 6.1.2, registre des risques avec scénarios IA[2]
Résultats d'analyse d'impact	cl. 6.1.4, dossier par système d'IA concerné[5]
Plan de traitement des risques	cl. 6.1.3, actions, propriétaires, échéances[2]
Surveillance et mesure	cl. 9.1, indicateurs et résultats sur la performance du SMIA[6]
Audits internes	cl. 9.2, programme, rapports, constats[2]
Revue de direction	cl. 9.3, ordre du jour, décisions, actions[6]

Une revue de direction tenue oralement sans compte rendu ne sert à rien à l'audit, même si elle a réellement eu lieu. Idem pour la formation, un message Teams ne remplace pas un enregistrement nominatif qui montre qui a suivi quoi et quand^[2].

Non-conformités et actions correctives

La clause 10.2 demande de conserver la nature des non-conformités, les actions engagées et leurs résultats^[1]. Dans la pratique observée par les organismes de certification, ce registre est souvent incomplet, surtout pour des écarts mineurs détectés en interne mais non tracés. C'est une cause récurrente de constat à l'audit initial^[4].

Documentation des systèmes d'IA eux-mêmes

L'annexe A introduit des contrôles spécifiques liés au cycle de vie des systèmes d'IA, qui appellent leur propre documentation. On y trouve par exemple les exigences de transparence vis-à-vis des utilisateurs, la documentation technique du système, les éléments sur les données utilisées et sur la performance attendue^[5]. Ces documents-là ne sont pas du SMIA au sens strict, ils sont produits par le SMIA.

Pour un éditeur, cela signifie typiquement une fiche par système d'IA, finalité, données d'entraînement, limites connues, méthode d'évaluation, mécanismes de surveillance en production. Microsoft publie ce type de fiche pour ses produits Copilot, et l'illustre dans le cadre de sa certification^[7].

Ce qui n'est pas obligatoire mais souvent confondu

Plusieurs documents circulent dans les modèles commerciaux comme s'ils étaient exigés par la norme, alors qu'ils relèvent du choix de l'organisme. Le distinguer évite de produire dix livrables inutiles.

• Manuel du SMIA : hérité d'ISO 9001 ancien format, non requis par la clause 7.5^[6].
• Charte éthique de l'IA : utile, mais la norme parle d'objectifs et de principes, pas d'un document baptisé « charte ».
• Procédure pour chaque contrôle de l'annexe A : la SoA suffit si la mise en œuvre du contrôle est démontrable autrement^[2].
• Cartographie SI complète : souvent utile, jamais imposée comme telle.
• Politique distincte par thème : la politique IA peut être unique et renvoyer à des règles plus fines.

La logique de la norme est celle d'une obligation de résultat documenté, pas d'une obligation de format. Un auditeur compétent évalue la pertinence du corpus au regard du périmètre et de la maturité, pas le poids du classeur^[4].

Structurer le corpus sans l'alourdir

Pour un consultant qui démarre une mission, l'erreur la plus coûteuse est de reproduire un modèle générique téléchargé. Les démarches observées montrent qu'un corpus calibré sur le périmètre réel passe l'audit initial avec moins de constats qu'un corpus pléthorique mal maîtrisé^[4].

Trois principes tiennent. Un, partir des risques et impacts réels, et ne documenter que ce qui les traite. Deux, mutualiser avec un SMSI ISO 27001 existant quand c'est cohérent, la structure harmonisée le permet^[7]. Trois, dater et versionner chaque document, parce que la clause 7.5.3 exige une maîtrise des informations documentées, distribution, accès, modification, conservation^[1].

Point de contrôle pratique

Avant l'audit étape 1, une revue interne du corpus aide à repérer ce qui manque. Une check-list resserrée fonctionne mieux qu'un inventaire long.

• Le périmètre identifie-t-il les systèmes d'IA, les sites, les exclusions et la justification.
• La politique IA est-elle signée par la direction et datée.
• La SoA couvre-t-elle tous les contrôles de l'annexe A avec justification d'exclusion^[2].
• Chaque système d'IA dispose-t-il d'une analyse d'impact à jour^[5].
• Le programme d'audit interne et la revue de direction sont-ils tracés sur les douze derniers mois.
• Le registre de non-conformités contient-il au moins quelques entrées avec suivi documenté.

Pièges fréquents côté consultant

Premier piège, confondre documents pour l'auditeur et documents pour l'organisme. Les preuves doivent être lisibles par l'auditeur, mais elles doivent d'abord servir aux opérations. Un registre des risques alimenté uniquement avant l'audit ne tient pas plus de six mois.

Deuxième piège, sous-estimer l'analyse d'impact. Elle est conceptuellement distincte de l'évaluation des risques et regarde l'effet du système d'IA sur les personnes concernées, candidats, patients, administrés^[5]. Un département cantonal qui déploie un outil de scoring sans cette analyse documentée s'expose à un constat majeur à l'audit.

Troisième piège, sur-documenter pour rassurer. Les analyses publiées par les cabinets spécialisés signalent que la longueur d'un document n'est jamais un critère, et qu'un corpus pléthorique nuit à la maîtrise de version exigée par la clause 7.5.3^[6]. À titre indicatif, selon les retours d'organismes comme A-LIGN ou Schellman, un SMIA initial bien calibré tient dans une vingtaine de documents structurants, hors enregistrements opérationnels^[2][5]. Ce chiffre est indicatif et doit être recoupé avec la situation réelle de chaque organisme.

Quatrième piège, oublier que la documentation doit refléter ce qui se passe vraiment. Un journal de surveillance d'un modèle qui décrit des seuils jamais mesurés est pire qu'absent, parce qu'il signale au lecteur attentif que le contrôle n'existe pas. Pour un Lead Implementer, la règle pragmatique consiste à n'écrire que ce qu'on est prêt à montrer en preuve sur six mois glissants.

Questions fréquentes

À lire ensuite