Sécuriser ses prompts : guardrails et framework OWASP

Un modèle de langage a une particularité qui le distingue des composants logiciels classiques : il traite les instructions et les données dans le même flux de texte, sans frontière nette entre les deux. Cette absence de séparation est la racine de la plupart des risques de sécurité propres aux LLM. Un attaquant n'a pas besoin d'exploiter une faille technique : il lui suffit de rédiger un texte que le modèle interprétera comme une consigne, alors que vous l'attendiez comme une donnée à traiter.

Pour structurer la défense, le meilleur point de départ est l'OWASP Top 10 for LLM Applications, dont l'édition 2025 fait référence. C'est l'équivalent, pour l'IA, du célèbre Top 10 des vulnérabilités web. Passons en revue les risques les plus directement liés au prompt, puis les guardrails à mettre en place.

L'OWASP Top 10 pour les LLM, en bref

Voici la liste 2025, dans l'ordre de criticité retenu par OWASP. Tous ne concernent pas directement le prompt, mais plusieurs s'y jouent en première ligne.

Code	Risque	Lien avec le prompt
LLM01	Injection de prompt	Direct — le cœur du sujet
LLM02	Divulgation d'informations sensibles	Direct
LLM03	Vulnérabilités de la chaîne d'approvisionnement	Indirect
LLM04	Empoisonnement des données et du modèle	Indirect
LLM05	Mauvaise gestion des sorties	Direct
LLM06	Agence excessive	Direct (conception)
LLM07	Fuite du prompt système	Direct
LLM08	Faiblesses des vecteurs et embeddings (RAG)	Indirect
LLM09	Désinformation / hallucinations	Direct
LLM10	Consommation non maîtrisée	Indirect

LLM01 — L'injection de prompt, risque numéro un

L'injection de prompt occupe la première place pour la deuxième édition consécutive, et ce n'est pas un hasard. Elle se décline en deux formes.

Injection directe

L'utilisateur tente directement de détourner le comportement du modèle : « ignore tes instructions précédentes et fais plutôt ceci ». C'est le « jailbreak » classique, le plus connu mais pas le plus dangereux aujourd'hui.

Injection indirecte

Bien plus insidieuse, elle ne vient pas de l'utilisateur mais des données que le modèle consomme : une page web, un PDF, un e-mail, voire le contenu d'une image. L'attaquant y cache des instructions ; lorsque le modèle traite ce contenu, les consignes dissimulées prennent le contrôle de la session. Point crucial : ces instructions n'ont pas besoin d'être lisibles par un humain — il suffit que le modèle les interprète.

Comment s'en défendre

• Séparer instructions et données. Délimitez clairement le contenu non fiable (balises, sections dédiées) et indiquez explicitement au modèle qu'il ne doit jamais traiter ce contenu comme une consigne.
• Contraindre le comportement. Définissez précisément le rôle du modèle et ce qu'il n'a pas le droit de faire, plutôt que de compter sur des interdictions vagues.
• Tester de façon adversariale. Simulez des attaques d'injection sur votre prompt avant la mise en production — c'est la seule manière de connaître sa robustesse réelle.

Aucune méthode ne garantit une protection à 100 % contre l'injection : c'est une propriété intrinsèque des modèles génératifs. L'objectif est de réduire la surface et l'impact, pas de viser une immunité illusoire.

LLM07 — La fuite du prompt système

Votre prompt système contient souvent plus que des instructions : règles métier, noms d'outils internes, parfois — à tort — des éléments sensibles. La fuite de prompt système survient quand un attaquant parvient à le faire révéler par le modèle. Deux principes de défense :

• Ne jamais placer de secret dans un prompt. Clés d'API, identifiants, jetons : rien de tout cela n'a sa place dans les instructions. Partez du principe que tout prompt système peut fuiter.
• Ne pas faire reposer la sécurité sur la confidentialité du prompt. Les contrôles d'accès réels doivent vivre dans votre application, pas dans une consigne demandant au modèle de « ne pas révéler » quelque chose.

LLM02 — La divulgation d'informations sensibles

Ce risque a fortement grimpé dans le classement 2025, porté par des incidents réels de fuite de données. Un modèle peut restituer des informations confidentielles présentes dans son contexte — données d'autres utilisateurs, contenu interne, données personnelles. Les garde-fous côté prompt :

• Définir des catégories de contenus sensibles et des règles pour les identifier et les traiter.
• Appliquer des filtres sémantiques et des vérifications sur les sorties pour détecter les contenus non autorisés.
• Limiter le contexte fourni au modèle au strict nécessaire pour la tâche.

LLM05 — La mauvaise gestion des sorties

Une règle d'or souvent oubliée : la sortie d'un LLM est une donnée non fiable, au même titre qu'une saisie utilisateur. Si votre application exécute, affiche ou transmet la réponse du modèle sans contrôle, vous créez une faille. Une injection réussie produit une sortie malveillante que votre code exécute ensuite docilement.

LLM06 — L'agence excessive

À mesure que les LLM passent du statut de répondeur passif à celui d'agent actif — qui envoie des e-mails, interroge des bases, appelle des API — le rayon d'impact d'une faille explose. OWASP distille la cause en trois excès à corriger dès la conception :

• Fonctionnalités excessives. N'accordez à un agent que les outils strictement nécessaires. Un agent qui lit des documents n'a aucune raison de pouvoir en supprimer.
• Permissions excessives. Évitez les identités génériques à hauts privilèges. Préférez le contexte de l'utilisateur et le principe du moindre privilège.
• Autonomie excessive. Pour toute action à fort impact (mouvement de fonds, envoi de message, suppression), maintenez une validation humaine dans la boucle.

LLM09 — La désinformation et les hallucinations

L'édition 2025 a renommé l'ancienne catégorie « surconfiance » en « désinformation », et y a intégré les hallucinations. Le modèle invente des faits, fabrique des citations, produit des réponses convaincantes à des questions auxquelles il ne peut pas répondre de façon fiable. Côté prompt, on atténue en fournissant un contexte de référence, en demandant au modèle de s'y tenir, et en l'autorisant explicitement à reconnaître son incertitude.

Une démarche, pas une case à cocher

Sécuriser ses prompts n'est pas une action ponctuelle mais une discipline continue. Le bon réflexe consiste à intégrer ces vérifications dans une boucle régulière : auditer chaque prompt sur sa robustesse à l'injection, sa gestion des contenus sensibles et sa confidentialité, corriger les points faibles, puis re-tester après chaque modification pour éviter les régressions.

C'est précisément ce qu'évalue un audit structuré : la dimension sécurité y pèse lourd, avec des critères dédiés à la robustesse face aux injections, au filtrage de contenu et à la confidentialité. Plutôt que de découvrir une faille en production, on la repère sur la grille — et on la corrige avant le déploiement.

Pour le contexte plus large — pourquoi l'optimisation des prompts compte aussi pour la qualité et le coût — voir notre article « Pourquoi optimiser ses prompts est devenu fondamental ».