GuidesSécurité IA
Votre assistant IA peut-il être retourné contre vous ? Le test en 3 questions
Trier les mails, répondre aux clients, préparer un devis : un assistant IA rend ces services parce qu'il lit et agit à votre place. Trois questions suffisent pour savoir s'il peut aussi le faire pour quelqu'un d'autre.
Ivan SommavillaFondateur de Nexus Core
- Catégorie
- Sécurité IA
- Temps de lecture
- 5 min
- Publication
- 27 octobre 2026
Sommaire
Le constat
Un assistant IA branché sur vos outils lit du texte écrit par d'autres : les mails qu'il trie, le formulaire rempli sur votre site, la page web qu'il résume, le PDF envoyé par un fournisseur. Or un modèle de langage ne fait pas de différence fiable entre vos consignes et celles qu'un inconnu glisse dans ce texte. C'est l'injection de consignes (prompt injection).
L'OWASP, fondation de référence en sécurité des applications, le dit sans détour dans son classement 2026 des risques des applications d'IA : aucun mécanisme de prévention fiable n'existe aujourd'hui. La défense ne consiste donc pas à espérer détecter l'attaque, mais à construire l'outil pour qu'une consigne piégée, même suivie, ne mène à rien de grave.
Le test qui suit sert à cela. Il ne juge ni la qualité des réponses ni le modèle utilisé : seulement ce que l'assistant a le droit de lire et de faire. Il se passe en cinq minutes, sans être technicien.
Les trois questions
| Question | On répond « oui » si l'assistant… |
|---|---|
| A. Lit-il du contenu que n'importe qui peut écrire ? | lit des mails reçus, un formulaire de votre site, des pages web, des PDF envoyés par des tiers, des avis clients, des tickets |
| B. A-t-il accès à des données privées ? | voit votre fichier clients, vos devis, votre comptabilité, votre boîte mail, vos documents internes |
| C. Peut-il agir ou envoyer quelque chose vers l'extérieur ? | envoie un mail, publie, paie, modifie ou supprime une donnée, appelle une adresse web, ou affiche une image ou un lien |
La troisième question se lit large. Une image affichée dans une réponse suffit : si son adresse est choisie par l'attaquant et contient vos données, le simple fait de la charger les lui envoie, sans aucun clic.
Lire le résultat
| Réponses « oui » | Niveau | Ce qu'il faut faire |
|---|---|---|
| A, B et C | 🔴 Haut risque | Couper l'un des trois accès (le plus simple : C), ou faire valider chaque action par un humain qui voit l'action exacte, pas un résumé |
| A et B, ou A et C | 🟠 À évaluer | Écrire le risque qui reste et pourquoi on l'accepte ; borner ce qui peut sortir (destinataires, domaines, montants) |
| B et C, sans A | 🟡 Sous contrôle | Vérifier qu'aucun texte extérieur n'entre par un détour : pièce jointe, document partagé, résultat de recherche |
| Un seul, ou aucun | 🟢 Faible | Rien de spécifique ; les règles habituelles de sécurité s'appliquent |
Les niveaux rouge et orange reprennent la « règle de deux » que l'OWASP retient comme plancher : un assistant qui cumule les trois accès doit faire approuver chaque action par un humain, et celui qui en cumule deux, dont la lecture de contenu extérieur, doit faire l'objet d'une évaluation écrite du risque restant. Les niveaux jaune et vert, et le conseil de couper d'abord la troisième jambe, sont ma lecture.
Pourquoi ça marche : une consigne piégée arrive par A, vise ce que protège B et sort par C. Retirer une seule des trois jambes retire la condition d'une attaque grave, quel que soit le modèle. La règle et son origine sont détaillées dans le guide Sécuriser un agent IA de code.
Le test passé sur mes propres outils
Avant de le proposer, je l'ai passé sur les quatre assistants IA que j'utilise. Résultat : un vert, un orange, deux rouges.
| Assistant | A | B | C | Niveau |
|---|---|---|---|---|
| Assistant du site | oui (visiteurs) | non | non | 🟢 |
| Tri de mes mails | oui (mails reçus) | non pour le modèle | oui, décidé par le code | 🟠 |
| Assistant personnel sur messagerie | oui | oui, en lecture | oui, borné | 🔴 |
| Assistant de code | oui | oui | oui | 🔴 |
Le tri des mails est orange parce que le modèle ne fait que classer : c'est le code qui choisit le dossier et compose l'alerte, et il ne sait ni envoyer de mail ni supprimer. Le test a quand même trouvé un point faible : le résumé d'un mail piégé pouvait faire recopier un numéro de téléphone ou un IBAN jusque dans mes alertes. Ces numéros sont désormais masqués.
Pour l'assistant de code, les trois accès sont le prix de son utilité. Je les ai bornés : un bac à sable qui limite les adresses joignables, un compte dédié sur mon serveur où, en administrateur, il ne peut lancer qu'une liste fermée de scripts, et aucune mise en ligne sans une revue indépendante puis ma validation.
Deux limites à connaître
- La validation humaine s'use. À fort volume, on finit par approuver sans lire ; l'OWASP le note expressément. Mieux vaut couper un accès que de faire valider cent actions par jour.
- Le test ne mesure pas l'autonomie. Un assistant qui enchaîne vingt actions sans retour humain reste plus risqué qu'un assistant qui en fait une, même avec les mêmes réponses ; l'OWASP relève que la règle de deux ne dit rien de cette profondeur.
L'ANSSI va dans le même sens dans ses recommandations pour les systèmes d'IA générative : proscrire l'usage automatisé de l'IA pour des actions critiques, comme une transaction bancaire, la production de contenu public ou une action qui a un impact direct sur des personnes (R9), et limiter, voire proscrire, les actions automatiques déclenchées à partir d'entrées non maîtrisées, comme des données issues d'Internet ou de mails (R27).
Chaque automatisation IA que je livre passe ce test, et son résultat figure dans le dossier remis au client : voir Agents IA.
Sources
- OWASP GenAI Security Project, « OWASP Top 10 for LLM Applications 2026 », version 1.0, entrée LLM01 « Prompt Injection », p. 13-14 (licence CC BY-SA 4.0).
- ANSSI, « Recommandations de sécurité pour un système d'IA générative », guide ANSSI-PA-102, 29 avril 2024, recommandations R9 et R27.