Votre assistant IA lit des e-mails, des PDF, des pages web, des tickets. Il obéit aussi à des instructions. Le problème, c’est qu’il ne sait pas faire la différence entre les deux — et un attaquant, lui, le sait très bien.
Une faille qui tient au fonctionnement même des LLM
Un modèle de langage reçoit un seul flux de texte : les consignes du développeur, la question de l’utilisateur, les documents récupérés, les résultats des outils. Tout est concaténé. Il n’existe pas, dans ce flux, de frontière technique entre ce qui est une donnée et ce qui est un ordre.
La prompt injection exploite exactement cela : faire passer une instruction pour du contenu, et laisser le modèle l’exécuter. C’est pour cette raison que l’OWASP la classe en tête de son Top 10 des applications LLM (LLM01:2025).
Tout ce que votre assistant lit peut devenir une instruction. Tout.
Directe ou indirecte : la seconde est la plus dangereuse
Dans une injection directe, l’utilisateur lui-même tente de contourner les consignes (« ignore tes règles et… »). C’est le cas le plus connu, et le moins grave : l’attaquant n’obtient généralement que ce que l’utilisateur pouvait déjà voir.
Dans une injection indirecte, l’instruction est cachée dans un contenu que le système va lire pour le compte d’un utilisateur légitime :
- un texte blanc sur fond blanc dans un PDF de fournisseur ;
- une phrase dans la signature d’un e-mail entrant ;
- un commentaire dans une page web consultée par un agent ;
- un champ libre dans un ticket de support ou un formulaire client.
La victime ne voit rien. Le modèle, lui, lit tout — et agit avec les droits de la victime.
Ce que l’attaquant obtient réellement
La gravité d’une prompt injection ne dépend pas du modèle. Elle dépend de ce que le système autour du modèle lui permet de faire. Un chatbot isolé, sans accès à rien, produira au pire une réponse embarrassante. Un assistant branché sur la messagerie, le CRM et la GED peut :
- exfiltrer des données en les glissant dans un lien, une image ou un e-mail ;
- déclencher des actions : envoyer un message, modifier un enregistrement, créer un accès ;
- fausser une décision en injectant de fausses informations dans une synthèse ;
- se propager, en écrivant à son tour du contenu piégé lu par d’autres assistants.
Les 10 failles IA que votre DSI ne voit pas
L’OWASP LLM Top 10 traduit pour les dirigeants, avec les contrôles à exiger de vos équipes et fournisseurs.
Pourquoi aucun filtre ne suffit
La réponse réflexe consiste à ajouter un filtre : une liste de phrases interdites, un second modèle chargé de détecter les tentatives, un prompt système plus ferme. Ces mesures ont leur utilité, mais elles partagent une limite : elles cherchent à reconnaître une attaque formulée en langage naturel, qui peut être reformulée, traduite, encodée ou fragmentée à l’infini.
Un filtre réduit la probabilité d’une injection réussie. Il ne la ramène jamais à zéro. La question de sécurité n’est donc pas « comment empêcher toute injection ? », mais « que se passe-t-il quand une injection réussit ? ».
Les mesures qui limitent vraiment les dégâts
Les défenses efficaces sont architecturales. Elles partent du principe que le modèle peut être manipulé, et bornent ce qu’il peut faire dans ce cas.
- Moindre privilège. L’assistant n’accède qu’aux données et aux outils strictement nécessaires, avec les droits de l’utilisateur — jamais avec un compte de service omnipotent.
- Séparation des contenus. Les contenus externes sont marqués comme non fiables et traités à part des instructions ; ils ne déclenchent pas d’actions sans validation.
- Validation humaine pour toute action à impact : envoi externe, modification de données, paiement, création de compte.
- Sorties traitées comme non fiables. Pas de rendu automatique de liens ou d’images vers des domaines externes, pas d’exécution de code ou de requêtes générées sans contrôle.
- Journalisation des prompts, des sources lues et des appels d’outils, pour détecter et reconstituer.
- Tests d’attaque avant la mise en production, rejoués à chaque évolution.
Les trois questions à poser à vos équipes
Pas besoin d’être expert pour évaluer votre exposition. Posez ces trois questions pour chaque assistant ou agent en service :
- Que lit-il ? Quels contenus externes, non maîtrisés, entrent dans son contexte ?
- Que peut-il faire ? Quelles données peut-il consulter, quelles actions peut-il déclencher, avec quels droits ?
- Qui le verrait ? Si une injection réussissait demain, quelle trace en aurions-nous ?
Si l’une de ces réponses est « nous ne savons pas », le risque est réel — et il est probablement déjà exploitable.
À retenir
- La prompt injection est une conséquence du fonctionnement des LLM, pas un bug que l’on corrige.
- L’injection indirecte — cachée dans un document, un e-mail, une page — est la plus dangereuse.
- La gravité dépend des droits et des outils donnés au modèle, pas du modèle lui-même.
- Les filtres réduisent le risque ; seules l’architecture et le moindre privilège limitent les dégâts.
