Introduction
Les systèmes d’IA sont entrés dans les processus métier par la voie applicative : assistants internes, moteurs de recherche augmentée, copilotes de développement, agents connectés aux applications d’entreprise. Chacun de ces composants consomme des informations classifiées, détient des accès techniques et produit des sorties utilisées pour décider. Le système de management de la sécurité de l’information hérite donc d’un périmètre nouveau, avec des actifs, des flux et des modes de défaillance qui appellent des contrôles spécifiques.
Cet article détaille l’articulation entre ISO/IEC 27001 et le corpus normatif dédié à l’IA, la surface d’attaque propre aux systèmes à base de modèles, et les mécanismes de gouvernance à mettre en place sur le cycle de vie.
Le référentiel reste ISO/IEC 27001:2022, le périmètre évolue
Aucune édition ISO/IEC 27001:2026 n’existe. La norme applicable demeure ISO/IEC 27001:2022, avec les exigences relatives à l’établissement, la mise en œuvre, le maintien et l’amélioration continue d’un SMSI.
L’évolution porte sur l’inventaire à couvrir. Une architecture intégrant de l’IA ajoute aux actifs traditionnels :
- des modèles internes et des modèles tiers consommés par API ;
- des jeux de données d’entraînement, de fine tuning et d’évaluation ;
- des bases vectorielles et des index de récupération documentaire ;
- des pipelines MLOps, registres de modèles et artefacts de poids ;
- des prompts système, gabarits et jeux de règles conversationnelles ;
- des connecteurs, serveurs d’outils et espaces de mémoire persistante ;
- des agents disposant de droits d’exécution sur des applications métier ;
- des usages non déclarés dans les navigateurs et postes de travail.
Ce périmètre reste traitable par les mécanismes déjà exigés par la norme. Plusieurs mesures de l’Annexe A s’appliquent directement :
| Mesure Annexe A | Application aux systèmes d’IA |
|---|---|
| A.5.9 Inventaire des actifs | Registre des systèmes, modèles, jeux de données et index vectoriels avec propriétaire désigné |
| A.5.19 à A.5.23 Fournisseurs et services cloud | Qualification des fournisseurs de modèles, clauses de réversibilité, localisation et rétention des données |
| A.5.12 Classification | Classification des corpus indexés et alignement des droits de lecture |
| A.8.2 et A.8.3 Droits d’accès privilégiés | Comptes de service des agents, portée des jetons, durée de vie des secrets |
| A.8.15 et A.8.16 Journalisation et surveillance | Traçabilité des requêtes, des documents récupérés et des appels d’outils |
| A.8.25 à A.8.31 Développement sécurisé | Séparation des environnements, tests de sécurité des pipelines, revue des dépendances |
| A.5.7 Renseignement sur les menaces | Veille sur les vulnérabilités des modèles, des frameworks d’orchestration et des connecteurs |
Un SMSI mature dispose donc déjà de la majeure partie de l’infrastructure de contrôle nécessaire. L’effort porte sur l’extension du périmètre et sur l’ajout de contrôles propres au comportement des modèles.
Ce qu’ISO 27001 traite et ce qu’elle laisse ouvert
ISO/IEC 27001 traite les risques rapportés à la confidentialité, à l’intégrité et à la disponibilité de l’information. Appliquée à un assistant interne, elle encadre efficacement les droits d’accès, les secrets, les comptes techniques, la journalisation, la sécurité des infrastructures, la relation fournisseur, la gestion des incidents et la continuité.
D’autres modes de défaillance relèvent d’un autre registre. Un système peut satisfaire l’ensemble des contrôles SSI et produire simultanément :
- des réponses factuellement erronées présentées avec un niveau de confiance élevé ;
- des sorties discriminantes sur certaines populations ;
- une dégradation progressive de performance liée à l’évolution des données d’entrée ;
- un usage détourné vers une finalité différente de celle autorisée ;
- une recommandation dont la justification reste inaccessible à l’utilisateur ;
- une action exécutée au-delà du niveau d’autonomie prévu par le propriétaire du processus.
Ces phénomènes concernent l’exactitude, l’équité, l’explicabilité, la stabilité dans le temps et l’autorité déléguée. La sécurisation du système et la gouvernance de son comportement constituent deux chantiers complémentaires, portés par des référentiels distincts.
Architecture normative : 27001, 42001, 23894, 42005, 5259
| Référentiel | Objet | Fonction dans l’architecture |
|---|---|---|
| ISO/IEC 27001:2022 | Sécurité de l’information | Structurer le SMSI et maîtriser les risques SSI portant sur les actifs IA |
| ISO/IEC 42001:2023 | Management de l’IA | Définir politiques, rôles, objectifs et processus de gouvernance des systèmes d’IA |
| ISO/IEC 23894:2023 | Management du risque IA | Identifier, analyser et traiter les risques propres aux systèmes d’IA |
| ISO/IEC 42005:2025 | Évaluation d’impact | Documenter les impacts sur les personnes, les groupes et la société sur tout le cycle de vie |
| ISO/IEC 5259-5:2025 | Gouvernance de la qualité des données | Piloter la qualité des données d’analytique et de ML sur l’ensemble du cycle de vie des données |
ISO/IEC 42001 fournit le système de management. ISO/IEC 23894 alimente l’analyse de risque. ISO/IEC 42005 traite l’évaluation d’impact des systèmes d’IA. La série ISO/IEC 5259 couvre la qualité et la gouvernance des données, avec une partie 5 publiée en 2025 consacrée au cadre de gouvernance destiné aux organes de direction.
Deux référentiels techniques complètent utilement cet ensemble pour les équipes sécurité : le NIST AI Risk Management Framework 1.0 pour la structuration des fonctions Govern, Map, Measure et Manage, et MITRE ATLAS pour la modélisation des tactiques et techniques d’attaque visant les systèmes à base d’apprentissage.
Surface d’attaque des systèmes à base de modèles
Le OWASP Top 10 for LLM Applications fournit la base de travail la plus directement exploitable par une équipe sécurité. Les vecteurs suivants structurent la plupart des scénarios de menace observés en entreprise.
Injection de prompt indirecte. Une instruction hostile est déposée dans un document, une page web ou un ticket, puis récupérée par le pipeline RAG et interprétée comme une consigne. Le contrôle porte sur la séparation stricte entre instructions système et contenu récupéré, sur le filtrage des sources indexées et sur la limitation des actions déclenchables par le contenu.
Exfiltration via la couche de récupération. Un index vectoriel construit sans reprise du modèle d’habilitation expose à un utilisateur des extraits de documents auxquels son compte n’ouvre aucun droit. Le contrôle consiste à appliquer le filtrage d’autorisation au moment de la requête, sur les métadonnées de chaque fragment indexé.
Empoisonnement de données. Une altération des corpus d’entraînement, de fine tuning ou d’indexation modifie durablement le comportement du système. Le contrôle repose sur la provenance vérifiée, l’intégrité cryptographique des jeux de données et la revue des sources ouvertes à l’ingestion automatique.
Chaîne d’approvisionnement des modèles. Les poids, adaptateurs, bibliothèques d’orchestration et extensions tierces constituent des dépendances au même titre que les paquets logiciels. Le contrôle passe par la traçabilité des artefacts, l’interdiction des formats de sérialisation exécutables et l’inventaire des composants.
Abus d’outillage par les agents. Un agent disposant de droits d’écriture sur une application métier transforme une erreur de raisonnement en action irréversible. Le contrôle relève du moindre privilège, de la validation humaine des opérations sensibles et de la révocabilité immédiate des jetons.
Fuite par les traces. Prompts, sorties et documents récupérés transitent par des systèmes de journalisation, des outils d’observabilité et parfois des services tiers. Le contrôle impose une classification des journaux, une politique de rétention et une restriction d’accès équivalente à celle des données sources.
La conformité devient une propriété à maintenir
Les systèmes d’IA évoluent après leur mise en production. Le fournisseur remplace une version de modèle, les corpus s’enrichissent, les utilisateurs adoptent des usages non anticipés, le contexte métier change. Un niveau de risque accepté au déploiement devient caduc en quelques mois.
Une gouvernance opérationnelle définit donc des déclencheurs explicites de réévaluation :
- changement de version ou de fournisseur de modèle ;
- ajout d’une source documentaire ou d’un connecteur applicatif ;
- extension de la population utilisatrice ou du périmètre fonctionnel ;
- dérive mesurée sur les jeux d’évaluation de référence ;
- incident de sécurité, de qualité ou de conformité ;
- évolution réglementaire ou contractuelle applicable.
Les mécanismes techniques associés relèvent de pratiques familières aux équipes d’ingénierie : versionnement des modèles, des prompts et des configurations, jeux d’évaluation rejoués à chaque changement, télémétrie applicative, détection de dérive, journalisation explicative des décisions, procédure d’escalade et capacité de suspension. La recherche académique converge vers cette lecture. La revue publiée en 2025 dans le Journal of Strategic Information Systems par Papagiannidis, Mikalef et Conboy formalise la gouvernance responsable de l’IA autour de trois dimensions complémentaires : les structures organisationnelles, les relations entre acteurs et les processus opérationnels (doi.org/10.1016/j.jsis.2024.101885).
Agents IA : gouverner l’autorité déléguée
Un assistant conversationnel produit du texte. Un agent consulte des bases documentaires, interroge des applications, génère et transmet des documents, modifie des données et déclenche des traitements. L’objet à gouverner devient le niveau d’autorité accordé au système.
Une échelle d’autonomie explicite facilite l’arbitrage et l’audit :
| Niveau | Capacité | Contrôle associé |
|---|---|---|
| A0 | Suggestion textuelle sans accès système | Journalisation des usages, classification des données saisies |
| A1 | Lecture de sources internes via RAG | Filtrage d’habilitation à la requête, traçabilité des documents récupérés |
| A2 | Écriture réversible dans un périmètre applicatif délimité | Compte de service dédié, portée restreinte, revue a posteriori |
| A3 | Exécution d’actions à effet externe ou irréversible | Validation humaine préalable, séparation des fonctions, kill switch documenté |
Les principes appliqués sont ceux de la sécurité opérationnelle : moindre privilège, séparation des fonctions, identités machine distinctes par cas d’usage, jetons de courte durée, traçabilité des appels d’outils, capacité de révocation immédiate et supervision humaine proportionnée à l’effet des actions.
La gouvernance des données conditionne la gouvernance des modèles
Un système d’IA reste dépendant des informations qui l’alimentent. Le pilotage porte sur la provenance, la qualité, la représentativité, la fraîcheur, les droits d’utilisation, la classification, la traçabilité des transformations et les règles de suppression.
ISO/IEC 5259-5:2025 formalise ce cadre au niveau de la direction, avec des rôles, des contrôles et un pilotage sur l’ensemble du cycle de vie des données. Un programme de gouvernance IA dépourvu de gouvernance explicite des données reste structurellement incomplet, faute de pouvoir démontrer sur quelles bases un système produit ses sorties.
AI Act : état réel du calendrier après le Digital Omnibus
Le règlement (UE) 2024/1689 est entré en vigueur le 1er août 2024, avec une application par vagues (texte officiel). Le paquet Digital Omnibus sur l’IA, adopté par le Parlement européen le 16 juin 2026 par 423 voix pour, 57 contre et 174 abstentions, puis validé par le Conseil de l’Union européenne le 29 juin 2026, modifie le calendrier des obligations relatives aux systèmes à haut risque.
| Échéance | Obligations |
|---|---|
| 2 février 2025 | Pratiques interdites, obligation de maîtrise de l’IA au sein des équipes |
| 2 août 2025 | Obligations applicables aux fournisseurs de modèles à usage général |
| 2 août 2026 | Transparence de l’article 50, pouvoirs de sanction des autorités, gouvernance nationale |
| 2 décembre 2026 | Nouvelles interdictions introduites par le Digital Omnibus |
| 2 décembre 2027 | Systèmes à haut risque de l’annexe III, reportés depuis le 2 août 2026 |
| 2 août 2028 | Systèmes à haut risque de l’annexe I intégrés à des produits réglementés |
Le report concerne le volet haut risque. Les obligations de transparence, les interdictions et le régime de sanction s’appliquent selon le calendrier initial (Commission européenne). Les organisations conservent donc un intérêt opérationnel immédiat à cartographier leurs systèmes, à qualifier leur niveau de risque au regard de l’annexe III et à documenter leurs contrôles, ces travaux conditionnant la capacité à absorber les échéances de 2027 et 2028.
Les sept briques d’un système de gouvernance de l’IA
1. Registre des systèmes et cas d’usage. Finalité, propriétaire métier, propriétaire technique, données consommées, modèles utilisés, fournisseurs, périmètre utilisateur, niveau d’autonomie.
2. Classification du niveau de risque. Critères combinant sensibilité des données, effet des décisions sur les personnes, réversibilité des actions et exposition réglementaire.
3. Gouvernance des données. Origine, droits d’usage, classification, durée de conservation, règles de réutilisation et procédure de retrait d’un corpus indexé.
4. Gouvernance des fournisseurs et des modèles. Localisation et rétention, engagements de version, conditions d’usage des données soumises, réversibilité technique, plan de bascule vers un modèle alternatif.
5. Contrôles avant mise en production. Tests de sécurité applicative, exercices d’injection de prompt, revue des habilitations de la couche de récupération, jeux d’évaluation de référence, évaluation d’impact selon ISO/IEC 42005.
6. Surveillance continue. Télémétrie d’usage, indicateurs de qualité des sorties, détection de dérive, suivi des versions et des incidents, revue périodique du niveau de risque.
7. Mécanismes d’escalade. Seuils de déclenchement, restriction de périmètre, suspension, retrait, responsabilités nommées et procédure de communication.
Pourquoi DEVFORMA recommande une extension du SMSI existant
La création d’une gouvernance IA entièrement parallèle au SMSI multiplie les comités, les registres et les preuves à maintenir. Pour la majorité des organisations disposant déjà d’un SMSI certifié ou en cours de certification, la trajectoire la plus économique consiste à étendre les structures existantes.
Cette trajectoire s’appuie sur quatre étapes :
- intégration des actifs IA dans l’inventaire et dans l’analyse de risque du SMSI ;
- ajout des contrôles spécifiques aux modèles, aux pipelines et aux agents dans la déclaration d’applicabilité ;
- montée en exigence progressive vers un système de management conforme à ISO/IEC 42001 lorsque le nombre de cas d’usage et le niveau d’exposition le justifient ;
- alignement de l’évaluation d’impact et de la documentation sur les attentes du règlement européen.
Les organisations qui procèdent dans cet ordre disposent d’un système auditable, avec une charge documentaire maîtrisée et des responsabilités déjà attribuées.
FAQ
ISO 27001 couvre-t-elle l’intelligence artificielle ?
ISO/IEC 27001 couvre les risques de sécurité de l’information portant sur les actifs liés à l’IA, notamment les accès, les secrets, les infrastructures, les fournisseurs et la journalisation. Les risques liés à l’exactitude, à l’équité, à l’explicabilité et à l’autonomie relèvent d’ISO/IEC 42001, d’ISO/IEC 23894 et d’ISO/IEC 42005.
Quelle différence entre ISO 27001 et ISO 42001 ?
ISO/IEC 27001 spécifie un système de management de la sécurité de l’information. ISO/IEC 42001 spécifie un système de management de l’intelligence artificielle, avec des exigences portant sur la politique IA, les rôles, l’évaluation des risques et des impacts, le cycle de vie des systèmes et la surveillance après déploiement. Les deux normes partagent la structure harmonisée ISO, ce qui autorise un système de management intégré.
Une certification ISO 42001 est-elle obligatoire au titre de l’AI Act ?
Le règlement n’impose aucune certification ISO. Un système de management conforme à ISO/IEC 42001 fournit une base documentaire et organisationnelle directement mobilisable pour démontrer la maîtrise attendue.
Comment sécuriser un système RAG interne ?
Les priorités portent sur la reprise du modèle d’habilitation au niveau de chaque fragment indexé, la séparation entre instructions système et contenu récupéré, le contrôle des sources ingérées, la journalisation des documents renvoyés et la classification des traces.
Qu’est-ce qui déclenche une réévaluation du risque d’un système d’IA ?
Le changement de version ou de fournisseur de modèle, l’ajout d’une source ou d’un connecteur, l’extension du périmètre d’usage, une dérive mesurée sur les jeux d’évaluation, un incident ou une évolution réglementaire.
Le report du Digital Omnibus dispense-t-il d’agir en 2026 ?
Le report concerne les obligations relatives aux systèmes à haut risque. Les obligations de transparence, les interdictions et le régime de sanction s’appliquent depuis le calendrier initial, et les travaux d’inventaire, de qualification et de documentation conditionnent la tenue des échéances de 2027 et 2028.
Conclusion
L’intelligence artificielle occupe simultanément la position d’actif technologique, de dépendance fournisseur, de consommateur de données classifiées, de mécanisme de décision et, dans le cas des agents, de titulaire de privilèges applicatifs. Sa gouvernance se construit à plusieurs niveaux, avec ISO/IEC 27001 comme socle de sécurité, ISO/IEC 42001 comme système de management dédié, ISO/IEC 23894 pour le risque, ISO/IEC 42005 pour l’impact et la série ISO/IEC 5259 pour les données.
L’indicateur de maturité tient dans la capacité à démontrer, à tout moment et pour chaque système, quelles données l’alimentent, quels droits il détient, quelles actions il peut exécuter, comment son comportement est surveillé et qui dispose de l’autorité pour l’interrompre.
Formations DEVFORMA associées
- ISO/IEC 27001 Lead Implementer : construire et piloter un SMSI.
- ISO/IEC 27001 Lead Auditor : auditer un système de management de la sécurité de l’information.
- ISO/IEC 42001 Lead Implementer : déployer un système de management de l’IA.
- ISO/IEC 42001 Lead Auditor : évaluer la conformité d’un système de management de l’IA.
- ISO/IEC 27005 Risk Manager : structurer l’appréciation des risques.
- EBIOS Risk Manager : conduire une analyse de risque par scénarios.
