Outils · ISO 27001 → ISO 42001

Ce que votre système ISO 27001
vous évite de refaire.

Clause par clause, puis domaine par domaine : ce qui se réutilise, ce qui s'étend et ce qui reste à construire, selon ce que votre système fait réellement. Le résultat compte des exigences, pas des jours, et ne reprend aucun des pourcentages qui circulent.

Ce que le calculateur classe

Les 34 groupes d'exigences que vérifie la checklist d'audit interne : 25 pour les clauses 4 à 10, 9 pour les domaines de l'Annexe A. Chacun reçoit l'un de trois classements.

Se réutilise : le dispositif ISO 27001 fonctionne tel quel et reçoit un contenu propre à l'IA, comme l'audit interne. S'étend : l'appui existe mais ne suffit pas, comme la méthode d'appréciation des risques, dont l'objet change. À construire : rien n'y correspond dans ISO 27001, comme l'évaluation d'impact — ou le dispositif qui aurait servi d'appui n'a pas encore fonctionné chez vous.

Pourquoi aucun pourcentage

Des pourcentages circulent, présentés comme la part des contrôles réutilisables ou le temps économisé. Ils viennent de prestataires, se contredisent d'une source à l'autre et ne documentent pas leur méthode. Ce calculateur n'en reprend aucun.

Il compte des exigences, et un compte d'exigences n'est pas une charge de travail. Le travail propre à l'IA est à peu près le même avec ou sans ISO 27001, et il se répète système par système : cinq systèmes en périmètre demandent cinq évaluations d'impact. C'est pourquoi le calculateur demande leur nombre.

Ce que le résultat ne dit pas

Il ne dit pas que vos preuves ISO 27001 suffiront. Le classement est éditorial : il n'existe pas de correspondance officielle entre les deux normes, et il suit l'analyse des deux référentiels publiée sur ce site. Une accréditation ISO 27001 ne vaut pas non plus pour ISO 42001 : l'audit se prépare avec un organisme accrédité pour cette norme.

Vos réponses restent dans votre navigateur. Rien n'est transmis, sauf le nombre de systèmes d'IA et le statut de votre système ISO 27001 si vous demandez le plan de transition.

Le classement de référence

Pour un système ISO 27001 certifié, dont toutes les mesures d'appui s'appliquent déjà aux équipes qui travaillent sur l'IA. Le calculateur part de ce classement, puis retire l'appui de ce qui n'a pas encore fonctionné chez vous.

Les clauses 4 à 10

Exigence	Classement	Ce qui change
4.1 Contexte de l'organisme	S'étend	Ajouter à l'analyse les enjeux propres à l'IA, et déterminer le rôle de l'organisation vis-à-vis de ses systèmes, que la sécurité ne pose pas.
4.2 Parties intéressées	S'étend	Ajouter les personnes et les groupes qui subissent les décisions des systèmes, et leurs attentes.
4.3 Périmètre	S'étend	Fonder le périmètre sur un inventaire des systèmes d'IA, qui n'est pas un inventaire d'actifs informationnels.
4.4 Système de management	S'étend	Le même système de management, décrit par écrit avec ses processus et leurs articulations : y ajouter ceux que l'IA demande, comme l'évaluation d'impact.
5.1 Leadership et engagement	S'étend	Le même engagement de la direction, porté sur l'IA : des ressources allouées, et l'IA traitée en revue.
5.2 Politique	S'étend	Une politique IA distincte est exigée, articulée avec la politique de sécurité plutôt que dupliquée.
5.3 Rôles et responsabilités	S'étend	Attribuer les responsabilités du système de management de l'IA, en s'appuyant sur l'organisation en place.
6.1.1 Risques et opportunités	S'étend	Déterminer les risques et opportunités au regard de l'usage prévu des systèmes et de leur contexte d'application, avec des critères de risque qui servent aussi à apprécier les impacts.
6.1.2 Appréciation des risques	S'étend	Les échelles, la matrice et la gouvernance du risque se réutilisent. Les critères, l'objet et les conséquences à apprécier changent : les personnes et la société, et pas seulement l'organisation.
6.1.3 Traitement des risques	S'étend	Même mécanique de traitement, et une seconde déclaration d'applicabilité, sur les contrôles nécessaires, ceux de l'Annexe A d'ISO/IEC 42001 comme ceux qu'on y ajoute, tenue cohérente avec la première.
6.1.4 Évaluation d'impact	Nouveau	Écrire le processus, puis évaluer les conséquences de chaque système pour les personnes, les groupes et la société. ISO/IEC 27001 n'a aucun équivalent.
6.2 Objectifs	S'étend	Fixer des objectifs relatifs à l'IA, planifiés et suivis avec le même dispositif.
6.3 Planification des changements	Se réutilise	Le même dispositif, appliqué aux changements du système de management de l'IA.
7.2 Compétences	S'étend	Ajouter à la matrice les compétences propres à l'IA — données, modèles, évaluation d'impact —, attestées de la même façon.
7.3 Sensibilisation	S'étend	Sensibiliser à la politique IA, y compris les personnes qui utilisent les systèmes, au-delà des équipes techniques.
7.5 Informations documentées	Se réutilise	Même nomenclature, validation, gestion des versions et conservation : seul le corpus s'agrandit.
8.1 Planification et maîtrise opérationnelles	S'étend	Maîtriser aussi le cycle de vie des systèmes d'IA — nouvelle version de modèle, réentraînement, nouvel usage — et les services d'IA fournis par l'extérieur.
8.2 Appréciation des risques en fonctionnement	S'étend	Le même calendrier de réappréciation, étendu aux risques liés à l'IA : à intervalles planifiés et lors des changements significatifs, envisagés ou survenus, chaque résultat conservé.
8.3 Mise en œuvre du traitement des risques	S'étend	Le suivi du plan de traitement se réutilise ; il porte désormais sur les risques liés à l'IA, et mesure l'effet obtenu.
8.4 Évaluation d'impact en fonctionnement	Nouveau	Refaire l'évaluation d'impact de chaque système à intervalles planifiés, et quand un changement significatif est envisagé, en conservant chaque résultat.
9.1 Surveillance et mesure	S'étend	Ajouter des indicateurs sur les systèmes d'IA et sur les objectifs qui les concernent.
9.2 Audit interne	Se réutilise	Un programme unique, qui couvre les deux périmètres, avec des auditeurs formés aux exigences propres à l'IA.
9.3 Revue de direction	Se réutilise	Une seule revue peut couvrir les deux systèmes, si chaque entrée fixée par 9.3.2 y est aussi examinée pour l'IA. L'état des risques et les évaluations d'impact n'en font pas partie : les présenter est souvent utile, par choix de l'organisation.
10.1 Amélioration continue	Se réutilise	Le même suivi des actions d'amélioration, alimenté aussi par ce qui concerne l'IA.
10.2 Non-conformités et actions correctives	Se réutilise	Un registre unique, et le même examen d'efficacité des actions.

Les domaines de l'Annexe A

Domaine	Point d'appui dans ISO/IEC 27001:2022	Classement	Ce qui change
A.2 Politiques relatives à l'IA	A.5.1, politiques de sécurité	S'étend	La politique IA renvoie aux politiques de sécurité existantes, sans les dupliquer.
A.3 Organisation interne	A.5.2, fonctions et responsabilités ; A.6.8, signalement des événements	S'étend	Ajouter les rôles propres à l'IA, et un canal pour signaler les préoccupations sur les systèmes, qui ne sont pas des événements de sécurité.
A.4 Ressources des systèmes d'IA	A.5.9, inventaire des actifs, en partie	Largement nouveau	Inventorier, système par système, les données, les outils, les modèles et les compétences : l'inventaire des actifs n'en donne qu'une partie.
A.5 Évaluation des impacts	Aucun	Nouveau	Les contrôles qui encadrent l'évaluation d'impact de chaque système : processus, documentation, individus, groupes et société.
A.6 Cycle de vie des systèmes d'IA	A.8.25, cycle de développement sécurisé ; A.8.15, journalisation	S'étend et nouveau	Spécifier, vérifier, valider, déployer et surveiller chaque système, au-delà du développement sécurisé ; déterminer à quelles étapes du cycle de vie tenir des journaux d'événements (A.6.2.8, qui recommande au moins la phase d'utilisation). En pratique, on les conçoit pour pouvoir reconstituer une décision, ce qu'un journal de sécurité ne permet pas.
A.7 Données pour les systèmes d'IA	A.5.34, vie privée ; A.8.10 à A.8.12, suppression, masquage et fuite de données	Largement nouveau	Qualité, provenance et préparation des données : un autre sujet que leur protection.
A.8 Information des parties intéressées	A.5.24 à A.5.28, gestion des incidents, pour la seule communication des incidents	Largement nouveau	Documenter chaque système et ses limites pour ses utilisateurs, permettre de signaler ses effets négatifs et relever par écrit les obligations d'information envers les parties intéressées (A.8.5) ; seule la communication des incidents s'appuie sur l'existant.
A.9 Utilisation des systèmes d'IA	Aucun	Nouveau	Écrire des processus et des objectifs d'usage responsable, puis vérifier que chaque système sert ses usages prévus, conformément à sa documentation.
A.10 Tiers et clients	A.5.19 à A.5.22, relations avec les fournisseurs	S'étend	Faire entrer l'IA dans le processus fournisseurs que demande A.10.3, pour que l'usage fait de ce qu'ils fournissent reste aligné sur l'approche responsable de l'organisation — en pratique, des questions sur l'usage des données pour l'entraînement, la politique de version, la dépréciation —, et répartir les responsabilités avec chaque partie, clients compris (A.10.2).