ISO 42001 vs ISO 27001 : différences et passerelles

Deux objets de management différents

ISO/IEC 27001 organise un système de management de la sécurité de l'information dont la finalité tient en trois mots, confidentialité, intégrité, disponibilité de l'information^[4]. ISO/IEC 42001 organise un système de management de l'intelligence artificielle, le SMIA, dont la finalité est la gouvernance responsable des systèmes d'IA développés, fournis ou utilisés par l'organisation^[8].

La nuance n'est pas cosmétique. Un SMSI répond à la question « comment protégeons-nous l'information que nous traitons ». Un SMIA répond à la question « comment garantissons-nous que les systèmes d'IA que nous produisons ou utilisons restent transparents, équitables et sous contrôle, sur tout leur cycle de vie »^[8].

Pour un responsable qualité déjà certifié 27001, la conséquence pratique est claire. Le SMSI couvre la donnée comme actif à protéger. Le SMIA couvre le système d'IA comme objet à gouverner, ce qui inclut le modèle, les données d'entraînement, les décisions automatisées et leurs effets sur des personnes ou des tiers^[6].

Structure HLS commune, contenu distinct

Les deux normes suivent la structure harmonisée des normes de management ISO, ce qui rend la mise en parallèle des clauses 4 à 10 quasiment mécanique. Cette parenté facilite l'intégration d'un SMIA dans un SMSI existant, sans réécrire les fondations^[7].

Les sept clauses du tronc commun se lisent en miroir. La différence se joue dans le contenu, pas dans la structure.

4Contexte : enjeux IA et parties intéressées à ajouter

5Leadership : politique IA, rôles, comité éthique

6Planification : risque IA et analyse d'impact

7Support : compétences IA, communication

8Opérations : contrôles cycle de vie IA

9Évaluation : métriques de performance IA

10Amélioration : non-conformités IA

Synthèse des paires de clauses, d'après la cartographie publiée par DQS^[7] et la lecture clause à clause diffusée par P. Sullivan^[2].

Dans la pratique, votre processus de revue de direction, votre méthodologie d'audit interne et votre dispositif d'action corrective restent les mêmes véhicules. Ce qui change, ce sont les objets passés en revue, les compétences attendues des auditeurs et les preuves attendues à chaque étape^[7].

Cette parenté explique pourquoi de nombreux organismes recommandent une certification conjointe ou séquentielle, en s'appuyant sur le SMSI déjà en place. Selon Advisera, les organisations disciplinées peuvent obtenir les deux certifications en limitant la charge documentaire grâce au recouvrement structurel^[1].

Risque sécurité vs risque IA

La clause 6 marque la première vraie bifurcation. ISO 27001 demande une appréciation du risque sur les actifs informationnels, avec traitement et plan d'action. ISO 42001 demande la même démarche pour les systèmes d'IA, plus une analyse d'impact dédiée, qui examine les effets sur les personnes, les groupes et les tiers^[2].

L'analyse d'impact IA ne se confond pas avec l'analyse de risque sécurité. Elle s'intéresse aux biais possibles, à la qualité et la représentativité des données d'entraînement, à l'explicabilité des décisions et aux effets sociaux du système^[7]. Un risque de discrimination algorithmique, par exemple, n'est pas un risque de confidentialité au sens du SMSI.

Concrètement, un responsable qualité romand qui exploite un outil de scoring de candidatures gérera deux objets distincts. Côté 27001, il protégera les CV stockés. Côté 42001, il documentera la composition du jeu d'entraînement, mesurera les écarts de taux de sélection entre groupes et tracera les décisions du modèle, conformément à l'esprit des contrôles dédiés à la qualité des données et à la transparence^[7].

Observation qualitative, les démarches observées sur le terrain romand montrent que les équipes 27001 sous-estiment souvent ce périmètre nouveau et tentent de loger l'analyse d'impact IA dans leur matrice de risques existante. L'exercice se révèle vite limité, parce que les actifs à évaluer, les parties prenantes et les conséquences ne sont pas de même nature.

Annexe A : ce qui se recouvre, ce qui ne se recouvre pas

L'annexe A de 27001 vise des contrôles organisationnels, humains, physiques et techniques de sécurité. L'annexe A de 42001 introduit des contrôles propres au cycle de vie de l'IA, dont la qualité des données pour l'entraînement, la protection des modèles, la transparence et la traçabilité des décisions automatisées^[7].

Recouvrements et écarts sur des thèmes clés

Thème	ISO 27001	ISO 42001
Gouvernance et politique	A.5.1 politiques de sécurité	5.2 politique IA, 5.3 rôles IA
Qualité et gouvernance des données	A.5.34, A.8.10 classification	A.7.2 qualité des données pour l'IA
Protection des actifs IA	A.8.1 à A.8.12 actifs et chiffrement	A.7.3 modèles, jeux d'entraînement, algorithmes
Transparence et explicabilité	Non couvert directement	A.8.4 transparence des décisions IA
Incidents	A.5.25 à A.5.28 incidents sécurité	A.8.6 incidents IA, dérive, biais détecté
Fournisseurs	A.5.19 à A.5.22 sécurité fournisseurs	A.7.4 conformité IA des fournisseurs

Source de la cartographie, DQS, 2025^[7]. Les contrôles 27001 sont ceux de l'édition 2022. Vérifier l'évolution depuis cette date côté éditeurs et organismes de certification.

Deux zones n'ont pas d'équivalent direct côté 27001, la transparence et l'explicabilité des décisions, ainsi que la gestion d'incidents typiques de l'IA, comme la dérive de modèle ou la détection d'un biais en production^[7]. Ce sont, pour un responsable qualité, les chantiers neufs à instruire en priorité.

Construire le pont depuis un SMSI existant

Partir d'un SMSI mature est un avantage. La gouvernance, la gestion documentaire, le pilotage par indicateurs et le mécanisme d'audit interne constituent déjà l'ossature du futur SMIA. Reste à étendre, pas à dupliquer^[1].

Quatre extensions structurent le travail. Premièrement, élargir le contexte de la clause 4 pour intégrer les enjeux liés à l'IA, les parties prenantes nouvelles, et l'inventaire des systèmes d'IA développés ou utilisés^[2]. Deuxièmement, formaliser une politique IA distincte de la politique de sécurité, ou une politique parapluie avec une annexe IA explicite^[7].

Troisièmement, instaurer une analyse d'impact des systèmes d'IA en complément de l'appréciation des risques sécurité, avec ses propres critères et ses propres déclencheurs de revue^[2]. Quatrièmement, ajouter des contrôles d'annexe A spécifiques au cycle de vie IA, qualité des données, protection des modèles, transparence et gestion des incidents IA^[7].

Côté pilotage, l'évaluation de performance reste sous l'égide d'une logique PDCA commune, ce qui autorise un tableau de bord unifié, à condition d'identifier des métriques IA distinctes, par exemple la fréquence de revérification d'un modèle, le taux d'incidents liés à une dérive, ou la couverture documentaire des décisions automatisées^[7].

Audit combiné et déclaration d'applicabilité

La déclaration d'applicabilité de 27001 ne couvre pas les contrôles de 42001. Vous aurez donc deux SoA, ou une SoA consolidée qui distingue clairement les deux corpus de contrôles, faute de quoi l'auditeur ne pourra pas se prononcer sur le périmètre IA^[7].

Un audit combiné est techniquement faisable parce que la structure HLS le permet, et plusieurs organismes de certification proposent ce schéma^[3]. À la date de publication de cet article, juin 2026, l'écosystème suisse d'accréditation reste à vérifier auprès du SAS, car les périmètres accrédités pour 42001 évoluent vite.

Côté équipe d'audit interne, prévoir des compétences nouvelles, notamment sur la science des données, l'évaluation des biais et la documentation des modèles. Un auditeur qualité formé uniquement à 27001 ne sera pas en mesure de challenger une fiche de modèle ou une mesure d'équité, même s'il maîtrise la logique d'audit^[6].

Pour la documentation, la voie économe consiste à étendre les procédures existantes plutôt que d'en créer de nouvelles. Politique d'incidents augmentée d'un volet IA, procédure fournisseur enrichie d'une clause de provenance des modèles, gestion des changements appliquée aux versions de modèle et de jeux d'entraînement^[7].

Pièges fréquents côté responsable qualité

Premier piège, considérer 42001 comme un module complémentaire de 27001. Les normes partagent la grammaire, pas la substance. Une organisation qui copie son SMSI en remplaçant « information » par « IA » manquera la clause 6 sur l'analyse d'impact et les contrôles propres à l'annexe A de 42001^[2].

Deuxième piège, ranger l'IA fournisseur sous la seule politique fournisseurs 27001. Les exigences de provenance des modèles, de transparence et de partage des responsabilités sur le cycle de vie IA dépassent le périmètre habituel des contrats de sous-traitance sécurité^[7].

Troisième piège, sous-dimensionner la fonction de surveillance post-déploiement. Un modèle qui fonctionnait à la mise en production peut dériver, voir ses entrées changer ou produire des décisions biaisées avec l'évolution des données. ISO 42001 attend une surveillance continue, et un mécanisme d'incident spécifique^[7].

Quatrième piège, traiter la transparence comme une obligation documentaire en interne. La clause de transparence de 42001 vise aussi les utilisateurs et les personnes concernées par les décisions du système, ce qui peut imposer des notices, une explication de la décision automatisée et un mécanisme de recours, points absents de 27001^[7].

Interprétation, pour un responsable qualité déjà 27001, l'effort le plus rentable consiste à constituer un binôme métier et data avant de toucher au système de management. Un SMIA conçu sans interlocuteur data en interne reste documentaire et passera difficilement un audit sur le fond.

Questions fréquentes

À lire ensuite