Sécurité des grands modèles de langage (LLM) : sécurisation de la pile multicouche sous-jacente à une application LLM

La sécurité des LLM désigne les pratiques visant à protéger une application basée sur un grand modèle linguistique à tous les niveaux qui la composent : le modèle lui-même, les invites et le contexte extrait qu’il utilise, le serveur d’inférence qui l’exécute, le logiciel d’orchestration qui achemine les requêtes vers lui, ainsi que le code qui traite les résultats qu’il renvoie. Dans ce contexte, « LLM » désigne un grand modèle linguistique, et non le diplôme de master en droit.

La plupart des recommandations publiées sur ce sujet se limitent au modèle. Cette page reprend là où le modèle s'arrête. Les couches sous-jacentes, à savoir le serveur d'inférence, l'infrastructure de calcul distribué, le magasin de données et la passerelle qui les relie, sont des logiciels classiques dotés d'identifiants CVE classiques, de versions corrigées et, dans plusieurs cas, de délais de mise en conformité fixés par les autorités fédérales. C'est sur cette partie qu'une équipe de sécurité peut intervenir dès cette semaine.

Ce que couvre la sécurité des LLM, et sur quoi porte cette page

Un modèle linguistique de grande envergure est un modèle entraîné sur de très vastes corpus de textes afin de prédire et de générer du texte. Dans un déploiement en entreprise, il ne fonctionne presque jamais de manière autonome. Il est intégré à une API, exploite les documents récupérés, fait appel à des outils et renvoie des résultats utilisés par d’autres logiciels. Chacune de ces connexions représente un point de défaillance potentiel, et seules certaines d’entre elles impliquent réellement le modèle.

C’est là une distinction que la plupart des recommandations ont tendance à brouiller. La « sécurité » et la « sûreté » des modèles se recoupent sans pour autant être identiques. L’analyse technique de Red Hat sur les risques liés aux systèmes LLM, publiée le 18 novembre 2024, établit clairement la distinction : « Si un système LLM utilise la sortie d’un autre LLM et que cela a un impact négatif sur la confidentialité, l’intégrité ou la disponibilité, cela crée alors une faille de sécurité. » Un modèle qui renvoie une réponse biaisée ou erronée présente un problème de sécurité. Un modèle dont la réponse est transmise sans échappement à une commande shell, une requête de base de données ou un appel d’API privilégié présente un problème de sécurité, et ce problème réside dans le composant qui s’est fié à cette sortie.

Cette page traite de la pile qui héberge le modèle, et son champ d’application est délibérément restreint. La taxonomie complète des risques relève de la sécurité de l’IA générative. L’analyse approfondie de l’injection de prompts relève de prompt injection. La couverture globale relève de la sécurité de l’IA, et les tests adversariaux relèvent du « red teaming » en IA. Vous trouverez ici un inventaire couche par couche, les vulnérabilités recensées pour chacune de ces couches, les informations émises par l’application que l’équipe de sécurité peut exploiter, ainsi que des explications sur la manière d’interpréter les chiffres communiqués par un fournisseur.

La pile d'applications LLM, couche par couche

Une application LLM comporte environ huit couches, et la littérature consacrée au classement dans ce domaine en couvre environ trois. Les couches avec lesquelles un développeur interagit font l'objet d'une documentation très complète. En revanche, celles dont la gestion incombe à l'équipe d'exploitation sont pratiquement passées sous silence.

• Modèle. Les paramètres et l'architecture entraînés qui permettent de générer du texte.
• Invite et contexte. L'invite du système, la saisie de l'utilisateur et tous les autres éléments sont regroupés dans la fenêtre de contexte.
• Recherche et base de données vectorielle. Le corpus de documents et la base de données d'embeddings sont interrogés avant que le modèle ne fournisse une réponse. Dans un assistant enrichi par la recherche, c'est le corpus qui constitue la limite de sécurité, et non l'interface de chat.
• Appel d'outils et de fonctions. Les fonctions que le modèle est autorisé à appeler, ainsi que les privilèges qui y sont associés.
• Serveur d'inférence. Service chargé de charger le modèle en mémoire et de répondre aux requêtes qui lui sont adressées.
• Orchestration et calcul distribué. Le logiciel qui achemine les requêtes, planifie les tâches entre les machines et relie les modèles aux outils et aux données.
• Artefact de modèle et sérialisation. Le format de fichier dans lequel les poids sont fournis, ainsi que le code permettant de les désérialiser.
• Gestion des résultats. Le code qui exploite les résultats renvoyés par le modèle.

Les développeurs sont responsables des quatre premières couches. Les équipes chargées de la plateforme et des opérations sont responsables des trois suivantes, tandis que la gestion des sorties incombe généralement à l’équipe applicative qui l’a mise en place. Cette répartition est importante, car les couches concernées par les CVE relèvent presque exclusivement du domaine des opérations et sont souvent déployées sans qu’un responsable de la sécurité ne soit désigné.

Prompt injection, la manipulation du comportement d’un modèle par le biais de données d’entrée spécialement conçues, constitue le risque le plus connu au niveau de la couche « prompt » et « contexte » ; ce sujet est traité en détail sur une page dédiée plutôt qu’ici. Les points de terminaison d’inférence non gérés ou non autorisés au sein de votre infrastructure constituent un problème d’IA « fantôme » avant même d’être un problème lié aux modèles de langage grand format (LLM). Lorsque le modèle est autorisé à agir plutôt qu’à simplement répondre, la couche d’appel d’outils devient un problème de sécurité lié à l’IA agentique.

‍

La couche de service et d'orchestration dispose de CVE classiques, modifiables

Tout ce qui précède relève de l'architecture. C'est la partie sur laquelle vous pouvez agir.

La couche de mise à disposition et d’orchestration est le seul domaine où la sécurité des modèles de langage de grande envergure (LLM) se résume à trois verbes bien connus : inventorier, corriger et restreindre. Ces composants disposent d’identifiants CVE, de versions corrigées et de fiches de vulnérabilité publiques, et plusieurs d’entre eux sont soumis à des délais de correction fixés par les autorités fédérales. Aucune de ces mesures ne nécessite de connaissances en apprentissage automatique pour être mise en œuvre.

Couche et composant | ID CVE | Évaluateurs et notes | Version corrigée et statut | Serveur d'inférence,vLLM | CVE-2026-22778| Deux évaluateurs secondaires à 9,8 | CRITIQUE. Pas de note primaire NVD. Affecte les versions 0.8.3 à 0.14.1 incluses, corrigé dans la version 0.14.1. Absent de KEV. Serveur d’inférence,Ollama. CVE-2026-7482. Lemême CNA attribue une note de 8,8 (HAUT) selon CVSS 4.0 et de 9,1 (CRITIQUE) selon CVSS 3.1. Pas de note principale du NVD. Corrigé dans la version 0.17.1. Absent du serveur KEVInference, NVIDIATriton CVE-2026-47627. NVIDIAen tant que CNA, note de 9,8 (CRITIQUE) selon le CVSS 3.1. Pas encore évalué par le NVD. Affecte les versions 0.0 à 26.05. Absent de KEV. Calcul distribué,Ray. CVE-2023-48022. Le NISTen tant que source principale du NVD, 9,8 CRITIQUE. CISA-ADP en tant que source secondaire, 9,8 CRITIQUE. Officiellement marqué comme contesté. Authentification par jeton disponible à partir de la version 2.52.0. Absent de KEV, preuve de concept d’exploitation SSVC. Calcul distribué,RayCVE-2025-62593. NISTen tant que source principale NVD, 8,8 « ÉLEVÉ » selon CVSS 3.1. GitHub en tant que source d’alerte (CNA), 9,4 « CRITIQUE » selon CVSS 4.0. Corrigé dans la version 2.52.0. Ajouté à KEV le 17/08/2026, date limite le 20/08/2026. Cycle de vie du ML,MLflow. CVE-2026-64849. GitHuben tant que CNA, 9,3 CRITIQUE selon CVSS 3.1. Le NVD n’a publié aucune note principale bien qu’il ait marqué l’enregistrement comme « Analysé ». Corrigé dans la version 3.15.0. Ajouté à KEV le 19/08/2026, date limite le 02/09/2026. Passerelle LLM,LiteLLM. CVE-2026-42271. NISTen tant que source principale du NVD, note 8,8 (ÉLEVÉE), vecteur PR:L, ce qui signifie un appelant authentifié. Affecte les versions 1.74.2 à 1.83.6, corrigé dans la version 1.83.7. Ajouté à KEV le 08/06/2026, date limite le 22/06/2026 :Assistant à récupération améliorée. CVE-2025-32711 : Microsoften tant que CNA, niveau 9,3 CRITIQUE. NIST en tant que NVD principal, niveau 7,5 ÉLEVÉ. Non répertorié dans KEV, aucune exploitation SSVC.

Légende : Vulnérabilités recensées au niveau de la couche de mise en service et d’orchestration des LLM, au 25 août 2026. Il s’agit d’un échantillon horodaté et non d’une liste exhaustive. Texte alternatif : Tableau répertoriant huit vulnérabilités de l'infrastructure LLM, indiquant la couche et le composant concernés, l'identifiant CVE, chaque organisme d'évaluation avec sa note, ainsi que la version corrigée et le statut KEV.

Deux éléments permettent d'exploiter ce tableau. Tout d'abord, il faut préciser l'organisme qui attribue la note. Une note attribuée par une autorité de numérotation CVE (CNA) n'est pas la même qu'une note NVD, et sur cette pile, elles divergent souvent. CVE-2026-7482 affiche un score de 8,8 selon CVSS 4.0 et de 9,1 selon CVSS 3.1, attribués par la même CNA, et le NVD n’a publié aucun score de base indépendant bien qu’il ait marqué l’enregistrement comme « Analysé » ; par conséquent, l’indication « 9,1 selon le NVD » est erronée. Deuxièmement, lisez la description plutôt que le titre. CVE-2026-22778 n’est pas une vulnérabilité à exécution de code à distance liée à un seul bug : le NVD la classe sous les codes CWE-209 et CWE-532, qui correspondent tous deux à des failles de divulgation d’informations, et décrit une fuite d’adresse de tas qui « peut être enchaînée à un débordement de tas avec le décodeur JPEG2000 dans OpenCV/FFmpeg pour permettre l’exécution de code à distance ».

Le volume sur cette couche n'est ni marginal ni statique. Un Recensement des mots-clés NVD exécuté le 25 août 2026, en lisant le totalResults champ pour chaque nom de produit, renvoie 129 enregistrements pour Flowise, 70 pour vLLM, 68 pour LangChain, 63 pour Triton Inference Server, 36 pour Ollama, 35 pour llama.cpp, 30 pour LiteLLM, 18 pour SGLang et 4 pour TorchServe. Cinq jours plus tôt, trois de ces chiffres étaient inférieurs, à savoir 69, 67 et 32, et aucun n’était supérieur. On observe également une concentration : cinq CVE concernant NVIDIA Triton Inference Server ont été publiées le 18 août 2026, avec en tête CVE-2026-47627 avec un score de 9,8 (CRITIQUE), et les cinq sont notés au niveau secondaire, sans note primaire NVD.

L'exemple le plus parlant en matière de gouvernance à ce niveau est celui de Ray. Deux autorités attribuent à la vulnérabilité CVE-2023-48022 un niveau de gravité « CRITIQUE » (9,8), tandis que le NVD classe officiellement cette entrée comme « contestée », car le fournisseur affirme que « Ray, comme indiqué dans sa documentation, n'est pas destiné à être utilisé en dehors d'un environnement réseau strictement contrôlé ». Les entrées contestées sont exclues de certains workflows de gestion des vulnérabilités. Ce CVE est absent du catalogue des vulnérabilités connues pour être exploitées (KEV) de la CISA, et la catégorisation des vulnérabilités spécifiques aux parties prenantes de la CISA indique que son exploitation se limite à une preuve de concept, tandis que MITRE recense une campagne l'exploitant sous le nom de C0045 ShadowRay. Par ailleurs, une autre vulnérabilité de Ray, incontestée, le CVE-2025-62593, a été intégrée au catalogue KEV le 17 août 2026 avec une date d’échéance fixée au 20 août 2026, et son correctif correspond à la version 2.52.0 : il s’agit précisément de la version que l’enregistrement contesté désigne comme celle à partir de laquelle l’authentification par jeton est devenue disponible. L’hypothèse selon laquelle la sécurité dépend du déploiement ne constitue pas un contrôle.

KEV est le filtre opérationnel le plus précis dans ce domaine. Au 25 août 2026, le catalogue comptait 1 675 entrées, dont dix concernaient des composants de la pile LLM : six entrées Langflow, deux LiteLLM, une Ray et une MLflow. Aucune des quatre vulnérabilités CVE habituellement citées dans ce contexte ne figure parmi elles. Reconstruisez votre inventaire en vous basant sur la couche d’orchestration plutôt que sur les deux ou trois marques qui reviennent sans cesse dans la couverture.

L'exposition à ce niveau est bien réelle mais mal mesurée, et aucun des balayages ci-dessous ne précise la méthode utilisée. SecurityWeek, se référant à Cyera en mai 2026, a estimé ce chiffre à « environ 300 000 serveurs Ollama actuellement exposés sur l'Internet public ». Une analyse de juin 2026 portant sur des ressources de calcul d’IA volées faisait état d’« environ 175 000 instances Ollama exposées au public dans plus de 130 pays ». Dans une fenêtre d’analyse dont les auteurs précisent qu’elle date de novembre 2024, Trend Micro a recensé « plus de 3 000 serveurs entièrement ouverts » et, pour llama.cpp, « 80 serveurs exposés, dont 57 ne semblaient disposer d’aucune forme d’authentification ». SecurityWeek, dans un article consacré à la campagne Ray en novembre 2025, a relayé le décompte d’une autre société faisant état de « plus de 230 000 serveurs Ray accessibles depuis le Web ». La fiche du NVD relative à la vulnérabilité CVE-2026-7482 ne donne aucun chiffre et indique seulement qu’une « importante exposition sur l’Internet public a été observée ». Considérez la fourchette, les dates et les méthodes manquantes comme constituant les conclusions.

La validation d'un correctif est une tâche distincte de son application, et c'est là que les exercices de simulation d'attaques par l'IA trouvent toute leur utilité. Considérez ce tableau comme un document évolutif : les informations sur les vulnérabilités CVE deviennent rapidement obsolètes, le catalogue KEV est mis à jour chaque semaine, et il s'agit ici d'un échantillon et non d'un inventaire exhaustif. Désignez-en un responsable et définissez une fréquence de révision.

Artéfacts de modélisation et limites mesurées de la numérisation

Un artefact de modèle est un code exécutable intégré dans un conteneur de données. Voilà tout le problème résumé en une phrase.

Le problème réside dans une incohérence de séquence. Un scanner tel que picklescan « valide d’abord les fichiers Pickle et, s’ils sont validés, effectue une analyse de sécurité », tandis que la désérialisation Pickle « fonctionne comme un interpréteur, en interprétant les codes d’opération au fur et à mesure de leur lecture ». L'analyse a lieu avant le chargement. L'exécution a lieu pendant le chargement. Tout élément qui fait apparaître un fichier comme invalide, inconnu ou mal formé aux yeux du scanner, tout en restant chargeable par le framework, passe directement à travers cette brèche.

‍

Cet écart n'est pas purement théorique, et il a désormais été mesuré de trois manières différentes.

En février 2025, deux modèles malveillants exactement ont été détectés sur une plateforme publique de modèles grâce à une technique appelée « nullifAI », qui a permis de contourner le scanner en compressant le fichier au format 7z au lieu du format ZIP habituellement utilisé par le framework. Deux, ce n’est pas beaucoup. L’intérêt de ce cas réside dans le mécanisme utilisé, et non dans le nombre de cas détectés.

Entre février et mars 2025, quatre contournements de scanner distincts se sont vu attribuer des identifiants CVE. L'écart entre les notes attribuées par les évaluateurs est plus important que tout ce qui a été observé dans la section précédente.

Score CVE IDCNA (CVSS 4.0) Score principal NVD (CVSS 3.1) Éléments contournésCVE-2025-17165,3 MOYEN 9,8 CRITIQUEpip n'a pas été considéré comme une variable globale non sécurisée ; par conséquent, un modèle qui y a intégré un paquet a passé l'analyse avec succèsCVE-2025-18895.3 MOYEN 9,8 CRITIQUE Seules les extensions de fichiers « pickle » standard étaient prises en compte ; par conséquent, une extension non standard n'a jamais été analysée.CVE-2025-19445.3 MOYEN 6,5 MOYEN : un en-tête ZIP modifié a provoqué le plantage du scanner alors que le framework était encore en train de charger le modèleCVE-2025-19455.3 MOYEN 9,8 CRITIQUE : l'inversion de certains bits du drapeau ZIP a masqué le fichier « pickle » au scanner, mais pas au chargeur

Légende : Quatre failles de contournement répertoriées dans la base CVE concernant un scanner de modèles largement utilisé, toutes publiées entre février et mars 2025, avec un écart de 4,5 points dans la notation pour trois d’entre elles. Aucune ne figure dans le catalogue KEV à la date du 25 août 2026. Texte alternatif : Tableau présentant quatre vulnérabilités de contournement d’un scanner modèle, comparant le score CNA CVSS 4.0 de 5,3 aux scores NVD Primary CVSS 3.1 de 9,8, 9,8, 6,5 et 9,8, avec la technique de contournement correspondante pour chacune.

En juillet 2026, un prépublication a chiffré ce phénomène. ShadowPickle décrit trois attaques furtives de désérialisation de type « pickle » et indique que cette famille « échappe à dix scanners de pointe et à quatre hubs de modèles ». Sa variante « Overwritten », quant à elle, « affiche un taux d’évasion de 63 % face aux scanners, et des taux d’évasion jusqu’à 50 % supérieurs à ceux des attaques existantes ». L’article ne précise ni le nombre de scanners ni celui de hubs pris en compte dans ce chiffre de 63 %. Il s’agit d’un prépublication, non soumise à un examen par les pairs, provenant d’une seule source et sans validation indépendante ; il convient donc de considérer ce chiffre comme un motif d’inquiétude plutôt que comme une donnée fiable. L’essentiel réside dans la tendance : le contrôle par scan sur lequel s’appuient la plupart des équipes présente un taux d’évasion avéré plutôt qu’hypothétique.

La chaîne d'approvisionnement s'étend également au-delà du fichier de modèle. Une notification d'incident publiée le 16 juillet 2026 par le hub de modèles de première partie indique que la violation a débuté par un ensemble de données malveillant plutôt que par un modèle malveillant : « Un ensemble de données malveillant a exploité deux voies d'exécution de code dans notre processus de traitement des ensembles de données (un chargeur d'ensembles de données permettant l'exécution de code à distance et une injection de modèle dans la configuration d'un ensemble de données) pour exécuter du code sur un nœud de traitement. » À partir de là, selon les propres termes du hub, « l’acteur a obtenu un accès au niveau des nœuds, a récupéré des identifiants d’ cloud s et de clusters, puis s’est propagé latéralement vers plusieurs clusters internes au cours d’un week-end. »

Les mesures de contrôle applicables ici sont loin d'être prestigieuses. Privilégiez les « safetensors » à Pickle pour tout format que vous contrôlez, exigez la traçabilité des artefacts que vous ne contrôlez pas, et chargez les modèles non fiables au sein d'un bac à sable, en partant du principe que le chargement équivaut à une exécution.

Ce qu'une application LLM génère, et ce sur quoi un SOC peut agir

Une glissière de sécurité vous indique ce qu'elle a bloqué. Mais presque rien ne vous indique ce qu'elle a laissé passer.

Cette asymétrie constitue le problème de visibilité à ce niveau, et il convient de formuler une mise en garde avant de présenter le tableau : il n'existe pour l'instant aucun inventaire public faisant autorité concernant les données télémétriques des applications LLM ; le tableau ci-dessous repose donc sur une analyse des composants plutôt que sur des données tirées de la pratique. Utilisez-le comme une source d'inspiration pour l'architecture, et non comme une norme.

Composant « EventEmitting » : pourquoi il est pertinent en matière de sécurité ; ce que cache son absence ; enregistrement de la requête et de la réponse ; application ou passerelle ; seul enregistrement de ce qui a été demandé et de ce qui a été répondu ; exfiltration de données via le modèle, et l’utilisation abusive d’un compte légitimeVerdict de Guardrail et règle correspondanteGuardrailIndique ce qui a été bloqué et en vertu de quelle règleTout ce que Guardrail a laissé passerRequête de recherche et identifiants des documents renvoyésRecherche et magasin de vecteursRelie une réponse à un corpus source et à un ensemble d’autorisationsSi un utilisateur a accédé à des documents qu’il n’aurait pas dû voirAppel d’un outil ou d’une fonction avec des argumentsCouche d’orchestrationLe moment où le texte généré se transforme en actionAbus de privilèges, et l’étendue des répercussions d’une injection réussie. Événement de chargement d’un artefact du modèle avec hachage et source. Serveur d’inférence. Établit la provenance au moment du chargement. Quel artefact a réellement été exécuté, et s’il s’agissait de celui qui avait été approuvé ; Réponses d’erreur du serveur d’inférence ; Le serveur d’inférence : les réponses d’erreur constituent une surface d’attaque et révèlent l’état interne ; Reconnaissance ciblant la couche de service ; Décision d’authentification et d’autorisation au niveau du point de terminaison ; Passerelle ou serveur d’inférence : distingue un appelant autorisé d’un point de terminaison ouvert ; Accès non authentifié à un chemin de téléchargement de modèle ou de soumission de tâche ; Anomalies relatives aux jetons, coût et de débit. Passerelle : détecte l’abus de ressources et le vol de puissance de calcul à l’aide d’identifiants volés. Consommation illimitée et attaques silencieuses basées sur les coûts.

Légende : Un inventaire raisonné des données qu’une application LLM peut émettre, établi à partir des composants de la pile plutôt que d’une norme citée, car il n’existe aucun inventaire public faisant autorité. Texte alternatif : Tableau présentant huit événements de télémétrie d'une application LLM, indiquant le composant à l'origine de l'événement, la pertinence de chaque événement en matière de sécurité, ainsi que ce que perd une équipe de sécurité lorsque l'événement n'est pas collecté.

La seule référence faisant autorité disponible porte sur le cas des IA agentiques. Le Centre national de cybersécurité du Royaume-Uni, dans un document daté du 20 août 2026 consacré à la gestion des risques cybernétiques liés aux IA agentiques, indique que « l’activité des IA agentiques doit être considérée comme une forme d’activité utilisateur. Elle doit donc être intégrée à la surveillance opérationnelle de sécurité 24 h/24, 7 j/7 et aux procédures de réponse aux incidents. » La formulation est importante : cette recommandation porte sur la surveillance opérationnelle de la sécurité 24 h/24 et 7 j/7, et n’utilise à aucun moment les termes « LLM » ni « SOC ». Elle précise également les données à collecter pendant l’exécution d’un agent, en citant notamment les traces de la chaîne de pensée et les transcriptions de l’agent, ainsi que les événements enregistrés dans l’environnement de sandbox au sens large, tels que les journaux d’accès, les proxys et le trafic réseau, et elle impose que ces journaux soient protégés contre toute modification ou suppression.

Cette dernière clause constitue le mécanisme de détection. La manipulation des garde-corps et des journaux correspond à T1685 Désactiver ou modifier les outils, qui figure sous la rubrique TA0112 « Defense Impairment » (Compromission des défenses) dans le guide « MITRE ATT&CK » et concerne les adversaires qui « désactivent, dégradent ou altèrent les outils ou applications de sécurité » afin de « compromettre ou réduire la visibilité des capacités défensives ». Il s’agit de la seule technique ATT&CK mentionnée sur cette page.

La détection est considérée comme l'un des deux volets de ce domaine, même si pratiquement aucun professionnel ne s'y consacre. Une étude universitaire de 2025 sur les LLM en matière de sécurité classe les défenses en « deux catégories principales : les défenses basées sur la prévention et celles basées sur la détection », ce qui correspond à l'axe sur lequel repose déjà tout programme de sécurité abouti.

Cette section se limite délibérément aux informations émises par l'application. L'intégration SIEM, l'élaboration de règles de détection et le workflow du SOC pour l'IA générative sont abordés dans la section consacrée à la sécurité de l'IA générative, tandis que l'application d'analyses à ces signaux est traitée dans la section consacrée à la détection des menaces liées à l'IA. Lorsque l'application agit plutôt que de fournir des réponses, consultez la section consacrée à la sécurité de l'IA agentique.

Barrières de sécurité, pare-feu, passerelles et scanners, ainsi que les chiffres qu'ils avancent

Définissez ces outils en fonction de leur utilité, car les noms des catégories de fournisseurs et les structures de propriété des projets open source évoluent plus rapidement que les fonctionnalités elles-mêmes.

CatégorieCe qu’elle inspecteOù elle se situeCe qu’elle ne peut pas faireBarrière de sécuritéTexte de la requête et de la réponseAu sein de l’application, à la limite du modèleNe voit pas l’infrastructure sous-jacente et ne signale que ce qu’elle a bloquéPare-feu LLMTexte de la requête et de la réponseIntégré dans le chemin de la requête réseau, en amont de l’applicationPartage l’angle mort de la barrière de sécurité et n’apporte aucune visibilité sur les appels en coursPasserelle IARequêtes, routage, quotas et identifiants Entre l’application et un ou plusieurs fournisseurs de modèles N’inspecte pas les artefacts du modèle et ne teste pas le comportement du modèle Scanner de modèle L’artefact de modèle sérialisé, avant son chargement Dans le pipeline de build ou au niveau du hub de modèles Présente un taux d’évasion mesuré et ne voit rien lors de l’exécution Harnais « red team » Comportement du modèle et de l’application face à des entrées adversaires Hors ligne ou dans un environnement de pré-production Produit des constatations plutôt que des contrôles, et ses scores sont spécifiques au harnais

Légende : Les cinq catégories fonctionnelles des outils de sécurité pour les LLM, définies en fonction de ce que chacune inspecte et de son emplacement dans le chemin de la requête, plutôt qu’en fonction du nom de la catégorie du fournisseur. Texte alternatif : Tableau comparatif entre les « guardrails », les pare-feu LLM, les passerelles IA, les scanners de modèles et les harnesses « red team », en fonction de ce que chacun inspecte, de sa position dans le chemin de la requête et de sa principale limitation.

Pour répondre directement à cette question courante, un « LLM guard » est une sorte de garde-fou : un mécanisme de contrôle qui examine les invites ou les réponses à la frontière de l’application et qui les bloque, les masque ou les réécrit. Il s’agit d’une mesure de prévention, et non de détection, qui s’applique au texte franchissant cette frontière plutôt qu’à l’infrastructure sous-jacente.

Le terme « pare-feu LLM » mérite d’être défini, mais ne vaut pas la peine d’être recherché. Il s’agit d’un nom de catégorie donné par un fournisseur pour désigner une barrière de sécurité placée au niveau du réseau, et il décrit un véritable choix d’emplacement : en ligne dans le chemin de la requête plutôt qu’au sein du processus de l’application.

Le choix entre les catégories relève d’une question de couverture, et non de classement. Il faut se demander quelle couche un outil couvre réellement, où il se situe dans le chemin de la requête, ce qu’il fait en cas d’échec, s’il génère des données de télémétrie ou uniquement des verdicts, et s’il s’agit du seul contrôle sur cette couche. Une barrière de sécurité et un scanner de modèles ne sont pas en concurrence, car ils couvrent des couches différentes. Les outils de « red teaming » basés sur l’IA ne remplacent ni l’un ni l’autre, ils les testent tous les deux. Et rien dans ce tableau n’empêche prompt injection cette possibilité.

‍

Comment interpréter un test de performance en matière de sécurité des modèles LLM

Le taux de réussite des attaques (ASR) correspond à la proportion de tentatives qu’un harnais a classées comme réussies contre un modèle cible. Il n’a de sens que dans le cadre de son propre harnais et pratiquement nulle part ailleurs.

Trois variables influencent ce chiffre de manière indépendante : l’ensemble de prompts, le protocole d’évaluation et la définition de la réussite. Il suffit de modifier l’une d’entre elles pour que le chiffre change, ce qui explique pourquoi deux taux de réussite d’attaques publiés sont rarement comparables, même lorsqu’ils décrivent la même catégorie d’attaques. L’article de référence sur StrongREJECT indique clairement cette tendance, en soulignant qu’« il est peut-être plus courant que rare que les développeurs de jailbreaks exagèrent considérablement l’efficacité de leurs jailbreaks » et que « les méthodes d’évaluation existantes surestiment considérablement l’efficacité des jailbreaks par rapport aux jugements humains ». Notez bien cette tendance, et notez que l’article n’attribue aucun pourcentage à cette surestimation. Quiconque en cite un se réfère à une autre source.

Posez donc quatre questions à tout responsable commercial : quel harnais, quel juge, quel ensemble de consignes, et qu'est-ce qui a été considéré comme un succès ? Si ces quatre réponses ne sont pas disponibles, ce chiffre relève davantage du marketing que d'une mesure concrète.

Cartographie du cadre réglementaire, version épinglée

La plupart des frameworks présentés sur cette page ont évolué au cours des treize derniers mois ; la version et la date sont donc plus importantes que le nom.

2025 ID et titre2026 ID et titreMouvementNoteLLM01:2025 Injection de promptsLLM01:2026 Injection de promptsInchangéA conservé la première place dans les deux éditionsLLM02:2025 Divulgation d’informations sensiblesLLM02:2026 Divulgation d’informations sensiblesInchangéA conservé la deuxième place dans les deux éditionsLLM03:2025 Chaîne d’approvisionnementLLM04 : 2026 Chaîne d’approvisionnementBaisse de 1Couvre la section « artefacts de modèle » ci-dessusLLM04 : 2025 Empoisonnement des données et du modèleLLM05 : 2026 Empoisonnement des données et du modèleBaisse de 1Renuméroté, de sorte qu’un identifiant « 2025 » prête désormais à confusionLLM05 : 2025 Gestion inappropriée des sortiesLLM10 : 2026 Gestion inappropriée des sortiesBaisse de 5Le plus grand déplacement individuel de la listeLLM06 : 2025 Agence excessiveLLM03 :2026 Agence excessive +3 Reflète l’évolution vers des déploiements axés sur l’agent LLM07:2025 Fuite des invites système LLM08:2026 Exposition du contexte caché -1, renommé et élargi Portée élargie de la seule invite système à l’ensemble du contexte caché, y compris le texte de la politique récupéré et les schémas des outils que l’application expose au modèle LLM08:2025 Faiblesses des vecteurs et des plongements LLM09 : 2026 Faiblesses des vecteurs et des plongements Baisse de 1 La couche de récupération et de stockage des vecteurs LLM09 : 2025 Désinformation LLM07 : 2026 Désinformation Hausse de 2 LLM10 : 2025 Consommation illimitée LLM06 : 2026 Consommation illimitée Hausse de 4

Légende : Tableau de correspondance entre les classements « OWASP Top 10 » 2025 et 2026 pour les applications LLM. La colonne « 2026 » provient du référentiel canonique, la colonne « 2025 » de la page de la liste remplacée, et les changements de nom de l'article de Help Net Security, tous consultés le 25 août 2026. Texte alternatif : Tableau de correspondance associant chaque identifiant du Top 10 OWASP 2025 pour les LLM à son identifiant 2026, indiquant que deux entrées sont inchangées et que les huit autres ont été déplacées, l'une de ces huit ayant également été renommée et élargie.

Deux entrées conservent leur position, tandis que les huit autres ont toutes été déplacées. L’une de ces huit entrées a également été renommée et élargie : la couverture de cette publication par Help Net Security indique que « System Prompt Leakage a été renommée et élargie pour devenir Hidden Context Exposure ». Aucune entrée n’a été supprimée et aucune n’est entièrement nouvelle, ce qui est important si vous devez faire correspondre les contrôles de 2025 à la liste de 2026. L’édition 2026 a été publiée le 04/08/2026 et combine l’avis de la communauté avec des données d’incidents : ce même compte-rendu précise que « le vote représentait toujours 75 % de la pondération, mais les 25 % restants ont été influencés par les données issues de 6 639 incidents réels extraites de bases de données publiques sur les vulnérabilités et d’une base de données sur les dommages causés par l’IA ». La liste n’est pas reproduite ici. Les descriptions par risque relèvent de la sécurité des IA génératives, et la liste 2026 est disponible sous forme agrégée sur la page de ressources OWASP dédiée. La dérive de version est réelle et non hypothétique : vingt et un jours après sa publication, l’ancienne page de la liste ne répertoriait encore que les identifiants de 2025, ce qui explique pourquoi le tableau de correspondance renvoie chaque colonne à sa propre source.

Version du cadre | Date | Correspondance sur cette page | Top 10 de l’OWASP pour les applications LLM | Édition 2026, publiée le 04/08/2026 | 25/08/2026 | Taxonomie des risques, mise en correspondance ci-dessus | MITRE ATT&CK Enterprise v19.2, 15 tactiques 25/08/2026 Correspondance de la technique unique dans la section télémétrie MITRE ATLAS 2026.07 : 1 matrice, 16 tactiques, 101 techniques, 77 sous-techniques, 37 mesures d’atténuation, 68 études de cas 25/08/2026 Comportement des attaquants spécifique à l’IA, et le conflit de nomenclature ci-dessous Cadre de gestion des risques liés à l’IA du NIST 1.0, publié le 26/01/2023, en cours de révision 25/08/2026 Gouvernance des programmes selon les axes « Gouverner », Map, Measure et Manage. NIST AI 100-2 E2025, version finale, mars 2025. 25/08/2026. Taxonomie et terminologie de l’apprentissage automatique adversaire. Loi européenne sur l’IA. Règlement (UE) 2024/1689, version consolidée du 27/07/2026, modifié par le règlement (UE) 2026/174425/08/2026Transparence et obligations liées aux risques élevés, ainsi que leurs dates d’applicationISO/IEC 42001Texte de base de 2023, adoption européenne de la norme EN ISO/IEC 42001:202625/08/2026Certification des systèmes de gestion de l’IA, dates issues uniquement de sources secondaires

Légende : Tableau de correspondance des frameworks dont la version est fixée pour cette page, vérifié au 25 août 2026. MITRE ATLAS propose un calendrier mensuel des versions ; veuillez donc revérifier la version publiée avant de vous fier au nombre d'éléments. Texte alternatif : Tableau associant sept frameworks à une version spécifique et à une date de vérification, avec une note indiquant à quoi chacun correspond dans cet article.

Il y a un piège à connaître en matière de mappage. MITRE ATT&CK Entreprise La version 19.2 comporte exactement 15 tactiques, et aucune ne s'intitule « Évasion défensive » : la tactique TA0005 s'appelle désormais « Furtivité » et la tactique TA0112 « Affaiblissement défensif ». MITRE ATLAS communiqué 2026.07 propose toujours une tactique intitulée AML.0007 « Évasion défensive », et le champ de référence d’attaque de cet enregistrement ATLAS pointe vers TA0005. Les deux référentiels font l’objet d’un renvoi formel, mais divergent quant au nom attribué au même concept mis en correspondance ; par conséquent, toute mention de l’« Évasion défensive » doit préciser à quel référentiel elle se rapporte.

En matière de réglementation, les obligations de transparence prévues à l’article 50 de la loi européenne sur l’IA s’appliquent à compter du 2 août 2026 et n’ont pas fait l’objet d’un report. Le règlement (UE) 2026/1744 a reporté la mise en œuvre des obligations relatives aux systèmes à haut risque : celles concernant les systèmes à haut risque visés à l’annexe III s’appliqueront à compter du 2 décembre 2027 et celles visées à l’annexe I à compter du 2 août 2028. Selon le texte consolidé, les fournisseurs de systèmes générant du contenu synthétique déjà commercialisés doivent se conformer à l’article 50, paragraphe 2, au plus tard le 2 décembre 2026, et les articles 102 à 110 s’appliquent à compter du 27 juillet 2026. Il s’agit des dates les plus susceptibles de changer sur cette page ; veuillez donc les vérifier à nouveau sur EUR-Lex, ainsi qu’à l’aide des outils de gouvernance de l’IA que vous utilisez pour les suivre.

Deux autres références sont importantes pour les travaux menés au niveau des programmes : le cadre de gestion des risques liés à l’IA du NIST, publié le 26 janvier 2023 et actuellement « en cours de révision dans le cadre du plan d’action de la Maison Blanche sur l’IA », et le document NIST AI 100-2 E2025, qui présente la taxonomie définitive, prévue pour mars 2025, des attaques adversaires en apprentissage automatique et des mesures d’atténuation correspondantes. La norme ISO/IEC 42001 est la norme relative au système de gestion de l’IA, et la norme EN ISO/IEC 42001:2026 correspond à l’adoption européenne actuelle de ce même texte de base, remplaçant une adoption nationale de 2025 qui a été retirée. Ses dates de publication proviennent ici de sources secondaires, car les pages de l’organisme de normalisation ne sont pas accessibles au public.

Approches modernes pour sécuriser la pile LLM

Les budgets s'orientent vers ce niveau. Le rapport « State of Security 2026 » d’Enterprise Technology Research, basé sur un sondage mené auprès de 517 responsables technologiques spécialisés dans la sécurité et publié sans indication des dates de l’enquête, révèle que « plus de la moitié (59 %) des entreprises prévoient d’augmenter leurs dépenses dans cette catégorie », tandis que « un cinquième (20 %) des entreprises déclarent ne disposer d’aucun contrôle de sécurité spécifique aux agents, et seules 3 % les ont déployés à grande échelle dans leurs environnements de production ».

La thèse conceptuelle avancée par les responsables du projet OWASP pour l’édition 2026 repose sur le contrôle de l’ampleur des dégâts plutôt que sur une prévention parfaite. Comme le rapporte Help Net Security dans son article consacré à cette publication, ils ouvrent ainsi leur exposé : « Cessez d’essayer de construire un modèle qui ne puisse pas être trompé. » Dans la pratique, cela se traduit par trois capacités : la gestion de la posture au sein de l’infrastructure d’IA, couverte par la gestion de la posture de sécurité de l’IA; la détection en temps réel au niveau de la couche de service ; et la traçabilité de l’artefact du modèle. Le programme global est détaillé dans les lignes directrices du NCSC pour le développement de systèmes d’IA sécurisés, qui couvrent la conception sécurisée, le développement sécurisé, le déploiement sécurisé, ainsi que l’exploitation et la maintenance sécurisées. Ce travail tourné vers l’avenir est plus ciblé : il s’agit d’appliquer la même discipline d’inventaire et de correctifs aux composants d’orchestration qui, aujourd’hui, ne relèvent d’aucun responsable de la sécurité.

Le point de vue d'Vectra AI sur la sécurité des modèles de langage à grande échelle (LLM)

Vectra AI part du principe que le réseau moderne constitue une surface d'attaque unique, et que la pile de services LLM en fait désormais partie. L’approche « assume-compromise » s’applique ici exactement comme elle le fait pour l’identité, l’ cloud et l’infrastructure sur site. La prévention au niveau de la limite immédiate est nécessaire mais insuffisante. Ce qui importe sur le plan opérationnel, c’est l’observabilité du segment d’infrastructure dédié à l’IA, un signal permettant de distinguer le comportement réel d’un attaquant du bruit du modèle, ainsi que la capacité à agir sur ce signal. Telle est la méthodologie qui sous-tend l’approche « Attack Signal Intelligence », appliquée à un segment que la plupart des parcs informatiques n’ont pas encore répertorié, et c’est vers cela que se dirigent les programmes de sécurité de l’IA.

La sécurité LLM relève d'une approche par couches. Dressez l'inventaire des couches dont vous avez la charge, appliquez les correctifs aux composants associés à des identifiants CVE et soumis à des délais KEV, surveillez les données émises par vos applications, et remontez chaque référence fournisseur jusqu'au harnais qui l'a générée. Le modèle est la partie dont tout le monde parle. La pile sous-jacente, en revanche, est celle que vous pouvez corriger.

‍