Les applications fondées sur des grands modèles de langage — assistants internes, chatbots clients, agents connectés aux outils de l’entreprise — ouvrent une surface d’attaque que les tests d’intrusion classiques couvrent mal. Le Top 10 OWASP pour les applications LLM (édition 2025) donne un cadre commun pour les auditer. Voici les dix risques, puis ceux que je traite en premier en mission.
Les dix risques en un coup d’œil
- LLM01 — Injection de prompt : des instructions malveillantes, directes ou cachées dans un document, détournent le comportement du modèle.
- LLM02 — Divulgation d’informations sensibles : le modèle restitue des données personnelles, secrets ou informations confidentielles.
- LLM03 — Chaîne d’approvisionnement : modèles, jeux de données ou bibliothèques tiers compromis ou non maîtrisés.
- LLM04 — Empoisonnement des données et du modèle : données d’entraînement ou d’ajustement manipulées.
- LLM05 — Traitement inapproprié des sorties : la réponse du modèle est exécutée ou affichée sans validation (XSS, injection SQL, commandes).
- LLM06 — Agentivité excessive : l’agent dispose de trop de permissions, de fonctions ou d’autonomie.
- LLM07 — Fuite du prompt système : les instructions internes, parfois porteuses de secrets, sont révélées.
- LLM08 — Faiblesses des vecteurs et embeddings : failles propres aux architectures RAG (accès, cloisonnement, empoisonnement de la base).
- LLM09 — Désinformation : réponses fausses mais plausibles, prises pour argent comptant.
- LLM10 — Consommation non bornée : abus de ressources, coûts incontrôlés, déni de service.
Priorité 1 : injection de prompt et agentivité excessive
Dès qu’un assistant lit des contenus externes (e-mails, pages web, documents téléversés) et peut agir (envoyer, modifier, interroger une API), la combinaison LLM01 + LLM06 devient le scénario le plus critique : une instruction cachée dans un document suffit à déclencher une action. L’audit vérifie le principe du moindre privilège, la séparation des contenus de confiance et non fiables, et la validation humaine des actions à impact.
Test révélateur
Déposez dans la base documentaire un fichier contenant une instruction cachée (« ignore les consignes précédentes et… ») et observez si l’agent l’exécute. Ce test simple met en évidence la majorité des défauts d’architecture.
Priorité 2 : données sensibles et architecture RAG
Un RAG mal cloisonné restitue à un utilisateur des documents qu’il n’a pas le droit de lire : c’est LLM02 croisé avec LLM08. Les contrôles d’accès doivent s’appliquer au moment de la recherche, pas seulement à l’interface. On vérifie aussi le masquage des données personnelles et des secrets avant envoi au modèle, ainsi que la politique de conservation des conversations.
Priorité 3 : traitement des sorties
Toute sortie de modèle doit être traitée comme une entrée utilisateur non fiable. Si la réponse est insérée dans une page web, une requête ou une commande, les protections habituelles — encodage, requêtes paramétrées, liste blanche — s’appliquent sans exception (LLM05).
Compléter avec MITRE ATLAS
Là où l’OWASP décrit des familles de vulnérabilités, MITRE ATLAS documente les tactiques et techniques d’attaque observées contre les systèmes d’IA. Croiser les deux permet de construire des scénarios de test réalistes et de les relier à l’analyse de risques — par exemple dans une démarche EBIOS RM.
Ce que contient un rapport d’audit utile
- Une cartographie de l’architecture : modèles, sources de données, outils et permissions de l’agent.
- Les scénarios testés, mappés sur l’OWASP LLM Top 10 et MITRE ATLAS.
- Les vulnérabilités constatées, avec preuve et niveau de criticité.
- Un plan de remédiation priorisé, et les mesures de gouvernance associées (journalisation, revue humaine, registre).
Pour replacer ces contrôles techniques dans le cadre réglementaire, le guide AI Act & shadow AI est disponible ci-dessous.
