ISO/IEC 27090 : la nouvelle norme pour sécuriser vos systèmes d’IA

L’intelligence artificielle s’installe partout dans les organisations : assistants, analyse de documents, agents qui agissent dans vos outils. Elle hérite de toutes les menaces classiques de l’informatique, et en ajoute de nouvelles. Publiée en octobre 2026, la norme ISO/IEC 27090 propose pour la première fois un cadre international pour les comprendre, les détecter et les traiter.

À qui s’adresse-t-elle ?

À toutes les organisations, quelle que soit leur taille, publiques ou privées, qui développent des systèmes d’IA ou qui les utilisent. Elle couvre l’ensemble du cycle de vie : conception, entraînement, mise en service, exploitation et mises à jour.

Le point de départ : la sécurité classique

Le message de fond est rassurant : un système d’IA reste avant tout un logiciel, intégré dans d’autres applications. Les bonnes pratiques d’ISO/IEC 27001 et 27002 restent donc le socle. La norme souligne même que sécuriser l’infrastructure qui héberge un modèle est souvent un investissement plus efficace que des protections très spécifiques à l’IA.

Elle insiste aussi sur des fondations organisationnelles : un programme de gouvernance de l’IA, les principes du zero trust, les bonnes pratiques de développement logiciel, la maîtrise de la chaîne d’approvisionnement (modèles, données et composants fournis par des tiers), la modélisation des menaces et les exercices de type red teaming.

Les menaces propres à l’IA

Le cœur de la norme passe en revue neuf grands types de compromission. Pour chacun, elle décrit l’attaque, ses conséquences possibles, les moyens de la détecter et de la traiter. En résumé :

• Empoisonnement des données : des données d’entraînement manipulées faussent le comportement du modèle ;
• Évasion : des entrées spécialement conçues trompent le modèle lors de son utilisation ;
• Inférence d’appartenance : un attaquant découvre si une donnée précise, par exemple personnelle, a servi à l’entraînement ;
• Exfiltration de modèle : des requêtes en apparence légitimes permettent de reconstituer le modèle ;
• Inversion de modèle : les réponses du modèle servent à reconstituer des informations sur ses données d’entraînement ;
• Empoisonnement direct du modèle : le modèle lui-même est modifié ;
• Sorties sensibles : le modèle divulgue des informations qu’il n’aurait pas dû révéler ;
• Injection de prompt : des instructions malveillantes, parfois cachées dans un document ou une page web, détournent le comportement du modèle ;
• Sorties porteuses d’attaques : la réponse du modèle transporte du code ou des commandes malveillantes vers les systèmes qui l’exploitent.

Les bons réflexes qu’elle met en avant

• Limiter les données : n’utiliser que ce qui est nécessaire, ne pas conserver plus longtemps que besoin, chiffrer.
• Encadrer le comportement des systèmes d’IA : supervision humaine, transparence, validation continue, tests de biais, et moindre privilège pour les agents d’IA, qui ne doivent avoir accès qu’à ce dont ils ont besoin.
• Assurer la traçabilité des modèles et des données utilisées.
• Journaliser et surveiller l’utilisation des systèmes d’IA, filtrer les entrées anormales, limiter le volume de requêtes.
• Protéger l’environnement de développement.
• Revoir régulièrement les mesures : un modèle et ses protections peuvent se dégrader dans le temps, et certaines mesures peuvent même entrer en conflit entre elles.

Une norme de recommandations, pas de certification

ISO/IEC 27090 est un guide : on ne se fait pas certifier ISO/IEC 27090. Elle s’articule avec les autres références :

• ISO/IEC 27001 : votre système de management de la sécurité reste le cadre, dans lequel vous intégrez les menaces propres à l’IA ;
• ISO/IEC 42001 : elle encadre la gouvernance de l’IA dans un système de management certifiable ; ISO/IEC 27090 en apporte le volet sécurité ;
• L’AI Act : le règlement européen exige des systèmes d’IA à haut risque un niveau approprié de robustesse et de cybersécurité (article 15), notamment face à l’empoisonnement des données ou des modèles. ISO/IEC 27090 donne des pistes concrètes pour y parvenir.

Le sujet rejoint aussi NIS2 : dans son courrier d’août 2026 aux entités essentielles, le CCB belge cite les nouvelles menaces liées à l’IA de pointe pour justifier la priorité donnée aux mesures fondamentales. La norme est pour l’instant disponible en anglais.

Mon avis : une utilisation pragmatique

ISO/IEC 27090 est un document riche, et c’est justement là le piège : la tentation est grande de la traiter comme une liste de contrôles à cocher intégralement. Ce n’est pas, à mon sens, la bonne approche. Je la vois plutôt comme un catalogue de menaces dans lequel on puise selon son usage réel de l’IA.

Tout dépend de votre profil. La plupart des organisations ne développent pas de modèles : elles les utilisent. Les priorités ne sont donc pas les mêmes pour tout le monde :

• Vous utilisez des outils d’IA du marché (assistants, fonctions intégrées à vos logiciels) : concentrez-vous sur ce que vous y partagez, sur la gouvernance des usages et sur les engagements de vos fournisseurs. L’empoisonnement de modèle ou l’inférence d’appartenance concernent d’abord l’éditeur, pas vous.
• Vous connectez l’IA à vos données ou à vos outils (assistant branché sur vos documents, agents qui agissent dans vos applications) : c’est aujourd’hui le profil le plus exposé. L’injection de prompt, les sorties sensibles et les droits excessifs des agents deviennent vos priorités.
• Vous entraînez ou adaptez vos propres modèles : là, l’ensemble des menaces décrites par la norme vous concerne, de l’empoisonnement des données à l’exfiltration du modèle.

Ne créez pas un nouveau silo. Plutôt qu’un projet « sécurité de l’IA » à part, intégrez les menaces propres à l’IA dans votre analyse de risques existante et dans votre système de management. C’est plus simple, moins coûteux, et cohérent avec ISO 27001 comme avec NIS2.

Commencez par les fondamentaux. La norme le dit elle-même : sécuriser l’infrastructure, les accès et les fournisseurs est souvent plus rentable que des protections sophistiquées propres à l’IA. Avant d’investir dans des outils spécialisés, vérifiez que vos bases sont solides.

Gardez un œil sur les agents d’IA. Dès qu’une IA peut agir, envoyer un message, modifier un dossier ou déclencher une commande, le risque change de nature. Le principe du moindre privilège et la supervision humaine des actions sensibles sont, à mon avis, les deux mesures les plus utiles à mettre en place rapidement.

Par où commencer ?

1. Faites l’inventaire de vos usages d’IA, y compris les outils proposés par vos fournisseurs et ceux que vos équipes utilisent déjà.
2. Vérifiez vos fondamentaux : les systèmes qui hébergent ou appellent l’IA sont-ils couverts par vos mesures de sécurité habituelles ?
3. Intégrez les menaces propres à l’IA dans votre analyse de risques, avec ISO 27005 ou EBIOS Risk Manager.
4. Encadrez les agents d’IA : droits limités, supervision humaine pour les actions sensibles, journalisation.
5. Interrogez vos fournisseurs sur la provenance de leurs modèles et sur leurs propres mesures.
6. Sensibilisez vos équipes, notamment à l’injection de prompt et au partage de données sensibles.

En résumé

ISO/IEC 27090 ne remplace rien : elle complète votre sécurité existante pour l’adapter à l’IA. C’est une référence précieuse pour innover avec l’IA en toute sécurité et pour préparer les exigences de l’AI Act. Si vous souhaitez faire le point sur vos usages d’IA et leurs risques, je vous propose un premier échange de 30 minutes, sans engagement.