Agents IA et prompt injection : un risque sous-estimé pour les entreprises
Vous demandez à votre assistant IA de résumer un e-mail professionnel. L'IA s'exécute. Simple, rapide, efficace. Ce que vous ne savez pas, c'est que cet e-mail contenait des instructions cachées invisibles pour vous, parfaitement lisibles pour le modèle. En croyant suivre vos ordres, votre assistant a aussi suivi ceux d'un inconnu.
Bienvenue dans l'univers du prompt injection classé risque numéro 1 par l'OWASP dans son référentiel de sécurité dédié aux applications IA, et qualifié de "problème de sécurité non résolu" par OpenAI lui-même.
Qu'est-ce qu'une prompt injection, exactement ?
Pour comprendre cette attaque, il faut d'abord comprendre comment on "parle" à une IA. Lorsque vous interagissez avec un assistant comme ChatGPT, Copilot ou un chatbot d'entreprise, vous lui envoyez ce qu'on appelle un prompt une instruction en langage naturel. "Résume ce document." "Réponds à cet e-mail." "Trouve-moi les chiffres de vente du trimestre."
Une attaque par prompt injection consiste à glisser des instructions malveillantes supplémentaires dans le contenu que l'IA va traiter un document, un e-mail, une page web pour lui faire exécuter des actions non prévues, à votre insu. Le problème fondamental : un modèle de langage reçoit tout comme un seul et même flux de texte. Il ne dispose d'aucun mécanisme natif pour distinguer "ce que mon utilisateur m'a demandé de faire" de "ce que le contenu que je lis me demande de faire". Si un attaquant glisse des instructions dans un document que l'IA va traiter, le modèle les lira et très souvent les suivra, exactement comme si elles venaient de vous.
C'est une faille non pas dans le code, mais dans l'architecture même de ces systèmes.
Deux types d'attaques, un même résultat
Les attaques par prompt injection se déclinent en deux variantes principales.
La première l'injection directe est celle où l'attaquant interagit directement avec le modèle en formulant une requête conçue pour court-circuiter ses règles internes. L'objectif : forcer l'IA à révéler ses instructions confidentielles, contourner ses propres garde-fous, ou se comporter d'une façon non prévue.
La seconde, l'injection indirecte, est nettement plus insidieuse. L'attaquant n'a pas besoin d'interagir avec vous directement. Il lui suffit de placer des instructions malveillantes dans un contenu que votre assistant IA va consulter à votre place : un document partagé, une page web, un e-mail, un fichier PDF. Quand l'IA lit ce contenu pour vous en faire un résumé, elle exécute aussi les instructions cachées — sans que vous vous en rendiez compte.
Ce que ça donne en conditions réelles
En octobre 2025, un grand acteur de l'IA lançait un navigateur web intégrant un assistant en mode agent, capable de naviguer, remplir des formulaires et effectuer des recherches à votre place. Moins de 48 heures après le lancement, des chercheurs démontraient que cet agent était vulnérable aux injections indirectes quelques mots stratégiquement placés dans un document en ligne suffisaient à modifier son comportement, sans aucun avertissement.
En mars 2026, l'attaque "Claudy Day" était documentée par des chercheurs en sécurité : un attaquant avait créé un lien dont les paramètres contenaient des instructions cachées via des balises HTML invisibles. Dès qu'un utilisateur cliquait sur ce lien et ouvrait son assistant IA, les commandes cachées prenaient le contrôle — amenant l'agent à exfiltrer silencieusement l'historique complet des conversations de l'utilisateur.
Plus préoccupant encore : une vulnérabilité critique (CVE-2025-32711, CVSS 9.3) découverte en juin 2025 dans un assistant IA intégré à une suite collaborative d'entreprise largement utilisée permettait à un attaquant d'exfiltrer des informations sensibles simplement en envoyant un e-mail contenant l'injection. Aucune action de la victime n'était requise — zéro clic. Un correctif côté serveur a été déployé dès mai 2026.
Le problème s'aggrave avec les agents autonomes
Si les assistants conversationnels posent déjà un problème sérieux, la situation prend une autre dimension avec les agents IA autonomes ces assistants qui agissent à votre place : envoyer des e-mails, valider des commandes, accéder à des systèmes internes. Un assistant qui se fait injecter une instruction malveillante va peut-être révéler une information confidentielle. Un agent qui peut agir va potentiellement effectuer cette action lui-même — modifier un paramètre, transférer un fichier, déclencher un paiement. Même vecteur d'attaque, conséquences bien plus larges.
Comment se protéger concrètement
Traiter tout contenu externe comme non fiable : documents reçus, pages web consultées par un agent IA doivent être considérés comme potentiellement malveillants.
Limiter strictement les permissions des agents IA : un assistant qui résume des e-mails n'a pas besoin d'accès à la comptabilité.
Exiger une validation humaine pour les actions sensibles : transferts financiers, modifications de configuration ou communications externes ne doivent jamais être délégués intégralement à un agent sans confirmation humaine.
Intégrer des tests d'injection dans les audits de sécurité : comme on teste les applications web, les déploiements IA doivent être testés spécifiquement pour leur résistance aux injections.
Former les équipes : un collaborateur qui comprend le risque est une protection en soi.
Conclusion
Le prompt injection n'est pas un bug qu'une mise à jour viendra corriger. C'est une conséquence directe de la façon dont les modèles de langage fonctionnent et elle persistera tant que ces modèles seront incapables de distinguer nativement une instruction d'une donnée. Dans un monde où l'IA lit, agit et décide à notre place, lui accorder une confiance aveugle n'est plus une option.