Prompt injection : pourquoi 2026 ne la corrigera pas

Prompt injection : pourquoi 2026 ne la corrigera pas

En 2025, des attaquants ont glissé des instructions piégées dans les outils d’IA générative de plus de 90 organisations, puis s’en sont servis pour fabriquer des commandes volant identifiants et cryptomonnaies. Le rapport qui le documente, le 2026 Global Threat Report de CrowdStrike, tranche d’une formule : « les prompts sont le nouveau malware ». Le volume d’attaques assistées par IA a bondi de 89 % en un an.

Le réflexe serait de classer ça parmi les vulnérabilités qu’un correctif règle. C’est l’erreur de lecture qui va coûter cher dans les dix-huit mois qui viennent.

Une faille classée n° 1, deux éditions de suite

L’OWASP, l’organisation de référence sur la sécurité applicative, place la prompt injection en tête de son Top 10 des risques propres aux LLM (grands modèles de langage), au rang LLM01, pour la deuxième édition consécutive. Le classement n’a rien d’un hasard : il acte qu’un LLM ne sait toujours pas distinguer de façon fiable une instruction d’une donnée.

Tout le reste découle de là. Le modèle confond l’instruction et le contenu, le contexte et la métadonnée, l’intention de l’utilisateur et ce qui se cache dans un document. Vous lui demandez de résumer une page, il exécute l’ordre planqué dans cette page. La frontière que toute la sécurité informatique a passé quarante ans à ériger, entre le code et les données, n’existe pas dans un LLM.

Le problème n’est pas le modèle, c’est ce qu’on branche dessus

Tant qu’un modèle répond dans une fenêtre de discussion, le risque reste contenu. Il change de nature dès qu’on l’industrialise. Agents autonomes, pipelines RAG (génération augmentée par récupération, où le modèle va chercher des documents externes avant de répondre), routeurs qui aiguillent les requêtes entre plusieurs modèles, mémoire de long terme : chaque brique ajoutée pour rendre l’IA « utile en entreprise » élargit la surface d’attaque.

Un agent ne se contente pas de répondre, il agit : il lit vos fichiers, appelle des API, déclenche des workflows. Lui faire ingérer une instruction malveillante, ce n’est plus lui faire dire une bêtise, c’est lui faire faire quelque chose. Voilà pourquoi la prompt injection fonctionne à la fois comme porte d’entrée et comme amplificateur. On a connecté le modèle à des leviers réels sans résoudre le défaut qui le rend manipulable.

EchoLeak, ou le jour où une IA s’est trahie sans un seul clic

La démonstration la plus nette porte un nom : EchoLeak. En juin 2025, les chercheurs d’Aim Security divulguent cette vulnérabilité (CVE-2025-32711, score de gravité CVSS 9.3), premier exploit documenté de prompt injection « zero-click », sans aucune action de la victime, contre un système d’IA en production : Microsoft 365 Copilot. Un seul e-mail soigneusement rédigé suffisait à pousser Copilot à consulter des fichiers internes et à en exfiltrer le contenu vers un serveur contrôlé par l’attaquant.

Un an plus tôt, en août 2024, PromptArmor avait déjà montré la même mécanique sur Slack AI : une instruction déposée dans un canal public, ou cachée dans un document, permettait de siphonner des données de canaux privés, clés d’API comprises, sans y avoir le moindre accès.

Les deux failles ont été corrigées. C’est précisément là que le piège se referme : on a patché deux instances, pas la classe de vulnérabilité. La cause, l’incapacité du modèle à trier instruction et donnée, reste intacte. Demain, une autre intégration rouvrira la même porte.

Ce qui vient : la contamination en chaîne

La trajectoire est lisible, et elle pointe vers l’indirect. Deux techniques, déjà observées, vont se généraliser à mesure que les architectures se densifient.

  • L’injection inter-modèles. Un attaquant corrompt la sortie d’un modèle en sachant qu’elle sera reprise, résumée ou traitée par d’autres systèmes en aval. La charge se propage de proche en proche, comme un ver, le long de la chaîne d’IA qui s’échangent du contenu.
  • L’empoisonnement de la chaîne RAG. Plutôt que d’attaquer votre système de front, on sème en amont : documentation piégée, articles de blog, fichiers README sur des dépôts publics. Le jour où votre pipeline va récupérer ce contenu pour nourrir une réponse, il avale l’instruction avec.

Le pari, daté : sur 2026 et 2027, la prompt injection ne se règlera pas par un meilleur filtre en entrée. Le filtrage des entrées est un jeu du chat et de la souris que le défenseur perd, parce qu’il existe une infinité de formulations pour dire la même chose à un modèle. La bascule défensive se jouera ailleurs, au niveau de l’architecture, à une condition simple : cesser de faire confiance par défaut.

Concrètement, cela veut dire traiter toute donnée entrant dans un modèle comme potentiellement hostile, cloisonner ce qu’un agent a le droit de faire (principe du moindre privilège), et placer une validation humaine ou déterministe entre la décision du modèle et l’action irréversible. C’est déjà la direction qu’explore la recherche : CaMeL, proposé par Google DeepMind, troque le filtre contre de vieux principes de sécurité logicielle (intégrité du flux de contrôle, cloisonnement des données non fiables), et neutralise en banc d’essai une large part des injections, au prix d’un surcoût de calcul notable. Les organisations qui auront recâblé leurs agents sur ce principe encaisseront les prochaines failles. Celles qui auront empilé les intégrations en comptant sur un correctif éditeur découvriront, e-mail après e-mail, que le correctif n’arrive jamais pour une faille qui n’est pas un bug, mais le dessin même de ce qu’elles ont déployé.

Le point de bascule à surveiller n’est pas technique, il est culturel : le moment où « brancher une IA sur nos systèmes » cessera d’être un projet produit pour redevenir une décision de sécurité.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *