Sécuriser un système d'IA, c'est d'abord le traiter comme un système d'information à part entière : hébergement, comptes à privilèges, chaîne d'approvisionnement et journalisation restent les premiers points d'attaque. L'ANSSI considère d'ailleurs la compromission de l'infrastructure d'hébergement et d'administration comme un vecteur particulièrement plausible et critique 2. Mais un système d'IA générative ajoute des menaces propres : l'injection de prompt, l'empoisonnement des données ou du modèle, et l'extraction de données sensibles.
Ces menaces ont une caractéristique commune : elles exploitent le fait qu'un modèle de langage ne sépare pas strictement les instructions des données. Aucune défense ne les élimine totalement ; le NIST souligne qu'il n'existe pas de preuve de sécurité théorique pour les algorithmes d'apprentissage automatique courants et que la plupart des parades sont empiriques 4. La réponse passe donc par une défense en profondeur et par une limitation stricte de ce que le système peut faire.
Cet article passe en revue les principales menaces et les parades issues de trois références : les guides de l'ANSSI, le Top 10 de l'OWASP pour les applications LLM et la taxonomie des attaques adverses du NIST.
Sécuriser un système d'IA : cartographier la surface d'attaque
Le guide de l'ANSSI sur la sécurité des systèmes d'IA générative, publié en avril 2024, couvre l'ensemble du cycle de vie, de l'entraînement au déploiement et à la production, à travers 35 recommandations 1. Son analyse de risques de février 2025, cosignée par 19 agences partenaires étrangères, identifie plusieurs scénarios prioritaires 2 :
- La compromission de l'infrastructure d'hébergement et d'administration.
- La compromission de la chaîne d'approvisionnement, notamment par des bibliothèques open source ou des modèles pré-entraînés.
- La latéralisation via les interconnexions, par exemple une injection indirecte de prompt pouvant aller jusqu'à l'exécution de commandes.
- Les failles humaines et organisationnelles : dépendance excessive à l'automatisation, « shadow IA », dépendance technologique.
- Les dysfonctionnements des réponses, par exemple à la suite d'un empoisonnement des données d'entraînement.
L'OWASP propose une liste complémentaire, orientée application. Son Top 10 2025 pour les applications LLM recense : injection de prompt, divulgation d'informations sensibles, chaîne d'approvisionnement, empoisonnement des données et du modèle, traitement inapproprié des sorties, autonomie excessive, fuite du prompt système, faiblesses des vecteurs et des embeddings, désinformation et consommation non bornée 3. Cette liste est un bon support pour structurer les tests d'intrusion et les revues d'architecture.
L'injection de prompt, menace numéro un
L'injection de prompt occupe la première place du Top 10 OWASP 3. Elle prend deux formes. L'injection directe passe par la saisie de l'utilisateur, qui détourne volontairement ou non le comportement du modèle. L'injection indirecte, plus insidieuse, passe par un contenu externe ingéré par le système, page web, document, courriel, qui contient des instructions cachées 3. Avec la généralisation des architectures RAG et des agents dotés d'outils, l'injection indirecte devient la voie privilégiée pour exfiltrer des données ou déclencher des actions non prévues.
Les parades recommandées
L'OWASP recommande une combinaison de mesures 3, que les recommandations de l'ANSSI viennent renforcer 1 :
- Contraindre le comportement du modèle par le prompt système (rôle, périmètre, refus des tentatives de contournement), sans jamais en faire la seule barrière.
- Définir des formats de sortie attendus et les valider par du code déterministe.
- Filtrer les entrées et les sorties (ANSSI R25) et évaluer la pertinence et l'ancrage des réponses.
- Appliquer le moindre privilège : identifiants propres à l'application, fonctions sensibles exécutées par le code et non exposées au modèle.
- Exiger une validation humaine pour les actions à risque ; l'ANSSI proscrit l'usage automatisé de l'IA pour des actions critiques sur le SI (R9) et demande de limiter les actions automatiques d'un système traitant des entrées non maîtrisées (R27).
- Isoler et étiqueter les contenus externes non fiables.
- Tester régulièrement par des simulations d'attaque en traitant le modèle comme un utilisateur non fiable.
La seule hypothèse robuste : tout ce que le modèle lit peut devenir une instruction. Ce qu'il est autorisé à faire doit donc être borné en dehors du modèle.
Empoisonnement des données et du modèle
L'empoisonnement consiste à manipuler les données d'entraînement, de réglage fin ou d'indexation pour altérer le comportement du modèle. Le NIST distingue l'empoisonnement de disponibilité, qui dégrade le modèle de façon indiscriminée, l'empoisonnement ciblé, réputé difficile à contrer, et les portes dérobées, qui implantent un déclencheur activé ensuite en production 4. Pour les entreprises, le risque le plus concret vient de la chaîne d'approvisionnement : modèles téléchargés depuis des dépôts publics, bibliothèques tierces, jeux de données externes, et aussi bases documentaires alimentant un RAG.
Le CERT-FR rappelle dans sa synthèse de la menace publiée en février 2026 que des modèles open source malveillants peuvent exécuter du code au téléchargement et installer une porte dérobée, et que des failles dans les serveurs MCP élargissent la surface d'attaque 5. Les parades portent surtout sur la maîtrise des sources :
- Évaluer le niveau de confiance des bibliothèques, modules et sources de données externes (ANSSI R3 et R4) 1.
- Utiliser des formats de modèles sécurisés, qui n'exécutent pas de code au chargement (ANSSI R6) 1.
- Protéger en intégrité les données d'entraînement (ANSSI R19) et n'entraîner qu'avec des données légitimement accessibles aux utilisateurs (R18) 1.
- Cartographier la chaîne d'approvisionnement, composants logiciels, matériels et jeux de données compris 2.
- Contrôler les droits d'écriture sur les corpus indexés par un RAG, au même titre que sur une base de production.
Fuite et extraction de données
La divulgation d'informations sensibles figure au deuxième rang du Top 10 OWASP, et la fuite du prompt système au septième 3. Le NIST décrit plusieurs attaques visant la confidentialité : inférence d'appartenance d'une donnée au jeu d'entraînement, extraction de données d'entraînement depuis un modèle génératif, reconstruction de données, extraction du modèle lui-même 4. À ces attaques s'ajoute le risque le plus banal : des collaborateurs qui saisissent des données confidentielles dans un service grand public. Le CERT-FR cite le cas, rendu public en 2023, de salariés de Samsung ayant divulgué des données relatives aux semi-conducteurs via ChatGPT 5.
Les parades combinent architecture et usages. L'ANSSI demande de prendre en compte la confidentialité et le besoin d'en connaître dès la conception (R7 et R8), et de proscrire l'usage d'outils d'IA générative sur Internet pour un usage professionnel impliquant des données sensibles (R34) 1. En pratique, un assistant RAG doit appliquer les droits d'accès de l'utilisateur au moment de la recherche documentaire, et non se contenter de filtrer la réponse. Le prompt système ne doit contenir aucun secret, identifiant ou règle dont la divulgation poserait problème.
Les fondamentaux à ne pas négliger
Les recommandations les plus structurantes de l'ANSSI ne sont pas spécifiques à l'IA, et ce sont souvent celles qui manquent dans les projets menés rapidement 1 :
- Mener une analyse de risque avant l'entraînement ou l'intégration (R2).
- Héberger le système dans des environnements de confiance cohérents avec les besoins de sécurité (R11), et privilégier un hébergement SecNumCloud en cloud public (R14).
- Cloisonner chaque phase du système dans un environnement dédié (R12) et le système lui-même dans des environnements techniques dédiés (R28).
- Maîtriser et sécuriser les accès à privilèges des développeurs et administrateurs (R10).
- Journaliser l'ensemble des traitements réalisés au sein du système (R29).
- Prévoir des audits de sécurité avant la mise en production (R23).
Ces mesures ont un intérêt supplémentaire : elles limitent l'impact d'une attaque réussie, quelle qu'en soit la technique. Un agent qui n'a accès qu'aux données strictement nécessaires, dont chaque action est journalisée et dont les opérations sensibles exigent une validation, reste maîtrisable même si une injection de prompt parvient à contourner les filtres.
L'analyse de risques de 2025 insiste aussi sur l'adaptation du niveau d'autonomie du système à la criticité des actions, sur la limitation des interconnexions au strict besoin et sur la supervision continue 2. Enfin, les parades doivent être évaluées contre des attaquants adaptatifs : le NIST note que de nombreuses défenses, testées face à des attaques faibles, ont ensuite été contournées 4.
Conclusion
Sécuriser un système d'IA ne demande pas de réinventer la sécurité, mais de l'appliquer avec rigueur à un composant qui ne distingue pas instructions et données. Les priorités sont claires : borner les privilèges et l'autonomie, maîtriser la chaîne d'approvisionnement, filtrer et journaliser, tester en continu. DATASWING intègre ces exigences dès la conception des architectures d'IA qu'elle déploie et opère.
— Questions fréquentes
Ce qu'on nous demande souvent
Qu'est-ce qu'une injection de prompt indirecte ?+
C'est une attaque où les instructions malveillantes ne viennent pas de l'utilisateur mais d'un contenu que le système d'IA lit : page web, document, courriel ou résultat d'outil. Le modèle les interprète comme des consignes et peut divulguer des données ou déclencher des actions. Elle concerne particulièrement les assistants RAG et les agents connectés à des outils.
Comment se protéger de l'injection de prompt ?+
Aucune mesure unique ne suffit. Il faut combiner filtrage des entrées et sorties, validation des formats de réponse par du code, moindre privilège pour l'application, séparation des contenus non fiables, validation humaine des actions à risque et tests d'attaque réguliers. L'ANSSI recommande aussi de proscrire les actions critiques automatisées sur le SI.
Que contient le Top 10 OWASP pour les LLM ?+
La version 2025 liste dix risques : injection de prompt, divulgation d'informations sensibles, chaîne d'approvisionnement, empoisonnement des données et du modèle, traitement inapproprié des sorties, autonomie excessive, fuite du prompt système, faiblesses des vecteurs et embeddings, désinformation et consommation non bornée des ressources.
Que recommande l'ANSSI pour sécuriser une IA générative ?+
Son guide d'avril 2024 formule 35 recommandations couvrant tout le cycle de vie : analyse de risque préalable, hébergement de confiance et SecNumCloud en cloud public, cloisonnement des phases, maîtrise des accès à privilèges, filtrage des entrées et sorties, journalisation, audits avant production et interdiction des actions critiques automatisées.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
Recommandations de sécurité pour un système d'IA générative ↗ANSSI · 2024-04
- [2]
-
[3]
LLM01:2025 Prompt Injection - OWASP Top 10 for LLM Applications ↗OWASP Gen AI Security Project · 2025
- [4]
-
[5]
L'IA générative face aux attaques informatiques : synthèse de la menace en 2025 ↗CERT-FR / ANSSI · 2026-02
