Intégrer l'ISO 42001 à un SMSI ISO 27001 existant

Pourquoi intégrer plutôt que juxtaposer

Une organisation qui gère l'ISO 27001 et l'ISO 42001 comme deux systèmes cloisonnés accumule des doublons de documentation, deux programmes d'audit internes, deux revues de direction et deux registres de risques couvrant des sujets qui se chevauchent^[7]. Le coût de cette duplication dépasse le coût de l'intégration elle-même.

L'argument n'est pas seulement économique. Pour toute organisation qui utilise l'IA pour traiter des données sensibles, la sécurité de l'information et la gouvernance de l'IA s'appliquent aux mêmes systèmes, au même moment^[2]. Séparer les deux revient à découper artificiellement un risque qui est, par nature, transversal.

L'ISO 42001 a été conçue pour s'intégrer aux systèmes de management existants, pas pour les remplacer^[3]. Si vous disposez déjà d'un SMSI certifié, la question n'est pas « ISO 27001 ou ISO 42001 », mais bien « ISO 27001 et ISO 42001, gérées ensemble »^[2].

Ce que la structure harmonisée rend possible

Les deux normes suivent la structure harmonisée dite Annex SL, qui aligne les clauses 4 à 10 : contexte de l'organisation, leadership, planification, support, réalisation, évaluation des performances et amélioration continue^[3][4]. Ce squelette commun signifie qu'une seule analyse du contexte, un seul engagement de la direction et un seul cadre d'objectifs peuvent satisfaire les deux référentiels simultanément^[7].

Pour un responsable qualité familier de l'ISO 9001 ou de l'ISO 27001, l'ISO 42001 présentera un air de famille immédiat^[2]. La structure clause par clause de l'ISO 42001 reprend le même cycle PDCA (Plan-Do-Check-Act), ce qui facilite la cartographie des exigences communes.

Concrètement, les processus de gestion des compétences, de sensibilisation, de maîtrise documentaire (clause 7) et d'amélioration continue (clause 10) sont substantivement identiques dans les deux normes^[8]. Vous n'avez pas à réécrire ces procédures : vous les étendez.

Zones de recouvrement entre les deux normes

Selon un organisme de certification spécialisé, les organisations certifiées ISO 27001 peuvent réutiliser environ 50 à 60 % de leur documentation et de leurs processus existants lors du déploiement de l'ISO 42001^[4]. Ce chiffre, à considérer comme un ordre de grandeur (il varie selon la maturité du SMSI et l'étendue des systèmes d'IA), donne une idée de l'effort évité.

Les zones de recouvrement les plus directes concernent les exigences partagées suivantes^[4] :

• Contexte de l'organisation : compréhension des enjeux internes et externes, besoins des parties intéressées
• Leadership : engagement de la direction, politique, attribution des rôles
• Planification : approche par les risques, définition des objectifs
• Support : ressources, compétences, sensibilisation, documentation
• Évaluation des performances : surveillance, audit interne, revue de direction
• Amélioration : traitement des non-conformités et amélioration continue

Au niveau des contrôles, plusieurs domaines se superposent : contrôle d'accès, gestion des actifs (les modèles d'IA et les données d'entraînement sont des actifs à gérer), relations fournisseurs, gestion des incidents et continuité d'activité^[4]. Pour chacun de ces domaines, l'ISO 42001 n'abolit pas ce que l'ISO 27001 prescrit. Elle y ajoute une dimension propre à l'IA.

Recouvrement des contrôles entre ISO 27001 et ISO 42001

Domaine	ISO 27001	ISO 42001 (ajout)
Contrôle d'accès	Accès aux systèmes d'information	Accès aux jeux de données, API et pipelines d'entraînement[8]
Gestion des actifs	Inventaire des actifs informationnels	Enregistrement des modèles avec lignée des données et historique de versions[6]
Gestion des incidents	Détection et réponse aux incidents de sécurité	Incidents liés à l'IA : dérive de modèle, biais détecté en production[8]
Fournisseurs	Sécurité de la chaîne d'approvisionnement	Conformité IA des fournisseurs tiers[8]

Les écarts spécifiques à l'IA à combler

Si la moitié du chemin est déjà parcourue, l'autre moitié demande un travail ciblé. L'ISO 42001 introduit des exigences que l'ISO 27001 ne couvre pas, car elles relèvent non pas de la protection de l'information, mais de la manière dont l'information est interprétée, inférée et utilisée pour prendre des décisions^[3].

Les catégories de risques propres à l'IA comprennent le biais algorithmique, le manque de transparence et d'explicabilité, la surveillance humaine insuffisante, la dérive de modèle, la fiabilité et la sécurité des systèmes, ainsi que les impacts sociétaux et environnementaux^[4][5]. Pour approfondir ces risques spécifiques, consultez la page sur l'évaluation des risques IA.

L'analyse d'impact constitue un autre écart majeur. Là où l'ISO 27001 se concentre sur l'analyse d'impact métier (comment un incident de sécurité affecte les opérations), l'ISO 42001 exige une évaluation de l'impact des systèmes d'IA sur les individus, les groupes vulnérables, les droits fondamentaux et la société au sens large^[4]. Ce sont deux exercices distincts, même s'ils peuvent partager une méthodologie commune.

Enfin, l'Annexe A de l'ISO 42001 introduit des contrôles sans équivalent dans l'ISO 27001 : qualité des données d'entraînement, transparence et explicabilité des décisions, validation des modèles avant déploiement, gestion du cycle de vie des modèles^[8]. Pour un tour d'horizon de ces contrôles, voir notre article sur les 9 catégories de contrôles de l'Annexe A.

Démarche d'intégration en cinq étapes

La démarche qui suit synthétise les approches décrites par plusieurs sources spécialisées. Elle s'adresse à une organisation disposant déjà d'un SMSI ISO 27001 opérationnel.

Cinq étapes, de l'inventaire au premier audit combiné.

1Aligner le périmètre

2Cartographier les recouvrements et écarts

3Étendre politiques et registre de risques

4Adapter la gouvernance et les rôles

5Combiner audits et revue de direction

Chaque étape s'appuie sur les processus SMSI existants plutôt que d'en créer de nouveaux^[6].

Étape 1 : aligner le périmètre

Identifiez les systèmes d'IA déjà en usage dans votre organisation (modèles de machine learning, outils basés sur des LLM, moteurs de recommandation, systèmes de détection de fraude) et rattachez-les aux actifs existants du SMSI : données, applications, infrastructure^[6]. L'objectif est de lier explicitement les systèmes d'IA au périmètre SMSI actuel plutôt que de créer un périmètre IA séparé.

Cette étape correspond à ce que la norme appelle la détermination du domaine d'application (clause 4.3). Si votre SMSI couvre déjà l'infrastructure sur laquelle tournent vos modèles, l'extension de périmètre peut être modeste. Pour structurer cet inventaire, la cartographie des systèmes d'IA fournit une méthode applicable.

Étape 2 : cartographier les recouvrements et les écarts

Mappez les contrôles de l'Annexe A de l'ISO 42001 sur ceux de l'Annexe A de l'ISO 27001 pour identifier ce qui est déjà couvert, ce qui nécessite une extension et ce qui est entièrement nouveau^[6][8]. Ce travail de correspondance est le cœur d'une analyse d'écart (gap analysis).

En pratique, les contrôles liés à la gouvernance, à la gestion des accès et à la gestion des incidents seront en grande partie déjà satisfaits. Les contrôles liés à la qualité des données, à la transparence des modèles et à l'évaluation d'impact IA seront, eux, largement à construire.

Étape 3 : étendre les politiques et le registre de risques

Plutôt que de rédiger un corpus documentaire parallèle, étendez vos politiques existantes (utilisation acceptable, classification des données, gestion des tiers, gestion des changements) pour couvrir les réalités de l'IA^[6]. Par exemple, la politique d'utilisation acceptable peut intégrer des restrictions sur l'usage d'outils d'IA publics. La politique de classification des données peut exiger l'étiquetage des jeux de données d'entraînement.

Un guide praticien recommande de créer une politique de gouvernance de l'IA de haut niveau qui renvoie à la documentation SMSI existante plutôt que de la dupliquer^[6]. Cette approche maintient la cohérence et réduit la charge de maintenance documentaire.

Étape 4 : adapter la gouvernance et les rôles

L'intégration ne demande pas nécessairement de nouveaux comités. Elle demande d'élargir les comités existants. Le guide AIGL suggère d'étendre le comité SMSI pour y inclure des data scientists, des ingénieurs IA, des experts juridiques et des responsables des risques, et de définir des rôles tels que propriétaire de produit IA, responsable du risque modèle ou réviseur éthique^[6].

Un sous-comité dédié aux risques IA, rattaché à la structure SMSI existante, constitue un mécanisme de gouvernance pragmatique^[6]. Il évite la création d'une structure parallèle tout en assurant que les sujets propres à l'IA reçoivent l'attention nécessaire.

Étape 5 : combiner audits et revue de direction

Les programmes d'audit interne peuvent être fusionnés en un seul programme annuel couvrant les deux normes^[7]. La revue de direction peut se tenir en une seule séance avec un ordre du jour combiné et des enregistrements consolidés^[7]. Pour les détails pratiques de l'audit combiné, notre article sur l'audit intégré 42001/27001 détaille la marche à suivre.

Construire un registre de risques unifié

Le point d'intégration le plus déterminant est la méthodologie d'appréciation des risques. Un seul document de méthodologie, un seul registre de risques, un seul plan de traitement peuvent couvrir à la fois les risques de sécurité de l'information et les risques propres à l'IA^[7].

Les risques spécifiques à l'IA à ajouter au registre existant comprennent le biais et la discrimination, les entrées adverses et l'empoisonnement de modèle, l'usage d'IA non autorisée (« shadow AI ») et la fuite de propriété intellectuelle^[6]. Le guide AIGL recommande d'étendre les méthodologies existantes (ISO 27005 ou NIST AI RMF) plutôt que d'en inventer de nouvelles, en utilisant l'Annexe A de l'ISO 42001 comme référence^[6].

Les évaluations d'impact des systèmes d'IA, en revanche, restent des documents autonomes, liés aux entrées du registre de risques^[7]. Elles ne se confondent pas avec l'analyse d'impact métier de l'ISO 27001 : leur objet est différent, même si la mécanique de gestion documentaire peut être mutualisée.

Gouvernance et rôles : étendre sans empiler

SGS, organisme de certification et d'inspection, décrit l'intégration comme l'obtention de trois perspectives de risque au sein d'un seul cadre cohérent : les risques de sécurité de l'information (ISO 27001), les risques de qualité et d'exploitation (ISO 9001 le cas échéant), et les risques éthiques, opérationnels et sociétaux de l'IA (ISO 42001)^[3].

Pour la direction, cela signifie une vue consolidée de l'exposition aux risques organisationnels, plutôt que des rapports fragmentés^[3]. Le tableau de correspondance des rôles et responsabilités (RACI) peut être unifié : le DQS, organisme de certification, suggère d'intégrer les responsabilités de sécurité, d'IA et de protection des données dans une seule matrice^[8].

La politique elle-même peut être structurée comme un cadre unique avec des annexes spécifiques pour l'IA et la protection des données, plutôt que comme des documents séparés^[8]. Cette architecture documentaire est plus facile à maintenir et présente une image plus cohérente aux auditeurs, aux clients et aux régulateurs^[7].

Audit intégré et revue de direction commune

Un audit intégré permet d'évaluer les deux normes simultanément, ce qui réduit la charge d'audit^[4]. En pratique, l'auditeur vérifie les processus communs une seule fois (revue de direction, gestion documentaire, compétences, amélioration continue) et consacre du temps supplémentaire aux contrôles spécifiques à l'IA.

Pour la revue de direction, un ordre du jour combiné couvre les indicateurs de sécurité de l'information et les indicateurs de gouvernance IA. Les enregistrements de sortie sont consolidés^[7]. Cette approche évite les réunions redondantes et permet à la direction de prendre des décisions informées sur l'ensemble du périmètre.

Le hub Comparatifs et réglementation rassemble d'autres analyses de recoupement entre l'ISO 42001 et les référentiels connexes, y compris le comparatif ISO 42001 face à l'ISO 27001, l'AI Act et la nLPD.

Le piège le plus fréquent

Le piège le plus courant, observé dans les démarches d'intégration, consiste à traiter l'ISO 42001 comme un projet de conformité documentaire plutôt que comme une extension opérationnelle du système de management. On produit alors une déclaration d'applicabilité IA, un registre de risques IA et une politique IA, le tout déconnecté du SMSI.

Le résultat est précisément ce que l'intégration devait éviter : des structures parallèles, des revues séparées, une fatigue d'audit^[6]. Le guide AIGL le formule clairement : pour les organisations déjà certifiées ISO 27001, le risque principal n'est pas l'absence de gouvernance IA, mais la création de systèmes parallèles avec des politiques, des comités, des audits et des registres de risques séparés qui deviennent rapidement incohérents et coûteux^[6].

La parade : chaque nouveau document ou processus IA doit être rattaché à un document ou processus SMSI existant. Si vous ne trouvez pas le point de rattachement, c'est probablement que le document n'est pas nécessaire sous cette forme.

Exemple concret : banque cantonale et détection de fraude

Prenons le cas fictif d'une banque cantonale romande, déjà certifiée ISO 27001, qui utilise un système d'IA pour la détection de fraude sur les transactions. Ce scénario s'inspire directement d'un cas de figure décrit par SGS pour le secteur financier^[3].

Avec l'ISO 27001 en place, la banque protège déjà les données clients, dispose de contrôles d'accès et d'un processus de réponse aux incidents. En intégrant l'ISO 42001, elle ajoute trois dimensions : l'évaluation de l'équité et de l'explicabilité du modèle de détection de fraude, un processus d'approbation contrôlé pour les modifications du modèle, et le traitement des incidents liés à l'IA via les processus de gestion des incidents existants^[3].

Les mêmes registres d'actifs, les mêmes appréciations des risques et les mêmes workflows de réponse sont réutilisés. Il n'y a pas de duplication, seulement une extension^[3]. Le modèle de détection de fraude est inscrit dans l'inventaire des actifs avec sa lignée de données, son propriétaire, ses limites connues et son historique de versions^[6].

Si le modèle produit un faux positif systématique sur un segment de clientèle, cet événement est traité comme un incident dans le processus existant, avec une escalade vers le sous-comité risques IA pour analyse de biais. La banque n'a pas créé un deuxième système de gestion des incidents. Elle a étendu le premier.

Questions fréquentes

À lire ensuite