Réponse rapide : ISO 27090, de son nom complet ISO/IEC 27090:2026, est une norme internationale publiée en octobre 2026 qui guide les organisations face aux menaces de sécurité propres aux systèmes d'intelligence artificielle (IA). C'est un guide de recommandations : il ne se certifie pas et ne vaut pas conformité au règlement européen sur l'IA. Il donne en revanche une grille commune pour traiter des risques que les contrôles habituels ne voient pas.
Un pare-feu filtre des flux, un contrôle d'accès vérifie une identité. Aucun des deux ne voit qu'un jeu de données a été altéré, qu'une page web résumée par l'IA cachait une consigne ou qu'une réponse restitue un contrat confidentiel. Avec l'IA, la surface d'attaque s'étend aux données qui nourrissent le modèle, au modèle lui-même et à son comportement. Pour le responsable de la sécurité des systèmes d'information (RSSI), la question devient : comment intégrer ces risques à l'analyse qu'il pilote déjà ?
Qu'est-ce que la norme ISO/IEC 27090 ?
Réponse rapide : la norme ISO/IEC 27090 fournit des recommandations pour comprendre, détecter et atténuer les menaces spécifiques qui pèsent sur la sécurité des systèmes d'IA, tout au long de leur cycle de vie. Elle vise les organisations qui développent l'IA comme celles qui l'utilisent, et complète, sans les remplacer, les pratiques de sécurité de l'information des normes ISO/IEC 27001 et 27002.
ISO/IEC 27090 : norme internationale de cybersécurité consacrée à l'intelligence artificielle, publiée par l'Organisation internationale de normalisation (ISO) et la Commission électrotechnique internationale (CEI, IEC en anglais). Elle donne des lignes directrices pour comprendre, détecter et atténuer les menaces et les compromissions propres aux systèmes d'IA, des données d'entraînement jusqu'aux mises à jour du modèle.
| Élément | Ce qu'indiquent les fiches officielles |
|---|---|
| Titre officiel | Cybersecurity, Artificial intelligence (AI), Addressing security threats and compromises to AI systems (titre anglais) |
| Édition et date | Première édition, publiée le 14 octobre 2026 |
| Volume | 56 pages |
| Comité | ISO/IEC JTC 1/SC 27, sécurité de l'information, cybersécurité et protection de la vie privée |
| Nature | Lignes directrices : la norme fournit des recommandations, pas des exigences |
Selon le résumé de l'ISO, la norme aide à identifier ce qui doit être protégé, des données d'entraînement aux modèles, à comprendre comment les vulnérabilités s'exploitent et à choisir les mesures, du développement aux mises à jour du modèle. La fiche de l'ISO relève aussi que les données collectées en production peuvent servir plus tard à réentraîner ou mettre à jour un modèle, ce qui en fait une porte d'entrée.1
La norme vise-t-elle seulement l'IA générative ? Non. Elle porte sur les systèmes d'IA en général : l'empoisonnement des données ou le vol de modèle touchent aussi un modèle de détection de fraude ou de maintenance prédictive.
Quel est le statut d'ISO 27090 face au règlement européen sur l'IA ?
Réponse rapide : ISO 27090 est une norme internationale officielle, d'application volontaire, mais ce n'est pas une norme harmonisée au titre du règlement européen sur l'IA : l'appliquer ne crée aucune présomption de conformité. Elle aide en revanche à répondre aux attentes de cybersécurité que ce règlement fixe pour les systèmes à haut risque, sans en apporter la preuve à elle seule.
L'article 15 du règlement (UE) 2024/1689, connu sous le nom d'AI Act, exige des systèmes d'IA à haut risque un niveau approprié d'exactitude, de robustesse et de cybersécurité sur tout leur cycle de vie. Face aux vulnérabilités propres à l'IA, il attend des mesures contre les attaques qui visent les données d'entraînement (empoisonnement des données), les composants pré-entraînés (empoisonnement du modèle), les entrées conçues pour faire commettre une erreur au modèle (exemples contradictoires ou évasion), ainsi que les attaques contre la confidentialité et les défauts du modèle.2 C'est le terrain d'ISO 27090, dont le résumé cite l'empoisonnement des données et le vol de modèle.1
La présomption de conformité relève pourtant des normes harmonisées (ou, à défaut, de spécifications communes adoptées par la Commission) : publiées par les organismes européens de normalisation CEN (Comité européen de normalisation) et CENELEC (Comité européen de normalisation électrotechnique), évaluées par la Commission, puis référencées au Journal officiel de l'Union. La Commission indique que des normes internationales peuvent devenir des normes harmonisées lorsqu'elles sont disponibles et alignées sur les exigences européennes.3 ISO 27090 n'a pas ce statut. Pour situer ces obligations dans l'ensemble du règlement, consultez le guide adopter l'IA en entreprise sans perdre le contrôle.
Une norme européenne de cybersécurité de l'IA en préparation
Le comité technique commun JTC 21 du CEN et du CENELEC élabore les normes harmonisées demandées par la Commission dans dix domaines, dont la cybersécurité.3 Le projet prEN 18282, « Artificial intelligence, Cybersecurity specifications for AI Systems », a été soumis à enquête publique à partir du 15 mai 2026.4 À la date de rédaction, aucune version définitive n'est publiée. C'est ce type de norme harmonisée, et non ISO 27090, qui peut ouvrir une présomption de conformité pour la cybersécurité.
Quel calendrier pour les systèmes à haut risque ?
Le règlement (UE) 2026/1744 du 8 juillet 2026, dit train de mesures omnibus numérique sur l'IA, a modifié le calendrier : les obligations des systèmes à haut risque s'appliquent au 2 décembre 2027 pour ceux de l'annexe III, et au 2 août 2028 pour ceux qui relèvent de l'annexe I, liée aux produits couverts par la législation d'harmonisation de l'Union.5 Pour une organisation utilisatrice, ce délai ne change rien : les menaces décrites touchent déjà ses usages.
ISO 27090 suffit-elle à démontrer la conformité à l'article 15 ? Non. Elle structure les mesures, mais la conformité d'un système à haut risque se démontre selon les procédures du règlement.
Peut-on obtenir une certification ISO 27090 ?
Réponse rapide : non, aucune certification ISO 27090 n'existe, parce que la norme formule des recommandations et non des exigences auditables. Une organisation peut en revanche se faire certifier ISO/IEC 27001 pour la sécurité de l'information ou ISO/IEC 42001 pour le management de l'IA, et s'appuyer sur ISO 27090 pour traiter les menaces propres à l'IA dans ce cadre.
Une norme d'exigences dit ce qui doit être fait et qu'un auditeur vérifie ; une norme de lignes directrices dit ce qui devrait l'être. L'ISO présente ISO 27090 comme un document qui fournit des recommandations1 : la norme ne fixe pas d'exigences contre lesquelles un auditeur pourrait certifier une organisation.
ISO/IEC 27001:2022 spécifie les exigences d'un système de management de la sécurité de l'information ; l'ISO précise que la certification est possible mais pas obligatoire, et qu'elle ne la délivre pas elle-même.6 ISO/IEC 42001:2023, publiée en décembre 2023, spécifie les exigences d'un système de management de l'IA pour les organisations qui fournissent ou utilisent des produits et services fondés sur l'IA ; ISO/IEC 42006:2025 fixe les exigences applicables aux organismes qui auditent et certifient ces systèmes.7 Le guide sur le système de management de l'IA (SMIA) détaille cette démarche.
Face à une offre commerciale, « aligné sur ISO/IEC 27090 » est une affirmation recevable, à vérifier sur pièces ; une promesse de certificat ISO 27090 ne correspond à aucun dispositif existant.
Quelles menaces spécifiques à l'IA la norme ISO 27090 traite-t-elle ?
Réponse rapide : ISO 27090 traite des menaces de sécurité propres aux systèmes d'IA, qui visent les données, le modèle et son comportement ; son résumé public cite l'empoisonnement des données et le vol de modèle. D'autres sources officielles décrivent aussi les entrées conçues pour tromper le modèle, les attaques contre la confidentialité et la manipulation par les requêtes. Ces menaces s'ajoutent aux attaques classiques sans les remplacer, et plusieurs touchent directement les usages bureautiques de l'IA.
Ces deux exemples figurent dans le résumé public de la norme.1 Le tableau présente les grandes familles de menaces spécifiques à l'IA décrites par les sources publiques : l'article 15 du règlement européen,2 le Top 10 des risques pour les applications fondées sur les grands modèles de langage (LLM, large language models) de l'Open Worldwide Application Security Project (OWASP)8 et la taxonomie des attaques du National Institute of Standards and Technology (NIST), l'institut public américain chargé des normes et de la technologie.9
| Menace | Ce qui se passe | Exemple en entreprise |
|---|---|---|
| Empoisonnement des données | Des données d'entraînement ou de réentraînement altérées faussent le comportement du modèle | Un modèle de tri de factures réentraîné sur des données manipulées laisse passer des fraudes |
| Empoisonnement du modèle | Un modèle pré-entraîné ou un composant tiers arrive déjà compromis | Un modèle téléchargé pour un projet interne réagit de façon anormale à un mot déclencheur |
| Évasion | Une entrée conçue pour tromper le modèle provoque une erreur (exemple contradictoire) | Un document retouché échappe à un filtre de détection automatisé |
| Attaques contre la confidentialité | Des requêtes répétées révèlent si une donnée a servi à l'entraînement (inférence d'appartenance), voire reconstituent une partie de ces données (reconstruction de données) | Un modèle ajusté sur des dossiers RH laisse deviner qu'un salarié figure dans le jeu d'entraînement |
| Vol de modèle | Des requêtes en masse servent à copier le comportement d'un modèle | Un service d'IA ouvert aux partenaires est interrogé en boucle pour être copié |
| Divulgation d'informations sensibles | Le modèle restitue dans sa réponse des données qu'il n'aurait pas dû exposer | Un outil d'IA connecté au partage de fichiers cite un extrait de contrat à un collaborateur non habilité |
| Injection de prompt, directe ou indirecte | Des instructions glissées dans la requête ou dans un contenu lu par le modèle détournent son comportement | Une page web résumée par l'IA contient une consigne cachée qui oriente la réponse |
| Sorties piégées | Une réponse transporte un contenu actif, lien, code ou nouvelle consigne, qui agit sur le système qui la reçoit | Une réponse insérée dans un outil métier fait appeler une adresse externe |
| Consommation abusive | Des requêtes en volume épuisent les ressources ou le budget | Un script mal réglé consomme en une nuit le quota d'une équipe |
Aucune de ces familles ne se règle par un correctif unique. À propos de l'injection de prompt, l'OWASP écrit qu'il n'est pas établi qu'il existe une méthode de prévention infaillible.8 L'objectif réaliste est donc de réduire la probabilité et l'impact d'une attaque, et de savoir la détecter, pas de promettre l'immunité.
Pourquoi ces menaces concernent-elles aussi les organisations qui utilisent l'IA sans la développer ?
Réponse rapide : une organisation utilisatrice fournit au modèle ses données, ses documents et parfois l'accès à ses outils : elle porte donc une partie du risque, même sans entraîner aucun modèle. ISO 27090 s'adresse d'ailleurs aux organisations qui utilisent l'IA, pas seulement à celles qui la développent.
Les données qui partent chez les fournisseurs de modèles
Chaque requête envoyée à un modèle hébergé par un tiers transporte ce que le collaborateur y a mis : client, contrat, donnée de santé. L'Agence nationale de la sécurité des systèmes d'information (ANSSI) recommande de proscrire l'usage d'outils d'IA générative sur Internet pour un usage professionnel impliquant des données sensibles.10 Masquer les données avant l'envoi, comme l'explique le guide anonymisation des données et IA, réduit ce qu'une fuite peut exposer ; le lieu de traitement et les contrats comptent aussi, comme le détaille le guide sur l'IA souveraine.
Les contenus piégés que l'IA lit pour vous
Résumer une page web, analyser une pièce jointe, trier des CV : le modèle lit alors un texte écrit par un tiers. L'OWASP décrit ce scénario d'injection indirecte, où une page résumée contient des instructions cachées qui modifient le comportement du modèle.8 L'utilisateur est de bonne foi ; la consigne arrive par la donnée.
Les agents connectés à vos outils
Dès qu'un modèle peut envoyer un e-mail, créer un ticket ou appeler une interface de programmation (API), une consigne cachée peut se traduire en action. L'OWASP range ce risque sous le nom d'agentivité excessive, parmi ses dix risques majeurs.8 L'ANSSI recommande de limiter les actions automatiques d'un système d'IA qui traite des entrées non maîtrisées.10 La règle : plus l'IA peut agir, plus ses droits doivent être étroits et ses actions irréversibles validées par un humain.
La chaîne d'approvisionnement des modèles
Modèles, bibliothèques, connecteurs, jeux de données : une organisation utilisatrice dépend de composants qu'elle ne contrôle pas, et l'OWASP compte la chaîne d'approvisionnement parmi les dix risques majeurs des applications fondées sur les LLM.8 À demander à chaque fournisseur : lieu de traitement, usage pour l'entraînement, sous-traitants, annonce des mises à jour. Les usages hors de tout cadre, décrits dans le guide sur le Shadow AI, échappent à toutes ces questions.
Comment s'aligner sur ISO/IEC 27090 ?
Réponse rapide : s'aligner sur ISO/IEC 27090 consiste à intégrer les menaces spécifiques à l'IA dans la démarche de sécurité existante : connaître ses usages, modéliser les menaces, contrôler entrées, sorties et droits, journaliser, tester, encadrer les fournisseurs et préparer la réponse aux incidents. Huit étapes suffisent pour démarrer, sans attendre une certification qui n'existe pas.
Le texte intégral de la norme étant payant, ces huit étapes ne reproduisent pas son contenu : elles traduisent en pratique les objectifs affichés dans son résumé public, identifier ce qui doit être protégé, détecter et atténuer les menaces, sur tout le cycle de vie du système.1
Connaître ses usages et ses menaces
- Étape 1, inventorier les usages et les systèmes d'IA : outils grand public, fonctions d'IA des logiciels, projets internes, connecteurs et agents, avec leurs données et leurs droits.
- Étape 2, modéliser les menaces usage par usage : entrées non maîtrisées, données sensibles, actions possibles.
Pour l'étape 2, la base MITRE ATLAS, qui recense des tactiques et des techniques d'attaque contre les systèmes d'IA, et le Top 10 de l'OWASP fournissent des scénarios concrets.11 L'inventaire gagne à être porté par le comité décrit dans le guide sur la gouvernance IA, qui arbitre ensuite les usages autorisés.
Contrôler les entrées, les sorties et les droits
- Étape 3, contrôler les entrées et les sorties : filtrage des requêtes, masquage des données sensibles avant l'envoi, vérification des réponses qui alimentent un autre système, plafonds de volume par équipe.
- Étape 4, journaliser : qui a utilisé quel modèle, avec quelles données, pour quelles actions, sous une forme exploitable lors d'une enquête.
- Étape 5, appliquer le moindre privilège aux agents : droits limités au besoin, validation humaine de toute action irréversible, comme un envoi externe, un paiement ou une suppression.
Tester, encadrer les fournisseurs, préparer l'incident
- Étape 6, tester par des exercices d'attaque (red teaming) : tenter des injections, des extractions de données et des contournements, puis vérifier que les garde-fous tiennent.
- Étape 7, revoir les fournisseurs et les modèles selon les questions ci-dessus, contrat par contrat.
- Étape 8, préparer la réponse aux incidents d'IA : une fuite par une réponse ou une action non voulue d'un agent entre dans la procédure existante, avec un moyen de couper un usage rapidement.
Chaque étape produit une trace, utile lors d'un audit ISO/IEC 27001 pour montrer comment les menaces spécifiques à l'IA sont traitées. La sécurité se joue alors dans l'exécution quotidienne, requête par requête, plutôt que dans un rapport de fin d'année.
Où Crosstensor intervient-il face aux menaces décrites par ISO/IEC 27090 ?
Réponse rapide : ISO/IEC 27090 décrit les menaces, Crosstensor les traite dans l'exécution : chaque requête envoyée à un modèle passe par des contrôles appliqués automatiquement, et chaque échange laisse une trace exploitable. Aucun outil ne rend un système invulnérable ; l'objectif est de réduire la probabilité et l'impact d'une attaque, puis de pouvoir le démontrer.
Crosstensor transforme l'adoption de l'IA en démarche maîtrisée. Son différenciateur, Guard, détecte les données sensibles et les remplace par des balises avant l'envoi au modèle, puis réintègre les valeurs réelles dans la réponse. La table de correspondance ne quitte jamais l'infrastructure, opérée chez OVH, en France, sur serveurs HDS (hébergement de données de santé).
| Menace ou mesure | Réponse de Crosstensor |
|---|---|
| Sorties sensibles et fuite des entrées | Guard : données sensibles remplacées par des balises avant l'envoi, table de correspondance conservée en France |
| Injection de prompt et sorties piégées | Une protection contre les tentatives de manipulation qui se renforce en continu, et le blocage de requêtes |
| Inventaire et gouvernance des usages | Tableau de bord des usages, authentification unique (SSO, single sign-on), autorisations par modèle et par équipe |
| Consommation abusive | Enveloppe de crédits mutualisable, avec règles et quotas par équipe |
| Journalisation | Journal d'audit exportable et hash des échanges avec les modèles |
| Chaîne d'approvisionnement | Contrats avec les fournisseurs de modèles, dont le non-entraînement, gérés par Crosstensor ; accord de traitement des données (DPA, data processing agreement) signable par le client |
| Agents et actions | Principe de la plateforme : droits limités, validation humaine des actions irréversibles, connecteurs MCP (Model Context Protocol) avec gestion des droits |
Ces contrôles répondent à plusieurs des menaces spécifiques à l'IA présentées plus haut, sans remplacer l'analyse de risque ni les tests. Trois résultats :
- L'adoption : aussi simple qu'un outil grand public, mais fourni par l'entreprise, avec authentification unique et double authentification paramétrable.
- La maîtrise financière : un seul abonnement sous forme d'enveloppe de crédits mutualisable, suivi par équipe et par modèle.
- La liberté de choix du modèle : adoptez les meilleurs modèles dès leur sortie, vos données protégées par Guard.
Une infrastructure d'IA maîtrisée, opérée en France, sans serveur à installer : la plateforme fonctionne en logiciel en ligne (SaaS). Essayez gratuitement, sans installation ; la grille est sur la page Tarifs.
ISO 27090 et les normes voisines : laquelle fait quoi ?
Réponse rapide : ISO 27090 traite les menaces spécifiques à l'IA, ISO/IEC 27001 organise la sécurité de l'information, ISO/IEC 42001 organise le management de l'IA et le projet européen prEN 18282 prépare des spécifications de cybersécurité pour les systèmes d'IA. Seules les deux normes de système de management sont certifiables, et aucune des quatre n'apporte aujourd'hui de présomption de conformité au règlement européen.
| Norme | Nature | Certifiable | Lien avec le règlement européen | À quoi elle sert |
|---|---|---|---|---|
| ISO/IEC 27090:2026 | Lignes directrices internationales | Non | Aucune présomption de conformité ; aide à traiter les attentes de cybersécurité de l'article 15 | Identifier et traiter les menaces propres à l'IA |
| ISO/IEC 27001:2022 | Exigences d'un système de management de la sécurité de l'information | Oui, par un organisme tiers | Aucune présomption de conformité | Le socle de la sécurité de l'information |
| ISO/IEC 42001:2023 | Exigences d'un système de management de l'IA | Oui, par un organisme tiers | Aucune présomption de conformité ; structure la gouvernance des usages | Piloter les usages et les risques de l'IA dans la durée |
| prEN 18282 | Projet de norme européenne du CEN-CENELEC JTC 21 | Sans objet tant qu'elle n'est pas publiée | Élaborée dans le cadre de la normalisation du règlement | Spécifications de cybersécurité pour les systèmes d'IA |
Conclusion
ISO 27090 ne crée ni obligation ni certificat, mais elle donne au RSSI un référentiel international pour nommer les menaces propres aux systèmes d'IA et les traiter dans son dispositif existant. Trois idées suffisent : connaître ses usages, appliquer les contrôles à chaque requête, garder la trace. La présomption de conformité passera par les normes harmonisées européennes, encore en préparation ; les menaces, elles, sont déjà dans les usages.