Publiée le 14 octobre 2026, la norme ISO/IEC 27090 est le premier référentiel international consacré aux menaces de sécurité propres aux systèmes d’intelligence artificielle. Volontaire et non certifiable, elle produira pourtant des effets juridiques concrets : par le jeu de l’état de l’art, de l’article 15 de l’AI Act et de la doctrine de l’EDPB, elle devient la grille à laquelle régulateurs et juges mesureront la sécurité de vos systèmes d’IA.
L’essentiel
- L’ISO/IEC 27090:2026 (1re édition) a été publiée le 14 octobre 2026 par le sous-comité ISO/IEC JTC 1/SC 27.
- Elle décrit les menaces propres à l’IA (empoisonnement des données, évasion, vol et inversion de modèles, inférence d’appartenance, injection de prompt) et les moyens de les détecter et de les atténuer.
- C’est un guide : ni certification, ni obligation, ni présomption de conformité à l’AI Act.
- Elle devient pourtant opposable par trois mécanismes : l’état de l’art (RGPD, NIS2), l’article 15 de l’AI Act et la doctrine de l’EDPB sur l’anonymat des modèles.
- Priorité immédiate : revoir les contrats conclus avec les fournisseurs d’IA.
Qu’est-ce que la norme ISO/IEC 27090 ?
L’ISO/IEC 27090:2026 porte sur la cybersécurité de l’intelligence artificielle et, plus précisément, sur le traitement des menaces de sécurité et des compromissions des systèmes d’IA. Élaborée depuis 2022 au sein du sous-comité ISO/IEC JTC 1/SC 27, elle compte 56 pages et a été publiée le 14 octobre 2026.
Elle s’adresse à toute organisation qui développe ou utilise des systèmes d’IA. Son objet est triple : identifier ce qui doit être protégé, des données d’entraînement aux modèles ; comprendre les conséquences des attaques ; détecter et atténuer ces menaces sur tout le cycle de vie du système.
La norme insiste sur un point souvent négligé : les mises à jour et les réentraînements. Dans un système qui apprend en continu, les données d’exploitation deviennent des données d’entraînement, et donc une porte d’entrée pour l’empoisonnement.
Quelles menaces couvre-t-elle ?
| Menace | Ce que fait l’attaquant | Atteinte principale |
|---|---|---|
| Empoisonnement des données | Altère les données d’entraînement ou de réentraînement | Intégrité |
| Évasion | Soumet des entrées conçues pour tromper le modèle en production | Intégrité |
| Vol de modèle | Reproduit le modèle à partir de requêtes d’apparence légitime | Confidentialité, propriété intellectuelle |
| Inversion de modèle | Reconstitue des données d’entraînement à partir des sorties | Confidentialité |
| Inférence d’appartenance | Détermine si une personne figure dans le jeu d’entraînement | Confidentialité |
| Injection de prompt | Dissimule des instructions qui détournent le système | Intégrité, disponibilité |
Ces attaques ont un point commun : elles passent sous le radar des contrôles classiques. Un pare-feu ne voit pas des données empoisonnées, et des requêtes de vol de modèle ressemblent à un usage normal.
Comment s’articule-t-elle avec les normes ISO/IEC 27001, 27002 et 42001 ?
L’ISO/IEC 27001 fixe les exigences d’un système de management de la sécurité de l’information ; l’ISO/IEC 27002 en détaille les mesures ; l’ISO/IEC 42001 encadre le système de management de l’IA. L’ISO/IEC 27090 ne remplace aucune d’elles. Elle les complète en décrivant, menace par menace, ce que ces référentiels ne détaillent pas pour l’IA.
Les normes 27001 et 42001 partageant la même structure, un système de management intégré sécurité et IA est envisageable, la 27090 servant de référentiel technique pour les risques propres à l’IA.
Une norme volontaire : quel statut juridique ?
Formellement, l’ISO/IEC 27090 est un guide de bonnes pratiques. Trois conséquences en découlent.
- Elle n’est pas certifiable. Contrairement aux normes 27001 et 42001, aucun organisme ne délivre de certificat ISO/IEC 27090.
- Elle n’est pas obligatoire. Aucune réglementation ne la rend directement applicable.
- Elle n’est pas une norme harmonisée. Seules les normes harmonisées dont la référence est publiée au Journal officiel de l’Union européenne confèrent une présomption de conformité à l’AI Act (art. 40).
Ce serait pourtant une erreur de la traiter comme du droit souple sans portée.
Pourquoi la norme devient opposable en pratique
1. L’état de l’art : RGPD et NIS2
Le RGPD (art. 32) impose des mesures de sécurité appropriées, appréciées compte tenu de l’état des connaissances. La directive NIS2 (art. 21) exige des entités essentielles et importantes des mesures fondées sur l’état des connaissances et, le cas échéant, sur les normes européennes et internationales pertinentes. Sur ce point, voir notre article sur la transposition de NIS2 en France.
En sécurité de l’IA, cet état des connaissances dispose désormais d’un référentiel international publié. Après un incident, la CNIL, l’ANSSI ou le juge disposeront d’une grille pour apprécier si les mesures prises étaient suffisantes. En matière contractuelle, l’obligation de sécurité d’un prestataire s’apprécie elle aussi au regard des règles de l’art.
2. L’AI Act : l’article 15 vise déjà ces attaques
L’article 15 du règlement (UE) 2024/1689 exige des systèmes d’IA à haut risque qu’ils résistent aux tentatives de tiers non autorisés d’exploiter leurs vulnérabilités. Le texte vise nommément l’empoisonnement des données d’entraînement, l’empoisonnement des composants pré-entraînés, les exemples contradictoires et l’évasion, les attaques contre la confidentialité et les défauts du modèle.
L’ISO/IEC 27090 décrit précisément ces menaces. Dans l’attente des normes harmonisées, elle constituera une référence naturelle pour démontrer le respect de cette exigence.
Le calendrier a été ajusté par le règlement (UE) 2026/1744, dit « Omnibus IA », entré en vigueur le 27 juillet 2026. Les obligations des systèmes à haut risque de l’annexe III s’appliqueront le 2 décembre 2027, celles des systèmes intégrés à des produits réglementés le 2 août 2028. Ce report n’est pas un sursis : c’est un délai de mise en conformité. Les obligations relatives aux modèles d’IA à usage général, dont la cybersécurité des modèles à risque systémique (art. 55), n’ont pas été reportées. Pour les groupes établis hors de l’Union, voir les obligations de l’AI Act pour les entreprises hors UE.
3. Les données personnelles : inversion, inférence et avis 28/2024 de l’EDPB
L’inversion de modèle et l’inférence d’appartenance permettent d’extraire d’un modèle des informations sur les personnes dont les données ont servi à l’entraîner. Ce sont des scénarios de violation de données : notification à la CNIL dans les 72 heures en cas de risque (art. 33 du RGPD) et information des personnes en cas de risque élevé (art. 34).
Dans son avis 28/2024, publié le 18 décembre 2024, l’EDPB considère qu’un modèle entraîné sur des données personnelles ne peut être regardé comme anonyme que si la probabilité d’en extraire des données personnelles, notamment par des attaques d’inférence d’appartenance ou d’inversion, est insignifiante. Un modèle vulnérable à ces attaques reste soumis au RGPD.
Pour le DPO, l’ISO/IEC 27090 devient une grille de lecture des analyses d’impact (art. 35 du RGPD) des projets d’IA. Voir notre accompagnement en conformité RGPD et DPO externalisé.
Ce que les entreprises doivent faire maintenant
Revoir les contrats conclus avec les fournisseurs d’IA
Le chantier prioritaire est contractuel. Un contrat avec un fournisseur d’IA devrait traiter au minimum six points :
- Provenance et intégrité des données d’entraînement : garanties sur l’origine des données et les contrôles anti-empoisonnement.
- Interdiction d’entraîner les modèles sur vos données sans accord exprès et écrit.
- Notification des incidents propres à l’IA : empoisonnement détecté, extraction de modèle, injection de prompt, avec des délais compatibles avec vos propres obligations.
- Encadrement des mises à jour et des réentraînements : information préalable, tests, possibilité de revenir à la version antérieure.
- Journalisation, audit et réversibilité : accès aux journaux, droit d’audit, restitution des données en fin de contrat.
- Répartition des responsabilités calquée sur le couple fournisseur et déployeur de l’AI Act.
Nous rédigeons et négocions ces contrats informatiques et d’IA.
Intégrer les systèmes d’IA au registre des risques
- Recenser tous les usages d’IA, y compris ceux qui n’ont jamais été autorisés.
- Inscrire chaque système d’IA au registre des risques et, le cas échéant, à l’analyse d’impact.
- Ne jamais accorder à un agent d’IA plus de droits qu’à l’utilisateur qu’il assiste.
- Former les équipes à ce qu’elles peuvent confier à un outil d’IA, et à ce qu’elles ne doivent jamais lui confier.
Secteur financier : articuler avec DORA
Pour les entités financières, le règlement DORA (UE) 2022/2554 s’applique depuis le 17 janvier 2025. Un fournisseur de services d’IA est un prestataire tiers de services TIC : les clauses ci-dessus doivent s’articuler avec les dispositions contractuelles obligatoires de l’article 30 de DORA.
Et en Tunisie ?
Le décret-loi n° 2023-17 du 11 mars 2023 relatif à la cybersécurité a été complété par des textes d’application publiés en septembre 2023. Ils déterminent les entités soumises à des audits de sécurité obligatoires et périodiques, ainsi que les normes techniques de ces audits. Un système d’IA intégré au système d’information d’une entité assujettie a vocation à entrer dans leur périmètre.
Pour les entreprises présentes des deux côtés de la Méditerranée, voir aussi nos articles RGPD, loi tunisienne et intelligence artificielle et cadre juridique de la cybersécurité en Tunisie.
Questions fréquentes sur l’ISO/IEC 27090
La norme ISO/IEC 27090 est-elle obligatoire ?
Non. Aucun texte ne l’impose. Mais le RGPD et NIS2 apprécient les mesures de sécurité au regard de l’état des connaissances, que cette norme contribue désormais à définir pour l’IA.
Peut-on obtenir une certification ISO/IEC 27090 ?
Non. C’est un guide de bonnes pratiques. Les certifications possibles restent l’ISO/IEC 27001 (sécurité de l’information) et l’ISO/IEC 42001 (management de l’IA), que la 27090 aide à mettre en œuvre pour les risques propres à l’IA.
L’ISO/IEC 27090 donne-t-elle une présomption de conformité à l’AI Act ?
Non. Seules les normes harmonisées publiées au Journal officiel de l’Union européenne produisent cet effet (art. 40). Elle reste une référence utile pour démontrer le respect de l’article 15.
Quelle différence entre l’ISO/IEC 27090 et l’ISO/IEC 42001 ?
L’ISO/IEC 42001 organise la gouvernance de l’IA dans un système de management certifiable. L’ISO/IEC 27090 est un guide technique centré sur les menaces de sécurité propres aux systèmes d’IA.
Quelles clauses prévoir dans un contrat avec un fournisseur d’IA ?
Au minimum : la provenance des données d’entraînement, l’interdiction d’entraîner les modèles sur vos données, la notification des incidents propres à l’IA, l’encadrement des mises à jour, l’audit et la réversibilité, et une répartition claire des responsabilités.
En conclusion
La sécurité de l’IA est devenue une question de preuve. Le jour d’un incident, on ne vous demandera pas si vous étiez certifié, mais si vos mesures étaient à l’état de l’art. L’ISO/IEC 27090 vient d’en écrire une partie.
À propos de l’auteur. Maître Mohamed Zied El Air est avocat aux Barreaux de Paris et de Tunis et DPO certifié (PECB). Il accompagne les entreprises en France et en Tunisie en protection des données, cybersécurité, droit du numérique et contrats d’IA. Voir sa présentation.
Cet article est une information juridique générale, à jour à sa date de publication. Il ne constitue pas une consultation juridique.