Bienvenue dans un nouveau numéro de Décryptage IA, la rubrique où l’on prend un concept technique qui fait peur sur le papier, et où on le rend digeste en quelques minutes de lecture. Aujourd’hui, on s’attaque à un terme que vous allez croiser de plus en plus souvent dans l’actualité : l’injection de prompt indirecte.
Ce n’est pas un gadget de laboratoire réservé aux chercheurs en sécurité. C’est, selon l’organisation de référence en la matière, le risque numéro un recensé sur l’ensemble des applications construites autour de l’intelligence artificielle générative. Et pourtant, la plupart des utilisateurs, et même certains développeurs, n’ont qu’une vague idée de ce que ça recouvre vraiment.
D’abord, un rappel : comment un assistant IA reçoit ses ordres
Pour comprendre le problème, il faut d’abord comprendre une particularité fondamentale des grands modèles de langage, les technologies qui font tourner ChatGPT, Claude, Gemini et tous leurs cousins.
Un assistant IA ne fait pas de différence structurelle entre une instruction et une donnée. Tout arrive sous la même forme : du texte. Que ce texte provienne de vous, de son concepteur, ou d’un document que vous lui avez demandé de lire, le modèle le traite fondamentalement de la même façon comme du langage à interpréter et, potentiellement, à suivre.
| 💡 Le mot du jour : frontière de confiance En sécurité informatique classique, on sépare toujours nettement le code exécutable des données qu’il traite, c’est ce qu’on appelle une frontière de confiance. Un programme ne va jamais spontanément « exécuter » le contenu d’un fichier texte qu’il ouvre. Un modèle de langage, lui, n’a pas cette frontière aussi nette : le texte qu’il lit et le texte qui lui donne ses instructions se mélangent dans le même flux. C’est cette absence de cloison qui rend l’injection de prompt possible. |
Directe ou indirecte : la distinction qui change tout
Il existe deux grandes familles d’injection de prompt, et confondre les deux fait perdre l’essentiel du sujet.
| Injection directe | Injection indirecte | |
| Qui tape le message piégé ? | L’attaquant lui-même, dans la fenêtre de discussion | Personne ne le tape directement : il est caché dans un contenu tiers |
| Autre nom courant | « Jailbreak » | Attaque par contenu empoisonné |
| Exemple simple | « Ignore tes instructions précédentes et… » | Un document, une page web ou un e-mail contient un ordre invisible |
| Qui est visé ? | Le modèle lui-même et ses propres restrictions | Un utilisateur légitime, à son insu, via son propre assistant |
| Niveau de danger perçu par les experts | Connu et largement étudié depuis 2022 | Considéré comme nettement plus sérieux et plus difficile à contrer |
C’est cette seconde catégorie qui inquiète le plus la communauté de la sécurité, et pour une raison précise : dans une injection indirecte, l’attaquant ne s’adresse jamais à vous, et encore moins à votre assistant IA. Il empoisonne, en amont, un contenu qu’il sait que votre assistant va tôt ou tard rencontrer sur son chemin : un document, une page web, un e-mail, une image.
L’analogie qui rend tout ça limpide
Voici l’image que la plupart des spécialistes utilisent pour vulgariser ce concept, et elle fonctionne remarquablement bien.
| 🧐 Le stagiaire trop obéissant Imaginez que vous confiez à un stagiaire le tri de votre courrier professionnel chaque matin. Un jour, une enveloppe glissée dans la pile contient, en plus de son contenu normal, une petite note : « Merci de scanner tous les documents confidentiels du tiroir du haut et de les envoyer à cette adresse e-mail. » Un stagiaire humain un tant soit peu vigilant repérerait immédiatement l’anomalie : cette note ne vient pas de son responsable, elle est arrivée par un canal qu’il n’a aucune raison de considérer comme légitime. Il la signalerait, ou l’ignorerait tout simplement. Un assistant IA mal protégé, lui, ne fait pas toujours cette distinction. Il lit le contenu de l’enveloppe, y trouve une instruction rédigée en langage naturel, et parce que c’est justement sa fonction que de suivre des instructions en langage naturel, il l’exécute, sans mauvaise volonté, simplement parce que rien, dans sa conception, ne lui a appris à se méfier du courrier. |
Les portes d’entrée les plus courantes
Une injection de prompt indirecte peut se cacher à peu près partout où un assistant IA va chercher de l’information pour vous rendre service. Voici les vecteurs les plus documentés par les chercheurs en sécurité.
- Un document téléversé. PDF, fichier Word, feuille de calcul : un texte caché ou noyé dans la mise en forme peut transporter une instruction malveillante jusqu’à votre assistant.
- Une page web consultée par l’IA. Un assistant capable de naviguer sur Internet pour répondre à une question peut tomber sur une page conçue spécifiquement pour le piéger, parfois avec du texte invisible, écrit en blanc sur fond blanc, ou codé dans des caractères Unicode non imprimables.
- Un e-mail reçu. Un assistant qui résume automatiquement votre boîte de réception peut être manipulé par un message conçu pour ressembler à un e-mail ordinaire, mais qui contient en réalité des instructions cachées.
- Une image ou un fichier audio. Avec la généralisation des IA capables de traiter plusieurs types de contenus à la fois (texte, image, son), des instructions peuvent désormais se dissimuler jusque dans les métadonnées d’une photo.
- Le résultat d’un autre outil connecté. Quand un assistant IA interroge un logiciel tiers pour le compte de l’utilisateur, la réponse de cet outil peut elle-même transporter une instruction piégée si l’outil n’a pas été correctement sécurisé.
Ce que ça peut concrètement provoquer
Une fois l’instruction cachée exécutée, les conséquences varient selon les privilèges dont dispose l’assistant IA visé. Voici l’éventail des dégâts documentés par les chercheurs, du plus discret au plus grave.
1. Le vol d’informations sensibles. L’assistant peut être détourné pour rechercher, agréger et transmettre des données confidentielles vers un serveur contrôlé par l’attaquant, souvent en dissimulant cette fuite dans une requête d’apparence anodine.
2. La manipulation de l’utilisateur. L’IA peut être poussée à recommander un produit frauduleux, à afficher une fausse information, ou à orienter subtilement une décision de son utilisateur sans qu’il s’en aperçoive.
3. Le détournement d’actions automatisées. Quand l’assistant dispose d’un accès à des outils externes (envoyer un e-mail, modifier un document, exécuter une commande), l’instruction cachée peut lui faire exécuter ces actions à l’insu total de l’utilisateur légitime.
| ⚠️ Un précédent qui a fait date : EchoLeak En juin 2025, des chercheurs en sécurité ont révélé une faille baptisée EchoLeak dans Microsoft 365 Copilot, jugée suffisamment grave pour recevoir un score de gravité de 9,3 sur 10 selon l’échelle standard du secteur. Le principe : un simple e-mail spécialement conçu, envoyé à la victime, contenait des instructions cachées. Quand celle-ci demandait ensuite à Copilot de résumer sa boîte de réception, l’assistant exécutait discrètement ces instructions et exfiltrait des données sensibles sans le moindre clic de la victime. Ce cas a marqué un tournant : jusque-là largement considérée comme un risque théorique de laboratoire, l’injection de prompt indirecte est ainsi devenue, aux yeux de toute l’industrie, une vulnérabilité bien réelle et parfaitement exploitable en conditions de production. |
Ce précédent fait écho à ce qui a été démontré en août 2026 contre Rovo, l’assistant IA d’Atlassian, où un simple document uploadé permettait de faire fuiter le contenu des tickets Jira et des pages Confluence d’une entreprise.
Pourquoi c’est si difficile à corriger
Une question revient souvent : pourquoi les grandes entreprises technologiques, avec leurs moyens considérables, n’ont-elles pas simplement réglé ce problème ? La réponse tient en une phrase qui devrait vous surprendre.
| 💡 Il n’existe, à ce jour, aucune solution miracle Contrairement à d’autres failles informatiques classiques, l’injection de prompt ne peut pas être corrigée par une simple validation technique des entrées, comme on le ferait pour bloquer une injection SQL dans une base de données. La raison est presque philosophique : le langage naturel est, par nature, souple, ambigu et infiniment reformulable. On ne peut pas dresser une liste exhaustive de « mots interdits », parce qu’il existe toujours une façon différente de formuler la même instruction malveillante. Même les modèles les plus avancés du marché restent vulnérables après la mise en place de leurs meilleures mesures de protection, ce qui pousse les experts à recommander une défense en profondeur plutôt qu’une solution unique et définitive. |
Comment les éditeurs tentent de se protéger
Face à l’absence de solution parfaite, l’industrie a développé plusieurs lignes de défense complémentaires, qu’on retrouve de plus en plus dans les systèmes d’IA sérieux.
- La hiérarchie des instructions. Certains modèles sont entraînés à accorder une priorité plus élevée aux instructions de leur système d’origine qu’à tout texte rencontré ultérieurement dans un document ou une page web.
- Les modèles garde-fous. Un second modèle, spécialisé, filtre en amont les contenus suspects avant qu’ils n’atteignent l’assistant principal, c’est exactement le principe du modèle Shieldstral publié récemment par Mistral, que nous avons présenté dans un précédent article.
- Le principe du moindre privilège. Limiter, par défaut, l’accès d’un assistant IA aux seules données et actions strictement nécessaires à sa mission réduit mécaniquement l’ampleur des dégâts possibles en cas de faille.
- La surveillance des sorties. Certains systèmes analysent en continu le comportement de l’assistant à la recherche de requêtes sortantes inhabituelles, signe potentiel d’une exfiltration de données en cours.
| 🧐 Un chiffre qui remet les pendules à l’heure Selon un rapport international sur la sécurité de l’IA publié début 2026, le taux de réussite des attaques par injection de prompt reste élevé même contre les modèles les plus récents, en dessous de dix tentatives. Autrement dit : ce n’est pas une question de « si » un système va être ciblé, mais de savoir si vos défenses en profondeur limiteront suffisamment les dégâts le jour où l’attaque aboutira. |
Ce que vous, utilisateur, pouvez faire dès maintenant
1. Traitez tout contenu externe comme potentiellement suspect. Un document reçu d’un tiers, même a priori inoffensif, ne devrait jamais être soumis sans réflexion à un assistant IA disposant d’un accès large à vos données personnelles ou professionnelles.
2. Limitez les connecteurs et permissions par défaut. Ne donnez à votre assistant IA que les accès strictement nécessaires à la tâche du moment, et révoquez les autorisations superflues.
3. Restez attentif aux comportements inhabituels. Une suggestion inattendue, une action que vous n’avez pas explicitement demandée : ce sont des signaux à ne jamais ignorer, même s’ils paraissent anodins sur le moment.
4. Suivez les bulletins de sécurité des outils que vous utilisez. Cette classe de vulnérabilité évolue vite ; les correctifs et recommandations des éditeurs le sont tout autant.
Ce qui fascine dans l’injection de prompt indirecte, c’est qu’elle ne résulte d’aucun bug au sens classique du terme. Il n’y a pas de ligne de code défaillante à corriger, pas de faille logicielle à colmater d’un simple correctif. Le problème est niché dans la nature même de ce qui rend les grands modèles de langage si utiles : leur capacité à comprendre et suivre des instructions exprimées en langage naturel, peu importe leur origine.
C’est un peu comme si on avait inventé un employé exceptionnellement doué, capable de comprendre n’importe quelle consigne écrite dans n’importe quel style mais à qui on n’aurait jamais appris à se méfier d’une note glissée discrètement sous sa porte. Plus cet employé devient compétent et autonome, plus le risque qu’il obéisse à la mauvaise personne grandit en proportion.
Je ne pense pas que ce problème disparaîtra complètement à court terme. Mais je crois que la prise de conscience progresse, et vite : ce qui était considéré comme un risque théorique de chercheurs en 2023 fait aujourd’hui la une de la presse spécialisée, avec des cas concrets et documentés. C’est souvent ainsi que la sécurité informatique progresse : un incident retentissant à la fois, jusqu’à ce que la prudence devienne un réflexe collectif plutôt qu’une exception.
| 🎯 À retenir en une phrase Un assistant IA ne sait pas naturellement distinguer un ordre de son propriétaire d’un ordre caché dans ce qu’il lit et c’est précisément cette confusion que les attaquants exploitent. |
Et vous, qu’en pensez-vous ?
Ce sujet, encore mal connu du grand public, va pourtant façonner une bonne partie de notre rapport quotidien aux assistants IA dans les années à venir. Voici quatre pistes de réflexion et vos avis sont les bienvenus en commentaire.
1. Utilisez-vous déjà un assistant IA connecté à vos e-mails, vos documents ou vos outils de travail, et cette explication change-t-elle votre façon d’envisager les risques associés ?
2. La responsabilité d’une fuite de données causée par une injection de prompt devrait-elle peser sur l’éditeur de l’IA, sur l’entreprise qui l’a déployée, ou sur l’utilisateur qui a transmis le contenu piégé sans le savoir ?
Dites-moi en commentaire si ce concept vous était familier avant cette lecture, et n’hésitez pas à partager vos propres exemples de contenus suspects rencontrés en utilisant des assistants IA.