ISO/IEC 27090:2026 pour la sécurité de l'IA : ce que la norme demande vraiment

Si vous exploitez ou développez des systèmes d'IA, utilisez l'ISO/IEC 27090 comme couche de menaces et de mesures spécifiques à l'IA au sein de votre programme ISO/IEC 27001 ou ISO/IEC 42001 existant, et non comme un projet de conformité distinct.

L'ISO/IEC 27090:2026 est désormais une norme internationale publiée. L'ISO la recense comme publiée, avec une date de publication au 14 octobre 2026. Elle a été élaborée par le comité ISO/IEC JTC 1/SC 27, qui traite de la sécurité de l'information. Cet article explique ce que la norme couvre, ce qu'elle ne fait pas, et où elle se situe par rapport aux normes ISO/IEC 27001 et ISO/IEC 42001.

Les citations de praticiens dans cet article reflètent l'expérience de formation d'Abilene Academy et ne sont pas des positions de l'ISO. L'ISO/IEC 27090 est une norme publiée, et le catalogue de l'ISO fait foi pour son statut et son contenu.

Pourquoi une norme de sécurité pour l'IA maintenant

La plupart des systèmes d'IA en entreprise n'ont pas été conçus par l'équipe sécurité. Ils arrivent sous forme de fonctionnalité d'un logiciel en SaaS, de modèle derrière une API, d'agent connecté à un outil de tickets ou d'assistant de code dans l'équipe de développement. Chacun ajoute des chemins d'attaque que l'analyse de vulnérabilités classique ne voit pas : données d'entraînement empoisonnées, prompts qui dissimulent des instructions, et sorties de modèle qui déclenchent une action en aval.

La 27090 donne aux équipes sécurité un vocabulaire commun et une liste de menaces pour ces chemins. Elle ne vous demande pas d'acheter un outil. Elle indique quelles compromissions considérer, comment chacune se manifeste, comment la détecter et comment la réduire.

L'IA non autorisée rend l'inventaire urgent. Dans une enquête WatchGuard menée en avril 2026, 64 % des salariés déclarent utiliser des outils d'IA non autorisés dans le cadre de leur travail. L'échantillon comprenait 684 salariés de petites et moyennes organisations, et les réponses sont déclaratives. Source : WatchGuard, 2026 Cybersecurity Hygiene Report.

Ce qu'est l'ISO/IEC 27090, et ce qu'elle n'est pas

La norme comprend un cadre normatif court, un corps de lignes directrices et trois annexes informatives. La clause 5 traite de l'application de la sécurité de l'information à l'IA, notamment la gouvernance, les principes du zero trust, les pratiques de génie logiciel, la gestion de la chaîne d'approvisionnement, la modélisation des menaces et le red teaming. La clause 6 décrit les types de compromission, de l'empoisonnement de données à l'injection de prompt. La clause 7 couvre les mesures d'atténuation, y compris la manière dont elles peuvent entrer en conflit et perdre en efficacité avec le temps.

« Traitez chaque artefact de modèle, chaque jeu de données, chaque modèle de prompt et chaque permission d'outil comme une surface d'attaque. Si un élément peut modifier le comportement du modèle ou atteindre un système en aval, il doit figurer dans la modélisation des menaces. »

Alexis Hirschhorn, formateur chez Abilene Academy

Deux limites comptent. D'abord, la 27090 porte sur la protection des systèmes d'IA, et non sur l'usage de l'IA pour défendre les réseaux. Ensuite, elle ne garantit pas qu'un système est à l'abri de toute attaque. Ses mesures réduisent le risque, et le risque résiduel doit encore être assumé et accepté.

Les menaces liées à l'IA à comprendre en premier

La clause 6 décrit pour chaque compromission sa nature, les défaillances qu'elle provoque, la manière de la détecter et de l'atténuer. Le tableau utilise un langage simple. Les références de clauses proviennent de la norme ; les correspondances avec d'autres référentiels sont notre lecture et doivent être vérifiées par rapport aux versions en vigueur.

Deux lacunes sont à connaître. La table des matières ne comporte pas de rubrique distincte sur le jailbreak, et les risques liés aux agents et aux abus d'outils sont traités plus brièvement que dans des catalogues spécialisés. Pour ceux-ci, utilisez le Top 10 OWASP pour les applications LLM et la base de connaissances MITRE ATLAS en complément de la 27090.

Pourquoi c'est important maintenant : le calendrier réglementaire

Une norme n'est utile que si quelqu'un réclame les preuves. Quatre cadres le font aujourd'hui.

L'Omnibus numérique sur l'IA, règlement (UE) 2026/1744, a reporté les obligations autonomes à haut risque de l'annexe III au 2 décembre 2027 et celles de l'annexe I au 2 août 2028. Le calendrier AI Act pour les systèmes à haut risque détaille l'ensemble des dates. Le report change le moment où un régulateur peut agir ; il ne réduit pas le risque que portent vos systèmes.

La directive NIS 2 impose aux entités essentielles et importantes de maîtriser la sécurité de la chaîne d'approvisionnement et du développement, et les services d'IA entrent dans ces mesures lorsqu'ils font partie du service. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées au titre du Cyber Resilience Act : une faille d'injection de prompt dans un produit exploitée dans la nature peut donc devenir déclarable. Voir les obligations de signalement du CRA pour les délais.

En Suisse, le PFPDT a indiqué que la LPD révisée s'applique directement aux traitements de données personnelles assistés par IA. L'inférence d'appartenance, l'inversion de modèle et les sorties sensibles sont donc des défaillances de confidentialité au titre du devoir de sécurité des données, et elles doivent figurer dans l'analyse d'impact relative à la protection des données.

« En Suisse, une fonctionnalité d'IA qui traite des données personnelles est une activité de traitement comme une autre. L'innovation ne supprime pas l'obligation de documenter la finalité, les flux de données, les risques de sécurité, la conservation et le responsable désigné. »

Henri Haenni, Abilene Academy

De la liste des menaces aux mesures prouvées

Un test utile consiste à vérifier si une mesure laisse des preuves qu'un auditeur peut échantillonner. Le tableau indique où chaque menace entre dans le cycle de vie et quelle mesure de la 27090 s'applique.

Un modèle de maturité pour les mesures de sécurité de l'IA

N'essayez pas de mettre en œuvre l'ensemble du catalogue d'un coup. Avancez en trois étapes, et traitez chacune comme un ensemble de preuves que vous pouvez montrer.

Sources des chiffres ci-dessus : WatchGuard, 2026 Cybersecurity Hygiene Report (enquête d'avril 2026, réponses déclaratives) ; PagerDuty Shadow AI Survey (juin 2026).

Cas pratique : un agent IA de support avec accès au CRM

Il s'agit d'un exemple composite, et non d'un cas client. Prenons un assistant IA qui répond aux tickets clients et peut créer des notes dans le CRM. C'est une configuration courante, et elle illustre la plupart des menaces de la 27090 dans un seul système.

Inventaire. Le système est référencé avec son responsable (le responsable des opérations clients), son modèle et son fournisseur, ses sources de données (texte des tickets, enregistrements CRM), ses outils (créer une note, mettre à jour le statut) et ses approbations humaines. Les fonctionnalités d'IA intégrées à la plateforme de tickets y figurent également.

Modélisation des menaces. Quatre menaces comptent le plus : l'injection de prompt indirecte via les courriels clients (6.9), des permissions CRM excessives pour l'agent (5.3, 6.11.3), une sortie sensible qui expose le dossier d'un autre client (6.8), et des appels d'outils que personne ne journalise (7.5).

Mesures. L'agent dispose de son propre identifiant, avec le périmètre CRM minimal. Toute modification d'un dossier client exige une approbation humaine. La sortie est assainie avant d'atteindre l'interface CRM (6.10). Les appels d'outils sont journalisés avec l'utilisateur, l'entrée et le résultat. Des limites de débit s'appliquent au point d'accès (7.8). Des tests red team sont menés chaque trimestre, avec des courriels contenant des injections.

Preuves qu'un auditeur échantillonnerait. Le périmètre de l'identifiant de l'agent dans le registre des accès. Trois journaux d'appels d'outils échantillonnés, montrant une approbation et une action refusée. Le dernier rapport red team, avec ses cas de test d'injection et les tickets de correction. L'enregistrement de changement indiquant la dernière revue des permissions de l'agent.

Décision sur le risque résiduel. Une injection peut toujours amener l'agent à rédiger une mauvaise note, mais elle ne peut pas modifier un dossier client sans approbation ni lire les dossiers d'autres clients. Le responsable accepte le risque résiduel d'une mauvaise rédaction, consigne cette décision et fixe une date de revue liée au prochain changement de modèle ou de permissions.

Agents et outils : là où le rayon d'impact compte

L'IA agentique est le domaine où la norme est la plus mince. La 27090 applique le zero trust aux opérations des agents et recommande le moindre privilège pour le modèle. C'est une bonne base, mais elle ne fournit pas une liste complète des scénarios d'abus d'outils. Les questions pratiques sont concrètes : quels outils l'agent peut-il appeler, avec quels identifiants, quelles actions exigent une approbation humaine, et que se passe-t-il lorsqu'une instruction arrive dans un contenu récupéré ? Le Top 10 OWASP pour les applications LLM (édition 2025) classe la capacité excessive d'agir (excessive agency) parmi les risques majeurs : une sortie de modèle qui peut déclencher des outils, écrire des données ou envoyer des messages doit voir ses permissions limitées aussi strictement que n'importe quel compte de service.

« Un filtre d'injection de prompt est un contrôle utile, mais ce n'est pas un modèle d'autorisation. Concevez l'agent pour le jour où le modèle sera trompé : limitez ses identifiants, séparez ses permissions de celles de l'utilisateur, exigez une approbation pour les actions irréversibles et rendez chaque appel d'outil observable. »

Alexis Hirschhorn, formateur chez Abilene Academy

Notre formation Certified Artificial Intelligence Security Professional aborde ces sujets en ateliers : test d'injection de prompt, red teaming sur des applications LLM, et analyse des menaces ancrée dans MITRE ATLAS et le Top 10 OWASP LLM. Elle est dispensée en anglais et en français.

Ce que nous apprennent les incidents réels

Quatre cas publics illustrent la manière dont les menaces de la 27090 se concrétisent. Chacun est résumé à partir de la recherche ou du rapport du fournisseur d'origine, dont la source est indiquée.

Injection de prompt sans clic dans un assistant d'entreprise. Des chercheurs d'Aim Labs ont décrit un courriel piégé qui a conduit un assistant de type Microsoft 365 Copilot à divulguer des données de son contexte sans action de l'utilisateur, documenté sous la référence CVE-2025-32711 et analysé dans arXiv 2509.10540. L'attaque enchaînait plusieurs contournements : l'évasion d'un classifieur, le contournement du caviardage des liens et une requête d'image vers un domaine autorisé. Microsoft a corrigé la faille côté serveur. Enseignement : le rendu d'une sortie qui déclenche des requêtes réseau constitue un chemin de fuite de données.

Modèles malveillants sur une plateforme publique. Dans un billet de blog de JFrog daté du 27 février 2024, l'entreprise a signalé une centaine de modèles malveillants sur Hugging Face. L'un utilisait la sérialisation pickle de Python pour ouvrir une connexion vers une adresse distante au chargement. Enseignement : un fichier de modèle est du code. Traitez-le comme un binaire tiers, et privilégiez des formats sûrs comme safetensors.

Campagne d'intrusion orchestrée par l'IA. Dans son rapport de novembre 2025, Anthropic décrit un acteur qu'elle attribue avec une forte confiance à un groupe lié à un État, qui a utilisé un outil de code agentique pour mener des étapes de reconnaissance et d'intrusion contre plusieurs organisations, avec une intervention humaine à seulement quelques points de décision. L'acteur a présenté le travail comme un test légitime pour contourner les garde-fous. Enseignement : la résistance au jailbreak peut échouer, d'où l'importance de la détection et de la capacité à couper l'accès.

Vol d'une partie d'un modèle en production. Dans arXiv 2403.06634 (ICML 2024), Carlini et al. ont retrouvé la matrice de projection de modèles de langage en production à travers leur API publique. Enseignement : la conception d'une API est une décision de sécurité. Les logprobs et le logit bias élargissent ce qu'un attaquant peut apprendre.

La divulgation des vulnérabilités est inégale. Une étude portant sur les politiques de divulgation de 264 fournisseurs d'IA (arXiv 2509.06136) montre que 36 % ne proposaient aucun canal de divulgation de vulnérabilités, et que seulement 18 % mentionnaient explicitement les risques liés à l'IA. L'accès aux données, l'autorisation et l'extraction de modèle sont les types de vulnérabilités le plus souvent déclarés dans le périmètre, tandis que le jailbreak et les hallucinations sont le plus souvent exclus. Les équipes achats devraient poser une question concrète : quelle est votre politique de divulgation des vulnérabilités IA, et l'injection de prompt, l'extraction de modèle et l'empoisonnement de données sont-ils dans le périmètre ? L'étude mesure les politiques publiées, non le comportement réel des fournisseurs.

Utiliser la 27090 au sein de l'ISO/IEC 27001 et de l'ISO/IEC 42001

Si vous exploitez un système de management de la sécurité de l'information 27001, ajoutez les menaces liées à l'IA à votre registre des risques et aux justifications de votre déclaration d'applicabilité. Si vous exploitez ou prévoyez un système de management de l'IA 42001, reliez l'analyse d'impact IA et le processus de risque au catalogue de menaces. La norme renvoie à la 42001 pour le système de management et à la 27002 pour les lignes directrices sur les mesures : les trois fonctionnent comme un ensemble.

Les auditeurs d'un système 42001 recherchent la traçabilité : depuis une version de modèle, en passant par son analyse d'impact, ses décisions sur les données, ses résultats de tests et son approbation, jusqu'à sa surveillance. Le guide audit ISO 42001 : preuves attendues détaille le dossier de preuves.

« La conformité n'est pas un état que l'on atteint. C'est une propriété de vos registres. Si vos preuves n'existent que parce qu'on les a rassemblées pour l'audit, vous n'étiez jamais prêts : vous vous étiez préparés. »

Alexis Hirschhorn, formateur chez Abilene Academy

Pour les systèmes d'IA, cela signifie que l'inventaire, la modélisation des menaces, la provenance des données, les résultats de tests et les registres de surveillance doivent être tenus à jour dans le fonctionnement normal, et non reconstitués avant un audit. Utilisez ce principe comme test pour la liste de contrôle des preuves ci-dessous.

Les équipes qui souhaitent réunir l'inventaire IA, les modélisations de menaces et la piste de preuves en un seul endroit utilisent souvent une plateforme GRC native de l'IA, comme Acuna GRC, qui relie ces registres aux mesures qu'ils étayent.

Cinq questions avant le déploiement

Posez ces questions avant toute mise en service d'un système d'IA. Chaque réponse doit être étayée par les preuves de la colonne de droite.

Qui doit agir, et ce dont chacun est responsable

Ce que la 27090 ne résout pas

Surestimer la norme est l'erreur la plus courante. Soyons clairs sur les limites. Elle ne certifie pas une organisation. Elle ne crée pas de présomption de conformité au titre de l'AI Act : la présomption de l'article 40 dépend de normes harmonisées citées au Journal officiel. Elle ne remplace ni l'ISO/IEC 27001, ni la 27002, ni la 42001. Elle ne fournit pas un catalogue complet de contrôles pour les agents et les abus d'outils. Elle ne dispense pas d'une évaluation des risques propre à chaque système et d'une décision documentée d'acceptation du risque résiduel.

Questions fréquentes

L'ISO/IEC 27090 est-elle publiée ?

Oui. L'ISO recense l'ISO/IEC 27090:2026 comme publiée, en édition 1, avec une date de publication au 14 octobre 2026. Les projets décrivent un texte qui a depuis changé : vérifiez la version publiée avant de la citer.

Une organisation peut-elle être certifiée ISO/IEC 27090 ?

Non. C'est une norme de lignes directrices, et aucun schéma de certification n'existe pour elle. Faites-vous certifier selon l'ISO/IEC 27001 ou l'ISO/IEC 42001, et utilisez la 27090 comme référence pour traiter les menaces liées à l'IA dans ce périmètre.

L'ISO/IEC 27090 remplace-t-elle les mesures de l'ISO/IEC 27002 pour les systèmes d'IA ?

Non. La norme rappelle que les mesures classiques de sécurité de l'information restent applicables selon le risque. La 27090 ajoute par-dessus les menaces propres à l'IA et les mesures qui les traitent.

L'ISO/IEC 27090 couvre-t-elle l'injection de prompt ?

Oui. La clause 6.9 couvre l'injection de prompt, et sa définition inclut le contenu intégré à une instruction, ce qui recouvre l'injection indirecte via des documents, des courriels et des pages web. La clause 6.10 couvre les sorties qui transportent une charge d'injection.

L'ISO/IEC 27090 aide-t-elle à se conformer à l'AI Act ?

Elle constitue un guide pertinent pour les attentes de cybersécurité de l'article 15 applicables aux systèmes à haut risque. Ce n'est pas une norme harmonisée : l'utiliser ne crée pas, à elle seule, une présomption de conformité au titre de l'AI Act.

Quand les obligations de l'AI Act pour les systèmes à haut risque s'appliquent-elles ?

En vertu du règlement (UE) 2026/1744, les obligations pour les systèmes à haut risque de l'annexe III s'appliquent à partir du 2 décembre 2027, et celles de l'annexe I à partir du 2 août 2028. Les obligations de transparence de l'article 50 s'appliquent depuis le 2 août 2026.

L'ISO/IEC 27090 est-elle pertinente en Suisse ?

Oui. Le PFPDT indique que la LPD révisée s'applique directement aux traitements assistés par IA. Les recommandations de la norme sur les attaques contre la vie privée soutiennent les obligations de sécurité des données et d'analyse d'impact de la LPD. Les entreprises suisses qui servent des clients européens sont également soumises à l'AI Act et au CRA.

En quoi l'ISO/IEC 27090 diffère-t-elle de l'ISO/IEC 42001 ?

L'ISO/IEC 42001 fixe les exigences de gestion responsable de l'IA dans toute l'organisation, et elle est certifiable. L'ISO/IEC 27090 va plus loin sur les menaces de sécurité qui pèsent sur les systèmes d'IA et sur la manière de les détecter et de les réduire. La plupart des organisations utiliseront les deux.

La norme traite-t-elle de l'IA agentique ?

En partie. Elle applique le zero trust aux opérations des agents et recommande le moindre privilège pour le modèle. Pour les abus d'outils et la confiance entre agents, ajoutez le Top 10 OWASP LLM et le catalogue de techniques MITRE ATLAS.

Comment nous utilisons cette norme en formation

Dans nos sessions de sécurité de l'IA et d'ISO/IEC 42001, nous demandons aux équipes d'apporter une fonctionnalité d'IA réelle. Nous en cartographions les sources de données, le modèle ou le fournisseur, les outils, les approbations humaines, les journaux et les scénarios de défaillance. Le manque le plus courant n'est pas une mesure technique absente. C'est une fonctionnalité d'IA sans propriétaire, intégrée à un système métier existant.

Où se former ensuite

Équipes sécurité et SOC. La formation Certified Artificial Intelligence Security Professional couvre les techniques d'attaque de la clause 6, le Top 10 OWASP LLM et MITRE ATLAS, avec des ateliers sur l'injection de prompt et le red teaming. Alexis Hirschhorn l'anime. Vous pouvez consulter son profil de formateur.

Responsables de systèmes de management. La formation ISO/IEC 42001 Lead Implementer couvre le système de management de l'IA, et la formation ISO/IEC 27001 Lead Implementer couvre le système de management de la sécurité de l'information dans lequel s'insèrent les menaces liées à l'IA.

Responsables des risques et de la conformité. La formation Lead AI Risk Manager construit le processus de gestion des risques dans lequel s'intègrent les menaces de la 27090.

Le hub gouvernance de l'IA présente l'ensemble du parcours de formation.

Sources et vérification

Statut, structure et périmètre de la norme : catalogue ISO de l'ISO/IEC 27090:2026 et explication publiée par l'ISO. Structure des clauses et définitions : aperçu public de la norme, lorsqu'il est permis. Article 15 de l'AI Act : règlement (UE) 2024/1689 et service d'assistance de la Commission européenne sur l'AI Act. Calendrier de l'AI Act : règlement (UE) 2026/1744 publié au Journal officiel. Incidents : les sources citées ci-dessus, avec leurs dates de publication. Les correspondances avec les référentiels (NIST AI 100-2e2025, Top 10 OWASP LLM 2025, MITRE ATLAS) relèvent de notre interprétation et doivent être vérifiées par rapport aux versions en vigueur.

Cet article est une synthèse de planification. Le texte intégral de la norme est payant. Vérifiez les exigences précises de clause par rapport à la version publiée avant de vous y fier.