ISO 42001 checklist : 30 points avant l'audit

Avertissement sur les sources de cet article

Cet article repose sur la structure harmonisée (Harmonized Structure, anciennement High Level Structure) commune à toutes les normes ISO de systèmes de management, ainsi que sur la connaissance publique de l'architecture de l'ISO/IEC 42001. L'Organisation internationale de normalisation (ISO), basée à Genève, publie ces normes via ses comités techniques réunissant plus de 170 organismes nationaux membres^[1].

Les points de vérification présentés ci-dessous sont des interprétations de la structure connue de la norme. Pour toute vérification définitive, consultez le texte officiel de l'ISO/IEC 42001:2023 disponible auprès de l'ISO ou de la SNV (Association suisse de normalisation). Les observations pratiques sont signalées comme telles.

Pourquoi une checklist avant l'audit

Un consultant ou futur Lead Implementer qui prépare un organisme à la certification ISO 42001 a besoin d'un outil de vérification systématique. L'audit de certification, qu'il soit de stade 1 (revue documentaire) ou de stade 2 (vérification terrain), suit la logique des clauses de la norme. Arriver en audit sans avoir vérifié chaque exigence clause par clause revient à passer un examen sans relire le programme.

La checklist ne remplace pas la lecture de la norme. Elle structure votre revue finale. Si vous découvrez le SMIA (système de management de l'intelligence artificielle), commencez par comprendre la structure clause par clause de la norme avant d'utiliser cette liste.

La séquence retenue ici suit les clauses 4 à 10, puis l'Annexe A. C'est l'ordre dans lequel un auditeur procède généralement, et c'est aussi la logique de construction d'un système de management conforme à la structure harmonisée de l'ISO^[1].

Contexte et leadership (clauses 4 à 5)

Clause 4 : le contexte de l'organisme

La clause 4 demande de définir le périmètre du SMIA, d'identifier les parties intéressées et de comprendre les enjeux internes et externes. Voici les points de vérification, interprétés à partir de la structure harmonisée et de ce que l'on sait publiquement de l'ISO 42001.

• Le domaine d'application du SMIA est-il documenté, avec les systèmes d'IA inclus et exclus ?
• Les parties intéressées pertinentes (clients, régulateurs, personnes affectées par l'IA) sont-elles identifiées avec leurs attentes ?
• Les enjeux internes (compétences, culture, infrastructure) et externes (réglementation, marché) sont-ils analysés ?
• Le périmètre couvre-t-il l'ensemble du cycle de vie des systèmes d'IA concernés ?

Un point souvent sous-estimé selon les démarches observées : le périmètre du SMIA doit être cohérent avec l'inventaire réel des systèmes d'IA. Un périmètre trop large crée des obligations documentaires ingérables. Un périmètre trop étroit laisse des systèmes à risque hors gouvernance. La cartographie des systèmes d'IA constitue le socle de cette délimitation.

Clause 5 : le leadership

La direction doit démontrer son engagement, définir une politique IA et attribuer les rôles et responsabilités. Vérifiez les points suivants.

• Une politique IA est-elle formalisée, approuvée par la direction, communiquée et accessible ?
• Les rôles liés au SMIA (responsable IA, comité de gouvernance) sont-ils attribués avec des autorités claires ?
• La direction peut-elle démontrer son implication (comptes rendus de revue de direction, allocations de ressources) ?

L'auditeur cherchera des preuves tangibles d'engagement, pas seulement une signature sur un document. Si la direction ne peut pas expliquer en quelques phrases ce que le SMIA couvre et pourquoi, c'est un signal d'alerte. Le rôle du Lead Implementer inclut précisément cette capacité à faire le lien entre la norme et la réalité opérationnelle de la direction.

Planification et risques (clause 6)

Appréciation des risques et opportunités

La clause 6 couvre la planification, y compris l'appréciation des risques liés au SMIA et aux systèmes d'IA eux-mêmes, les objectifs IA et la planification des modifications. C'est la clause la plus spécifique à l'ISO 42001 par rapport aux autres normes ISO de systèmes de management.

Points de vérification (interprétation basée sur la structure connue de la norme) :

• Une méthodologie d'appréciation des risques IA est-elle documentée, avec des critères d'acceptation ?
• L'analyse d'impact des systèmes d'IA sur les individus et les groupes est-elle réalisée ?
• Les risques identifiés sont-ils traités par un plan de traitement documenté, avec des responsables et des échéances ?
• Les objectifs IA sont-ils mesurables, cohérents avec la politique, et suivis ?

L'ISO 42001 introduit une dimension propre à l'IA que l'on ne retrouve pas dans l'ISO 27001 ou l'ISO 9001 : l'obligation de considérer les impacts sur les personnes affectées par les systèmes d'IA. Pour approfondir la méthode, consultez le guide sur l'évaluation des risques IA.

Déclaration d'applicabilité

Comme l'ISO 27001 avec ses contrôles de l'Annexe A, l'ISO 42001 exige une déclaration d'applicabilité (SoA). Ce document liste les contrôles de l'Annexe A retenus ou exclus, avec la justification de chaque décision.

Vérifiez que la SoA est cohérente avec les résultats de l'appréciation des risques. Un contrôle exclu sans justification documentée sera relevé en non-conformité. Le guide sur la préparation de la SoA détaille la méthode.

Support et documentation (clause 7)

La clause 7 traite des ressources, des compétences, de la sensibilisation, de la communication et des informations documentées. C'est le socle opérationnel du SMIA.

Points de vérification clause 7

Sous-clause	Point de contrôle
7.1 Ressources	Budget, outils, temps alloués au SMIA sont-ils documentés ?
7.2 Compétences	Les compétences requises pour chaque rôle IA sont-elles définies et les écarts comblés (formation, recrutement) ?
7.3 Sensibilisation	Le personnel concerné connaît-il la politique IA, sa contribution au SMIA et les conséquences de non-conformité ?
7.4 Communication	Un plan de communication interne et externe sur le SMIA existe-t-il ?
7.5 Informations documentées	Les documents exigés par la norme sont-ils créés, identifiés, maîtrisés et accessibles ?

La clause 7.5 sur les informations documentées mérite une attention particulière. L'auditeur vérifiera non seulement l'existence des documents, mais aussi leur maîtrise : versionnage, approbation, diffusion, archivage. Le détail des documents obligatoires de la clause 7.5 vous donne la liste complète.

Observation qualitative : dans les démarches de certification observées sur d'autres normes ISO, la clause 7 génère un nombre disproportionné de non-conformités mineures, souvent parce que les compétences ne sont pas formellement évaluées ou que la sensibilisation se limite à un courriel envoyé une fois.

Réalisation et évaluation (clauses 8 à 9)

Clause 8 : réalisation des activités opérationnelles

La clause 8 concerne la planification et la maîtrise opérationnelle. Pour un SMIA, cela inclut la gestion opérationnelle des systèmes d'IA tout au long de leur cycle de vie.

• Les processus opérationnels liés aux systèmes d'IA sont-ils planifiés, mis en œuvre et maîtrisés ?
• Les critères de performance et de surveillance des systèmes d'IA sont-ils définis ?
• Les modifications des systèmes d'IA sont-elles gérées selon un processus documenté ?
• Les processus externalisés (fournisseurs d'IA, hébergeurs) sont-ils maîtrisés ?

La maîtrise des fournisseurs est un point sensible. Si votre organisme utilise des modèles d'IA fournis par des tiers (ce qui est le cas de la majorité des organisations), l'auditeur vérifiera que vous avez documenté les critères de sélection, les obligations contractuelles et les mécanismes de surveillance.

Clause 9 : évaluation des performances

La clause 9 exige la surveillance, la mesure, l'analyse et l'évaluation du SMIA, ainsi que l'audit interne et la revue de direction.

• Un programme d'audit interne du SMIA est-il planifié et exécuté par des auditeurs compétents et indépendants ?
• La revue de direction couvre-t-elle les éléments d'entrée requis (résultats d'audit, performance des systèmes IA, retours des parties intéressées) ?
• Des indicateurs de performance du SMIA sont-ils définis, mesurés et analysés ?

L'audit interne est un prérequis absolu avant l'audit de certification. Sans audit interne réalisé et documenté, l'auditeur de certification ne pourra pas poursuivre. Prévoyez un délai suffisant entre l'audit interne et l'audit de certification pour traiter les écarts identifiés. Le parcours complet est décrit dans le guide sur les étapes de la certification.

Amélioration et Annexe A (clause 10)

Clause 10 : amélioration continue

La clause 10 demande de traiter les non-conformités par des actions correctives et de démontrer l'amélioration continue du SMIA. Vérifiez que :

• Un processus de gestion des non-conformités et actions correctives est documenté et appliqué.
• Les non-conformités identifiées lors de l'audit interne ont été traitées avec analyse des causes.
• Des preuves d'amélioration continue existent (évolution des indicateurs, mise à jour des processus).

L'amélioration continue n'est pas un slogan. L'auditeur cherchera des traces concrètes : une appréciation des risques mise à jour après un incident, un contrôle renforcé suite à un retour utilisateur, une formation ajoutée après un écart de compétence identifié.

Vérification des contrôles de l'Annexe A

L'Annexe A de l'ISO 42001 contient des contrôles spécifiques à la gouvernance de l'IA, organisés en catégories couvrant des thèmes comme la politique IA, la gestion du cycle de vie, la qualité des données, la transparence ou encore la gestion des tiers. La liste commentée des contrôles de l'Annexe A détaille chaque catégorie.

Pour chaque contrôle retenu dans la SoA, vérifiez trois éléments : le contrôle est-il documenté, est-il appliqué, et des preuves de son fonctionnement existent-elles ? Un contrôle documenté mais non appliqué est une non-conformité. Un contrôle appliqué mais non documenté en est une autre.

Piège fréquent : la checklist cosmétique

Le piège le plus courant, observé dans les démarches de certification ISO en général, est de traiter la checklist comme un exercice de cases à cocher. L'organisme produit les documents requis, remplit les formulaires, mais le système ne vit pas. L'auditeur de certification le détecte en quelques questions.

Prenons un exemple concret. L'appréciation des risques IA existe dans un tableur, mais personne dans l'équipe opérationnelle ne peut expliquer comment un risque spécifique a été évalué. La politique IA est signée par la direction, mais le directeur ne peut pas en résumer le contenu. Les compétences sont listées dans un tableau, mais aucune formation n'a été dispensée.

La différence entre une checklist utile et une checklist cosmétique tient en un mot : la preuve d'application. Pour chaque point de cette liste, posez-vous la question suivante : si l'auditeur demande à voir une preuve concrète, que lui montrez-vous ? Si la réponse est « le document lui-même », vous avez un problème. La preuve doit être un enregistrement d'activité : un compte rendu, un registre mis à jour, un rapport d'analyse, un courriel de communication.

Mise en situation romande

Imaginons un éditeur de logiciel basé dans l'Arc lémanique, qui développe un outil de scoring pour des assureurs. L'entreprise emploie 45 personnes et souhaite obtenir la certification ISO 42001 pour répondre aux exigences de ses clients européens soumis au règlement sur l'IA.

Le consultant mandaté commence par la cartographie des systèmes d'IA. Il identifie trois systèmes : le modèle de scoring principal, un chatbot de support client, et un outil interne de tri de CV. Le périmètre du SMIA est défini pour couvrir les trois systèmes, car ils présentent tous des impacts potentiels sur des individus.

En parcourant la checklist clause par clause, le consultant relève plusieurs écarts typiques. La politique IA existe mais ne mentionne pas les principes d'utilisation responsable de l'IA. L'appréciation des risques couvre le modèle de scoring mais omet le tri de CV, pourtant à haut risque. La SoA exclut le contrôle sur la transparence sans justification documentée. Aucun audit interne n'a été réalisé.

Le plan de remédiation priorise les écarts : d'abord l'analyse d'impact sur le tri de CV (risque élevé pour les candidats), puis la mise à jour de la SoA, ensuite la révision de la politique, et enfin la planification de l'audit interne. Le consultant estime quatre mois de travail avant d'être prêt pour l'audit de stade 1. Pour estimer les coûts associés, le guide sur le coût et délai de certification fournit des repères utiles.

Ce scénario, bien que fictif, reflète une réalité observée dans les démarches de conformité : les écarts les plus fréquents ne portent pas sur l'absence totale de documentation, mais sur l'incohérence entre les documents et la pratique réelle.

Questions fréquentes

À lire ensuite