La prompt injection, ce troll caché dans vos contenus
La prompt injection, c’est l’équivalent IA du petit papier glissé sous la porte qui dit « ignore ton boss et fais n’importe quoi ». Sauf qu’ici, le papier est caché dans un texte qui a l’air innocent, et que votre modèle peut se mettre à suivre des instructions malveillantes.
Un exemple classique, popularisé dans une vidéo récente, consiste à dissimuler des règles du type « ignore les instructions précédentes » puis à imposer un nouveau style de réponse, voire à tenter de déclencher des actions. Dans la démo, le modèle finit par obéir et répond comme un pirate, concis, rude, obsédé par le rhum. C’est drôle deux minutes… jusqu’au moment où l’agent a accès à des outils, un navigateur, des emails ou des systèmes internes.
Et c’est là que ça devient sérieux. Entre des extensions navigateur côté IA et des assistants capables d’exécuter des actions, un site web peut théoriquement contenir du texte piégé qui influence le comportement du modèle. Bref, la prompt injection n’est pas un problème académique, c’est un risque produit.
Les deux conseils devenus viraux
Deux recommandations reviennent souvent pour « limiter » la prompt injection.
1) Préférer XML à Markdown pour délimiter l’entrée
L’idée est simple : XML a des balises d’ouverture et de fermeture explicites, donc le modèle verrait mieux ce qui est du contenu non fiable et ce qui est instruction.
En version Markdown, on ferait quelque chose comme :
- Rôle : classifieur SAFE ou UNSAFE
- Zone de contenu délimitée par des titres
En version XML, on encadre l’entrée dans une balise <content> puis on met les consignes ailleurs.
La théorie : le Markdown serait plus facile à “casser” ou à manipuler, tandis que l’XML serait plus strict.
2) Mettre les règles dans le system prompt, et l’entrée non fiable dans le user prompt
Deuxième idée : ne jamais coller le contenu utilisateur dans le system prompt. On garde le system prompt pour les règles de haut niveau, et on envoie le texte à analyser dans un message utilisateur.
Ça ressemble au bon sens, et c’est souvent présenté comme un rempart.
Sauf que… en sécurité, on teste au lieu de croire
Un point essentiel en sécurité LLM : les bonnes pratiques “générales” existent, mais les comportements dépendent du modèle, de sa taille, de son entraînement, et même de la version. Un conseil qui marche sur un modèle peut s’effondrer sur un autre.
C’est exactement ce qui a été vérifié via une batterie de tests reproductibles : 24 scénarios d’attaque, 5 modèles OpenAI (gpt-4.1, gpt-4.1-mini, gpt-4.1-nano, gpt-5, gpt-5-mini), 2 méthodes de délimitation (Markdown vs XML), et 2 emplacements d’injection (system vs user). Total : 480 tests.
Le but n’était pas de faire un concours de “prompt le plus propre”, mais de mesurer un truc simple : est-ce que l’attaque passe ou est-ce qu’elle est bloquée.
Markdown vs XML : le duel qui finit en match nul
Sur le papier, on a envie d’y croire : XML, c’est carré, structuré, avec des tags qui ferment. Markdown, c’est plus permissif, plus “texte libre”.
Dans la pratique, les résultats montrent qu’il y a très peu de différence globale entre Markdown et XML pour empêcher la prompt injection.
- Sur certains modèles, XML fait un peu mieux
- Sur d’autres, Markdown fait aussi bien, voire mieux
- Et surtout, l’écart n’est pas assez constant pour en faire une règle universelle
Autrement dit : XML peut être une bonne hygiène de prompt, mais ce n’est pas un bouclier magique.
Pourquoi le format ne suffit pas
Un LLM ne “parse” pas XML comme un compilateur. Il interprète des patterns et des intentions. Si l’attaque est bien formulée, elle peut rester persuasive même si vous l’enfermez dans de jolies balises.
C’est un peu comme écrire « ceci n’est pas une arnaque » en police Times New Roman : ce n’est pas la typographie qui rend le message honnête.
Oui, certains modèles sont entraînés à respecter des tags
Certains éditeurs expliquent avoir entraîné leurs modèles à respecter des balises XML. Très bien. Mais même là, “entraîné à” ne veut pas dire “immunisé”. Ça veut dire que ça améliore les chances, pas que ça élimine le risque.
System prompt vs user prompt : pas le game changer attendu
Deuxième croyance populaire : si on met l’entrée utilisateur dans un message user plutôt que dans le system prompt, on serait beaucoup plus protégé.
Les tests montrent que la différence est faible.
C’est contre-intuitif au premier abord, parce que le system prompt a souvent plus de poids. Donc on s’attend à une amélioration nette en déplaçant l’entrée non fiable vers user. Et pourtant, les taux de réussite et d’échec restent proches dans de nombreux cas.
Ce que ça implique
- Oui, il faut éviter de mettre du contenu non fiable dans le system prompt
- Non, ça ne suffit pas pour dire “on est safe”
La sécurité ne vient pas d’un seul choix de structure. Elle vient d’une stratégie.
Les chiffres qui piquent un peu (surtout sur les petits modèles)
Les résultats confirment un point très logique : plus le modèle est gros et capable, plus il résiste.
- gpt-5 est excellent, avec des scores très élevés et même un 100% dans un cas
- gpt-4.1 tient bien
- les variantes mini et nano se font plus souvent avoir
Ce qui est important ici, ce n’est pas de se moquer des petits modèles. Ils sont utiles, rapides, économiques. Mais si vous construisez un agent exposé à du contenu web non fiable, leur tolérance aux attaques devient un paramètre de risque majeur.
En clair : économiser 20 centimes par million de tokens peut coûter beaucoup plus cher si l’agent se fait manipuler.
Evals : la méthode qui met tout le monde d’accord
Le point le plus intéressant, c’est peut-être celui-là : le seul moyen sérieux de trancher entre des “bonnes pratiques” concurrentes, c’est de faire des evals.
Des evals, ici, c’est :
- une liste de scénarios réalistes d’attaque
- des tests automatisés
- un scoring clair (attaque bloquée ou non)
- idéalement, plusieurs modèles et plusieurs versions
Et la bonne nouvelle, c’est que ce n’est plus un chantier gigantesque réservé à des labos. On peut monter une suite de tests assez rapidement et l’intégrer dans un pipeline.
Si vous bossez sur des agents, de l’automatisation, des assistants qui lisent des emails, des pages web ou des tickets support, c’est un investissement qui paie vite.
Ce qu’il faut retenir pour votre produit IA
Si le format (XML ou Markdown) et l’emplacement (system ou user) ne changent pas radicalement la donne, alors qu’est-ce qu’on fait.
1) Commencez par une analyse de risque
Posez des questions simples :
- Le modèle a-t-il accès à des outils (web, fichiers, emails, API) ?
- Traite-t-il du contenu externe non fiable ?
- Une mauvaise action peut-elle déclencher un effet réel (envoi d’email, suppression, achat, fuite de données) ?
Plus la réponse est “oui”, plus vous devez investir.
2) Réduisez l’exposition au contenu non fiable
Moins vous donnez au modèle, moins il a de matière à interpréter comme des instructions.
- Nettoyez ou résumez côté serveur avant d’envoyer au LLM
- Limitez les champs, coupez les zones inutiles
- Évitez de coller des pages entières “au cas où”
3) Ajoutez des garde-fous au niveau système
Les prompts ne doivent pas être votre seul verrou.
- séparation stricte entre données et actions
- listes blanches d’outils et de domaines
- validation côté code pour toute action risquée
- confirmation explicite pour les opérations sensibles
Le meilleur agent, c’est celui qui doit demander la permission avant de faire une bêtise.
4) Utilisez des modèles adaptés à l’exposition
Si votre agent navigue sur le web ou lit des contenus utilisateurs, choisir un modèle plus robuste peut être une mesure de sécurité.
Oui, ça coûte plus cher. Mais ça peut aussi réduire les incidents.
5) Industrialisez les evals
Les tests ne sont pas un one-shot. Dès que vous changez :
- le modèle
- le prompt
- la structure des messages
- les outils disponibles
… vous devez re-tester. Les comportements changent vite, et parfois sans prévenir.
XML ou Markdown : alors on choisit quoi
Si on se base sur les résultats observés : choisissez surtout ce qui rend votre système maintenable.
- XML est pratique pour une structure claire et des extractions
- Markdown est pratique pour la lisibilité et la rapidité
Le vrai gain viendra davantage de :
- la qualité des garde-fous
- le choix du modèle
- la réduction de surface d’attaque
- les evals automatisées
Donc oui, vous pouvez utiliser XML si ça vous aide à organiser votre contexte. Mais ne le vendez pas comme une armure en vibranium.
Un plan d’action simple pour “moins se faire avoir”
Voici une checklist pragmatique si vous construisez un système LLM en production :
1) Séparez les rôles
- system prompt : règles globales, but, interdits
- user message : données non fiables
2) Délimitez proprement
XML ou Markdown, peu importe. L’important, c’est la cohérence et la clarté.
3) Refusez les actions dangereuses par défaut
Si l’agent peut appeler des outils, imposez :
- validation du schéma
- permissions
- confirmation utilisateur
4) Testez avec des scénarios d’attaque
Créez 20 à 50 attaques représentatives de votre contexte (web, email, PDF, support). Automatisez.
5) Surveillez en prod
- loggez les prompts (avec prudence sur les données sensibles)
- détectez les patterns d’injection
- mettez des alertes sur les actions
Oui, c’est moins fun que de débattre XML vs Markdown sur internet. Mais c’est nettement plus utile.
Le mot de la fin (sans le mot interdit)
La prompt injection est un problème réel, surtout quand les LLM sortent du chat pour aller manipuler des outils. Les recettes simples comme “utilise XML” ou “mets ça dans user” sont des pratiques raisonnables, mais elles ne remplacent pas une démarche de sécurité.
Les résultats de tests à grande échelle montrent surtout une chose : les différences entre XML et Markdown, ou entre system et user, sont souvent marginales face à d’autres facteurs comme la robustesse du modèle et la présence d’évaluations sérieuses.
Moralité : si quelqu’un vous promet qu’un simple changement de format va régler la prompt injection, demandez-lui gentiment ses evals. Et s’il répond en langage pirate en parlant de rhum, vous avez déjà votre réponse.
Source : Prompt injection : XML vs Markdown, system vs user… les tests qui cassent (un peu) le mythe