Risques de l'IA : fuites de données et injection de prompt

Les risques propres à l'IA générative viennent d'une particularité : un LLM reçoit dans un même texte les consignes et les données, et ne sait pas les séparer de façon fiable. Il peut donc obéir à des instructions cachées dans ce qu'il lit (l'injection de prompt), laisser sortir des informations qu'il voit (la fuite de données), ou produire une sortie que l'application utilise sans la contrôler. Ce chapitre présente ces risques du point de vue du défenseur : principe, symptômes, détection et contre-mesures, avec la grille de référence du domaine, le Top 10 OWASP des applications LLM.

Le Top 10 OWASP des applications LLM

Comme pour les applications web (OWASP Top 10), la fondation OWASP publie la liste des dix risques les plus importants pour les applications qui utilisent un LLM. L'édition en vigueur, publiée en août 2026, remplace celle de 2025 :

Par rapport à l'édition 2025, l'agentivité excessive passe de la 6ᵉ à la 3ᵉ place, poussée par les incidents causés par des agents, et la fuite du prompt système devient l'exposition du contexte caché : elle couvre tout ce que le modèle voit sans que l'utilisateur le voie, consignes, schémas des outils, règles internes. La liste est publiée en anglais : les noms français sont une traduction, et à l'oral le code suivi du nom anglais évite toute ambiguïté. Si tu croises un article ou un TP avec d'autres numéros, regarde de quelle édition il parle.

Pour les agents, l'OWASP a publié en décembre 2025 un second classement, le Top 10 des applications agentiques, qui détaille les risques des systèmes qui enchaînent des actions.

L'injection de prompt

Le principe. Dans une application classique, le code et les données sont séparés : une requête préparée empêche une saisie de devenir du SQL (injection SQL). Un LLM n'a pas cette séparation : consignes du développeur, question de l'utilisateur, contenu d'un document, tout arrive dans le même contexte, sous forme de tokens. Si un texte qu'il lit ressemble à une consigne, il peut la suivre. Aucune technique ne garantit aujourd'hui qu'il ne le fera pas.

On distingue deux formes :

• L'injection directe : l'utilisateur lui-même formule sa demande pour faire sortir le modèle de son rôle, contourner ses règles ou lui faire révéler ses consignes. On parle aussi de jailbreak.
• L'injection indirecte : les instructions sont cachées dans un contenu que le modèle lit pour faire son travail : un courriel à résumer, une page web consultée, un document indexé par le RAG, un ticket, un commentaire dans du code relu par un agent. L'utilisateur légitime ne voit rien : le texte peut être écrit en blanc sur fond blanc, ou placé dans une partie du document qui ne s'affiche pas.

L'injection indirecte est la plus dangereuse, parce qu'elle vient de l'extérieur et qu'elle frappe au moment où le modèle a des outils. Un assistant qui trie les courriels du support et peut créer des tickets, consulter l'annuaire ou envoyer des réponses peut être poussé par un courriel piégé à utiliser ces outils contre l'entreprise.

Les symptômes qui doivent alerter :

• l'assistant sort de son périmètre ou change de ton sans raison ;
• il révèle ses consignes, ou des informations qu'il n'aurait pas dû citer ;
• il appelle un outil que la demande ne justifiait pas, ou avec des arguments étranges (une adresse externe, un autre compte que celui de l'utilisateur) ;
• sa réponse contient des liens, des images ou des instructions qui n'ont rien à voir avec la question.

La détection repose sur la journalisation : chaque prompt, chaque contenu externe lu, chaque appel d'outil et chaque réponse sont enregistrés, avec l'utilisateur concerné. On surveille les appels d'outils hors des usages habituels, comme on surveille les connexions inhabituelles dans un SIEM (journaux et SIEM). Certaines équipes placent dans le prompt système une valeur témoin, une chaîne unique et sans valeur : si elle apparaît dans une réponse, c'est que les consignes ont fuité.

Les contre-mesures, en couches, parce qu'aucune ne suffit seule :

1. Limiter ce que le modèle peut faire. Pas d'outil inutile, des outils en lecture seule quand c'est possible, un compte technique aux droits minimaux. C'est la mesure la plus efficace : une injection réussie contre un assistant qui ne peut rien faire ne fait pas de dégâts.
2. Ne rien mettre de secret dans le contexte. Pas de mot de passe, de clé ou d'adresse sensible dans le prompt système ni dans les documents indexés.
3. Marquer les données externes. Les placer entre balises et dire au modèle de les traiter comme des données. Cela réduit le risque, sans l'éliminer.
4. Valider les actions sensibles par un humain, avec un résumé clair de ce qui va être fait.
5. Contrôler les sorties : schéma JSON imposé, liste des domaines autorisés pour les liens, échappement avant tout affichage.
6. Filtrer les entrées et les sorties avec des règles ou un second modèle chargé de repérer les tentatives. Utile, mais contournable.
7. Tester : essayer soi-même, dans un labo, de détourner son assistant avant de le mettre en service.

Le TP Le prompt n'est pas un mur te fait vivre les deux côtés sur trois jours : tu confies un secret à ton propre assistant, tu constates qu'il finit par le livrer, puis tu le durcis et tu prouves l'effet de tes mesures.

Les fuites de données

Les données peuvent sortir par trois chemins.

1. Ce que les utilisateurs collent dans un assistant public. Un salarié colle le fichier des clients pour « le mettre en forme », un journal de serveur pour « comprendre l'erreur », du code de l'entreprise pour « le corriger ». Ces données partent chez le fournisseur, sont conservées selon ses conditions, et peuvent servir à entraîner ses prochains modèles selon l'offre et les réglages. On parle de shadow AI quand les salariés utilisent des outils que l'entreprise n'a ni choisis ni encadrés. La réponse passe par la charte (chapitre 12) et par un outil validé, avec un contrat.

2. Ce que l'application laisse sortir. Un RAG qui n'applique pas les droits d'accès cite des documents confidentiels (LLM09) ; un assistant qui reçoit des données personnelles dans son contexte peut les répéter à la mauvaise personne (LLM02) ; un prompt système qui contient des informations internes peut être extrait (LLM08).

3. Ce que l'application garde. Les journaux des prompts et des réponses contiennent ce que les utilisateurs ont écrit, donc souvent des données personnelles. Ils se protègent, se purgent et se déclarent comme n'importe quel traitement (chapitre 10).

La sortie non validée

La réponse d'un modèle est une donnée non fiable, au même titre qu'une saisie dans un formulaire : elle peut contenir du HTML, du JavaScript, du SQL ou une commande, par erreur ou parce qu'une injection l'y a mise.

Les agents trop puissants

L'agentivité excessive (LLM03) regroupe trois excès : trop d'outils (l'assistant de tri a aussi accès à la suppression de comptes), trop de droits (son compte de service est administrateur du domaine), trop d'autonomie (il agit sans validation). Chaque excès transforme une erreur ou une injection en incident. La réponse est la même que pour un compte humain : le moindre privilège, une séparation des tâches, et une validation pour ce qui est irréversible (les permissions d'un agent).

La consommation non maîtrisée

Chaque requête coûte, en argent pour une API, en temps de calcul pour un modèle local. Un utilisateur malveillant, ou un simple bug, peut envoyer des milliers de longues requêtes : la facture explose ou le service devient indisponible. Les parades :

• un max_tokens adapté à l'usage, et une taille maximale pour les entrées ;
• une limitation du nombre de requêtes par utilisateur et par minute, comme pour une API (limitation de débit) ;
• une limite de dépense chez le fournisseur et une alerte avant de l'atteindre ;
• un délai maximal pour chaque appel, et un nombre maximal de tours pour un agent.

La chaîne d'approvisionnement

Un modèle ouvert, un jeu de données ou un serveur MCP sont des composants logiciels comme des bibliothèques : ils peuvent être piégés (LLM04) ou empoisonnés (LLM05). Télécharge les modèles depuis la source officielle de l'éditeur ou le registre d'Ollama, vérifie ce que tu installes, préfère les formats qui ne contiennent que des données (safetensors, GGUF) aux anciens formats capables d'exécuter du code au chargement, et tiens l'inventaire des modèles et des serveurs MCP utilisés, comme une nomenclature logicielle (SBOM). Pour le RAG, contrôle qui peut ajouter des documents à l'index.

Analyser les risques d'un projet d'IA

Avant de mettre un assistant en service, on applique la démarche habituelle d'analyse de risques : quels biens essentiels, quels besoins de sécurité, quelles menaces, quelles mesures. Pour l'assistant de tri de Sorbier :

Si l'assistant traite des données personnelles à grande échelle ou de façon innovante, une analyse d'impact RGPD peut s'imposer (AIPD). L'ANSSI a publié en avril 2024 un guide de Recommandations de sécurité pour un système d'IA générative, à consulter avant tout déploiement sérieux.

Exercices

const reponse = await fetch("/api/assistant", { method: "POST", body: JSON.stringify({ question }) })
  .then((r) => r.json());
document.querySelector("#reponse").innerHTML = reponse.texte;

document.querySelector("#reponse").textContent = reponse.texte;