Le projet OWASP GenAI Security a publié début août 2026 une nouvelle édition de son Top 10 des risques des applications LLM. Elle mérite qu'on s'y arrête, moins pour son classement que pour la phrase qui l'ouvre : plutôt que de chercher un modèle qu'on ne puisse pas tromper, construisez le système autour de lui pour que, le jour où il est trompé, rien d'important ne casse. Sécuriser une application LLM, c'est d'abord accepter ce renversement.
Ce que la version 2026 change
Deux nouveautés méritent d'être connues avant d'entrer dans le détail.
Le classement s'appuie pour la première fois sur des incidents réels. Les éditions précédentes reposaient entièrement sur le vote de la communauté. Celle-ci conserve ce vote pour 75 % du poids et introduit, pour le quart restant, les données de 6 639 incidents relevés dans des bases publiques de vulnérabilités et une base recensant les dommages liés à l'IA. Le référentiel cesse d'être une opinion d'experts pour devenir en partie une observation.
Le périmètre s'élargit. L'injection de prompt couvre désormais les attaques dites multimodales, dont la charge est dissimulée dans une image ou un fichier audio plutôt que dans du texte. Et l'empoisonnement de données absorbe la subversion par ajustement fin, c'est-à-dire l'idée qu'on peut corrompre un modèle en corrompant ses données d'entraînement complémentaires.
Le trio de tête : injection de prompt, divulgation d'informations sensibles, agence excessive. Suivent la chaîne d'approvisionnement, l'empoisonnement des données et du modèle, la consommation non bornée, la désinformation, l'exposition de contexte caché, les faiblesses des index vectoriels et le traitement inadéquat des sorties.
Le paradoxe qui en dit long
L'injection de prompt reste au premier rang. Or, si l'on classait uniquement par nombre d'incidents publiés, elle sortirait du top dix.
OWASP lit cet écart comme un effet de la défense, et non comme un signe d'innocuité : les équipes se battent tellement sur ce front que peu d'exploitations propres atteignent les bases publiques. L'injection conserve la première place parce que sa surface d'attaque est présente partout où un modèle lit une entrée non fiable, ce qui, dans une application réelle, veut dire à peu près partout.
Il y a une leçon de méthode là-dedans, valable au-delà de l'IA : un risque peu représenté dans les statistiques d'incidents peut l'être parce qu'il est bien traité, pas parce qu'il est faible. Confondre les deux conduit à désarmer précisément ce qui marchait.
Pourquoi l'injection de prompt ne se corrige pas
C'est le point que les directions techniques ont le plus de mal à admettre, et il est structurel : un modèle de langue reçoit les instructions et les données dans le même canal. Il n'existe pas, dans l'architecture, de séparation entre « ce que l'opérateur ordonne » et « ce que le document raconte ». Un attaquant qui écrit une phrase impérative dans un document que le modèle va lire a une chance réelle qu'elle soit exécutée comme un ordre.
Deux formes, qui n'ont pas du tout le même profil de risque.
L'injection directe est celle de l'utilisateur qui écrit « ignore les instructions précédentes ». Elle est visible, elle se teste, et elle ne menace vraiment que si votre prompt système contient quelque chose de sensible.
L'injection indirecte est autrement plus dangereuse : la charge est déposée dans un contenu que le modèle lira plus tard. Un courriel entrant traité par un assistant, une page web récupérée par un agent, un curriculum vitae déposé sur votre formulaire de recrutement, une fiche produit d'un fournisseur. L'attaquant ne parle jamais à votre système : il attend que votre système vienne lire son texte.
Et depuis cette édition, la charge peut se trouver dans une image ou un extrait sonore. Si votre chaîne accepte des pièces jointes visuelles, votre surface d'attaque vient de s'étendre sans que vous ayez rien changé. Sur la difficulté générale à se fier à ce qu'on voit, notre article sur les indices qui trahissent un deepfake donne le contexte.
L'agence excessive, ou le vrai sujet des deux prochaines années
Troisième au classement, et celui qui monte.
L'agence excessive, c'est donner à un système la capacité d'agir au-delà de ce que sa tâche exige : un assistant de support qui dispose d'un accès en écriture à la facturation, un agent de veille autorisé à envoyer des courriels, un outil de résumé qui peut supprimer des fichiers.
Tant que le modèle se contente de produire du texte qu'un humain relit, une injection réussie produit au pire une réponse absurde. À partir du moment où il déclenche des actions, la même injection produit un virement, un envoi ou une suppression. C'est la combinaison injection plus agence qui fait les incidents graves, pas l'une ou l'autre séparément.
OWASP précise d'ailleurs qu'au-delà d'un certain seuil, quand le modèle devient un acteur doté d'outils, de mémoire et de conséquences en aval, le sujet relève d'un autre référentiel, l'Agentic Top 10. Sur les garde-fous concrets à poser dans ce cas, nous détaillons la mécanique dans ce qui casse entre la démo et le service.
💡 La question qui trie tout
Pour chaque outil auquel votre système a accès, demandez-vous : si un inconnu écrivait lui-même les arguments de cet appel, qu'est-ce qui se passerait de pire ? C'est exactement le pouvoir que vous accordez à quiconque peut glisser du texte dans ce que votre modèle lit. La réponse dicte le niveau de contrôle à poser en amont, et c'est la première chose que nous regardons dans un audit NET&PRO.
Ce qu'on met en face
Aucune de ces mesures ne suffit seule. C'est ce qui explique la formulation d'OWASP : on ne bloque pas l'attaque, on limite ce qu'elle peut atteindre.
Le moindre privilège, appliqué aux outils. Chaque outil exposé au modèle reçoit le droit minimal nécessaire, et rien de plus. Séparez la lecture de l'écriture. Un agent qui n'a pas de droit d'écriture sur la facturation ne peut pas émettre d'avoir, quelle que soit l'ingéniosité de l'injection.
Un humain sur les opérations qui engagent. Paiement, envoi externe, suppression, modification de droits : validation explicite. Ce n'est pas un aveu de faiblesse technique, c'est le même principe que la double signature bancaire.
Le contenu externe explicitement marqué. Encadrez dans vos invites ce qui provient de l'extérieur, et dites-le au modèle : ce bloc est une donnée à analyser, jamais une instruction à suivre. Ce n'est pas une garantie, c'est une réduction mesurable du taux de réussite des injections.
La sortie validée avant tout effet. Un contrôle déterministe, écrit en code ordinaire, avant chaque action : le montant est dans une fourchette plausible, le destinataire figure dans une liste connue, le format est conforme. On ne fait pas valider une IA par une autre IA sur ce qui engage.
Le traitement inadéquat des sorties, catégorie souvent négligée, mérite une mention à part : si la réponse du modèle est insérée dans une page web, une requête de base de données ou une commande système sans échappement, vous avez rouvert les failles classiques du web par une porte neuve. Une sortie de modèle est une entrée utilisateur, avec exactement les mêmes précautions.
Une consommation bornée. Plafond de jetons, plafond de tours, limitation du débit par utilisateur. Sans ces bornes, un attaquant n'a même pas besoin d'exfiltrer quoi que ce soit : il lui suffit de faire tourner votre facture.
La fuite d'information, deuxième au classement, et la plus banale
Deuxième position, et c'est probablement là que se situe le risque le plus immédiat pour une PME, parce qu'il ne demande aucune attaque.
Les cas ordinaires : un prompt système qui contient une clé d'API ou une règle commerciale confidentielle ; des journaux de débogage qui conservent le texte intégral des échanges, données personnelles comprises ; un index vectoriel construit sur des documents internes sans filtrage par droits, où toute question bien posée devient une requête sur des documents auxquels l'utilisateur n'avait pas accès.
Ce dernier point mérite d'être souligné, parce qu'il est systématiquement découvert trop tard : si votre recherche documentaire ne filtre pas par les droits de l'utilisateur qui pose la question, elle contourne votre gestion des droits. Le modèle ne fait que restituer ce que la recherche lui a donné.
Et tout cela relève du RGPD comme n'importe quel traitement, avec les obligations correspondantes de durée de conservation, de minimisation et de traçabilité. Le cadre réglementaire ajoute par-dessus ses propres exigences, que nous détaillons dans ce que change l'AI Act depuis août 2026.
Par où commencer, concrètement
Une revue tient en une journée si l'on s'y prend dans cet ordre.
- Inventoriez les entrées non fiables. Tout ce que votre modèle lit et que vous n'avez pas écrit : formulaires, courriels, fichiers déposés, pages récupérées, contenus fournisseurs, index documentaires. C'est votre surface d'injection.
- Inventoriez les actions possibles. Chaque outil, chaque droit, chaque effet de bord. C'est votre rayon de souffle.
- Croisez les deux. Une entrée non fiable qui peut atteindre une action irréversible est une priorité. Le reste attend.
- Coupez ce qui n'est pas nécessaire. L'outil dont personne ne se sert, le droit d'écriture hérité d'un prototype, l'index qui contient trois ans d'archives dont vous n'avez plus besoin.
- Testez avec de vraies charges. Écrivez vous-même dix tentatives d'injection dans les documents que votre système lit, et regardez ce qui passe. C'est instructif, et rarement rassurant la première fois.
Le point 4 est celui qui produit le plus de sécurité par heure investie, et c'est aussi le seul qui ne demande ni budget ni compétence particulière. Commencez par là.
