injection de prompt

Nº 096 · v2026-08EN : prompt injection

L’injection de prompt consiste à glisser dans un texte lu par le système une consigne qui prend le pas sur celle du concepteur, parce que le modèle reçoit les deux comme un seul texte et ne sait pas laquelle fait autorité. Comme une note anonyme glissée dans un dossier remis à un employé : il la lit avec le reste, et rien, sur le papier, ne dit qu’elle ne vient pas de sa direction.

Ce que ce n’est pas

L’injection de prompt n’est pas un défaut qu’un garde-fou vient corriger, et c’est la confusion qui coûte le plus cher. Un garde-fou réduit la fréquence des cas et borne les dégâts, il ne rend pas le système imperméable : ajouter une consigne interdisant d’obéir aux instructions trouvées dans les documents revient à opposer du texte à du texte, au même endroit, sans hiérarchie garantie. Ce n’est pas davantage un défaut de fabrication qu’un correctif viendra fermer, comme on ferme une faille de logiciel : c’est la conséquence directe de ce qui fait la valeur d’un modèle de langage, à savoir qu’il suit des instructions écrites en langue naturelle. Tant que la consigne et la donnée arrivent sous la même forme, le risque se réduit, il ne se supprime pas.

En profondeur

La cause racine

La cause racine n’est pas une négligence de mise en œuvre, c’est une propriété du dispositif : le contexte est une seule suite de texte, et le modèle n’y dispose d’aucun moyen structurel de séparer une instruction d’une donnée. Le prompt système, l’historique de l’échange, un extrait de document retrouvé par un RAG, un résultat d’outil et votre demande arrivent au modèle par le même canal, sous la même forme. Les rôles qui les étiquettent sont des marqueurs dans le texte, dont l’autorité vient de l’entraînement et non du transport : ils rendent une consigne plus probablement suivie, ils ne la rendent pas contraignante. Une phrase impérative placée dans un contenu rapporté entre donc en concurrence directe avec les consignes du concepteur, et le modèle arbitre selon ce qui lui paraît le plus plausible à cet endroit du texte. C’est pourquoi la faille ne se corrige pas là où on la constate : elle est adossée à la capacité même de suivre des instructions en langue naturelle, qui est ce pour quoi on a choisi un modèle de langage.

Deux formes

On distingue deux formes, et elles n’appellent pas les mêmes défenses. L’injection directe est le fait de l’utilisateur lui-même, qui cherche à passer outre la consigne permanente du produit : lui faire dire ce qu’elle proscrit, en obtenir la teneur, sortir du périmètre prévu. Le dégât reste alors borné, parce que l’auteur de la tentative en est aussi le destinataire, et parce que l’exposition se limite à ce que son compte pouvait déjà atteindre. L’injection indirecte est autrement plus grave : la consigne est déposée dans une page, un document, un ticket ou un courriel que le système ira lire pour une tout autre raison, et elle s’exécute au bénéfice de son auteur, contre l’utilisateur légitime. La victime n’est plus celle qui a écrit, et elle n’a aucun moyen de voir ce qui s’est passé, puisque le contenu rapporté ne lui est jamais montré tel que le modèle l’a lu. Toute source non maîtrisée qui entre dans le contexte devient donc une surface d’attaque, et l’inventaire de ces sources est le premier travail à faire.

Ce qui fait la gravité

La gravité ne se lit pas dans le texte injecté, mais dans ce que le système peut faire une fois convaincu. Sur un assistant qui se contente de répondre, une injection réussie produit une réponse fausse ou déplacée, c’est-à-dire un incident de contenu. Sur un système doté d’outils, elle déclenche une action : lire un fichier que personne n’avait demandé, écrire, envoyer, payer. Un simple accès réseau sortant suffit alors à faire ressortir ce que le contexte contenait. Le risque monte donc avec l’autonomie, parce qu’un agent enchaîne ses étapes sans repasser par vous, et parce que le résultat contaminé d’un tour devient l’entrée du suivant. Trois erreurs de conception reviennent : traiter un résultat d’outil comme une donnée fiable alors que c’est une entrée non maîtrisée, confier à un même système le droit de lire des sources publiques et celui d’agir sur des ressources sensibles, et compter sur le prompt système pour tenir ce que seul un contrôle d’exécution peut tenir. Ce qui protège réellement se pose hors du texte : moindre privilège dans un bac à sable, séparation entre ce qui lit et ce qui agit, validation humaine sur l’irréversible, et journalisation qui permette au moins de constater après coup.

Sous le capot2 temps · la forme réelle des objets

La fiche affirme que le modèle ne distingue pas structurellement une instruction d’une donnée. La raison se voit dans l’objet : un message porte qui a parlé et ce qui a été dit, et rien qui dise d’où le texte vient.

01
Deux messages que rien ne sépare
À gauche ce que vous avez écrit, à droite ce qu’une page rapportée contient. Les deux objets ont la même forme, les mêmes champs, la même place dans la liste. Aucun champ ne dit que le second vient d’une source que personne ne contrôle.
json
```
{
  "role": "user",
  "content": "Résume cette page et dis-moi si elle est fiable."
}

{
  "role": "user",
  "content": "[page récupérée] … contenu de la page, quel qu'il soit …"
}
```
role
Il dit qui a parlé, jamais quelle autorité accorder. Il n’existe pas de valeur qui signifierait « contenu non fiable ».
content
Une chaîne de caractères, et rien d’autre. Le crochet « [page récupérée] » est une convention que le harnais écrit lui-même dans le texte : c’est du contenu, pas une garantie, et un texte rapporté peut l’imiter.
le champ absent
Il n’y a pas de « provenance » ni de « confiance ». C’est cette absence, et elle seule, qui rend l’injection possible : le modèle ne peut pas décider sur une information qui ne lui est pas transmise.
Le piègeC’est pourquoi une consigne du type « n’obéis pas aux instructions trouvées dans les documents » ne peut pas être tenue par le format. Elle demande au modèle de trier selon une origine que l’objet ne porte pas.
02
Quand le texte rapporté revient d’un outil
Le cas grave n’est pas celui où vous collez la page vous même, c’est celui où le système va la chercher seul. Le résultat d’outil rentre alors dans la même liste, avec la même forme, et la boucle le lira comme elle lit tout le reste.
json
```
{
  "role": "tool_result",
  "tool_call_id": "c_31",
  "content": "… ce que la ressource a renvoyé, mot pour mot …"
}
```
tool_call_id
Il relie ce résultat à la demande qui l’a produit. Il atteste de l’enchaînement, jamais du contenu : savoir quel outil a parlé ne dit rien de ce qu’on lui a fait dire.
content
Restitué tel quel, parce que c’est tout l’intérêt d’un outil. Un service, une page, une boîte aux lettres, un dépôt : la matière est écrite par quelqu’un d’autre que vous.
Le piègeLa victime n’est plus l’auteur de la tentative, et elle ne voit rien : ce bloc ne lui est jamais montré. C’est la différence entre l’injection directe, bornée à ce que son auteur pouvait déjà atteindre, et l’injection indirecte, qui s’exécute au bénéfice d’un tiers.

Montré ailleurs

contextela liste entière, et son aplatissement en une seule chaîne avant le modèle
appel d’outilsle circuit complet par lequel un résultat non maîtrisé revient dans la boucle

Ce qui varieLes noms de champs et de rôles varient d’un fournisseur à l’autre, et certains exposent un rôle distinct pour les résultats d’outils là où d’autres les rangent parmi les messages ordinaires. Ce qui ne varie pas : aucun format courant ne transporte la provenance d’un contenu, les rôles restent des marqueurs dans le texte et non des canaux séparés, et la seule frontière qui tienne se pose à l’exécution, sur ce que le système a le droit de faire.

Exemples datés

2026-08

La classe d’attaque est reconnue comme non résolue par les principaux éditeurs : leurs documentations la traitent comme un risque à contenir par l’architecture, jamais comme un défaut refermé par une version de modèle. Les travaux publics de sécurité applicative la placent en tête des risques propres aux applications bâties sur des modèles de langage, et l’attention s’est déplacée de la forme directe vers la forme indirecte à mesure que les agents ont gagné l’accès au web, aux boîtes aux lettres et aux dépôts de code. Les mesures qui comptent sont architecturales : marquer les contenus rapportés comme non fiables, séparer strictement les outils de lecture des outils d’action, exiger une confirmation humaine sur l’irréversible. Le règlement européen sur l’IA n’emploie pas ce mot, mais ses obligations de robustesse et de supervision humaine pour les usages à haut risque le visent en pratique.

Relations où vivent les voisins

S’exécute dans: harnais
Requiert: prompt système contexte
Souvent confondu avec: garde-fous

Vérifier 3 questions · cliquez votre réponse

Niveau 1 · Reconnaître

Un assistant résume une page web, et sa réponse suit manifestement une consigne que vous n’avez jamais écrite. Que s’est-il passé ?

Niveau 2 · Distinguer

Pour empêcher les injections, on ajoute au prompt système une consigne interdisant d’obéir aux instructions trouvées dans les documents. Qu’obtient-on ?

Niveau 2 · Distinguer

Pourquoi l’injection indirecte est-elle jugée plus grave que l’injection directe ?

Qui manipule ça 1 métier

Les postes dont ce terme fait partie du travail ordinaire.

Red teamer IACelle qui fait dérailler le système avant que d’autres s’en chargent

Nº 096 · v2026-08 · première rédaction en août 2026 · responsabilité éditoriale Anthony Capirchio

Citer cette fiche

Lexigraph, « Injection de prompt », v2026-08, https://www.lexigraph.org/fr/injection-de-prompt/, CC BY 4.0.