L’essentiel
- La sécurité de l’IA consiste à protéger les données, les modèles, les chaînes de traitement et les interfaces d’un système d’IA sur tout son cycle de vie. C’est une discipline distincte de l’usage de l’IA au service de la cybersécurité.
- Avec le règlement européen sur l’IA, la sécurité de l’IA n’est plus facultative : l’article 15 impose aux systèmes à haut risque un niveau approprié d’exactitude, de robustesse et de cybersécurité, y compris face aux attaques adverses et à l’empoisonnement des données.
- Les menaces sont propres à l’apprentissage automatique : exemples adverses, empoisonnement des données et des modèles, vol de modèle, injection d’invite et traitement non sécurisé des sorties, recensés dans l’OWASP Top 10 pour les applications LLM et dans MITRE ATLAS.
- On ne protège pas ce que l’on n’a pas inventorié : le registre des systèmes d’IA et la découverte du shadow AI constituent le premier contrôle, pas un détail.
- Les organisations qui réussissent traitent la sécurité de l’IA comme un jeu de contrôles gouverné, relié au règlement européen, à l’ISO/IEC 42001 et au NIST AI RMF, avec des preuves qu’un auditeur acceptera plutôt qu’un simple tableau de bord.
Qu’est-ce que la sécurité de l’IA ?
La sécurité de l’IA désigne la protection d’un système d’IA et de tout ce dont il dépend : les données d’entraînement et d’inférence, le modèle lui-même, les chaînes qui le construisent et le servent, ainsi que les interfaces qui l’exposent aux utilisateurs et aux autres systèmes. Elle couvre l’ensemble du cycle de vie, de la collecte des données à l’entraînement, au déploiement, à la surveillance, puis au retrait.
Une distinction embrouille souvent les premières discussions, autant la poser clairement. Utiliser l’IA pour la sécurité, c’est appliquer l’apprentissage automatique à des tâches défensives, par exemple la détection d’anomalies ou le tri des alertes. La sécurité de l’IA, objet de ce guide, consiste à protéger le système d’IA lui-même contre les attaques et les défaillances. La nuance compte, car les deux mobilisent des responsables, des contrôles et des preuves différents.
Pourquoi cette distinction pèse-t-elle sur la conformité ? Parce que le régulateur traite désormais la sécurité du système d’IA comme une obligation nommée. Le règlement européen réunit exactitude, robustesse et cybersécurité dans un même article pour les systèmes à haut risque (article 15 du RIA). Dès lors que la sécurité relève d’une exigence légale et non d’une préférence d’ingénierie, elle appelle une gouvernance : des contrôles définis, une responsabilité attribuée et des traces qui prouvent que les contrôles fonctionnent.
Pourquoi la sécurité de l’IA est devenue une exigence de conformité
Pendant une décennie, sécuriser un modèle fut une bonne idée cantonnée à l’ingénierie. La donne a changé. Trois instruments font aujourd’hui de la sécurité de l’IA une obligation documentée.
D’abord, le règlement européen sur l’IA. L’article 15 impose aux fournisseurs de systèmes à haut risque de les concevoir pour atteindre un niveau approprié d’exactitude, de robustesse et de cybersécurité, et de maintenir ces propriétés tout au long de la vie du système. Il désigne l’adversaire sans détour : le système doit résister aux tentatives de tiers non autorisés visant à altérer son usage, ses sorties ou ses performances, y compris les attaques adverses et l’empoisonnement des données.
Ensuite, l’ISO/IEC 42001. La norme de 2023 est le premier système de management de l’IA certifiable, et ses contrôles de l’annexe A intègrent la sécurité de l’IA, la gouvernance des données et l’atténuation des attaques adverses dans un système qu’un organisme externe peut auditer (ISO/IEC 42001). La sécurité y trouve une place dans un cycle gouverné plutôt que dans un arriéré de tâches.
Enfin, le cadre de gestion des risques de l’IA du NIST. Le NIST structure le travail en quatre fonctions, Gouverner, Cartographier, Mesurer et Gérer, et c’est dans la fonction Gérer que vivent les contrôles de sécurité (NIST AI RMF). Lu avec la correspondance des cadres présentée dans notre guide des référentiels, il transforme la sécurité en routine reproductible et documentée.
L’écart entre l’obligation et la capacité reste large. Dans une évaluation de Microsoft portant sur 28 organisations, 25 ne disposaient pas des bons outils pour sécuriser leurs systèmes d’IA. C’est la conformité qui comble cet écart, car elle impose l’inventaire, le choix des contrôles et la preuve, au lieu de laisser la sécurité à qui pense à la réclamer.
Le paysage des menaces sur l’IA
Protéger un système d’IA commence par savoir contre quoi on se défend. Les attaques sur l’IA ne se calquent pas sur la sécurité applicative classique, car le modèle, les données et l’invite sont autant de surfaces d’attaque. Mieux vaut regrouper les menaces par cible. La base de connaissances MITRE ATLAS recense ces techniques dans une matrice inspirée d’ATT&CK, et notre guide MITRE ATLAS déroule la correspondance entre technique et contrôle.
Attaques sur le modèle
Les exemples adverses sont des entrées façonnées pour tromper le modèle tout en paraissant normales à l’oeil humain. Les attaques par évasion les emploient à l’inférence pour franchir un classifieur. L’extraction de modèle, ou vol de modèle, interroge un modèle déployé assez de fois pour en reconstruire une copie fonctionnelle, dérobant la propriété intellectuelle et créant un modèle miroir que l’attaquant sonde hors ligne.
Attaques sur les données
L’empoisonnement corrompt le jeu d’entraînement afin que le modèle apprenne la mauvaise chose, d’une simple dégradation de l’exactitude à des portes dérobées déclenchées par une entrée choisie. Les attaques par inférence d’appartenance font l’inverse : elles cherchent à savoir si un enregistrement précis figurait dans les données d’entraînement, ce qui peut exposer des informations personnelles ou confidentielles.
Attaques sur la couche applicative
Pour les systèmes bâtis sur de grands modèles de langage, la couche applicative est désormais la cible la plus tendre. L’OWASP Top 10 pour les applications LLM place en tête l’injection d’invite, où l’attaquant dissimule des instructions dans une invite, un document ou la sortie d’un outil pour contourner les garde-fous, exfiltrer des données ou déclencher des actions via les outils connectés. Le traitement non sécurisé des sorties, quand la réponse du modèle est propagée sans validation, transforme un défaut de langage en compromission du système.
Chaîne d’approvisionnement et risques agentiques
Modèles, jeux de données et bibliothèques proviennent de tiers : un modèle à poids ouverts empoisonné ou une dépendance compromise sont des risques de chaîne d’approvisionnement. Les systèmes agentiques, capables d’appeler des outils et d’agir sur leurs propres sorties, élargissent le rayon d’impact : une seule injection réussie peut se propager en actions réelles. Notre guide des agents d’IA autonomes traite des contrôles de gouvernance que ces systèmes exigent.
On ne protège pas ce que l’on ne voit pas : inventaire de l’IA et shadow AI
Chaque contrôle qui suit suppose que vous savez quels systèmes d’IA vous exploitez. La plupart des organisations l’ignorent. Les équipes adoptent des copilotes, intègrent des modèles tiers et branchent des agents plus vite qu’aucune fonction centrale ne peut suivre, produisant du shadow AI : de l’IA en usage que la gouvernance n’a jamais vue.
Le shadow AI est un problème de sécurité avant d’être un problème de conformité. Un modèle non recensé n’a ni responsable, ni évaluation des menaces, ni surveillance, ni procédure d’incident. Le premier contrôle d’un programme de sécurité de l’IA n’est donc pas un pare-feu, c’est un inventaire. Un registre vivant des systèmes d’IA, de leurs données, de leurs modèles et de leur niveau de risque rend possibles tous les contrôles ultérieurs. Notre guide du shadow AI explique comment l’IA cachée devient une faille de gouvernance, et pourquoi la découverte est le contrôle zéro.
Relier la sécurité de l’IA aux cadres : RIA, ISO 42001, NIST AI RMF
Le geste qu’aucune page concurrente ne fait consiste à relier chaque menace au contrôle qui y répond et à la clause qui l’exige. C’est ce qui transforme la sécurité de l’IA, d’une liste de courses d’outils, en une position de conformité défendable.
| Obligation | Ce qu’elle exige | Contrôle qui y répond |
|---|---|---|
| Article 15 du RIA (robustesse) | Résistance aux erreurs, défauts et manipulations adverses | Tests adverses et red teaming, tests hors distribution |
| Article 15 du RIA (cybersécurité) | Résistance à l’altération non autorisée de l’usage, des sorties ou des performances | Contrôle d’accès, intégrité du modèle et des données, service sécurisé |
| ISO/IEC 42001 annexe A | Contrôles de sécurité de l’IA gérés dans un système certifié | Jeu de contrôles documenté, responsable désigné, cycle de revue |
| NIST AI RMF (Gérer) | Traitement priorisé des risques d’IA identifiés | Registre des risques, correspondance des contrôles, surveillance |
Construisez la correspondance une fois et chaque audit devient une simple consultation plutôt qu’une course. L’explication de l’ISO 42001 et le guide du NIST AI RMF approfondissent chaque versant, et le guide opérationnel du RIA situe l’article 15 parmi les obligations plus larges des systèmes à haut risque.
Des menaces aux contrôles auditables
Une menace que l’on ne peut pas prouver est une menace que l’on ne peut pas défendre en audit. Chaque classe de menace doit donc se résoudre en un contrôle nommé, doté d’un responsable et d’une trace.
- Attaques adverses et par évasion : tests adverses et red teaming programmés, résultats consignés et rejoués à chaque évolution du modèle.
- Empoisonnement des données : traçabilité et provenance des données, contrôles d’intégrité sur la chaîne d’entraînement.
- Vol de modèle : limitation de débit, surveillance des requêtes et contrôle d’accès sur les points d’inférence.
- Injection d’invite et sorties non sécurisées : validation des entrées et des sorties, listes d’autorisation des outils, isolement entre le modèle et les actions en aval.
- Dérive et obsolescence : surveillance continue des performances et du comportement, avec des seuils qui déclenchent une alerte.
L’intérêt de rédiger les contrôles ainsi n’est pas la liste, c’est la preuve. Un tableau de bord montre un état à l’instant présent ; un auditeur veut une trace dans la durée. Chaque contrôle doit produire un artefact daté : un rapport de test, un journal de surveillance, une revue d’accès. Notre guide de l’auditabilité précise ce qui rend un système d’IA auditable et comment le prouver, et la surveillance continue de la conformité est ce par quoi ces artefacts s’accumulent sans course manuelle avant chaque revue.
Qui est responsable de la sécurité de l’IA ? Rôles et gouvernance
La sécurité de l’IA échoue quand chacun suppose qu’un autre en a la charge. La cybersécurité classique relève du RSSI, mais la sécurité de l’IA traverse la science des données, le MLOps et la conformité : la responsabilité doit donc être explicite.
Un partage praticable confie la responsabilité à un référent ou un comité de gouvernance de l’IA, le RSSI répondant des contrôles de sécurité, la science des données des tests de modèle, et la conformité des preuves et de la correspondance aux cadres. Une courte matrice de responsabilités, arrêtée une fois, prévient l’échec courant où un modèle est livré sans responsable de sa sécurité. Cette couche de gouvernance fait l’objet de notre guide du système d’exploitation de la gouvernance de l’IA, qui montre comment ces rôles se relient à l’environnement de contrôle.
Comment mettre en oeuvre un programme de sécurité de l’IA
Traduire ces idées en programme opérationnel relève d’une séquence, pas d’un projet avec une date de fin.
- Inventorier chaque système d’IA, shadow AI compris, et attribuer à chacun un niveau de risque.
- Mener une évaluation des menaces et des risques par système, avec l’OWASP LLM Top 10 et MITRE ATLAS comme listes de contrôle.
- Choisir les contrôles à partir de votre correspondance aux cadres et désigner un responsable pour chacun.
- Tester les contrôles : tests adverses, red teaming et validation, calibrés selon le niveau de risque.
- Recueillir la preuve sous forme d’artefacts datés pour chaque contrôle.
- Surveiller en continu la dérive, les abus et les nouvelles vulnérabilités.
- Intégrer la gestion des incidents, y compris le signalement réglementaire lorsqu’il est requis. Le règlement européen fixe des obligations de signalement des incidents graves, traitées dans notre guide du signalement au titre de l’article 73.
Menez la séquence en boucle. Chaque nouveau modèle rentre à l’étape une, et chaque changement notable relance les tests et la preuve.
Questions fréquentes
Qu’est-ce que la sécurité de l’IA, simplement ?
La sécurité de l’IA, c’est protéger un système d’IA, ses données, son modèle, ses chaînes de traitement et ses interfaces, contre les attaques et les défaillances sur tout son cycle de vie. Elle se distingue de l’usage de l’IA pour la sécurité, comme la détection de menaces. En contexte de conformité, elle recouvre aussi des obligations nommées, comme l’exigence de l’article 15 du règlement européen imposant aux systèmes à haut risque de maintenir exactitude, robustesse et cybersécurité.
Quelle différence entre sécurité de l’IA et cybersécurité ?
La cybersécurité classique protège réseaux, applications et terminaux. La sécurité de l’IA ajoute des surfaces d’attaque que les contrôles classiques ne couvrent pas : les données d’entraînement, le comportement appris du modèle et l’invite. Un pare-feu n’arrête ni l’empoisonnement des données ni l’injection d’invite. La sécurité de l’IA prolonge donc la cybersécurité par des contrôles conscients du modèle, tests adverses, traçabilité des données et validation des sorties, reliés aux cadres propres à l’IA.
Quelles sont les principales menaces sur l’IA ?
Les classes récurrentes sont les exemples adverses et attaques par évasion sur les modèles, l’empoisonnement des données et des modèles, le vol ou l’extraction de modèle, l’inférence d’appartenance, l’injection d’invite et le traitement non sécurisé des sorties sur la couche applicative, et les risques de chaîne d’approvisionnement liés aux modèles et bibliothèques tiers. L’OWASP Top 10 pour les applications LLM et MITRE ATLAS sont les deux catalogues de référence que la plupart des équipes utilisent pour vérifier qu’aucune catégorie ne manque.
Le règlement européen sur l’IA impose-t-il la sécurité de l’IA ?
Oui. L’article 15 impose aux fournisseurs de systèmes à haut risque d’atteindre et de maintenir un niveau approprié d’exactitude, de robustesse et de cybersécurité, stable sur toute la vie du système. Il nomme explicitement la résistance aux attaques adverses et à l’empoisonnement des données. La sécurité est donc une obligation documentée pour les systèmes à haut risque, non une pratique d’ingénierie facultative.
Quel lien entre ISO 42001, NIST AI RMF et la sécurité de l’IA ?
L’ISO/IEC 42001 est un système de management de l’IA certifiable dont les contrôles de l’annexe A incluent la sécurité de l’IA, lui donnant un foyer gouverné et auditable. Le NIST AI RMF structure le travail en Gouverner, Cartographier, Mesurer et Gérer, les traitements de sécurité vivant dans la fonction Gérer. Ensemble, ils permettent de relier chaque contrôle de sécurité à une clause reconnue, ce qui fait de l’audit une consultation plutôt qu’une course.
Par où commencer un programme de sécurité de l’IA ?
Par l’inventaire. On ne peut ni sécuriser, ni tester, ni attester un système d’IA que l’on n’a pas recensé, et la plupart des organisations exploitent du shadow AI que la gouvernance n’a jamais vu. Construisez un registre vivant des systèmes d’IA avec leurs données, leurs modèles et leurs niveaux de risque, puis menez les évaluations de menaces, choisissez des contrôles reliés aux cadres, testez-les et recueillez des preuves datées. L’inventaire est le contrôle zéro ; tout le reste en dépend.
Conclusion
La sécurité de l’IA est passée du confort d’ingénierie à l’obligation de conformité nommée, et les pages qui se classent sur le terme n’ont pas suivi : elles décrivent des menaces et vendent des outils, sans relier la sécurité aux cadres qui l’exigent désormais. Les organisations qui s’y prennent bien traitent la sécurité de l’IA comme un jeu de contrôles gouverné, relié au règlement européen, à l’ISO 42001 et au NIST AI RMF, partant d’un inventaire honnête pour aboutir à des preuves qu’un auditeur acceptera. AI Sigil est conçu pour exécuter précisément cette boucle, de la découverte de l’IA à la correspondance des contrôles jusqu’aux preuves prêtes pour l’audit. Découvrez comment le système d’exploitation de la gouvernance de l’IA fait de la sécurité de l’IA une capacité défendable et continue.