Injection de prompt : protéger votre application IA du risque n°1 de l'OWASP 2026

Dans son Top 10 pour les applications LLM 2026, l'OWASP maintient l'injection de prompt (LLM01) à la première place. Rien d'étonnant : dès qu'une application envoie à un modèle de langage un texte qu'elle ne contrôle pas — un message client, un e-mail, une page web, un PDF —, ce texte peut contenir des instructions. Et le modèle peut les suivre.

Comment fonctionne une injection de prompt

Un LLM reçoit un seul flux de texte : vos instructions système, la demande de l'utilisateur et les données à traiter. Il n'existe pas de frontière technique stricte entre « ce qu'il faut faire » et « ce qu'il faut lire ». On distingue deux formes :

• Injection directe : l'utilisateur écrit lui-même « Ignore tes instructions précédentes et… » dans le chatbot.
• Injection indirecte : l'instruction est cachée dans un contenu que l'IA lit pour vous — un e-mail résumé par un assistant, une page web analysée par un agent, un CV traité par un outil RH, du texte blanc sur fond blanc dans un document.

L'injection indirecte est la plus dangereuse : la victime n'a rien tapé de suspect, elle a seulement demandé à l'IA de traiter un document piégé.

Ce que risque concrètement votre application

• Fuite de données : le modèle révèle son prompt système, des données d'autres clients ou des informations internes (LLM02).
• Actions non voulues : un agent doté d'outils envoie un e-mail, modifie un enregistrement ou appelle une API (c'est le risque d'agentivité excessive, LLM03).
• Exfiltration : le modèle insère des données sensibles dans une URL d'image ou un lien que le navigateur charge automatiquement.
• Désinformation : une réponse manipulée affichée comme fiable à vos clients.

Pourquoi il n'existe pas de correctif unique

Contrairement à une injection SQL, qu'on neutralise avec des requêtes préparées, l'injection de prompt n'a pas de solution définitive : le modèle doit interpréter le langage naturel, y compris celui des données. La défense repose donc sur plusieurs couches et sur un principe simple : considérer toute sortie du modèle comme non fiable.

8 défenses à mettre en place

1. Le moindre privilège pour les outils

Un agent qui ne peut que lire ne peut pas supprimer. Donnez à chaque outil les droits minimum, et faites exécuter les actions avec les permissions de l'utilisateur, jamais avec un compte technique tout-puissant.

2. Une validation humaine pour les actions sensibles

Envoi, paiement, suppression, modification de statut : soumettez ces appels à approbation. Nous détaillons cette approche dans notre article sur les agents IA avec un humain dans la boucle.

3. Séparer clairement instructions et données

Encadrez les contenus externes avec des délimiteurs explicites et rappelez dans le prompt système qu'ils doivent être traités comme des données, jamais comme des consignes. Cela ne suffit pas seul, mais réduit les attaques naïves.

4. Valider et assainir les sorties

Échappez le HTML produit par le modèle avant affichage, validez les JSON contre un schéma, refusez les URL externes non prévues dans les réponses (pour bloquer l'exfiltration par image). C'est le pendant IA de la règle « ne jamais faire confiance aux entrées ».

5. Ne rien mettre de secret dans le prompt système

Partez du principe que le prompt système finira par être révélé. Aucune clé API, aucun mot de passe, aucune règle métier confidentielle ne doit s'y trouver.

6. Cloisonner les données

Dans un système RAG, filtrez les documents récupérés selon les droits de l'utilisateur avant de les envoyer au modèle. Le modèle ne peut pas divulguer ce qu'il n'a jamais reçu.

7. Limiter la consommation

Plafonnez le nombre de requêtes, de tokens et d'appels d'outils par utilisateur et par session. Cela limite aussi bien les abus que les coûts (risque LLM10, consommation non bornée).

8. Journaliser et tester

Conservez les prompts, réponses et appels d'outils (en respectant les données personnelles), et testez régulièrement votre application avec des tentatives d'injection connues. Ajoutez ces scénarios à vos tests automatisés.

Checklist rapide avant mise en production

• ☐ Inventaire des sources de texte non fiables lues par l'IA
• ☐ Liste des outils et de leurs droits
• ☐ Approbation humaine sur les actions irréversibles
• ☐ Sorties échappées et validées
• ☐ Aucun secret dans les prompts
• ☐ Filtrage des données par utilisateur
• ☐ Quotas et journalisation

Conclusion

L'injection de prompt n'est pas un bug qu'on corrige une fois : c'est une propriété des modèles de langage, à gérer comme on gère les entrées utilisateur depuis toujours. Limitez ce que l'IA peut faire, vérifiez ce qu'elle produit, et gardez un humain sur les décisions qui comptent. Pour le contexte général, voir aussi Cybersécurité 2026 : IA agentique et menace quantique.

Source : OWASP Top 10 for LLM Applications 2026.