Cybersécurité de l'IA : ce qu'exige l'AI Act

La cybersécurité de l'IA désigne la protection des systèmes d'intelligence artificielle contre les attaques qui visent leurs données d'entraînement, leur modèle, les requêtes qu'ils reçoivent et les actions qu'ils déclenchent. L'AI Act en fait une exigence légale pour les systèmes à haut risque : son article 15 impose exactitude, robustesse et cybersécurité, et nomme les attaques à contrer (empoisonnement des données ou du modèle, exemples contradictoires, atteintes à la confidentialité). Ces exigences s'appliqueront en décembre 2027, mais les attaques, elles, existent déjà. Cet article, qui complète notre guide sur l'AI Act, présente les menaces, le cadre légal et les mesures recommandées par l'ANSSI.

Un système d'IA reste un système d'information : serveurs, comptes, interfaces de programmation (API), dépendances logicielles. Toutes les mesures classiques s'y appliquent. Mais il présente trois particularités. Son comportement dépend de données autant que de code : altérer le jeu d'entraînement revient à modifier le programme. Il interprète des entrées en langage naturel, où instructions et données se mélangent. Et, de plus en plus, il agit : envoyer un courriel, lancer une requête dans une base, modifier un fichier.

L'ANSSI a fait le point sur la menace dans sa synthèse publiée le 4 février 2026. Elle n'a pas connaissance d'attaques contre des acteurs français menées grâce à l'IA de bout en bout, mais elle relève que les systèmes d'IA deviennent eux-mêmes des cibles : empoisonnement de données, modèles piégés diffusés en source ouverte, failles dans les connecteurs entre agents et outils, comptes d'IA volés par des logiciels espions, fuites de données saisies par des salariés. La sécurité de l'IA n'est donc pas une question d'avenir réservée aux fournisseurs de modèles : elle concerne toute organisation qui en déploie.

L'article 15 du règlement (UE) 2024/1689 fait partie des exigences applicables aux systèmes d'IA à haut risque. Il pèse d'abord sur le fournisseur, qui conçoit le système, mais il conditionne ce que le déployeur peut attendre de lui. Il comporte trois volets.

Exactitude

Le système atteint un niveau d'exactitude approprié à sa destination, et ce niveau, avec les indicateurs utilisés pour le mesurer, figure dans la notice d'utilisation. La Commission doit encourager, avec les organismes de métrologie, l'élaboration de méthodes de mesure communes.

Robustesse

Le système résiste autant que possible aux erreurs, défaillances et incohérences, notamment liées à son environnement ou à ses interactions avec des personnes ou d'autres systèmes. Des solutions de redondance, de secours ou de sécurité intégrée peuvent y contribuer. Pour un système qui continue d'apprendre après sa mise en service, il faut éviter que des sorties biaisées ne réalimentent ses futures entrées (boucles de rétroaction).

Cybersécurité

Le système résiste aux tentatives de tiers non autorisés d'en modifier l'usage, les sorties ou les performances en exploitant ses vulnérabilités. Le paragraphe 5 nomme les attaques propres à l'IA contre lesquelles il faut des mesures pour prévenir, détecter, réagir, résoudre et maîtriser : la manipulation du jeu d'entraînement (« empoisonnement des données »), celle des composants préentraînés (« empoisonnement de modèles »), les entrées conçues pour induire le modèle en erreur (« exemples contradictoires » ou « contournement de modèle »), les attaques visant la confidentialité et les défauts du modèle.

Calendrier et normes

Depuis le règlement omnibus (UE) 2026/1744, entré en vigueur le 27 juillet 2026, ces exigences s'appliquent à partir du 2 décembre 2027 pour les systèmes de l'annexe III et du 2 août 2028 pour ceux intégrés à des produits réglementés (annexe I). La conformité pourra se démontrer par des normes harmonisées : celle qui porte sur la cybersécurité, prEN 18282, préparée par le comité technique commun CEN-CENELEC JTC 21, était encore à l'état de projet en octobre 2026. L'article 42 prévoit aussi une présomption de conformité pour les systèmes certifiés dans le cadre d'un schéma européen de cybersécurité du règlement sur la cybersécurité (Cybersecurity Act).

Les fournisseurs de modèles d'IA à usage général présentant un risque systémique ont, eux, une obligation de cybersécurité propre (article 55), applicable depuis le 2 août 2025 : garantir une protection adaptée du modèle et de son infrastructure physique.

Plusieurs référentiels classent ces attaques. Le NIST AI 100-2 E2025, publié en mars 2025 par l'institut américain des normes, distingue pour l'IA prédictive le contournement (évasion), l'empoisonnement et les atteintes à la confidentialité, et ajoute pour l'IA générative les attaques sur la chaîne d'approvisionnement et l'injection de requêtes, directe ou indirecte. L'ANSSI, dans son guide de 2024, retient trois familles : la manipulation (détourner le système en production par des requêtes malveillantes), l'infection (contaminer l'entraînement) et l'exfiltration (voler des données ou les paramètres du modèle). L'ENISA propose de son côté un cadre de bonnes pratiques en trois couches : socle de cybersécurité classique, mesures propres à l'IA, mesures sectorielles.

Le schéma ci-dessous les replace sur les quatre maillons d'un système d'IA.

Un modèle de langage ne sépare pas strictement les consignes de son concepteur et les données qu'il traite : tout est du texte. L'injection de requêtes, ou prompt injection, exploite cette faiblesse. Directe, l'utilisateur rédige lui-même une requête qui contourne les garde-fous. Indirecte, l'instruction malveillante est cachée dans une page web, un document partagé ou un courriel que l'assistant lit pour accomplir sa tâche, à l'insu de l'utilisateur.

L'OWASP Top 10 pour les applications de grands modèles de langage (édition 2025) la place en tête, devant la divulgation d'informations sensibles, les failles de la chaîne d'approvisionnement, l'empoisonnement, le traitement non sécurisé des sorties et l'« autonomie excessive ». Ce dernier point devient central avec les agents : l'OWASP leur consacre depuis décembre 2025 un Top 10 spécifique. Plus un système peut agir, plus une injection réussie a de conséquences.

Aucune technique ne supprime ce risque. L'ANSSI l'écrit dans son bulletin du 13 avril 2026 sur les agents d'IA installés sur les postes de travail : des consignes défensives rédigées dans les instructions du modèle peuvent être contournées, et le durcissement de la configuration reste le levier principal. Elle y recommande de ne pas déployer ces outils en production tant qu'ils ne sont pas éprouvés, de les cantonner à des environnements de test isolés sans données sensibles, de limiter leurs capacités au strict nécessaire et d'exiger une validation humaine pour toute action ayant des effets.

L'empoisonnement consiste à introduire des données malveillantes dans ce qui sert à entraîner ou à ajuster un modèle, pour dégrader ses résultats ou y installer une porte dérobée qui ne s'active qu'en présence d'un motif précis. La synthèse de l'ANSSI cite une étude selon laquelle 250 documents malveillants peuvent suffire à empoisonner un modèle. Le risque concerne aussi les bases documentaires qu'un assistant consulte pour répondre (génération augmentée par récupération) : y glisser un document piégé revient à empoisonner ses réponses.

Les modèles eux-mêmes sont des composants logiciels venus de tiers. Certains formats de fichiers permettent d'exécuter du code au chargement : l'ANSSI recommande des formats sûrs et des contrôles d'intégrité. Les modèles et jeux de données téléchargés depuis des plateformes publiques, les bibliothèques et les connecteurs forment une chaîne d'approvisionnement à inventorier, comme les dépendances d'un logiciel classique ; c'est la logique de la nomenclature logicielle (SBOM), que certains étendent aux composants d'IA. Pour les services d'IA achetés, cette vigilance passe par la gestion des risques tiers et un questionnaire fournisseur qui interroge la provenance des modèles, l'usage de vos données et la protection contre ces attaques.

Le guide de l'ANSSI Recommandations de sécurité pour un système d'IA générative, publié le 29 avril 2024, est la référence française. Il couvre tout le cycle de vie, de l'entraînement à la production, en 35 recommandations. Les plus structurantes :

• conduire une analyse de risques avant la phase d'entraînement et intégrer la sécurité à chaque étape ;
• évaluer la confiance accordée aux bibliothèques, modules et sources de données externes ;
• cloisonner les environnements d'entraînement, de déploiement et de production, et isoler le système d'IA dans un environnement dédié ;
• privilégier un hébergement qualifié SecNumCloud pour les usages sensibles ;
• n'entraîner le modèle que sur des données que ses utilisateurs ont le droit de connaître, et protéger l'intégrité des données et des fichiers du modèle ;
• filtrer les entrées et les sorties, et sécuriser les interactions avec les applications métier ;
• interdire les actions automatisées sur des opérations critiques sans validation humaine, et limiter celles déclenchées par des contenus non fiables ;
• journaliser l'ensemble des traitements : requêtes, appels à des greffons et à des données, filtrages, réponses ;
• prévoir un mode dégradé qui fonctionne sans l'IA ;
• ne jamais confier de données sensibles à des services d'IA grand public en ligne.

L'ANSSI a complété ce guide par une analyse de haut niveau, Développer la confiance dans l'IA par une approche par les risques cyber (février 2025), rédigée avec la CNIL, l'Inria, le LNE, le PEReN et l'AMIAD et cosignée par des partenaires étrangers, par des recommandations communes avec le BSI allemand sur les assistants de programmation (octobre 2024 : relecture systématique du code généré, pas de génération pour les modules critiques), puis par le bulletin d'avril 2026 sur les agents.

Trois textes européens se rencontrent sur la sécurité de l'IA. Ils ne visent ni les mêmes acteurs ni le même objet, mais ils se renvoient l'un à l'autre.

Le pont le plus explicite figure à l'article 12 du Cyber Resilience Act : un produit à éléments numériques qui est aussi un système d'IA à haut risque et qui satisfait aux exigences essentielles du CRA est présumé conforme aux exigences de cybersécurité de l'article 15, dans la mesure où sa déclaration UE de conformité le couvre. L'évaluation de la conformité suit la procédure de l'AI Act, sauf pour certains produits importants ou critiques au sens du CRA. Un fabricant de logiciel intégrant de l'IA a donc intérêt à mener les deux démarches ensemble ; notre guide sur le Cyber Resilience Act détaille ses obligations.

NIS 2, enfin, ne parle pas d'IA, mais ses mesures de gestion des risques (article 21) couvrent tout le système d'information de l'entité, y compris les systèmes d'IA qu'elle utilise et les fournisseurs qui les lui procurent. Un incident important touchant un assistant d'IA, une fuite de données par exemple, entre dans le régime de notification.