Injection de prompt : un risque de cybersécurité pour l’entreprise

Vous travaillez dans une PME et vous devez analyser un fichier contenant des données commerciales. Vous souhaitez utiliser l’IA pour gagner du temps, mais vous ne savez pas exactement comment formuler votre demande.

Une recherche sur Internet vous conduit vers une bibliothèque de prompts. Vous en trouvez un qui correspond parfaitement à votre besoin. Vous le copiez, le collez dans l’outil utilisé par votre entreprise et obtenez le résultat attendu.

Sauf que ce prompt contient également une instruction que vous n’avez pas identifiée. Si l’IA dispose d’un accès à des données ou à des outils de l’entreprise, cette instruction peut lui demander de réaliser une action qui n’était pas prévue.

Ce scénario est volontairement simplifié, mais le mécanisme qu’il illustre est bien réel : une instruction apparemment anodine peut devenir le vecteur d’une injection de prompt.

Nous avons appris à nous méfier d’un programme ou d’un script récupéré sur Internet. Alors pourquoi faisons-nous plus facilement confiance à un prompt dont nous ne connaissons pas davantage l’origine ?

Le prompt : le code des IA

Un prompt sert à donner des instructions à une IA qui peut désormais disposer de capacités importantes pour accomplir une tâche. Récupérer un prompt déjà fait dans une bibliothèque comporte cependant un risque qu’il ne faut pas négliger. On peut y voir un aspect pratique. Avoir un prompt qui correspond peu ou prou à notre travail peut nous paraître être une solution rapide pour donner des instructions à une IA. Mais selon ce que votre agent IA sera autorisé à faire, un prompt peut aussi occasionner des conséquences parfois importantes.

L’injection de prompt : quand l’instruction devient l’attaque

L’injection de prompt consiste à introduire une instruction malveillante dans un prompt ou dans un contenu traité par l’IA. Cette instruction pourra modifier le comportement de l’IA, contourner les règles prévues ou lui faire utiliser les outils à sa disposition d’une manière inattendue.

On distingue principalement deux types d’injections :

Injection directe. L’instruction problématique est directement présente dans le prompt transmis à l’IA.

Injection indirecte. L’utilisateur donne un prompt légitime, mais l’IA rencontre ensuite une instruction malveillante dans une source qu’elle consulte.

Injection de prompt indirecte : une instruction malveillante présente dans une source externe est interprétée par une IA.

La prudence de l’utilisateur ne suffit pas toujours et une injection de prompt non détectée peut exposer son IA et son entreprise à un risque de cybersécurité important.

Le risque varie quand l’IA possède des outils

Deux cas peuvent se présenter :

Une IA conversationnelle isolée produira principalement une réponse. Les conséquences directes sont généralement limitées, même si une réponse manipulée peut encore induire l’utilisateur en erreur.
L’IA connectée ou capable d’agir peut lire, rechercher, envoyer, modifier, appeler une API ou déclencher une action. Les conséquences potentielles sont alors beaucoup plus importantes.

Dans tous les cas, il est primordial de vérifier les bases de la sécurité liée à l’IA :

À quelles données a-t-elle accès ?
Peut-elle envoyer des messages ou modifier des fichiers ?
Peut-elle appeler des services externes ?
A-t-elle accès à des clés d’API ou à des secrets ?

Les réponses à ces questions donneront une idée de l’impact potentiel d’une injection de prompt. Plus l’IA dispose d’accès aux données et de capacités d’action, plus les conséquences potentielles doivent être prises au sérieux. On ne le répétera jamais assez :

La règle du moindre privilège s’applique pleinement à l’utilisation d’une IA.

Une IA hébergée localement n’échappe pas à ce risque : la maîtrise de l’hébergement ne dispense pas de sécuriser les instructions, les données auxquelles l’IA accède et les actions qu’elle peut réaliser.

Pourquoi je n’utilise plus de bibliothèques de prompts

Je ne récupère plus de prompts prêts à l’emploi sur Internet. Lorsque j’ai besoin d’un prompt complexe pour Claude, je préfère demander à ChatGPT de le construire à partir de mon besoin, puis je le contrôle avant de le transmettre à Claude.

Cette démarche n’est pas liée à ces deux outils : le principe reste le même quelles que soient les IA utilisées. Elle ne garantit évidemment pas qu’un prompt soit sans risque, mais elle évite d’introduire volontairement dans la chaîne des instructions dont je maîtrise mal la provenance.

Une IA peut néanmoins produire une instruction problématique que la seconde ne détectera pas forcément. D’où l’importance du contrôle humain entre les deux interfaces. L’objectif n’est pas de supprimer tout risque, mais de mieux maîtriser la provenance des instructions utilisées.

Méthode de création d’un prompt avec deux IA et contrôle humain avant transmission à la seconde IA.

Comment réduire le risque en entreprise ?

Une injection de prompt ne se traite pas uniquement au niveau du modèle d’IA. La sécurité dépend aussi de la manière dont l’application est conçue, des données auxquelles elle peut accéder et des actions qu’elle est autorisée à réaliser. Pour une entreprise, quelques principes permettent déjà de réduire le risque :

Tracer : connaître l’origine d’un prompt avant de l’utiliser, particulièrement lorsqu’il provient d’une bibliothèque ou d’une source externe. Pour les usages récurrents, l’entreprise peut également constituer une bibliothèque interne de prompts validés ou identifier des sources externes de confiance.

Relire : comprendre les instructions avant de les transmettre à une IA. Un prompt complexe ne devrait pas être considéré comme anodin simplement parce qu’il est écrit en langage naturel.

Comparer : confronter les instructions à l’objectif recherché et repérer celles qui n’ont aucune raison d’être présentes.

Écarter : en cas de doute sur l’origine ou le comportement d’un prompt, ne pas l’utiliser.

Quatre réflexes face à un prompt d’origine inconnue : tracer, relire, comparer et écarter.

Pour les IA capables d’accéder aux données ou d’agir sur le système d’information, ces précautions doivent être complétées par des mesures techniques : limiter leurs droits au strict nécessaire, isoler les données sensibles, journaliser les actions et maintenir une validation humaine pour les opérations critiques.

Enfin, ces systèmes doivent être testés face aux injections de prompts. Il ne suffit pas de vérifier si le modèle refuse une instruction malveillante : il faut aussi observer ce qu’une instruction malveillante pourrait lui faire lire, révéler ou exécuter.

J’y reviendrai plus en détail dans un prochain article.

Conclusion

Le prompt est souvent vu comme la manière de demander quelque chose à une IA. Mais depuis l’arrivée des agents et des IA connectées au SI, cette définition est à revoir. Aujourd’hui, un prompt peut donner des instructions à une IA capable d’agir sur des données et des applications. Il devient ainsi un vecteur d’attaque potentiel qui doit être pris en compte dans la politique de cybersécurité de l’entreprise. L’injection de prompt figure d’ailleurs sous la référence LLM01 dans le Top 10 OWASP 2026 des risques pour les applications utilisant des LLM (voir sources).

À mesure que les IA gagnent en capacité d’action, la provenance de leurs instructions devient elle aussi une question de cybersécurité.