Le web d’aujourd’hui a drastiquement évolué et son utilisation a bien changé. Pour s’adapter, il n’est plus question de simplement chatter pour avoir une réponse rapide à nos questions, mais d’intégrer l’IA pour s’adapter aux usages. Un assistant branché sur votre messagerie et votre base documentaire. Un chatbot qui consulte les commandes de vos clients. Un agent qui prépare des devis et les envoie seul. Ces projets d’IA avancent vite dans les entreprises, souvent portés par les métiers. Sauf qu’avec un développement rapide, on en oublie souvent la cybersécurité. Alors d’où démarrer ?
Le 4 août 2026, l’OWASP a publié la nouvelle édition de son Top 10 pour les applications LLM : l’OWASP Top 10 LLM pour l’IA est le référentiel qui permet de parler des risques de l’IA générative avec un vocabulaire commun. Huit risques sur dix changent de place, et le classement intègre désormais des incidents réels.
Voici les dix risques expliqués en langage clair, ce qui a bougé depuis 2025 et comment un pentest applicatif cadré sur cette liste permet de vérifier si votre assistant y est exposé, avant de le confier à vos équipes ou à vos clients.
OWASP Top 10 LLM pour l’IA : de quoi parle-t-on exactement ?
L’OWASP (Open Worldwide Application Security Project) est une fondation à but non lucratif, connue pour son classement des vulnérabilités web. Son projet GenAI Security Project applique la même démarche aux applications construites sur des grands modèles de langage (LLM). La liste classe dix familles de risques, avec des exemples d’attaque et des mesures de protection : un outil de sensibilisation, pas une norme de conformité. La version actuelle est la publication officielle OWASP GenAI LLM Top 10 2026, après les éditions de 2023 et 2025.
Ce Top 10 ne remplace pas le Top 10 OWASP des applications web : il couvre les risques propres aux modèles d’IA (instructions détournées, données exposées par les réponses, outils déclenchés à mauvais escient), là où le Top 10 web couvre les failles classiques d’un site ou d’une API. Une application qui embarque un assistant IA est exposée aux deux.
Ce qui change dans l’OWASP Top 10 LLM 2026
Le classement combine désormais un vote de la communauté (environ 75 % du poids) et des données d’incidents réels (environ 25 %), avec 6 639 incidents classables sur 7 714 recensés. Ce que la communauté redoute et ce qui arrive en production ne coïncident donc pas toujours.
Dans le classement 2026, Prompt Injection (1re place) et Sensitive Information Disclosure (2e place) restent stables. Excessive Agency passe de la 6e à la 3e place, devant Supply Chain (4e, contre 3e en 2025) et Data and Model Poisoning (5e, contre 4e). Unbounded Consumption bondit de la 10e à la 6e place et Misinformation de la 9e à la 7e. Hidden Context Exposure recule de la 7e à la 8e place, Vector and Embedding Weaknesses de la 8e à la 9e, et Improper Output Handling chute de la 5e à la 10e.
Trois mouvements sont à retenir. Plus un assistant peut agir, plus une erreur ou une manipulation coûte cher : c’est ce qui place Excessive Agency dans le trio de tête. Unbounded Consumption fait la plus forte hausse : il s’agit de provoquer des calculs très coûteux pour un effort minime. Enfin, l’ancien « System Prompt Leakage » devient Hidden Context Exposure, au périmètre plus large.
Les 10 risques de l’OWASP Top 10 LLM expliqués simplement
LLM01 Prompt Injection : détourner l’IA avec du texte
Une instruction cachée dans un message, un document ou une page web lue par le modèle suffit à modifier son comportement, que l’attaque soit directe ou indirecte (un CV ou un e-mail à résumer). Plutôt que de chercher un modèle impossible à tromper, il faut limiter les dégâts possibles quand il est détourné.
LLM02 Sensitive Information Disclosure : quand l’IA en dit trop
Le modèle expose des données qu’il ne devrait pas révéler, dans ses réponses, ses journaux ou ses outils : un assistant interne qui cite une grille de salaires indexée par erreur. Limitez les données accessibles et filtrez les réponses. Le versant usage est détaillé dans l’article intitulé Est-ce qu’utiliser une IA est dangereux pour mes données ?
LLM03 Excessive Agency : trop d’autonomie
Un modèle doté d’outils (messagerie, fichiers, API, paiement) peut transformer une sortie manipulée en action réelle. La parade relève du moindre privilège, au cœur du principe du Zero Trust : une identité dédiée, des droits minimaux et une validation humaine pour les actions sensibles.
LLM04 Supply Chain : les composants tiers
Modèles communautaires, jeux de données, adaptateurs : chaque composant tiers est une porte d’entrée. La liste cite les fichiers de modèles au format pickle, capables d’exécuter du code à l’ouverture, et le slopsquatting, où un attaquant enregistre le nom d’un paquet inventé par une IA. Vérifiez l’origine de ce que vous importez.
LLM05 Data and Model Poisoning : des données empoisonnées
Des données corrompues s’intègrent au modèle à l’entraînement, à l’ajustement ou à l’ingestion et y installent un comportement nuisible, difficile à corriger après coup. Maîtrisez vos sources et testez le modèle avant sa mise en production.
LLM06 Unbounded Consumption : la facture comme cible
Un attaquant, ou un usage mal borné, déclenche des calculs très coûteux : on parle de « Denial of Wallet », le service reste en ligne mais la facture d’API explose. Posez des quotas, des plafonds de dépenses et des alertes de coût.
LLM07 Misinformation : des réponses fausses mais crédibles
Le modèle produit une réponse fausse avec aplomb, ce qui devient sérieux quand elle alimente un traitement automatique : un montant inventé repris dans un devis, une clause juridique erronée. Prévoyez une vérification humaine pour toute décision financière, juridique ou opérationnelle.
LLM08 Hidden Context Exposure : le contexte caché ne l’est pas vraiment
Consignes système, règles de modération et schémas d’outils ne sont pas destinés à l’utilisateur, mais des questions habiles peuvent les faire ressortir. Aucun mot de passe ni clé d’API dans ce contexte, et des contrôles d’accès appliqués par le code, pas par une consigne écrite en texte.
LLM09 Vector and Embedding Weaknesses : la base documentaire de l’IA
Beaucoup d’assistants interrogent vos documents via une base vectorielle (le principe du RAG). Si les droits d’accès ne sont pas appliqués à la recherche, un utilisateur peut obtenir des extraits qu’il n’aurait jamais dû voir. Appliquez les droits avant la recherche, pas après.
LLM10 Improper Output Handling : ne jamais faire confiance à la sortie
Une réponse du modèle transmise sans contrôle à un navigateur, une base de données ou un terminal peut déclencher une injection SQL, une attaque XSS ou une exécution de code. Le recul de cinq places est relatif et ne signifie pas que le risque a disparu : comme pour les failles les plus courantes révélées par un pentest, validez toute sortie comme une saisie utilisateur.
OWASP Top 10 LLM ou Top 10 Agentic : lequel appliquer ?
Le Top 10 LLM s’applique quand le modèle est un composant d’une application (chatbot, résumé, recherche interne). Le Top 10 OWASP pour les applications agentiques, publié le 9 décembre 2025, s’applique quand il devient un acteur : il appelle des outils, garde une mémoire d’une session à l’autre et déclenche des conséquences en aval. Dès qu’un assistant peut envoyer un e-mail ou modifier un fichier, il faut superposer les deux listes.
Comment tester une application IA : le rôle du test d’intrusion
Connaître la liste ne dit pas si votre assistant y est exposé : seul un test le montre. Un test d’intrusion cadré sur l’OWASP vérifie par exemple si une instruction glissée dans un formulaire ou une pièce jointe modifie son comportement, ce que les outils connectés permettent réellement de faire, si un utilisateur peut atteindre les documents d’un autre, et si des limites empêchent une consommation excessive.
Les assistants IA s’appuient souvent sur des API : un pentest d’API fait donc partie du périmètre. Un audit de cybersécurité complète le test côté organisation : qui valide les usages d’IA, quelles données ont le droit d’y entrer, quels fournisseurs sont retenus.
Par où commencer : 6 actions pour une PME ou une ETI
- Recenser les usages d’IA. Vos équipes utilisent probablement des outils que personne n’a validés : c’est la version IA du shadow IT.
- Cartographier ce que chaque assistant peut lire et faire : documents, outils connectés, droits associés.
- Sortir les secrets du contexte : aucune clé d’API ni mot de passe dans les consignes ou les documents indexés.
- Garder un humain dans la boucle pour les actions sensibles : envoi externe, paiement, suppression.
- Poser des limites de consommation : quotas, plafonds de dépenses, alertes de coût.
- Faire tester avant la mise en production, pour corriger sans pression.
Ces sujets relèvent de la gouvernance de sécurité que la directive NIS2 peut demander aux entités concernées, sa transposition française étant toujours en cours. Une politique d’usage de l’IA n’a d’effet que si la sensibilisation des équipes la transforme en réflexes : ne pas coller de données clients dans un outil non validé.
Pour résumer : notre FAQ sur le Top 10 OWASP LLM
Qu’est-ce que l’OWASP Top 10 LLM ?
C’est la liste, publiée par l’OWASP GenAI Security Project, des dix risques de sécurité les plus critiques pour les applications construites sur des grands modèles de langage.
Quelle est la dernière version de l’OWASP Top 10 LLM ?
L’édition 2026, publiée le 4 août 2026, remplace celle de 2025 : huit risques sur dix changent de rang et System Prompt Leakage devient Hidden Context Exposure.
Quelle différence entre l’OWASP Top 10 LLM et l’OWASP Top 10 web ?
Le Top 10 web recense les failles classiques des sites et des API, le Top 10 LLM les risques propres aux modèles d’IA. Une application qui embarque une IA doit être examinée avec les deux.
Un test d’intrusion peut-il évaluer une application qui utilise un LLM ?
Oui, à condition de cadrer le périmètre pour inclure le modèle, ses outils, sa base documentaire et les API. Le cadrage OWASP ajoute les scénarios propres à l’IA aux tests classiques.
Passer de la liste à un test concret
L’OWASP Top 10 LLM 2026 indique où regarder. Il ne dit pas ce qui se passe dans votre application, avec vos données et vos droits d’accès. Un test d’intrusion adapté à votre périmètre répond à cette question avec des preuves plutôt que des suppositions. Avant d’ouvrir un assistant à vos clients, la bonne question n’est donc pas « sommes-nous concernés ? », mais « que peut-il faire, avec quelles données, et qui l’a vérifié ? ».