Cadre de référence · Sécurité des systèmes d’IA
L’ISO 27090 décrit comment des attaquants peuvent compromettre des systèmes d’IA et comment détecter et contenir ces attaques. Sightadel vous aide à évaluer ces menaces pour chaque système d’IA et à gérer les mesures là où se trouvent déjà vos preuves pour l’ISO 27001, l’ISO 42001 et l’AI Act.
De quoi s’agit-il
La première édition de l’ISO 27090 est parue en octobre 2026. La norme traite des menaces de sécurité qui concernent spécifiquement les systèmes d’IA. Elle décrit les conséquences qu’une attaque peut avoir au cours du cycle de vie d’un système et la manière de détecter et d’atténuer ces attaques. Elle s’adresse aux organisations de tout type et de toute taille qui développent ou utilisent des systèmes d’IA.
Il s’agit d’attaques qui n’existent pas sous cette forme pour les logiciels classiques. L’ISO cite comme exemples l’empoisonnement des données d’entraînement et le vol d’un modèle au moyen de requêtes apparemment anodines. Des articles spécialisés sur la norme mentionnent d’autres types, comme des entrées préparées qui trompent un modèle, l’injection de prompt ou les déductions sur les données d’entraînement. La norme aide aussi à déterminer ce qui doit être protégé, des données d’entraînement jusqu’au modèle final.
L’ISO 27090 est un guide. Elle ne contient pas d’exigences selon lesquelles un organisme certifie, ni de système de management propre. L’ISO la présente comme un complément à l’ISO 27001 et à l’ISO 27002 : si vous exploitez un SMSI, vous intégrez les menaces propres à l’IA dans l’appréciation des risques et choisissez les mesures adaptées. Pour l’instant, la norme n’existe qu’en anglais.
Les clients et les acheteurs demandent comment vous protégez les modèles et les données d’entraînement contre la manipulation. La norme vous donne un langage commun pour ces réponses et une liste d’attaques que vous devriez avoir examinées.
Même si vous n’utilisez un modèle de langage que via un fournisseur, vous êtes concerné, par exemple lorsque le texte d’e-mails ou de documents pousse le système à une mauvaise action. L’essentiel porte alors sur le choix du fournisseur, la configuration et la surveillance.
Si vous exploitez l’ISO 27001 ou l’ISO 42001, vous n’avez pas besoin d’un nouveau processus. Les menaces de l’ISO 27090 entrent dans l’appréciation des risques existante, les mesures dans le plan de traitement existant.
Exigences
Résumé avec nos propres mots. Seul le texte original dans sa version en vigueur fait foi.
Vous savez quels systèmes d’IA vous développez ou utilisez et quelles parties doivent être protégées : données d’entraînement, modèles, entrées et sorties.
Dans SightadelVous enregistrez les systèmes d’IA et leurs composants comme actifs avec un responsable. Un inventaire IA issu de l’ISO 42001 se réutilise.
Les types d’attaques envisageables pour vos systèmes sont connus, par exemple l’empoisonnement des données ou le vol de modèle, de même que les dégâts qu’une attaque réussie causerait.
Dans SightadelVous consignez les menaces par système d’IA dans le registre des risques, évaluées et reliées aux actifs concernés.
Les attaques sont rattachées aux phases où elles agissent : développement, exploitation et mise à jour du modèle.
Dans SightadelLes points ouverts de chaque phase deviennent des plans d’action avec responsable et échéance.
Les conséquences d’une attaque sont estimées, en particulier là où l’IA intervient dans des applications critiques pour la sécurité ou dans des décisions importantes.
Dans SightadelL’évaluation figure avec le risque, la justification dans le commentaire. Le journal d’activité montre qui a décidé quoi et quand.
Pour les menaces pertinentes, des mesures sont choisies qui permettent de détecter les attaques ou d’en limiter l’effet.
Dans SightadelChaque mesure avec statut, responsable et preuve. La même mesure peut aussi couvrir une exigence de l’ISO 27001 ou de l’ISO 42001.
Les données d’entraînement, les modèles pré-entraînés et les services d’IA de tiers sont traités comme une porte d’entrée possible. Vous savez d’où ils viennent et qui peut les modifier.
Dans SightadelVous évaluez les fournisseurs de données, de modèles et de services d’IA dans le module Fournisseurs, avec questionnaire et preuves.
En exploitation, vous surveillez les signes d’attaque, comme des schémas de requêtes inhabituels. Les incidents touchant des systèmes d’IA suivent le processus habituel de gestion des incidents.
Dans SightadelLes enseignements tirés des incidents deviennent des mesures assorties d’une échéance, et l’historique reste visible dans le journal d’activité.
Les menaces propres à l’IA font partie de l’appréciation des risques du SMSI, les mesures du plan de traitement.
Dans SightadelVous reliez les preuves une seule fois et les utilisez pour l’ISO 27001, l’ISO 42001 et l’AI Act.
Déroulement
Deux à quatre mois jusqu’à l’analyse des menaces et au plan de mesures pour les principaux systèmes d’IA, si un SMSI fonctionne déjà. La mise en œuvre des mesures techniques peut prendre plus de temps.
Lister tous les systèmes d’IA, y compris les services achetés. Noter pour chaque système les données, modèles et interfaces qui en font partie.
Parcourir la norme pour voir quels types d’attaques concernent quel système et à quelle phase ils agissent.
Estimer conséquences et probabilité, en commençant par les systèmes critiques. Les résultats vont dans le registre des risques existant.
Choisir les contre-mesures, nommer les responsables, étayer la mise en œuvre par des preuves. Planifier les mesures techniques avec le développement et l’exploitation.
Observer l’exploitation, réévaluer après un changement de modèle et lorsque de nouveaux types d’attaques sont connus, et intégrer les résultats à la revue de direction.
Prêt à démarrer
Clarifier ces questions tôt fait gagner des semaines par la suite. Dans Sightadel, elles sont prévues comme premières tâches.
Répartition des rôles
Si un logiciel remplissait tout, la norme manquerait son but – et l’auditeur s’en apercevrait. C’est pourquoi ce qui reste de votre ressort est clairement défini.
Retours du terrain
Tirés de longues années de conseil et de certification : ce sont les points qui coûtent le plus de temps ou mènent à des non-conformités lors de l’audit.
Pare-feu et contrôle d’accès n’aident pas contre des données d’entraînement empoisonnées ou des entrées préparées. Examinez à part les attaques qui visent le modèle lui-même.
Les modèles de langage des logiciels standard et des services cloud en font partie. C’est justement là que fonctionnent les attaques par les entrées, même sans modèle entraîné par vos soins.
Il n’en existe pas pour l’ISO 27090. Prévoyez la preuve via l’audit ISO 27001 ou ISO 42001 ou via une vérification externe.
Sa mise en œuvre aide pour l’art. 15 de l’AI Act, mais ne prouve pas la conformité. Vérifiez séparément les obligations légales.
Sans le développement et les responsables des données, l’analyse des menaces reste théorique. Qui construit ou exploite le modèle a sa place autour de la table.
Nouveaux modèles, nouvelles données et nouveaux types d’attaques changent sans cesse la situation. Définissez des déclencheurs de réévaluation et examinez régulièrement les systèmes critiques.
Une preuve, plusieurs frameworks
Nous ne donnons volontairement aucun pourcentage – il dépend de votre périmètre. Là où les exigences se recoupent, une même preuve est rattachée à toutes.
L’ISO présente l’ISO 27090 comme un complément à l’ISO 27001 et 27002. L’appréciation des risques, le plan de traitement, le processus de gestion des incidents et l’audit interne du SMSI portent aussi les mesures pour les systèmes d’IA.
ISO 42001Le système de management de l’IA exige une appréciation des risques pour les systèmes d’IA. L’ISO 27090 en fournit la partie consacrée aux attaques ciblées, et l’inventaire IA sert aux deux.
EU AI ActL’art. 15 exige robustesse et cybersécurité pour les systèmes d’IA à haut risque, explicitement aussi contre l’empoisonnement des données, le contournement de modèle et les attaques contre la confidentialité. L’ISO 27090 aide à la mise en œuvre, mais n’est pas une norme harmonisée.
RGPDLes attaques qui permettent des déductions sur les données d’entraînement peuvent exposer des données personnelles. Pour la protection de la vie privée dans l’IA, l’ISO prépare la norme sœur ISO 27091, qui n’est pas encore publiée.
Audit et preuve
On ne peut pas se faire certifier selon l’ISO 27090. La norme est un guide et ne contient pas d’exigences auditables. Elle devient visible à travers les systèmes de management dans lesquels vous l’intégrez : lors d’un audit ISO 27001 ou ISO 42001, vous montrez comment vous avez évalué et traité les menaces pesant sur les systèmes d’IA.
Si vous souhaitez un regard indépendant, faites vérifier l’analyse des menaces et les mesures par un tiers. Sightadel ne vérifie pas. Vous choisissez un vérificateur dans notre réseau de partenaires indépendants ou celui de votre choix, et aucune commission n’est versée pour les vérifications, ni à nous ni aux partenaires. Le vérificateur obtient dans Sightadel un accès dédié aux réponses, justifications et preuves et ne peut rien supprimer.
Vers le réseau d’auditeurs indépendantsL’ISO 27090 se concentre sur les menaces qui touchent uniquement ou principalement les systèmes d’IA. Elle les rattache au cycle de vie, décrit les conséquences possibles et montre comment détecter et atténuer les attaques. La description de la norme par l’ISO cite explicitement l’empoisonnement des données d’entraînement et le vol d’un modèle au moyen de requêtes qui ressemblent à une utilisation normale. Elle souligne aussi les conséquences dans les applications critiques pour la sécurité.
La norme ne redéfinit pas la sécurité de l’information en général. Contrôle d’accès, chiffrement, journalisation, gestion des vulnérabilités et continuité restent du ressort de l’ISO 27001 et 27002. L’ISO 27090 intervient là où ces mesures ne suffisent pas pour l’IA, par exemple quand un attaquant modifie le comportement d’un modèle par les données ou les entrées sans prendre le contrôle d’un serveur.
L’équité, la transparence ou l’impact sur les personnes concernées ne sont pas non plus son sujet. Pour cela, il existe l’ISO 42001 avec l’appréciation des risques et l’analyse d’impact pour l’IA, ainsi que l’AI Act de l’UE. Pour la vie privée dans l’IA, l’ISO élabore la norme sœur ISO 27091. Qui introduit la norme doit connaître cette délimitation afin que les responsabilités ne soient pas attribuées deux fois ou pas du tout.
La norme elle-même s’achète auprès de l’ISO ou d’un organisme national de normalisation. Vous n’avez pas besoin d’un organisme de certification, puisqu’il n’y a pas de certificat. Licence Sightadel pour l’ISO 27090 : Prix sur demande. Si vous gérez déjà l’ISO 27001 ou l’ISO 42001 dans Sightadel, vous continuez à utiliser le registre des risques, les mesures et les preuves.
Le poste le plus important est le temps des spécialistes. Une analyse des menaces pour des systèmes d’IA ne se fait pas par la seule équipe de sécurité de l’information. Il vous faut des personnes qui connaissent les modèles, les données et les interfaces : développement, responsables des données, exploitation et, pour les services achetés, les achats. Prévoyez plusieurs séances de travail par système d’IA critique.
La mise en œuvre des mesures techniques peut coûter cher, par exemple des contrôles supplémentaires sur les données d’entraînement, des limites de requêtes ou des tests avec des entrées préparées à dessein. Il vaut la peine de procéder par criticité et de commencer par les systèmes où une attaque causerait le plus de dégâts. Là où l’expérience manque, vous ajoutez du conseil sous forme de forfait directement dans l’application.
À l’art. 15, l’AI Act de l’UE exige que les systèmes d’IA à haut risque atteignent un niveau approprié d’exactitude, de robustesse et de cybersécurité tout au long de leur cycle de vie. Parmi les attaques citées figurent l’empoisonnement des données, l’empoisonnement de modèle, les entrées préparées pour contourner le modèle, les attaques contre la confidentialité et les défauts du modèle. Cela recoupe largement les thèmes de l’ISO 27090.
La norme n’est pas pour autant une preuve de conformité. Ce n’est pas une norme harmonisée dont la référence est publiée au Journal officiel de l’UE, elle ne crée donc pas de présomption que l’art. 15 est respecté. Le CEN-CENELEC élabore une norme européenne distincte sur la cybersécurité des systèmes d’IA au titre du règlement, qui n’existe pour l’instant qu’à l’état de projet. Après le report de 2026, les obligations pour les systèmes à haut risque s’appliquent à partir de décembre 2027 pour les systèmes autonomes et d’août 2028 pour l’IA dans les produits réglementés.
Si votre système est considéré comme à haut risque et quelles obligations en découlent, vous le vérifiez séparément, de préférence avec votre conseil juridique. Sightadel ne fournit pas de conseil juridique à ce sujet. Pour les obligations légales, Sightadel dispose d’un framework distinct consacré à l’AI Act, que vous gérez avec les mêmes preuves.
L’effort est le plus faible lorsque vous utilisez l’ISO 27090 comme source de connaissances pour des processus existants. Dans l’appréciation des risques selon l’ISO 27001, vous ajoutez pour chaque système d’IA les menaces de la norme. Les mesures choisies vont dans le plan de traitement et, lorsqu’elles dépassent l’annexe A, dans la Déclaration d’applicabilité comme mesures supplémentaires.
Si vous exploitez l’ISO 42001, l’inventaire IA vous donne déjà la liste des systèmes, de leurs finalités et de leurs responsables. L’appréciation des risques liés à l’IA y porte sur les risques pour l’organisation et pour les personnes concernées. L’ISO 27090 aide à remplir correctement la partie sur les attaques ciblées, plutôt que de la régler avec des phrases générales sur la sécurité informatique.
Dans Sightadel, menaces, mesures et preuves sont rattachées au système d’IA concerné. Vous reliez la même mesure, par exemple un contrôle de l’origine des données d’entraînement, à l’ISO 27001, à l’ISO 42001 et à l’AI Act. Vous la tenez ainsi à jour une seule fois et voyez dans chaque framework où elle compte. Lors de l’audit interne, vous vérifiez ensuite si les mesures pour les systèmes d’IA fonctionnent comme prévu.
Dans l’empoisonnement des données, un attaquant introduit des données manipulées dans l’entraînement afin que le modèle réagisse ensuite de manière erronée ou dans son intérêt. Cela compte surtout si vous entraînez ou réentraînez vous-même des modèles, par exemple avec des données d’internet, de clients ou de prestataires. Des sources connues, des contrôles avant l’entraînement et des droits clairs sur qui peut modifier les données offrent une protection.
Dans le vol de modèle, un attaquant envoie de nombreuses requêtes et construit à partir des réponses un modèle qui se comporte de façon similaire. Sont surtout concernés les fournisseurs dont le modèle est accessible via une interface. Des schémas de requêtes inhabituels et des limites par utilisateur sont ici des points de départ évidents. Si vous ne faites qu’acheter de l’IA, cette attaque vous concerne généralement moins.
Les systèmes à modèle de langage ajoutent l’injection de prompt : des instructions cachées dans des entrées, des e-mails ou des documents amènent le système à contourner des règles ou à divulguer des données. Cela touche aussi les entreprises qui n’utilisent l’IA que via un fournisseur. Le détail des attaques décrites par la norme se trouve dans son texte. Sightadel ne contient pas ce texte.
Comme il n’y a pas de certificat, personne n’impose une documentation précise. Utiles, et précieux lors des audits ISO 27001 ou ISO 42001 : une liste des systèmes d’IA avec les éléments à protéger, l’analyse des menaces par système, les mesures choisies avec leur justification et les preuves de leur mise en œuvre et de leur efficacité. Consignez qui a réalisé quelle évaluation et quand.
Les systèmes d’IA évoluent plus vite que beaucoup d’autres systèmes. Un nouveau modèle chez le fournisseur, un nouveau jeu de données ou une nouvelle interface peut modifier l’évaluation. Définissez quels changements déclenchent une nouvelle analyse et faites du contrôle une étape fixe des achats et de la mise en service. Après un incident ou lorsqu’une nouvelle attaque est connue, examinez les systèmes concernés hors calendrier.
Dans Sightadel, les réévaluations, les revues des fournisseurs, l’audit interne et la revue de direction fonctionnent sous forme de cycles récurrents avec échéance. Dans le Trust Center, vous montrez à vos clients comment vous sécurisez les systèmes d’IA, sans rassembler de nouveaux documents pour chaque demande.
Ce que cela coûte
Vous ne payez que les frameworks dont vous avez réellement besoin. Les éditions diffèrent par leur capacité et leur délai de réponse, pas par leur contenu métier. Gérer plusieurs frameworks vous fait économiser durablement. Tous les prix, remises et un simulateur se trouvent sur la page des tarifs.
L’organisme de certification ou d’audit vous facture directement ses honoraires. Si besoin, vous ajoutez un accompagnement sous forme de forfait dans l’application.
Documents de travail
Vous trouverez des check-lists et modèles pour d’autres frameworks dans la rubrique Ressources.
Aides pratiques, pas de conseil juridique.
Notions clés
Questions et réponses
Plus de réponses dans la FAQ ou directement via notre formulaire de contact.
Non. La norme est un guide sans exigences auditables. Lors d’un audit ISO 27001 ou ISO 42001, vous pouvez toutefois montrer comment vous avez évalué et traité les menaces pesant sur les systèmes d’IA.
Oui. La première édition est parue en octobre 2026, pour l’instant uniquement en anglais.
Pas automatiquement. Sur le fond, la norme correspond bien aux obligations de cybersécurité des systèmes d’IA à haut risque, mais ce n’est pas une norme harmonisée. Si des obligations vous concernent et lesquelles, vous le vérifiez séparément. Sightadel ne fournit pas de conseil juridique à ce sujet.
Souvent oui, à plus petite échelle. Les attaques par les entrées, comme l’injection de prompt, touchent aussi les services utilisés. L’accent porte alors sur le choix du fournisseur, la configuration, les droits du système et la surveillance.
L’ISO présente l’ISO 27090 comme un complément à l’ISO 27001 et 27002. Vous intégrez les menaces propres à l’IA dans l’appréciation des risques de votre SMSI et gérez les mesures dans le même plan de traitement.
L’ISO 42001 est le système de management de l’IA avec inventaire, appréciation des risques et analyse d’impact. L’ISO 27090 apporte une expertise sur les attaques ciblées qui alimente cette appréciation des risques. Seule l’ISO 42001 donne lieu à un certificat.
Licence Sightadel : Prix sur demande, tous les détails figurent sur la page des tarifs. S’y ajoutent l’exemplaire de la norme et votre effort interne. Il n’y a pas de frais d’organisme de certification.
Non. Les normes ISO sont protégées par le droit d’auteur. Sightadel contient la structure, les questions guides, les modèles et ses propres explications, pas le texte de la norme. Il vous faut un exemplaire de la norme en interne.
Outre la sécurité de l’information, les personnes qui développent ou exploitent les modèles, les responsables des données et, pour les services achetés, les achats. Sans elles, l’analyse reste superficielle.
14 jours, accès complet, sans données de paiement. Tout ce que vous créez est conservé dans l’offre payante.
