Dix risques propres aux modèles de langage
La liste OWASP pour les LLM classe, par ordre de gravité, les faiblesses les plus observées dans les applications qui s'appuient sur ces modèles. On y trouve l'injection de prompt, la mauvaise gestion des sorties, l'empoisonnement des données d'entraînement, le déni de service lié aux modèles, la fuite d'informations sensibles, l'usage d'extensions non fiables, la manipulation à distance par des composants tiers, la dérive excessive d'autonomie, l'appropriation d'informations par le modèle et l'absence de journalisation. Cette nomenclature n'est pas une norme juridique, mais un guide technique : chaque entrée décrit une famille de vulnérabilités, ses causes et les contre-mesures attendues. Elle aide une équipe à structurer sa revue de sécurité autour de scénarios concrets plutôt que de principes vagues.
L'intérêt de cette liste tient à sa généalogie. Elle prolonge le classement OWASP historique pour les applications web, que des années de pratique ont imposé comme langage commun entre développeurs et auditeurs. En l'étendant aux modèles, l'organisation reconnaît qu'un LLM introduit des surfaces d'attaque inédites : non plus un formulaire à malformater, mais une instruction à dissimuler dans un document, une page ou un message. Pour une entreprise qui déploie un agent, disposer de ce référentiel commun permet de dialoguer avec les métiers et la direction sur un risque partagé, sans exiger de chacun une culture technique approfondie. C'est un outil de méthode autant que de défense.
L'injection de prompt, tête de liste
En première position figure l'injection de prompt : l'attaque consiste à introduire, dans le texte que le modèle traite, une consigne qui détourne son comportement. Elle peut être directe, glissée par l'utilisateur, ou indirecte, cachée dans un document, une page web ou un courriel que l'agent est chargé de lire. Le modèle n'a, par construction, aucun moyen robuste de distinguer une instruction légitime d'une instruction parasite : tout arrive sous forme de texte. C'est ce qui rend le risque structurel et non anecdotique. Une application qui laisse un agent résumer des pages non maîtrisées ouvre potentiellement la porte à des ordres qu'elle n'a jamais voulu exécuter.
Les contre-mesures relèvent moins du modèle que de l'architecture. Il s'agit de séparer strictement données et instructions, de limiter ce que l'agent peut déclencher sans validation humaine, et de filtrer les entrées comme les sorties. Un principe gouverne l'ensemble : ne jamais accorder à un modèle plus de pouvoir que ce que la tâche exige. Le moindre privilège, appliqué aux agents, réduit l'ampleur d'un détournement réussi. Aucune technique n'élimine totalement le risque d'injection, car il découle de la nature même du langage. On ne supprime pas le danger : on borne son effet, on journalise les actions et on surveille les comportements anormaux pour interrompre ce qui s'écarte.
Fuite de données et empoisonnement du modèle
Les données sensibles constituent un autre motif central de la liste. Un modèle peut restituer, dans ses réponses, des informations présentes dans ses données d'entraînement ou dans son contexte immédiat. Rien n'empêche de lui confier des documents confidentiels, si ce n'est les protections que l'on a mises en place. Fuite par le prompt d'un utilisateur, par une base de connaissances mal cloisonnée, par des journaux conservés trop longtemps : les chemins sont nombreux. La règle élémentaire consiste à ne jamais placer dans le contexte d'un modèle plus d'informations que nécessaire, et à cloisonner ce qu'il peut consulter selon l'identité de la personne à qui il répond.
L'empoisonnement des données vise un autre moment du cycle : l'entraînement ou l'enrichissement du modèle. En injectant volontairement des contenus biaisés, un attaquant influence durablement les réponses du système. Le risque augmente avec les sources ouvertes et les bases documentaires alimentées automatiquement. En miroir, l'appropriation d'informations survient quand le modèle divulgue, à travers ses sorties, des éléments que la réglementation protège, comme des données personnelles ou des secrets industriels. Ces risques touchent à la fois la sécurité et la conformité. Le RGPD impose de limiter les données, de documenter les traitements et de garantir des droits aux personnes. Sécuriser un modèle, c'est aussi respecter ces obligations dans la manière dont on collecte et conserve la matière première.
Sécuriser un agent, pas seulement un modèle
Un LLM isolé dans une interface de démonstration pose peu de problèmes. Un agent qui consulte des bases, envoie des courriels, exécute du code ou engage des dépenses change d'échelle. La superficie d'attaque s'étend à chaque outil branché sur le modèle. Les extensions non fiables et la manipulation par des composants tiers constituent à ce titre des entrées explicites de la liste OWASP. Chaque connecteur est une confiance accordée ; multipliez-les sans contrôle et vous multipliez les chemins par lesquels un détournement devient une action réelle. La question de sécurité se déplace alors du modèle vers l'orchestration.
L'autonomie excessive et l'absence de journalisation complètent le tableau. Un agent laissé libre d'enchaîner des actions sans point de contrôle peut causer des dommages avant qu'un humain ne s'en aperçoive. La remédiation est à la fois technique et organisationnelle : validation des opérations sensibles, plafonds, délais, et surtout journaux complets permettant de reconstituer ce qui s'est passé. Sans traçabilité, un incident ne s'analyse pas et ne se prévient pas. La conformité ne suffit pas non plus à garantir la sécurité : la réglementation européenne fixe des obligations, notamment pour les systèmes à haut risque, mais elle laisse à l'ingénierie le soin d'implémenter ces garde-fous. La liste OWASP donne le canevas ; l'équipe pose les verrous.
Aller plus loin
Sécuriser un système fondé sur les modèles de langage suppose de connaître les risques, mais aussi de savoir les tester et les documenter. Pour approfondir, consultez le catalogue des 31 formations et repérez les parcours dédiés à la sécurité des agents d'IA.
Vous voulez maîtriser ce sujet en pratique ?
Cabinet MARA forme en ligne, sur des cas réels, avec des modules courts et un suivi de progression.
Voir la formation liée Les 31 formations