ISO 27090 : Comprendre le futur standard de cybersécurité pour les Systèmes d'IA

L'intelligence artificielle redessine le périmètre de la cybersécurité. Face à des systèmes capables d'apprendre, de raisonner et d'agir de façon autonome, les approches traditionnelles ne suffisent plus. C'est dans ce contexte qu'émerge la norme ISO/IEC 27090— actuellement au stade FDIS (Final Draft International Standard) depuis juillet 2025, soit l'étape précédant sa publication officielle. Un cadre de référence conçu spécifiquement pour traiter les menaces et les défaillances propres aux systèmes d'IA.

Que vous soyez RSSI, fournisseur de solutions IA ou responsable conformité, cet article vous donne les clés pour comprendre ses apports et anticiper son intégration dans votre stratégie de sécurité.

Pourquoi la cybersécurité classique ne suffit plus face à l'IA

La cybersécurité repose historiquement sur trois piliers fondamentaux : confidentialité, intégrité et disponibilité (le triptyque CID). Ces principes ont structuré des décennies de bonnes pratiques, de la gestion des accès jusqu'aux plans de continuité d'activité.

Mais l'IA change profondément la donne. Les organisations déploient massivement des assistants conversationnels (ChatGPT, Copilot), des agents autonomes, des architectures RAG (Retrieval-Augmented Generation), des systèmes de recommandation et des pipelines de machine learning. Ces systèmes ne sont plus de simples logiciels : ils apprennent à partir de données, interagissent avec les utilisateurs et peuvent agir de façon autonome.

Cette évolution introduit de nouvelles surfaces d'attaque que la cybersécurité traditionnelle ne couvre pas :

• La manipulation des données d'entraînement pour biaiser un modèle

• L'exploitation des sorties d'un modèle pour extraire des données sensibles

• Les attaques par prompt injection pour contourner les garde-fous

• Le vol ou la reconstruction d'un modèle propriétaire

Sécuriser l'IA, c'est donc appliquer les principes de la cybersécurité à une nouvelle génération de systèmes numériques — avec des méthodes et des outils adaptés à leurs spécificités.

ISO 27090 : présentation et positionnement

La norme ISO/IEC 27090 (Cybersécurité — Intelligence artificielle — Lignes directrices pour traiter les menaces de sécurité et les défaillances dans les systèmes d'intelligence artificielle) est au stade FDIS depuis février 2026— étape très avancée qui précède immédiatement la publication officielle. Elle s'inscrit dans la famille des normes ISO 27000 et vient compléter un écosystème normatif déjà structuré :

La particularité de l'ISO 27090 est nette : elle s'intéresse avant tout aux mécanismes techniques de sécurité et aux menaces propres aux modèles d'IA. Elle vient enrichir ISO 42001 — qui traite de la gouvernance de l'IA et couvre, notamment via son Annexe A (A.6.2 sur les données pour les systèmes IA, A.6.5 sur la documentation), des aspects de traçabilité des données et du cycle de vie — en apportant une profondeur technique et sécurité supplémentaire, plus opérationnelle sur les processus comme l'entraînement des modèles, la validation continue et la résistance aux attaques.‍

💡 À noter pour les équipes conformité : ISO 42005, consacré à l'évaluation d'impact des systèmes d'IA, s'articule directement avec la clause 6.1.4 d'ISO 42001 et les obligations de l'AI Act (article 27 sur l'analyse d'impact sur les droits fondamentaux). Son absence dans une démarche de conformité constitue un angle mort notable.

Pour les organisations certifiées ISO 27001, ISO 27090 permet d'étendre l'analyse des risques aux composants spécifiques de l'IA : données d'entraînement, modèles, pipelines ML. Pour les organisations avec des filiales ou des clients hors UE, le NIST AI RMF (AI Risk Management Framework) constitue un référentiel complémentaire incontournable, très répandu en Amérique du Nord et de plus en plus utilisé en Europe dans une logique d'interopérabilité des référentiels.

Structure du Standard : 3 Chapitres Clés + 2 Annexes

Chapitre 5 — Appliquer la sécurité de l'information aux systèmes d'IA

Le chapitre 5 pose les fondations : comment transposer les principes classiques de la sécurité de l'information (CID) aux systèmes d'IA, tout au long de leur cycle de vie.

Les pratiques clés recommandées incluent

• Intégrer la sécurité dès la conception (développement, entraînement, déploiement, exploitation)‍
• Appliquer les principes Zero Trust : ne jamais faire confiance par défaut, vérifier chaque accès, appliquer le principe du moindre privilège‍
• Mettre en place une gouvernance IA : inventaire des modèles, analyse des risques, traçabilité‍
• Sécuriser la chaîne d'approvisionnement via des concepts comme l'AI BOM (AI Bill of Materials) pour tracer l'origine des modèles et des données‍
• Réduire la surface d'attaque des données : minimisation, anonymisation, limitation de la durée de conservation‍
• Surveiller et tester en continu les modèles pour détecter dérives, anomalies et attaques‍
• Anticiper avec le threat modelling et le red teaming pour simuler des attaques réelles‍‍

💡 Les fonctionnements autonomes des agents IA remettent en question les outils Zero Trust traditionnels, orientés identité. Une réflexion émerge vers des modèles basés sur le contexte et les intentions (intent-based security).

Chapitre 6 — Identification des menaces spécifiques aux systèmes d'IA

Ce chapitre référence les principales attaques ciblant les modèles d'IA, leurs impacts sur la sécurité et les méthodes de détection associées. Pour chaque type d'attaque, la norme décrit la nature de l'attaque, ses impacts potentiels et les mesures de mitigation associées :

• Data poisoning : injection de données malveillantes dans les données d'entraînement pour dégrader la précision du modèle ou le rendre vulnérable à de futures attaques

• Evasion attack : modification des entrées, imperceptible pour les humains, pour produire des sorties incorrectes

• Membership inference : création de paires entrée-sortie pour identifier des données mémorisées par le modèle

• Model exfiltration : reconstruction d'un modèle fonctionnellement équivalent à l'original

• Model inversion : utilisation des sorties du modèle pour reconstituer des données d'entraînement et divulguer des informations sensibles

• Direct model poisoning : manipulation directe du modèle pendant le développement ou l'exploitation (sans passer par les données d'entraînement)

• Direct model theft : vol direct des paramètres du modèle depuis l'environnement de production ou de développement

• Direct training data leak : accès non autorisé aux données d'entraînement

• Model input / output leak : compromission de la confidentialité des données d'entrée ou de sortie du modèle

• Prompt injection : instructions malveillantes dans les entrées pour produire des comportements involontaires

• Output injection attacks : sorties contenant des attaques de type XSS (cross-site scripting)

‍

Cette cartographie permet aux équipes sécurité d'intégrer les risques IA dans leurs analyses de cybersécurité existantes, en les reliant directement aux propriétés CID.

Chapitre 7 — Mesures d'atténuation et bonnes pratiques

Le chapitre 7 décrit les contrôles de sécurité permettant de réduire l'impact des attaques. Il insiste sur un point fondamental : la sécurité d'un système d'IA doit être pensée comme un ensemble cohérent, et non comme une série de protections indépendantes. Certaines mesures peuvent interagir entre elles ou dégrader les performances du modèle si elles ne sont pas évaluées globalement.

Les 10 grandes catégories de mesures couvertes :

1. Vue d'ensemble — Évaluer les mesures de mitigation de manière globale, analyser leurs interactions, assurer une surveillance continue en production‍
2. Interactions conflictuelles — Évaluer systématiquement les effets combinés des mécanismes de défense avant déploiement‍
3. ‍Continuité sur le cycle de vie — Combiner plusieurs niveaux de protection (contrôle des données, dropout, filtrage des entrées/sorties)‍
4. Dégradation dans le temps — Surveillance continue, tests réguliers, réentraînement et validation avant redéploiement‍
5. Journalisation et surveillance — Journaliser entrées, sorties, utilisateur, date et version du modèle pour détecter comportements suspects et attaques automatisées‍
6. Environnement de développement — Sécuriser données, code, paramètres, documentation et bases RAG pour prévenir fuite et altération‍
7. Détection des entrées malveillantes — Détection OOD (Out Of Distribution), analyse statistique, détection d'anomalies‍
8. Limitation du taux (throttling) — Limiter la fréquence des requêtes pour contrer l'extraction, l'inversion et les attaques adversariales‍
9. Masquage du niveau de confiance — Limiter ou arrondir les scores de confiance pour empêcher la reconstruction du modèle‍
10. Limitation de la taille du modèle — Réduire la complexité pour limiter les risques de mémorisation et de fuite de données

‍

Fournisseur ou Déployeur : des responsabilités différenciées

ISO 27090 distingue deux rôles clés, une distinction cohérente avec la logique de l'AI Act européen :

Le fournisseur développe ou met sur le marché un système d'IA. Il se concentre sur la sécurisation du modèle et de son cycle de vie : robustesse, résistance aux attaques, intégrité des données d'entraînement.

Le déployeur intègre ce système dans un contexte métier. Il sécurise l'environnement d'intégration : accès aux données, exposition via des APIs, usages métier et supervision. Il doit maîtriser les enjeux de sécurité propres aux modèles pour valider les systèmes qu'il intègre et en assumer la responsabilité opérationnelle.

Cette double lecture est essentielle pour toute organisation souhaitant déployer des systèmes d'IA de manière fiable, conforme à l'AI Act et auditée.

Les domaines encore peu couverts

Malgré son périmètre ambitieux, le projet de norme laisse plusieurs zones à approfondir :

• La sécurité des agents autonomes, des serveurs MCP (Model Context Protocol) et des architectures multi-agents — des guides pratiques de l'OWASP GenAI publiés en octobre 2025 proposent déjà des recommandations pour sécuriser ces architectures

• Les risques cognitifs et informationnels : manipulation des utilisateurs, désinformation automatisée

• Les risques économiques et stratégiques liés à l'usage des modèles à grande échelle

En France, l'ANSSI a publié des recommandations de sécurité dédiées aux systèmes d'IA générative, apportant un cadre opérationnel complémentaire aux normes internationales. Le Hub France IA contribue également à une vision globale de la sécurisation de l'IA à travers ses livres blancs et travaux de synthèse.

ISO 27090 : un levier de confiance, pas seulement de conformité

La sécurité des systèmes d'IA dépasse désormais le traditionnel triptyque CID. Elle s'élargit à des dimensions comme la transparence des décisions, la responsabilité algorithmique, l'explicabilité (XAI — Explainable AI) et l'impact concret sur les individus.

Pour les organisations, anticiper l'adoption d'ISO 27090, en complémentarité avec ISO 42001 pour la gouvernance, ISO 42005 pour l'évaluation d'impact, ISO 27001 pour la sécurité de l'information, et le NIST AI RMF pour les contextes internationaux; permet de structurer une démarche de sécurité IA robuste, documentée et auditée. C'est aussi un signal fort envoyé aux clients, partenaires et régulateurs : la sécurité de vos systèmes d'IA est traitée sérieusement, intégrée dès la conception et non ajoutée après coup.

Dans un paysage où les risques évoluent aussi vite que les innovations architecturales (agents, RAG, LLM multimodaux), cette approche normative devient un prérequis incontournable pour tout déploiement IA responsable.

Vous souhaitez approfondir ce sujet ou évaluer votre niveau de maturité face aux exigences d'ISO 27090 ? Retrouvez nos webinaires dédiés à la sécurité IA en entreprise.

‍