J’apprends que la norme ISO/IEC 27090 est enfin publiée (14 octobre 2026).
C’est quoi?
Son titre complet est ISO/IEC 27090:2026, Cybersecurity, Artificial intelligence (AI), Addressing security threats and compromises to AI systems. En français : Cybersécurité, Intelligence artificielle (IA), Traitement des menaces et des situations susceptibles de compromettre les systèmes d’IA. Autrement dit, les menaces et les compromissions propres aux systèmes d’intelligence artificielle.
Elle compte 56 pages. Elle vient du même comité que l’ISO/IEC 27001, le sous-comité SC 27.
ISO la publie comme norme internationale. C’est un guide, pas une norme d’exigences. Personne ne va être « certifié 27090 ». Les certifications pertinentes restent ISO/IEC 27001 pour la sécurité de l’information et ISO/IEC 42001 pour le système de gestion de l’IA.
Vous pouvez avoir un coupe-feu bien configuré, l’authentification multi-facteur partout, des serveurs à jour et un système de gestion de la sécurité de l’information (SGSI) certifié. Votre système d’IA peut rester vulnérable, puisque l’attaque ne vise plus le serveur. Elle vise les données d’entraînement, le modèle, les questions qu’on lui pose ou ce qu’il répond.
Les neuf menaces
| Menace | Ce qui se passe | Surtout touché |
|---|---|---|
| Empoisonnement des données (data poisoning) | Des données malveillantes glissées dans l’entraînement modifient le comportement futur du modèle. | Intégrité |
| Évasion (evasion attack) | Une entrée légèrement modifiée trompe le modèle, par exemple pour passer sous un filtre de détection. | Intégrité |
| Inférence d’appartenance (membership inference) | Les réponses du modèle révèlent si les données d’une personne ont servi à l’entraîner. | Confidentialité |
| Exfiltration du modèle (model exfiltration) | Des requêtes répétées permettent de reproduire un modèle propriétaire. | Confidentialité |
| Inversion du modèle (model inversion) | Les réponses permettent de reconstituer une partie des données d’entraînement. | Confidentialité |
| Empoisonnement direct du modèle (direct model poisoning) | Le modèle lui-même est altéré ou remplacé, par exemple par une version qui contient une porte dérobée. | Intégrité |
| Sortie sensible (sensitive model output) | Le modèle divulgue de l’information confidentielle qu’il a apprise ou reçue. | Confidentialité |
| Injection d’invite (prompt injection) | Une instruction malveillante, tapée directement ou cachée dans un document, un courriel ou une page web, détourne le modèle. | Intégrité et confidentialité |
| Injection par la sortie (output contains injection attacks) | Le modèle produit du code ou du contenu qui attaque le système qui l’affiche ou l’exécute. | Intégrité |
L’annexe B en ajoute trois : le vol direct du modèle, la fuite des données d’entraînement et la fuite des entrées du modèle, c’est-à-dire ce que vous lui envoyez.
Deux des neuf n’ont même pas besoin d’un attaquant. La sortie sensible et l’injection par la sortie peuvent arriver par accident, dans un usage normal.
L’injection d’invite n’est qu’une menace sur neuf. Si votre analyse de risque IA se limite à ça, vous oubliez les données, le modèle et la chaîne d’approvisionnement.
La plupart des mesures ne sont pas nouvelles non plus. Limiter le nombre de requêtes, journaliser, valider les entrées, traiter les réponses du modèle comme non fiables et protéger l’environnement de développement, c’est de la sécurité applicative classique appliquée à un nouvel sujet.
Où elle se place par rapport à 27001 et 42001
27001 = le cadre. Gestion des risques, gouvernance, audit et amélioration continue.
42001 = la gouvernance de l’IA. Responsabilités, risques et conséquences pour les personnes touchées.
27090 = le détail technique des attaques contre le système d’IA.
Elle ne remplace rien. Elle s’ajoute. La norme classe elle-même chaque menace selon l’actif touché et la propriété compromise (confidentialité, intégrité, disponibilité). Si vous avez un SGSI, ça s’ajoute directement à votre registre des risques. Si vous êtes dans une démarche 42001, elle renvoie à des contrôles précis de 42001, notamment sur la supervision humaine. Le reste de la famille est dans Autour de l’ISO 42001.
C’est pour qui?
La norme vise toute organisation, peu importe sa taille, qui développe ou utilise des systèmes d’IA.
Lu au pied de la lettre, ça veut dire tout le monde. Votre comptable qui utilise Copilot « utilise un système d’IA ».
Pourtant, la valeur de la norme pour vous dépend d’une seule question. Contrôlez-vous une partie du système? Les données, le modèle, l’intégration, les accès ou ce qu’on fait des réponses?
Si vous ne contrôlez rien d’autre que le choix de l’outil et qui l’utilise, la norme a peu à vous offrir. La sécurité du modèle relève du fournisseur. Votre travail est ailleurs.
Quand devriez-vous vous en servir?
Avant de lire 56 pages, posez ces questions pour chaque outil d’IA que vous utilisez ou que vous développez.
- L'IA lit-elle du contenu qui vient de l'extérieur, comme des courriels reçus, des pages web ou des documents de clients?
- Peut-elle agir sans vous, comme envoyer, modifier, payer ou supprimer?
- Peut-elle aller chercher plus d'information que la personne qui l'utilise a le droit de voir?
- Envoyez-vous des renseignements personnels ou confidentiels à un fournisseur infonuagique pour la faire fonctionner?
- Sa réponse est-elle affichée ou exécutée par un autre système?
- Sa réponse peut-elle partir sans qu'une personne la relise?
- Avez-vous entraîné ou ajusté le modèle avec vos propres données?
Un seul oui et la norme est pour vous. Sinon, vous pouvez attendre.
Voici quelques cas de figure.
Vos employés utilisent ChatGPT ou Claude dans leur navigateur
Techniquement, vous utilisez un système d’IA. En pratique, la norme a peu à vous offrir. Le risque principal est ce que vos employés collent dans l’outil, ce que la norme appelle la fuite des entrées du modèle.
Votre priorité est une politique d’usage de l’IA, des forfaits où vos données ne servent pas à entraîner le modèle, des règles claires sur ce qui peut y entrer et de la formation. C’est le même raisonnement que pour les contrôles 42001 qui ne s’appliquent pas si votre PME n’utilise que ChatGPT.
Copilot prépare un brouillon de réponse à vos courriels
Oui, la norme vous concerne. Le courriel reçu est un contenu externe que vous ne contrôlez pas. Si quelqu’un y cache une instruction, c’est de l’injection d’invite indirecte (6.9).
Le cas EchoLeak, publié en juin 2025, le montre bien. Les chercheurs d’Aim Security ont démontré qu’un simple courriel contenant des instructions cachées pouvait amener Microsoft 365 Copilot à extraire des données internes et à les faire sortir de l’entreprise. L’employé n’avait rien à cliquer. Il lui suffisait de poser une question normale à Copilot. Microsoft a corrigé la faille (CVE-2025-32711) et rien n’indique qu’elle a été exploitée. Pourtant, le scénario est exactement celui que décrit la norme. J’en avais déjà parlé plus en détail dans l’article sur l’injection d’invite.
Le brouillon peut contenir de l’information tirée de vos autres courriels ou documents. La norme prend l’exemple d’une firme de consultants qui donne à son IA tous les rapports qu’elle a produits (B.7). Ce que l’IA peut aller chercher doit correspondre à ce que la personne a le droit de voir.
Attention : Copilot branché sur SharePoint voit tout ce que l’utilisateur a le droit de voir, y compris les permissions trop larges oubliées depuis des années. Le modèle n’est pas le problème : ce sont vos accès!
Que le résultat ne soit qu’un brouillon est une bonne chose. La suite, c’est la supervision humaine. Elle devient critique. La norme met en garde contre l’effet de fatigue : à force de cliquer sur « Envoyer », on ne relit plus. Elle prend justement l’exemple d’un agent branché sur la messagerie.
Vous développez un outil où l’IA analyse de l’information pour vous donner un résumé
Oui, même si vous n’entraînez aucun modèle. La norme traite l’IA comme un composant logiciel intégré dans un système. Vous intégrez un modèle, donc vous héritez de ses risques.
Ce qui vous concerne :
- Un document piégé peut fausser le résumé (injection d’invite indirecte).
- Le résumé peut révéler de l’information d’un autre dossier (sortie sensible).
- Si le résumé s’affiche dans une page web, il peut contenir du code qui s’exécute (injection par la sortie). Traitez-le comme une saisie d’utilisateur.
- Ce que vous envoyez à l’interface de programmation (API) d’un fournisseur infonuagique peut fuiter (fuite des entrées).
- Le résumé peut être faux et convaincant. La norme parle de confiance excessive (overreliance).
Ce qui ne vous concerne pas, tant que vous utilisez le modèle d’un fournisseur sans l’ajuster : l’empoisonnement de l’entraînement, l’inversion, l’inférence d’appartenance et l’exfiltration du modèle. Ça, c’est le travail du fournisseur.
Un point que la norme rend explicite (7.6) : si votre outil va chercher dans une base de documents avant de résumer (RAG, génération augmentée par récupération), cette base contrôle les réponses autant que des données d’entraînement. Elle se protège de la même façon.
Vous offrez de l’IA à vos clients
Agent conversationnel sur votre site web, API ou fonction IA dans le logiciel que vous vendez. L’exfiltration du modèle, l’injection par la sortie et la limitation des requêtes vous concernent directement. La norme recommande d’informer les gens qu’une IA est impliquée (6.11.3.4).
Vous entraînez ou ajustez un modèle
Tout l’article 6 s’applique, plus la protection de l’environnement de développement (7.6) et la provenance des données (6.11.4). Personne d’autre ne va gérer ces risques à votre place.
Le lien avec la Loi 25
Trois des neuf menaces font sortir des renseignements personnels par le modèle : l’inférence d’appartenance, l’inversion du modèle et la sortie sensible.
Une communication non autorisée de renseignements personnels est un incident de confidentialité au sens de la Loi 25. Que la fuite passe par un modèle plutôt que par une base de données ne change rien. Vous devez l’évaluer et la consigner, puis aviser la Commission d’accès à l’information et les personnes concernées s’il y a un risque de préjudice sérieux. Le plan à avoir avant l’incident est ici.
Un projet d’acquisition, de développement ou de refonte d’un système qui traite des renseignements personnels exige une évaluation des facteurs relatifs à la vie privée (EFVP). Si votre projet IA touche des renseignements personnels, ces menaces ont leur place dans votre EFVP. Le détail de cette obligation est dans EFVP : l’évaluation à faire avant de signer.
En pratique
Si vous avez répondu oui à au moins une question, voici par où commencer.
- Faites l’inventaire de vos systèmes d’IA, y compris les fonctions IA intégrées dans les logiciels que vous achetez. C’est souvent là qu’est la surprise.
- Commencez par la sécurité classique autour du modèle : comptes, accès, permissions, mises à jour. La norme le dit elle-même (5.1) : c’est souvent un meilleur premier investissement que des contrôles sophistiqués contre les attaques par requêtes.
- Sachez d’où viennent vos modèles et vos données. Sachez aussi qui peut les modifier.
- Ajoutez les scénarios propres à l’IA à votre registre des risques existant. Pas un deuxième registre à côté du premier.
- Journalisez minimalement ce que la norme recommande (7.5) : la question, la réponse, la date, l’heure, l’utilisateur et la version du modèle. Décidez qui va réagir si quelque chose d’anormal apparaît.
- Achetez ensuite la norme (204 francs suisses sur la boutique de l’IEC) pour l’équipe qui crée ou intègre le système.
Bref, ISO/IEC 27090 n’est pas une certification et elle n’est pas pour tout le monde. Si vous ne faites qu’utiliser des outils d’IA, encadrez l’usage et passez à autre chose. Si vous branchez l’IA à vos données ou à vos clients, c’est maintenant la référence pour savoir ce que votre analyse de risque oublie.
Savez-vous combien de vos logiciels ont ajouté une fonction IA dans la dernière année?
Vous voulez savoir où vous en êtes là-dessus? Parlons-en.