ISO 27090 expliquée aux équipes de sécurité de l’IA

ISO/IEC 27090:2026 est une norme internationale qui fournit des lignes directrices sur les menaces et les compromissions de sécurité touchant les systèmes d’intelligence artificielle. Publiée le 14 octobre 2026, elle explique comment les organisations peuvent comprendre, détecter et atténuer ces menaces tout au long du cycle de vie de l’IA. Son titre officiel est Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Fiche de publication ISO

Pour une équipe de sécurité, la question pratique est simple : qu’est-ce qu’un attaquant pourrait modifier ou dérober dans un système d’IA, ou lui faire faire, et qu’est-ce qui limiterait le préjudice qui en résulterait ?

Ce guide présente le champ d’application de la norme ISO 27090, les principales menaces pour la sécurité de l’IA, ses liens avec ISO 27001 et ISO 42001, ainsi qu’une manière concrète de transformer ses lignes directrices en travail de sécurité doté de responsables, de mesures de protection et de preuves. Les recherches sur lesquelles il repose ont été vérifiées le 18 octobre 2026.

Ce que couvre la norme ISO 27090

ISO 27090 porte sur la protection des systèmes d’IA. Son objet dépasse l’IA générative, les grands modèles de langage et les chatbots pour couvrir les systèmes d’IA de manière plus large. Explication d’ISO 27090 par l’ISO

La norme publiée relie des pratiques éprouvées de sécurité de l’information aux menaces propres à l’IA. Son contenu traite de la gouvernance, de la sécurité de la chaîne d’approvisionnement, de la modélisation des menaces et du red teaming, puis des types de compromission, notamment l’empoisonnement, l’évasion, l’exposition d’informations et l’injection de prompt. Elle examine également la manière dont les mesures d’atténuation interagissent et restent efficaces dans la durée. Extrait publié d’ISO/IEC 27090

Le champ d’application inclut les organisations de toute taille qui développent ou utilisent l’IA, notamment les entreprises, les organismes publics et les organisations à but non lucratif. Acheter un service d’IA auprès d’un tiers ne place donc pas une organisation en dehors du public visé. Fiche de publication IEC

Un bon point de départ consiste en une revue commune réunissant la sécurité, l’ingénierie, les équipes data, les achats et le responsable métier. Chacun doit pouvoir expliquer la partie du système qu’il maîtrise et les décisions pour lesquelles il dépend des autres.

Pourquoi les systèmes d’IA exigent une analyse de sécurité complémentaire

Une application d’IA relie plusieurs éléments qui méritent chacun un examen distinct : logiciels, données, fichiers ou services de modèles, instructions, utilisateurs et actions en aval.

Prenons un assistant documentaire connecté à une base de connaissances interne. Une revue classique peut examiner l’authentification, le chiffrement et les vulnérabilités logicielles. Une revue de sécurité de l’IA doit aussi se demander ce qui se passe si un document récupéré tente de modifier les instructions de l’assistant, si des utilisateurs peuvent récupérer des contenus hors de leurs autorisations et quelles actions les sorties générées peuvent déclencher.

Ces questions prennent plus de poids lorsqu’un assistant peut mettre à jour des enregistrements ou appeler des outils externes. Une réponse erronée et une action non autorisée n’ont pas les mêmes conséquences et appellent des mesures de protection différentes.

Pour votre première revue, répondez à trois questions :

• Qu’est-ce qui peut influencer le système ? Incluez les données d’entraînement, les contenus récupérés, les prompts, les fournisseurs et les mises à jour de modèles.
• Qu’est-ce qui peut sortir du système ? Incluez les réponses, les journaux, les exports et les actifs de modèle.
• Qu’est-ce que le système peut modifier ? Incluez les fichiers, les tickets, les comptes, les transactions et les autres services connectés.

Il s’agit d’une méthode pratique de cadrage pour les exemples qui suivent, et non d’une reproduction des clauses de la norme.

Les menaces pour la sécurité de l’IA à connaître

Les explications suivantes reprennent la terminologie du NIST sur l’apprentissage automatique antagoniste et les recommandations de l’OWASP pour les applications LLM. Les scénarios sont donnés à titre d’illustration. Taxonomie du NIST sur l’apprentissage automatique antagoniste Recommandations de l’OWASP sur l’injection de prompt Recommandations de l’OWASP sur le traitement des sorties

Gardez ces distinctions claires lors de l’appréciation des risques. Un document malveillant récupéré par une application de génération augmentée par récupération (RAG) ne relève pas automatiquement de l’empoisonnement des données d’entraînement : la récupération ne met pas, à elle seule, à jour les poids du modèle. Elle peut en revanche exposer l’application à une injection de prompt indirecte.

En matière de sécurité des LLM, des prompts plus robustes ne constituent à eux seuls qu’une stratégie de contrôle incomplète. L’OWASP recommande des mesures telles que des privilèges restreints et une approbation pour les actions sensibles, tandis que le NCSC insiste sur la gestion de l’injection de prompt comme un risque permanent, par la conception et l’exploitation du système. Recommandations de l’OWASP sur l’injection de prompt Recommandations du NCSC sur le risque d’injection de prompt

ISO 27090 face à ISO 27001 et ISO 42001

Ces normes soutiennent des volets différents du travail d’une organisation en matière de sécurité et de gouvernance de l’IA.

Ces distinctions reprennent les descriptions des éditeurs pour ISO 27001, ISO 27002 et ISO 42001.

Pour une équipe qui exploite déjà un SMSI, une approche pragmatique consiste à enrichir les registres existants. Ajoutez les systèmes d’IA concernés à l’inventaire des actifs, évaluez leurs chemins d’attaque, désignez des responsables du traitement et reliez les preuves associées. Pour savoir comment organiser ce travail, consultez la checklist de mise en œuvre d’ISO 27001.

Une checklist pratique de mise en œuvre d’ISO 27090

Les étapes ci-dessous constituent une démarche de mise en œuvre élaborée à partir du contenu de la norme et des recommandations publiques sur l’IA sécurisée. Elles ne forment ni une checklist officielle de l’ISO ni un relevé de clauses obligatoires.

1. Définir le système et son responsable

Choisissez un cas d’usage de l’IA ayant une finalité métier claire. Consignez le responsable redevable, les utilisateurs, le fournisseur du modèle, le mode d’hébergement et les services connectés.

Tracez ensuite le périmètre de la revue. Incluez l’application et ses dépendances, pas seulement le point de terminaison du modèle. Un assistant destiné aux clients et disposant d’un accès à des outils appelle une évaluation différente de celle d’un outil interne de synthèse de texte sans droit d’agir.

Résultat utile : une fiche système indiquant sa finalité, son périmètre, ses dépendances, les actions autorisées et le responsable redevable.

2. Retracer la provenance des données et des modèles

Consignez l’origine des jeux de données et des artefacts de modèle, les personnes habilitées à les modifier et les versions déployées. Incluez les données de fine-tuning, les collections de récupération, les prompts et les canaux de retour pertinents pour le système.

Les recommandations du NCSC sur le développement préconisent de suivre les actifs d’IA et leur provenance, de les protéger et de conserver les informations nécessaires pour restaurer des versions fiables. Recommandations du NCSC sur le développement sécurisé de l’IA

Pour un modèle acheté, demandez au fournisseur quelles responsabilités il assume et quelles informations il communique lorsque les modèles ou les services évoluent.

Résultat utile : un inventaire versionné indiquant les sources, les règles d’accès, l’historique des modifications et les responsabilités des fournisseurs.

3. Modéliser les menaces du flux de travail réel

Examinez le système du point de vue d’un attaquant. Identifiez les points d’entrée, les actifs sensibles, les autorisations et les conséquences d’une compromission réussie. Les recommandations du NCSC sur la conception sécurisée préconisent la modélisation des menaces et une attention particulière aux composants tiers et au moindre privilège. Recommandations du NCSC sur la conception sécurisée de l’IA

Rédigez des scénarios concrets. « Risque lié à l’IA » est trop vague pour déclencher une action utile. « Un document déposé par un tiers persuade l’assistant de demander un fichier de preuves à accès restreint » donne à une équipe un élément précis à analyser.

Hiérarchisez selon l’exposition et le préjudice potentiel. Consignez qui accepte le risque résiduel et à quel moment cette décision doit être réexaminée.

Résultat utile : un court registre des risques reliant les scénarios d’attaque aux actifs, aux conséquences, aux mesures de protection et aux responsables.

4. Placer les mesures de protection aux frontières pertinentes

Sélectionnez des mesures adaptées au scénario traité. Pour les actifs de modèle, il peut s’agir d’un stockage protégé, de restrictions d’accès et de contrôles d’intégrité. Pour les services déployés, envisagez l’authentification, la séparation des environnements et des mesures limitant les accès non autorisés ou l’exfiltration. Ce sont des thèmes des recommandations du NCSC sur le déploiement. Recommandations du NCSC sur le déploiement sécurisé de l’IA

Pour les sorties générées, validez et encodez le contenu en fonction de sa destination avant qu’un autre système n’agisse en conséquence. Les recommandations de l’OWASP sur le traitement des sorties expliquent pourquoi une sortie de modèle ne doit pas acquérir d’autorité du seul fait qu’elle provient du modèle. Recommandations de l’OWASP sur le traitement des sorties

Résultat utile : une fiche de mesure indiquant la frontière qu’elle protège, son responsable et la preuve utilisée pour la vérifier.

5. Tester l’application complète

Concevez les tests autour des conséquences identifiées dans votre modélisation des menaces. Pour un assistant RAG, utilisez des documents antagonistes et des utilisateurs disposant d’autorisations différentes. Pour un agent, testez ce qui se passe lorsqu’un contenu récupéré lui demande de dépasser les actions autorisées.

Définissez le résultat attendu avant d’exécuter le test. Par exemple : l’application doit refuser une demande de fichier à accès restreint même si le modèle tente de formuler cette demande.

Consignez la configuration de l’application, la version du modèle, les entrées de test, le résultat et toute correction. Choisissez des données de test qui n’exposent pas inutilement de véritables informations confidentielles.

Résultat utile : des tests de sécurité reproductibles, liés à des risques précis et aux décisions de mise en production.

6. Surveiller les changements et préparer la réponse

Examinez l’effet des mises à jour de modèles, de données et de prompts. Surveillez les entrées et sorties pertinentes tout en protégeant les informations sensibles dans les journaux. Les recommandations du NCSC sur l’exploitation mettent en avant la surveillance comportementale et les implications de sécurité des changements tout au long de l’exploitation. Recommandations du NCSC sur l’exploitation sécurisée de l’IA

Décidez à l’avance qui peut désactiver un outil, révoquer un identifiant, isoler une intégration ou annuler une version. Fixez des déclencheurs de revue, tels qu’un nouveau fournisseur, des autorisations élargies, une mise à jour significative du modèle ou un incident de sécurité.

Résultat utile : des responsabilités de surveillance, des critères de revue des changements, une procédure de réponse aux incidents et une voie de restauration testée.

Transformer les risques de sécurité de l’IA en preuves

Le tableau ci-dessous est un modèle de travail proposé. Ses exemples de preuves sont des recommandations pratiques, et non une liste de documents imposés par ISO 27090.

Imaginons par exemple une équipe de sécurité qui utilise un assistant pour résumer des preuves fournies par des clients. Un document fourni par un fournisseur contient des instructions demandant de téléverser ces preuves vers une adresse externe.

Le test de l’équipe doit suivre l’action tentée à travers l’application. L’assistant dispose-t-il d’un outil capable de téléverser des fichiers ? Cet outil applique-t-il les autorisations de l’utilisateur ? Les destinations sont-elles restreintes ? Une personne responsable doit-elle approuver le transfert ?

Un enregistrement de revue utile identifierait le scénario, la frontière qui empêche le transfert, le résultat du test et la personne qui a accepté le risque résiduel. Si le système évolue, cet enregistrement indique à la personne chargée de la revue suivante ce qui doit être vérifié à nouveau.

Cette approche donne plus de consistance à une évaluation que l’affirmation selon laquelle le système utilise une « IA responsable ». Elle rattache la décision de sécurité à un élément qu’une autre personne peut examiner. Pour en savoir plus sur l’organisation des éléments justificatifs, consultez comment structurer la préparation à l’audit.

Certification et exigences d’ISO 27090

ISO 27090 fournit des lignes directrices de sécurité, et non des exigences de certification d’un système de management. L’explication de l’ISO distingue son objet des exigences relatives à l’AIMS dans ISO 42001. Explication d’ISO 27090 par l’ISO

Définissez d’abord le niveau d’assurance dont vous avez besoin : une revue de sécurité, une réponse à une demande d’assurance d’un client, une analyse d’écarts interne ou une certification selon une norme de système de management applicable.

Demandez à toute personne proposant une évaluation d’en préciser le périmètre, les critères et le schéma d’assurance. Le résultat est ainsi plus facile à interpréter, et l’on évite de confondre une revue des pratiques de sécurité de l’IA avec la certification d’un système de management.

Pour un projet de mise en œuvre, procurez-vous la norme publiée, confrontez ses lignes directrices à vos propres systèmes et consignez pourquoi certaines mesures de protection sont appropriées. Les exemples de cet article offrent une structure de départ pour ce travail.

ISO 27090 et l’AI Act de l’UE

Appliquer une norme internationale n’établit pas automatiquement la conformité à l’AI Act de l’UE. L’article 40 associe une présomption de conformité aux normes harmonisées dont les références ont été publiées au Journal officiel de l’UE, et uniquement dans la mesure où elles couvrent les exigences ou obligations concernées. Article 40 de l’AI Act

Utilisez une revue de sécurité fondée sur ISO 27090 comme l’un des éléments d’une évaluation de conformité au périmètre distinct. Consignez l’obligation juridique évaluée, les preuves qui l’étayent et tout écart restant.

Questions fréquentes sur ISO 27090

Quelle est la date de publication d’ISO 27090 ?

La première édition, ISO/IEC 27090:2026, a été publiée le 14 octobre 2026. Consultez la fiche actuelle de l’éditeur lorsque des documents plus anciens font référence à un projet ou à une année antérieure. Fiche de publication IEC

ISO 27090 couvre-t-elle l’IA générative et la sécurité des LLM ?

Son contenu publié traite de l’injection de prompt et des sorties sensibles des modèles, ce qui la rend pertinente pour la sécurité de l’IA générative. Son champ d’application couvre aussi d’autres systèmes d’IA. Extrait publié d’ISO/IEC 27090 Explication d’ISO 27090 par l’ISO

Une entreprise qui utilise une IA tierce peut-elle appliquer la norme ?

Oui. Le public visé comprend les organisations qui utilisent l’IA comme celles qui la développent. Commencez par les risques et responsabilités qui relèvent de votre maîtrise, puis identifiez ce que vous devez savoir de vos fournisseurs. Fiche de publication IEC

Une certification ISO 27001 signifie-t-elle qu’un système d’IA est sûr ?

Une certification de système de management ne garantit pas qu’une application donnée résistera à toutes les attaques. Utilisez le système de management pour organiser les décisions relatives aux risques, et évaluez la conception, la configuration et le comportement réels du système d’IA. ISO 27090 peut éclairer ce travail de sécurité.

Où obtenir le PDF d’ISO 27090 ?

Utilisez le catalogue officiel de l’ISO ou l’IEC Webstore pour la norme publiée et les options de licence. Vérifiez que la désignation est bien ISO/IEC 27090:2026. Un article ou un aperçu ne fournit qu’une partie du contenu.

Rendre le travail de sécurité de l’IA vérifiable

Commencez par un cas d’usage de l’IA aux conséquences importantes. Identifiez comment il pourrait être compromis, choisissez des mesures de protection pour les frontières pertinentes et définissez les preuves qui démontreront que ces mesures fonctionnent. Attribuez à chaque action un responsable et un déclencheur de revue.

Secani relie exigences, risques, mesures, preuves, responsables et décisions de revue dans un espace de travail partagé dédié à la sécurité et à la conformité. Échangez avec Secani sur l’organisation de votre travail de sécurité de l’IA, afin que les équipes voient ce qui a été évalué, ce qui requiert une attention et qui en est responsable.