Un responsable du support d’une fintech de 2 000 employés contacte l’équipe de sécurité. Leur chatbot de service client vient d’indiquer à un utilisateur comment contourner la vérification d’identité ; la transcription montre le bot citant avec assurance une politique interne. La question semble simple, mais elle est trompeuse. S’agit-il d’une erreur classique du modèle, d’une injection de prompt, d’une fuite de données ou d’une dépendance compromise ? Si nous ne parvenons pas à classifier rapidement l’incident, nous ne pourrons pas choisir la bonne mesure de confinement, identifier les preuves à préserver ni mobiliser la bonne équipe.
Dans ce cours, nous utilisons le classement OWASP Top 10 for LLM Applications 2026 comme référentiel commun pour le tri, la modélisation des menaces, les tests et la surveillance. Le tri consiste à prendre une décision rapide et responsable concernant la nature de la défaillance, l’ampleur probable de son impact et les mesures à prendre alors que la situation évolue encore. L’objectif de la leçon 1 est d’apprendre à nommer les symptômes observés en production, en utilisant des catégories cohérentes entre les équipes et dans le temps.
Lorsqu’une fonctionnalité basée sur un LLM dysfonctionne, les équipes débattent souvent de l’intention et de la formulation. Nous nous appuierons plutôt sur des symptômes observables : quelles sources d’entrée ont alimenté le modèle, quelles sorties ont été produites et quels effets externes en ont découlé. Ces indices orientent généralement vers une ou deux catégories OWASP, avant même que la cause première ne soit connue. Nous allons maintenant trier un incident simulé et identifier la catégorie principale, ainsi que les catégories secondaires connexes qu’il convient de surveiller en parallèle :
Pour effectuer une classification correcte, il est nécessaire de partager une représentation mentale du mode d’assemblage d’une requête unique par une application basée sur un LLM. La fenêtre de contexte désigne l’ensemble des jetons (tokens) pris en compte par le modèle pour générer une réponse. Elle inclut souvent le texte saisi directement par l’utilisateur, des extraits issus de bases de connaissances, des résultats d’outils ainsi que des instructions masquées, telles qu’une invite système (system prompt). L’introduction de contenu non fiable dans cette fenêtre de contexte peut influencer le comportement du modèle, entraîner une exposition de données ou provoquer des actions en aval présentant des risques. Dans la section suivante, nous examinerons les points d’entrée probables de ce contenu non fiable et la manière dont il a conduit au contournement de politique observé :
Ne vous fiez pas uniquement à l’étiquetteUn même symptôme peut correspondre à plusieurs catégories. Considérez les premières classifications comme des hypothèses de travail et conservez les preuves avant d’entreprendre toute optimisation.
Le classement OWASP Top 10 for LLM Applications 2026 recense les risques les plus critiques pour les applications utilisant des grands modèles de langage (LLM). Il permet aux équipes de sécurité, d’ingénierie et de gouvernance de désigner les mêmes modes de défaillance par les mêmes termes, et garantit que les plans de test couvrent l’ensemble du périmètre de risque plutôt que de se limiter au dernier incident en date. Ce cours est structuré autour de ces dix catégories ; nous les aborderons directement dans les leçons et les exercices, sans les reléguer au rang de simple annexe de référence. Voici le référentiel complet que nous utiliserons tout au long de la formation :