OWASP Top 10 LLM 2026 : la grille qui relie les risques des modèles

L’édition 2026 du OWASP Top 10 for LLM Applications a été publiée le 4 août 2026 par le projet GenAI Security de l’OWASP. Elle classe dix risques, codés LLM01 à LLM10, pour les applications qui emploient un modèle de langage comme composant. Le modèle lui-même, qu’on entraîne, qu’on interroge et qu’on vole, relève d’une autre liste, l’OWASP Machine Learning Security Top 10. Cette page n’est pas un onzième article du site sur l’injection de prompt : la rubrique IA couvre déjà le fond de ces dix risques, page par page. C’est la grille qui les relie, avec ce qui manquait ailleurs — le code officiel, l’édition, et ce qui a bougé depuis l’édition précédente.

→ Lire l’explication complète de la marmotte

Les dix risques de l’édition 2026

Code	Titre officiel	Traduction	Rang en 2025
LLM01:2026	Prompt Injection	Injection de prompt	1
LLM02:2026	Sensitive Information Disclosure	Divulgation d’informations sensibles	2
LLM03:2026	Excessive Agency	Agentivité excessive	6
LLM04:2026	Supply Chain	Chaîne d’approvisionnement	3
LLM05:2026	Data and Model Poisoning	Empoisonnement des données et du modèle	4
LLM06:2026	Unbounded Consumption	Consommation sans borne	10
LLM07:2026	Misinformation	Désinformation	9
LLM08:2026	Hidden Context Exposure	Exposition du contexte caché	7 (sous un autre nom)
LLM09:2026	Vector and Embedding Weaknesses	Faiblesses des vecteurs et des plongements	8
LLM10:2026	Improper Output Handling	Traitement incorrect des sorties	5

Pour chacun de ces risques, le fond est déjà sur le site : l’empoisonnement des données d’entraînement pour LLM05, la sécurité du corpus documentaire d’un système RAG et ce qu’est un plongement pour LLM09, la validation des appels de fonctions pour LLM03 et LLM10, le déni de portefeuille pour LLM06, les secrets placés dans les prompts et le scellement du prompt système pour LLM08, la revue du code généré et l’hallucination de paquets pour LLM10. Ce qui suit ne les répète pas : il explique la grille.

La méthode a changé, et c’est la vraie nouveauté

Toutes les éditions précédentes reposaient sur le jugement : des centaines de praticiens votaient sur ce qui compte le plus. Cette fois, le projet a confronté ce vote à un relevé de ce qui s’est réellement produit. Les auteurs ont rassemblé 7 714 incidents issus de bases publiques de vulnérabilités et d’une base d’incidents liés à l’intelligence artificielle, puis ont construit des classifieurs qui en ont trié 6 639, ceux qui portaient assez de détail. La question posée était simple : ce que craignent les praticiens correspond-il à ce que montre le relevé d’incidents ?

La réponse, écrivent-ils, est non, pas toujours — et les désaccords ont plus appris que les accords. Le vote compte pour trois quarts de la pondération finale, les données pour un quart. Ce déséquilibre est délibéré et expliqué : une liste de consensus ne doit pas être réécrite par une année de données imparfaites, mais un quart de poids suffit à déplacer une entrée d’un cran quand l’écart entre croyance et preuve est large.

Deux cas méritent le détour, parce qu’ils disent quelque chose de la mesure en sécurité.

L’injection de prompt est classée première par les praticiens. Classée selon le relevé brut d’incidents, elle sort complètement du top 10. Les auteurs lisent cet écart comme un effet de défense : les équipes se battent dur contre l’injection, donc peu d’exploitations propres atteignent une base publique, et le décompte public sous-estime un risque que les équipes mûres paient cher à contenir. Elle reste première. La surface, rappellent-ils, se trouve partout où un modèle lit une entrée non fiable, c’est-à-dire partout.

La désinformation va dans l’autre sens, et c’est l’entrée sur laquelle les auteurs demandent de ralentir. Les votants l’avaient placée en bas de liste ; le relevé d’incidents la place en haut. C’est l’écart le plus large dans la direction qui fait mal : la croyance basse, la preuve haute. La liste la place finalement au milieu, en septième position. Quand une sortie fluide et assurée déclenche une décision ou un appel d’outil, une réponse fausse devient une action fausse — et le relevé dit que cette défaillance arrive plus souvent que le vote ne le suppose.

Ce qui a bougé depuis 2025

L’agentivité excessive monte de la sixième à la troisième place, et c’est le mouvement le plus lourd de conséquence de la liste. Vote et relevé d’incidents sont d’accord sur ce point : c’est dans les déploiements agentiques que les dégâts atterrissent.

La consommation sans borne gagne quatre places, de la dixième à la sixième, portée par des praticiens qui pèsent l’épuisement des ressources et des budgets plus haut qu’avant. Le traitement incorrect des sorties tombe le plus bas, de la cinquième à la dixième. La divulgation d’informations sensibles tient la deuxième place : c’est, écrivent les auteurs, le seul endroit du haut de liste où croyance et preuve concordent simplement, et donc celui où leur confiance est la plus haute.

« System Prompt Leakage » devient « Hidden Context Exposure », et le renommage corrige un contresens tenace. Ce que l’entrée dit — déjà en 2025, plus explicitement en 2026 — est l’inverse de ce qu’on lui prête. Un prompt système n’est pas un secret. Les praticiens doivent concevoir en partant du principe que le contexte caché est découvrable, et que rien de ce qu’il contient ne doit être considéré comme confidentiel. Le vrai défaut est derrière : des identifiants ou des jetons placés dans ce contexte, des garde-fous dont le contournement devient trivial dès qu’on lit leurs conditions, une séparation de privilèges déléguée au modèle. La gravité, dit le texte, suit ce qu’on a mis dans le contexte caché et la façon dont l’application s’y repose — d’« informatif » quand sa divulgation n’a aucun impact, à « critique » quand elle enchaîne vers une exécution de code ou une exfiltration large.

Le nouveau nom élargit d’ailleurs le périmètre au-delà du prompt : instructions de développeur, texte de politique récupéré depuis une base documentaire ou un service de profils, et schémas des outils et fonctions exposés au modèle. C’est cohérent, puisque la description d’un outil qui indique « nécessite le rôle développeur » renseigne autant qu’une consigne.

Quatre entrées ont grossi plutôt que d’être dédoublées, au motif explicite que des catégories étroites auraient émietté la liste sans rien apporter. L’injection de prompt couvre désormais les attaques multimodales, où l’instruction se cache dans une image ou une piste audio. La chaîne d’approvisionnement couvre le cas où un artefact de modèle promu n’est pas ce qu’il prétend être. L’empoisonnement des données et du modèle absorbe la subversion par réglage fin. Le traitement incorrect des sorties englobe le code non sécurisé que les assistants produisent à grande échelle.

La frontière avec le Top 10 des applications agentiques

L’édition 2026 pose cette frontière en toutes lettres, et c’est utile, parce que les deux listes se chevauchaient dans l’usage. Cette liste porte le risque tant que le modèle est un composant à l’intérieur de l’application. À l’instant où ce modèle devient un acteur — avec des outils qu’il appelle, une mémoire qu’il conserve entre les sessions et des conséquences qu’il déclenche en aval — le risque passe au Top 10 OWASP des applications agentiques.

Les auteurs reconnaissent que beaucoup d’incidents lus se situent exactement sur cette ligne, et donnent la règle d’usage : lire une entrée ici pour la défaillance du modèle-composant, et l’apparier avec la liste agentique dès que le modèle agit de lui-même, parce qu’aucune des deux ne couvre seule ce terrain. Le site décrit ce basculement dans la sécurité des agents autonomes outillés.

Trois exclusions explicites de l’entrée LLM08 montrent comment la frontière fonctionne en pratique : la fuite de données d’usagers ou d’entraînement relève de LLM02, pas de LLM08 ; les amplifications agentiques du même risque — mémoire persistante, canaux entre agents, persistance de configuration d’outils — relèvent de la liste agentique ; les problèmes d’application classiques hérités par un système intégrant un modèle — fuite par les journaux côté serveur, inspection du paquet côté client — relèvent de la sécurité applicative ordinaire.

Comment s’en servir sans en faire une norme

La posture revendiquée par les auteurs tient en une phrase, et elle vaut mieux que la plupart des recommandations du secteur : cessez d’essayer de construire un modèle qu’on ne peut pas tromper ; construisez le système autour de lui pour que, le jour où il est trompé — et il le sera — rien d’important ne casse. Les dix entrées découlent de cette position, et elle explique pourquoi les contre-mesures sérieuses sont presque toutes extérieures au modèle : validation déterministe des sorties, autorisation appliquée hors du modèle, bornes de consommation, séparation des privilèges par contexte.

Ce qui vaut pour les autres référentiels de la famille vaut ici : ce n’est ni une norme opposable, ni une certification, ni un plan de remédiation. Personne n’est en conformité avec LLM03. Pour l’articulation avec une obligation réelle, c’est la rubrique Normes qui porte le sujet — et le règlement européen sur l’intelligence artificielle ne cite aucun Top 10 comme source d’exigence. La façon de citer ces documents selon leur maturité est traitée dans la page chapeau des Top 10 de l’OWASP.

Dernier point d’hygiène, et il est propre à cette liste plus qu’à toute autre : un code sans son millésime ne veut rien dire ici. « LLM03 » désigne l’agentivité excessive en 2026 et la chaîne d’approvisionnement en 2025. « LLM05 » désigne l’empoisonnement en 2026 et le traitement des sorties en 2025. Sept des dix entrées ont changé de numéro en un an. Un ticket, une politique interne ou un tableau de bord qui citent un code nu deviendront faux à la prochaine édition, et probablement avant.

🐝 Ce qui arrive si on s’en passe

Sans le millésime à côté du code, un indicateur « LLM05 » suivi depuis un an compare l’empoisonnement de données au traitement des sorties : la courbe décrit une amélioration qui n’a jamais eu lieu, et le ticket de correction ne désigne plus rien. Sans la leçon réelle de LLM08, une équipe passe des semaines à durcir un prompt système contre l’extraction au lieu de retirer les identifiants qui s’y trouvent : le contexte finit par fuir, comme prévu, et les secrets partent avec. Sans contrôle déterministe hors du modèle, une autorisation déléguée à une consigne textuelle tombe à la première instruction cachée dans un document lu, et aucune trace ne distingue l’action légitime de l’action détournée. Sans borne de consommation, une boucle d’appels déclenchée par une entrée hostile n’indisponibilise rien et produit une facture d’inférence que personne ne regarde avant la fin du mois. Sans la frontière avec la liste agentique, un système qui appelle des outils est évalué avec une grille conçue pour un modèle qui se contente de répondre, et les défaillances propres à l’action — mémoire empoisonnée, délégation de privilèges, cascade entre agents — n’apparaissent dans aucune analyse.

🦫 Explication de la marmotte 🍫

Une association internationale de spécialistes en sécurité informatique publie chaque année une liste des dix problèmes les plus graves pour les logiciels qui utilisent une intelligence artificielle capable d’écrire du texte. La version actuelle date d’août 2026.

Les problèmes recensés sont de plusieurs sortes. Le modèle peut suivre une consigne malveillante cachée dans un document, une image ou un son qu’on lui donne à lire. Il peut répéter une information confidentielle qu’il a vue pendant son apprentissage ou dans un échange précédent. Il peut se tromper en donnant l’impression d’être sûr de lui, et cette erreur devient grave quand un autre programme agit sur sa réponse. Il peut consommer sans limite du temps de calcul facturé. Et les données, les modèles ou les composants utilisés pour le construire peuvent avoir été modifiés par un attaquant.

Une entrée de cette liste est souvent mal comprise. Elle concerne les consignes cachées que l’on donne au modèle avant la conversation. Beaucoup de gens croient qu’elle demande de protéger ces consignes comme un secret. Elle dit l’inverse : il faut partir du principe que ces consignes seront découvertes, et donc ne jamais y mettre de mot de passe, ni s’en servir pour décider qui a le droit de faire quoi. Les vraies protections se placent en dehors du modèle, dans du code ordinaire qui vérifie et qui refuse.

Cette liste change beaucoup d’une année sur l’autre : sept des dix numéros ont changé de sens entre la version de 2025 et celle de 2026. Il faut donc toujours écrire l’année avec le numéro, sinon personne ne saura de quel problème on parlait.

Pages voisines

La citent

OWASP Top 10 LLM 2026 : la grille qui relie les risques des modèles

Elle cite

: les deux pages se citent l’une l’autre.

OWASP Top 10 LLM 2026 : la grille qui relie les risques des modèles

OWASP Top 10 LLM 2026 : la grille qui relie les risques des modèles

Les dix risques de l’édition 2026

La méthode a changé, et c’est la vraie nouveauté

Ce qui a bougé depuis 2025

La frontière avec le Top 10 des applications agentiques

Comment s’en servir sans en faire une norme

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines