ISO 27001 et ISO 27090 mises en œuvre ensemble — la sécurité de l’IA dans un seul SMSI

L’ISO/IEC 27001 est une norme d’exigences : elle définit ce qu’un système de management de la sécurité de l’information doit accomplir, et elle est de ce fait certifiable. L’ISO/IEC 27090 est une norme d’orientation : elle décrit les menaces qui visent spécifiquement les systèmes d’IA, comment les détecter et comment s’en défendre. Elle n’exige pas de système de management propre, mais s’appuie sur la pratique établie de l’ISO/IEC 27001 et de l’ISO/IEC 27002 — deux phrases formulées de manière contraignante dans sa section de principes demandent de mettre en œuvre des mesures de sécurité de l’information selon une approche fondée sur les risques et de prendre en compte les compromissions propres à l’IA sur l’ensemble du cycle de vie.

Deux points d’ancrage portent tout le modèle

Premièrement, l’appréciation des risques : les neuf types de compromission sont évalués pour chaque système d’IA du domaine d’application — dans le même registre et avec la même méthode que tous les autres risques de sécurité de l’information. Deuxièmement, la déclaration d’applicabilité : l’ISO/IEC 27001 admet des mesures de toute provenance et exige de les comparer avec l’annexe A. Les recommandations de défense de l’ISO/IEC 27090 deviennent ainsi des mesures du SMSI, qui sont mises en œuvre, surveillées, auditées et examinées lors de l’audit de certification.

• Pas de second système de management, pas de seconde méthode d’appréciation des risques, pas de seconde maîtrise documentaire
• Chaque mesure une seule fois, avec correspondances multiples — vers l’annexe A, l’ISO/IEC 27090 et, si nécessaire, l’ISO/IEC 42001 ou l’AI Act
• L’audit interne, la revue de direction et l’audit de certification couvrent aussi les mesures IA
• Les organisations qui n’ont pas encore de SMSI construisent le SMSI et le profil IA en un seul projet

Des analyses séparées entraînent des entretiens en double et des résultats contradictoires. C’est pourquoi nous examinons une seule fois chaque exigence des articles 4 à 10 et chaque mesure pertinente de l’annexe A — en évaluant au passage si la déclinaison IA est couverte. S’y ajoute l’examen des contenus propres à l’IA de l’ISO/IEC 27090 qui n’ont pas d’équivalent direct dans l’ISO/IEC 27001 : les neuf types de compromission, le Zero Trust pour les modèles et les agents, le red teaming, les interactions entre mesures et la baisse de leur efficacité dans le temps.

1. 1
   Cadrage et contexte

   Lancement avec la direction et l’équipe SMSI : objectifs de l’initiative — certificat, exigences des clients ou AI Act —, domaine d’application provisoire, parties intéressées ayant des exigences en matière d’IA.

2. 2
   Inventaire de l’IA

   Recenser tous les systèmes d’IA — développés en interne, exploités dans votre propre tenant, utilisés sous forme d’API ou de SaaS ou intégrés à des logiciels standard ; le recoupement avec les achats, le parc de licences, les dépôts de code et les données réseau révèle l’IA fantôme (shadow AI).

3. 3
   Revue documentaire

   Politique, méthode d’appréciation des risques, registre des risques, déclaration d’applicabilité, descriptions de processus, évaluations des fournisseurs et politiques IA existantes.

4. 4
   Entretiens et échantillons

   RSSI et équipe SMSI, exploitation informatique, ingénierie ML et data science, développement logiciel, achats, protection des données et métiers ; échantillons techniques portant sur les droits d’accès aux modèles et aux données, la journalisation et les filtres d’entrée et de sortie.

5. 5
   Évaluation par niveaux de maturité

   Chaque exigence sur quatre niveaux, de « inexistant » à « efficace et vérifié » — avec une double évaluation pour l’exigence du SMSI et pour sa déclinaison IA.

6. 6
   Registre des écarts et synthèse pour la direction

   Écarts avec risque, charge, responsables et priorité ; carte de chaleur par article de la norme et par système d’IA ; les dix principaux écarts pour la direction.

Ce que livre l’analyse d’écarts

• Première version de l’inventaire IA avec propriétaires et criticité
• Registre des écarts ISO/IEC 27001 × ISO/IEC 27090 avec niveaux de maturité
• Évaluation de la pertinence des neuf types de compromission pour chaque système d’IA
• Carte de chaleur et synthèse pour la direction avec priorités et estimation sommaire de la charge
• Recommandation sur le domaine d’application et le parcours de certification

Le point de départ est l’appréciation des risques : pour chaque système d’IA du domaine d’application, les types de compromission pertinents sont évalués selon leur vraisemblance et leurs conséquences. Le traitement des risques choisit ensuite les mesures — dans l’annexe A, dans l’ISO/IEC 27090 ou par dérivation propre — et les compare avec l’annexe A afin qu’aucune mesure nécessaire ne manque. Il en résulte une déclaration d’applicabilité étendue qui indique, pour chaque mesure, sa source, sa justification et son état de mise en œuvre.

Deux voies vers la déclaration d’applicabilité

Prioriser plutôt que tout faire en même temps

• D’abord les mesures sans regret : inventaire IA, propriétaires, protection des accès, journalisation, règles d’utilisation de l’IA générative
• Ensuite selon le risque : les systèmes d’IA les plus critiques et les types de compromission jugés élevés
• Tenir compte des échéances : audits clients, prochain audit de surveillance, obligations de l’AI Act relatives à l’IA à haut risque à partir de décembre 2027
• Faire accepter formellement les risques résiduels par les propriétaires des risques — et non par l’équipe projet

L’ISO/IEC 27001 exige que les modifications du SMSI soient réalisées de manière planifiée — l’extension IA est une telle modification ; la bonne pratique consiste à définir à l’avance l’objectif, les conséquences possibles, les ressources et les responsabilités. Cela protège un certificat existant, puisque le SMSI reste opérationnel pendant la transformation, et donne une structure claire à une construction nouvelle. Le concept couvre l’organisation de projet, les lots de travail, les dépendances, le budget, la communication et les indicateurs.

Feuille de route par vagues

1. 1
   Vague 0 · semaines 1 à 4Mandat et mesures immédiates

   Confirmer le domaine d’application, compléter l’inventaire IA, désigner les propriétaires, publier les règles d’utilisation de l’IA générative, assainir les accès aux modèles et aux données, activer la journalisation pour les systèmes les plus critiques.

2. 2
   Vague 1 · mois 2 à 4Gouvernance et méthode

   Adopter la politique et la politique de sécurité de l’IA, lancer le plan de traitement des risques issu de la phase 2, définir les exigences envers les fournisseurs.

3. 3
   Vague 2 · mois 3 à 8Mesures techniques

   Zero Trust pour les données, les modèles et les agents, contrôles des entrées et des sorties, protection de l’environnement de développement, surveillance et limitation du débit, red teaming des systèmes les plus critiques.

4. 4
   Vague 3 · mois 6 à 10Migration et formation

   Migrer les processus et les données, former par public cible, mesurer les indicateurs, collecter les preuves.

5. 5
   Vague 4 · mois 9 à 12Vérifier et décider

   Audit interne, actions correctives, revue de direction et décision sur l’audit de certification.

Les durées sont des valeurs indicatives issues de projets pour une construction conjointe portant sur un nombre limité de systèmes d’IA. Avec un SMSI existant et certifié, une grande partie des vagues 1 et 4 devient sans objet — l’extension IA peut alors souvent être intégrée d’ici le prochain audit de surveillance.

Indicateurs de pilotage

• Part des systèmes d’IA disposant d’un propriétaire, d’une appréciation des risques et d’une entrée dans la déclaration d’applicabilité
• Part des systèmes d’IA critiques dotés d’une journalisation de l’inférence et d’une surveillance
• Constats ouverts issus du red teaming et des audits, par ancienneté et gravité
• Taux de formation par public cible
• Respect des délais des lots de travail par rapport à la feuille de route

Sur le plan organisationnel, la mise en œuvre commence par des règles qui concernent tout le monde : la politique complétée par l’IA, les règles d’utilisation de l’IA générative, la classification des données d’entraînement, de prompt et de sortie, et une procédure de changement qui traite les changements de modèle, les réentraînements et les modifications des prompts système ou des sources de récupération comme des modifications logicielles. Sur le plan technique, la mise en œuvre suit les types de compromission jugés élevés lors de l’appréciation des risques.

Le Zero Trust comme fil conducteur

L’ISO/IEC 27090 transpose à l’IA les principes Zero Trust que l’ISO/IEC 27002 décrit pour les architectures de systèmes sécurisées : les accès aux données d’entraînement, aux modèles et aux sources de récupération sont authentifiés et autorisés individuellement, les applications d’IA reçoivent des frontières claires, les actions des agents d’IA sont contrôlées individuellement, les droits ne sont accordés que pour la tâche et pour une durée limitée, et le comportement des systèmes est surveillé en continu. Ces principes traversent toutes les recommandations de défense de la norme.

Preuves à collecter dès maintenant

• Politiques et règles d’utilisation approuvées avec numéro de version
• Configurations et concepts d’habilitation pour les modèles, les données et les agents
• Preuves de journalisation et de surveillance avec exemples d’analyses
• Rapports de test issus du red teaming et des tests de recette avec traitement des constats
• Tickets de changement pour les changements de modèle et les réentraînements, avec revalidation

La migration comporte deux niveaux. Au niveau des processus, les processus existants du SMSI prennent en charge les cas liés à l’IA, au lieu qu’un univers de processus IA distinct se crée à côté du SMSI. Au niveau des données, les registres, mesures et preuves sont transférés depuis des tableurs, des wikis et d’anciens outils vers un modèle de données consolidé dans lequel chaque mesure n’existe qu’une seule fois et renvoie à plusieurs référentiels.

Migration des données en cinq étapes

1. 1
   Recensement

   Quels registres, listes de mesures, preuves et constats d’audit existent, où — et avec quelle qualité ?

2. 2
   Modèle de données cible

   Un modèle couvrant actifs, risques, mesures, preuves et fournisseurs, avec correspondances multiples vers l’ISO/IEC 27001, l’ISO/IEC 27090 et, si nécessaire, l’ISO/IEC 42001, l’AI Act, NIS 2 ou DORA.

3. 3
   Nettoyage

   Fusionner les doublons, compléter propriétaires et dates de validité, clarifier les mesures orphelines — tout l’héritage ne mérite pas d’être migré.

4. 4
   Essai à blanc et recette

   Migration de test avec échantillons, recette par les responsables métier, rapprochement des volumes.

5. 5
   Bascule et archivage

   Date de bascule, courte exploitation en parallèle, archivage des données historiques dans le respect des obligations de conservation — l’historique des preuves doit être préservé pour le prochain audit.

Les contenus découlent des types de compromission et des mesures définis en phase 2 — c’est pourquoi ils diffèrent nettement selon les rôles. Une formation unique pour tous manque aussi bien la direction générale, qui doit évaluer les risques et débloquer des ressources, que l’ingénierie ML, qui doit prévenir des attaques concrètes contre les données et les modèles.

Démontrer l’efficacité

• Profil de compétences par rôle, avec niveau cible et niveau actuel
• Preuves de participation et courts tests de connaissances
• Preuves pratiques, comme des scénarios d’exercice réussis
• Indicateurs en revue de direction : taux de formation par public cible, signalements d’anomalies

L’ISO/IEC 27001 exige des audits internes à intervalles planifiés, un programme d’audit précisant fréquence, méthodes, responsabilités et modalités de compte rendu, ainsi que des auditeurs objectifs et impartiaux. Les lignes directrices en la matière sont l’ISO 19011 pour les audits de systèmes de management et l’ISO/IEC 27007 pour les audits de SMSI. Le référentiel d’audit est l’ISO/IEC 27001 ainsi que les exigences propres de l’organisation — pour les mesures IA, donc, la déclaration d’applicabilité. L’ISO/IEC 27090 n’est pas un référentiel d’audit ; elle agit à travers les mesures que vous en avez reprises.

Questions d’audit typiques liées à l’IA

• Tous les systèmes d’IA en production figurent-ils dans l’inventaire — et l’inventaire concorde-t-il avec les achats et les données réseau ?
• Existe-t-il, pour chaque système d’IA du domaine d’application, une appréciation des risques à jour couvrant les types de compromission pertinents ?
• Les droits d’accès aux modèles, aux données d’entraînement et aux sources de récupération sont-ils conformes au concept d’habilitation ? Échantillon tiré des habilitations.
• Les entrées et sorties, la version du modèle et les appels d’outils sont-ils journalisés et analysés ? Échantillon tiré des journaux.
• Le dernier changement de modèle a-t-il été précédé de tests et d’une revalidation ? Échantillon tiré des tickets de changement.
• Les constats du red teaming sont-ils traités et suivis ?
• Les fournisseurs de modèles sont-ils évalués et engagés contractuellement ?

L’ISO/IEC 27001 définit ce que la direction doit examiner à intervalles planifiés : l’état d’avancement des actions décidées lors des revues de direction précédentes, les modifications des enjeux internes et externes ainsi que des besoins et attentes des parties intéressées, les retours sur les performances de sécurité de l’information — non-conformités, résultats de surveillance, de mesure et d’audit, atteinte des objectifs —, les retours des parties intéressées, les résultats de l’appréciation des risques et l’état du traitement des risques, ainsi que les opportunités d’amélioration. Elle débouche sur des décisions documentées.

Décisions qui devraient figurer au compte rendu

• Appétence au risque pour l’IA et acceptation des risques résiduels pour les systèmes les plus critiques
• Ressources pour les prochaines vagues de la feuille de route
• Ajustements du domaine d’application en cas de nouveaux systèmes d’IA
• Go ou no-go pour l’audit de certification
• Objectifs et indicateurs pour le prochain cycle

1. 1
   Choix de l’organisme de certification

   Choisir un organisme accrédité — en Allemagne, accrédité par la DAkkS ; convenir du domaine d’application, des sites et de la durée d’audit. Les exigences applicables aux organismes sont définies par l’ISO/IEC 17021-1 et l’ISO/IEC 27006-1.

2. 2
   Audit d’étape 1

   Examen de la documentation et de l’aptitude à la certification : domaine d’application incluant les systèmes d’IA, appréciation des risques, déclaration d’applicabilité, planification et réalisation de l’audit interne et de la revue de direction.

3. 3
   Audit d’étape 2

   Évaluation de l’efficacité sur site : entretiens, visites et échantillons — pour les systèmes d’IA, par exemple concepts d’habilitation, journaux, rapports de test et preuves de gestion des changements.

4. 4
   Actions correctives et décision

   Les non-conformités sont corrigées dans les délais fixés par l’organisme de certification ; l’organisme statue ensuite sur la certification.

5. 5
   Certificat et cycle

   Le certificat est valable trois ans ; des audits de surveillance ont lieu les années suivantes, puis le renouvellement de la certification. Les nouveaux systèmes d’IA sont intégrés via le domaine d’application et la déclaration d’applicabilité.

Ce que dit le certificat — et ce qu’il ne dit pas

Le certificat atteste un SMSI conforme à l’ISO/IEC 27001 pour un domaine d’application décrit. Si celui-ci inclut les systèmes d’IA, leur sécurité fait partie du système de management certifié. Le certificat ne porte pas la mention « certifié selon l’ISO/IEC 27090 », et la communication ne doit pas non plus en donner l’impression. Formulation correcte : « SMSI certifié selon l’ISO/IEC 27001 ; les mesures applicables à nos systèmes d’IA s’inspirent de l’ISO/IEC 27090. »

Optionnel : audit combiné avec l’ISO/IEC 42001

Les organisations qui souhaitent en outre démontrer le management de l’IA dans son ensemble — évaluation d’impact, responsabilités, cycle de vie, qualité des données — peuvent intégrer un système de management de l’IA selon l’ISO/IEC 42001. Les deux normes suivent la même structure harmonisée ; des audits combinés sont possibles. À noter : au 22 octobre 2026, aucun organisme de certification accrédité par la DAkkS pour l’ISO/IEC 42001 n’était répertorié en Allemagne ; les offres s’appuyant sur une accréditation délivrée par d’autres organismes d’accréditation doivent être examinées au cas par cas.

Sept erreurs que nous constatons souvent

• Un second registre ou un système de management de l’IA distinct à côté du SMSI — double maintenance, évaluations contradictoires
• ISO/IEC 27090 cochée comme une check-list au lieu d’être priorisée via l’appréciation des risques
• IA fantôme dans les logiciels standard et le SaaS ignorée
• Protection reposant uniquement sur des règles de prompt plutôt que sur des droits, des validations et l’isolation
• Pas de journalisation de l’inférence — incidents inaperçus, audits sans preuves
• Migration juste avant l’audit, l’historique des preuves est perdu
• Communication du type « certifié ISO 27090 » — trompeuse et attaquable au titre du droit de la concurrence

Facteurs de succès

• Mandat visible de la direction, avec une appétence au risque définie pour l’IA
• Un propriétaire par système d’IA au sein des métiers, pas seulement dans l’informatique
• Un seul modèle de données, multi-référentiel
• Des mesures sans regret précoces pour des effets rapides
• Le red teaming comme preuve d’efficacité
• Des formations par public cible plutôt qu’un cours unique