Un chiffre pour poser le décor. En 2025, plus de 90 % des organisations testent des cas d'usage d'IA générative. Mais seules 5 % se déclarent prêtes sur le plan cyber. Le fossé est énorme. Et c'est exactement là que ça casse.
Vous branchez un LLM sur vos données, vos outils, vos API. Tout marche en démo. Puis un jour, une requête bien tournée fait fuiter une info sensible, ou un agent envoie un mail qu'il n'aurait jamais dû envoyer. Ce guide est fait pour éviter ça. On liste les menaces réelles et les parades concrètes, celles qu'une équipe technique lyonnaise peut mettre en place sans budget de multinationale.
Pourquoi la sécurité LLM en production est un chantier à part
Sécuriser une IA générative en entreprise, ce n'est pas sécuriser une appli web classique. Le modèle traite du langage naturel. Il ne distingue pas nativement une instruction légitime d'une instruction malveillante glissée dans un texte. C'est la faille de base.
Et le problème grossit avec l'autonomie. Les LLM ne se contentent plus de répondre. Ils envoient des e-mails, interrogent des bases de données, appellent des API, prennent des décisions. Ce passage du passif à l'actif change tout. La puissance du modèle devient la surface d'attaque.
Un chiffre récent le montre bien. La documentation technique de Claude Opus 4.5 (Anthropic, novembre 2025) rapporte un taux de réussite d'une injection de prompt indirecte en environnement de codage agentique de 4,7 % en une tentative. Ça monte à 33,6 % en dix tentatives, et 63 % en cent tentatives. La leçon est simple : plus l'agent est autonome et plus les interactions se répètent, plus le risque grimpe. Un attaquant patient finit par passer.
Les cadres de référence à connaître
Bonne nouvelle : vous n'avez pas à tout inventer. Trois références structurent le sujet.
OWASP Top 10 for LLM Applications
Publié en 2023, mis à jour fin 2024 pour l'édition 2025. Il réordonne les risques selon les incidents réels et l'essor de l'IA agentique. Il ajoute deux nouvelles catégories. L'injection de prompt garde la première place pour la deuxième édition consécutive.
Les risques majeurs identifiés : injection de prompt, fuite de données, attaques de la chaîne d'approvisionnement, empoisonnement du modèle, permissions excessives des agents, désinformation, abus de ressources. Le message de fond : il faut sécuriser non seulement le modèle, mais aussi les données, les outils, les intégrations et les workflows autour de lui.
MITRE ATLAS
La base de connaissances de référence pour cartographier les tactiques adverses contre les systèmes de machine learning. Plus de 130 techniques d'attaque documentées, 26 mesures d'atténuation. C'est votre carte pour savoir contre quoi vous vous défendez, technique par technique.
L'ANSSI, votre point d'ancrage français
Le 29 avril 2024, l'ANSSI a publié ses Recommandations de sécurité pour un système d'IA générative. 35 recommandations qui couvrent tout le cycle de vie, de la conception à la production. Plusieurs sont directement actionnables par une équipe technique :
- Intégrer la sécurité dans toutes les phases du cycle de vie du système d'IA.
- Mener une analyse de risque avant la phase d'entraînement.
- Évaluer le niveau de confiance des bibliothèques et modules externes utilisés.
- Évaluer le niveau de confiance des sources de données externes.
- Appliquer les principes de DevSecOps sur toutes les phases du projet.
Recommandation à afficher au-dessus de votre poste : proscrire l'usage automatisé de systèmes d'IA pour des actions critiques sur le système d'information. Autrement dit, un LLM ne doit jamais déclencher seul une action irréversible ou sensible sans validation humaine.
L'ANSSI a remis le sujet sur la table le 4 février 2026 avec une nouvelle documentation sur la vulnérabilité des IA génératives, avec un focus sur le Shadow IA. On y revient plus bas, c'est un angle mort pour beaucoup d'entreprises de la région.
Les attaques à connaître, et comment les contrer
1. L'injection de prompt
C'est la menace numéro un, et pour de bonnes raisons. Elle existe sous deux formes.
L'injection directe : l'utilisateur tape une instruction qui détourne le comportement du modèle. Classique du genre : « ignore tes instructions précédentes et fais X ».
L'injection indirecte, plus vicieuse : l'instruction malveillante est cachée dans un document, une page web ou un e-mail que le système va lire. Le cas de Slack AI, documenté par PromptArmor en 2024, montre comment une injection indirecte a pu servir à exfiltrer des données. Le modèle lit un contenu piégé et exécute une consigne qu'aucun utilisateur légitime n'a donnée.
Piège fréquent : croire qu'un simple délimiteur autour des données suffit. Simon Willison, référence reconnue du secteur, le répète : les délimiteurs seuls ne protègent pas contre l'injection de prompt. Il n'existe pas de rustine magique.
Les parades concrètes :
- Défense multicouche plutôt qu'une seule barrière. Filtrage en entrée, contrôle des sorties, permissions restreintes.
- Séparer clairement le contexte système des données utilisateur, tout en sachant que ça ne suffit pas seul.
- Traiter tout contenu externe récupéré (documents, mails, pages web) comme non fiable par défaut.
- Limiter ce que le modèle peut déclencher : moins il a de pouvoir, moins une injection réussie fait de dégâts.
Pour creuser, on a déjà détaillé le sujet dans Injection de prompt : la faille que les entreprises sous-estiment.
2. Les permissions excessives des agents
Un agent qui a accès à votre CRM, votre messagerie et vos bases de données est puissant. Il est aussi dangereux. Si on le détourne, il agit avec tous ses droits. L'Excessive Agency monte en criticité avec la multiplication des agents autonomes, et l'OWASP l'a bien noté.
Les parades concrètes :
- Principe du moindre privilège. L'agent n'accède qu'à ce dont il a strictement besoin, rien de plus.
- Validation humaine obligatoire pour toute action sensible : envoi externe, suppression, transaction, modification de config.
- Journaliser toutes les actions de l'agent pour pouvoir tracer et rejouer un incident.
- Cloisonner : un agent par domaine, pas un super-agent qui touche à tout.
Deux lectures pour aller plus loin : Sécuriser un agent IA qui a accès à vos outils et Agents IA en production : les cinq garde-fous à poser.
3. La mauvaise gestion des sorties
Dans l'OWASP 2025, l'improper output handling est passé de la deuxième à la cinquième place. Ne vous y trompez pas : il reste critique. Le principe à retenir : la sortie d'un LLM est une donnée non fiable. Vous devez lui appliquer la même sanitisation qu'à n'importe quelle entrée externe.
Un modèle peut générer du code, du HTML, une requête SQL. Si vous exécutez ça sans contrôle, vous ouvrez la porte à l'injection classique (XSS, SQL) via l'IA.
Les parades concrètes :
- Encoder et échapper systématiquement les sorties avant affichage ou exécution.
- Ne jamais passer une sortie de LLM directement à un interpréteur ou un shell.
- Valider le format attendu avant tout usage en aval.
4. L'empoisonnement et la chaîne d'approvisionnement
Le guide du BSI allemand, co-rédigé avec l'ANSSI, structure les menaces en trois familles : evasion, poisoning et privacy attacks. L'empoisonnement consiste à corrompre les données ou le modèle. Des chercheurs ont démontré une attaque combinant empoisonnement du système de récupération et injection de prompt, dans des systèmes qui réinjectent leurs propres sorties dans leur base. Résultat : un fort taux de succès à partir d'un seul contenu piégé.
Les parades concrètes :
- Évaluer la confiance des sources de données et des modèles externes, comme le recommande l'ANSSI.
- Vérifier la provenance des bibliothèques et modèles téléchargés.
- Isoler et contrôler ce qui rentre dans une base de récupération (RAG), surtout si le système réinjecte ses sorties.
Le Shadow IA : le risque que vous ne voyez pas
C'est le sous-angle que l'ANSSI a mis en avant début 2026, et il est central pour beaucoup d'entreprises de la métropole. Le Shadow IA, ce sont les usages informels, voire dissimulés, d'outils d'IA au sein de l'organisation. Un salarié qui colle un contrat client dans un chatbot grand public. Une équipe qui branche un agent sur des données sensibles sans prévenir personne.
Vous ne pouvez pas sécuriser ce que vous ne voyez pas. La première parade n'est pas technique, elle est organisationnelle : cadrer les usages avant qu'ils ne se cadrent tout seuls dans votre dos.
Sur ce point, deux ressources utiles : Shadow AI : quand vos équipes utilisent des IA sans vous le dire et Rédiger une charte d'usage de l'IA pour ses équipes.
Tester avant de déployer, sans usine à gaz
La plupart des failles se détectent avant la mise en production, à condition de tester. Pas besoin d'un labo dédié. Une équipe technique lyonnaise peut poser une démarche solide avec peu de moyens.
- Un jeu de tests d'attaque. Constituez une batterie de prompts malveillants (injections directes et indirectes) et rejouez-les à chaque déploiement. Rappelez-vous les chiffres d'Anthropic : une attaque qui échoue une fois peut réussir à la centième. Testez en répétition.
- Une analyse de risque en amont. Comme le recommande l'ANSSI, listez ce que le système peut faire de pire et priorisez les défenses en fonction.
- Du red teaming léger. Faites tester votre système par quelqu'un qui n'a pas participé à sa conception. Un regard externe trouve les angles morts.
- De la journalisation dès le premier jour. Sans logs, vous ne saurez jamais ce qui s'est passé.
Pour construire votre batterie de tests, notre guide Comment évaluer la réponse d'une IA : construire son jeu de tests donne une méthode réutilisable.
Par où commencer cette semaine
Ne cherchez pas à tout traiter d'un coup. Voici l'ordre qui rapporte le plus vite.
- Recensez vos usages IA, Shadow IA compris. Vous ne pouvez pas protéger ce que vous ignorez.
- Appliquez le moindre privilège à tout agent en production. Coupez les accès inutiles aujourd'hui.
- Mettez une validation humaine sur toute action critique. C'est la recommandation la plus simple et la plus efficace de l'ANSSI.
- Traitez chaque sortie de LLM comme une donnée non fiable, et sanitisez-la.
- Constituez un jeu de tests d'injection et rejouez-le à chaque déploiement.
La sécurité LLM en production n'est pas un projet qu'on boucle. C'est une pratique qu'on installe, comme le DevSecOps l'a été pour le développement classique. Le fossé entre les entreprises qui expérimentent et celles qui sont vraiment prêtes va se creuser. Autant être du bon côté.
Laisser un commentaire