--- title: "Prompt injection : risques, exemples et défenses" description: "La prompt injection survient lorsqu’une instruction non fiable modifie le comportement du modèle, surtout avec des données ou outils sensibles." canonical: "https://zephior.com/fr/glossary/prompt-injection" last-updated: 2026-07-28 --- # Prompt injection : risques, exemples et défenses > La prompt injection survient lorsqu’une instruction non fiable modifie le comportement du modèle, surtout avec des données ou outils sensibles. Par [Tony Kim](https://zephior.com/fr/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 5 minute read. ## Définition La prompt injection est une attaque ou interaction où des instructions issues de l’utilisateur ou d’un contenu externe détournent le modèle du comportement voulu. Elle est directe dans le prompt ou indirecte dans un document, une page, un message ou un résultat d’outil. ## Problème Les modèles traitent instructions et données dans le même canal linguistique. Une phrase dans un document peut rivaliser avec la tâche système, sans frontière de sécurité déterministe. L’impact devient grave si le modèle reçoit secrets, outils puissants ou capacité d’agir. ## Point de vue Une consigne système plus forte ne suffit pas. Supposez que le modèle peut être influencé et concevez le système pour qu’une sortie manipulée ne dépasse pas les droits, ne divulgue pas de données inutiles et n’agisse pas sans politique et validation. ## L’injection indirecte transforme un contenu ordinaire en instruction L’injection directe apparaît dans le message utilisateur. L’indirecte est incorporée dans une page, un PDF, un ticket, un calendrier ou un article que l’application lit ensuite. L’utilisateur peut ne jamais la voir. Un agent amplifie le risque par ses actions. Une page peut demander l’envoi de données ou modifier des arguments d’outil. Provenance et hiérarchie aident, mais la sécurité vient de données et autorité limitées hors du modèle. | Surface | Exemple | Contrôle | | --- | --- | --- | | Entrée utilisateur | Remplacer la tâche | Limite de capacité | | Document | Action cachée | Traitement non fiable | | Résultat outil | Texte API hostile | Schéma et provenance | | Mémoire | Instruction persistante | Politique d’écriture | | Sortie modèle | Commande ou balisage | Validation aval | ## Concevoir pour un modèle susceptible de suivre la mauvaise instruction Les défenses par instruction réduisent certains cas mais restent probabilistes. Les contrôles forts sont classiques: moindre privilège, autorisation, minimisation, isolation, interfaces validées, confirmation, suivi et réponse aux incidents. Adaptez au dommage. Un outil de rédaction sans secret a moins d’impact qu’un agent capable d’envoyer, acheter ou modifier. Renforcez revue et isolation avec l’autorité et gardez un arrêt déterministe avant tout effet irréversible. - Ne jamais utiliser le prompt comme autorisation. - Garder les secrets hors du contexte. - Traiter tout texte retrouvé comme non fiable. - Valider dans le composant qui exécute. - Tester les effets plutôt que le refus. ## Déroulement 1. **Cartographier instructions et données.** Inventoriez consignes système, messages, fichiers, web, courriels, mémoire et outils. Marquez confiance, propriétaire et permission. Un contenu client, tiers ou généré reste non fiable même dans un document métier. 2. **Réduire l’autorité accessible.** Ne placez pas de secret réutilisable dans le prompt. Donnez des opérations étroites et droits minimaux, autorisez lors de l’exécution et limitez à l’utilisateur et à la ressource. Séparez lire, rédiger et agir. 3. **Limiter et valider les effets.** Utilisez schémas d’outils, listes permises, validation, encodage et contrôles transactionnels. Montrez les détails avant confirmation. Validez URL, code, requête et balisage dans le système qui les reçoit. 4. **Tester les chemins réalistes.** Placez des instructions adverses dans prompts, documents, métadonnées, pages et résultats. Testez exfiltration, redirection, abus d’outil et persistance. Mesurez si l’effet fut empêché, pas si le modèle a écrit un refus. ## Décisions clés - Quelles entrées un acteur non fiable influence-t-il? - Quelles données et quels outils sont inutiles pour la tâche? - Où l’autorisation est-elle imposée à l’appel? - Quelle sortie devient exécutable, rendue ou transmise? - Quelle confirmation humaine a du sens avant l’effet? ## Risques - Un document retrouvé redirige l’agent vers le but de l’attaquant. - Le secret du prompt crée une fausse confiance car le contexte peut fuir. - Un outil trop puissant transforme le texte en action non autorisée. - La sortie injecte du code dans un interpréteur aval. - La mémoire conserve une instruction hostile pour plus tard. ## Indicateurs - scénarios bloqués avant effet matériel - appels non autorisés refusés par politique - champs sensibles exposés au modèle par tâche - actions importantes avec confirmation valide - sorties dangereuses rejetées en aval - couverture de régression par canal ## Questions fréquentes ### Qu’est-ce que la prompt injection? Une entrée utilisateur ou un contenu externe fournit des instructions qui détournent le modèle du comportement prévu par l’application. ### Qu’est-ce que l’injection indirecte? Une instruction cachée dans un document, une page, un courriel ou un résultat que l’application donnera plus tard au modèle. ### Le prompt système empêche-t-il l’attaque? Non de façon déterministe. Il faut moindre privilège, autorisation externe, minimisation, outils validés et approbation des actions importantes. ### Prompt injection et jailbreak sont-ils identiques? Ils se recoupent. Le jailbreak vise souvent les restrictions du modèle; l’injection vise les instructions de l’application et peut exploiter contenu et outils. ## Sources primaires - [LLM01:2025 Prompt Injection](https://genai.owasp.org/llmrisk/llm01-prompt-injection/), OWASP Gen AI Security Project