Sécuriser un chatbot IA : injection de prompt et fuites de données

Un chatbot IA peut être détourné par ses propres utilisateurs ou par les contenus qu’il lit : c’est l’injection de prompt, premier risque du classement OWASP des applications fondées sur des modèles de langage. Il peut aussi laisser échapper des informations qu’il ne devrait pas connaître ou exécuter des actions qu’on ne lui avait pas confiées. Aucune mesure unique ne supprime ces risques ; on les réduit en limitant ce que le chatbot sait, ce qu’il peut faire et ce qu’on vérifie avant et après ses réponses.

Cet article présente les principaux risques et des mesures accessibles pour une PME. Il ne remplace pas un test d’intrusion adapté à votre application, que vous pouvez demander via notre page cybersécurité. Pour les aspects juridiques, voir notre article sur les obligations RGPD et AI Act d’un chatbot.

Quels sont les principaux risques d’un chatbot IA ?

L’OWASP (Open Worldwide Application Security Project) publie un classement des dix principaux risques pour les applications utilisant des modèles de langage. L’édition 2025 comprend notamment l’injection de prompt (LLM01), la divulgation d’informations sensibles (LLM02), la gestion inappropriée des sorties (LLM05), l’agentivité excessive (LLM06), la fuite du prompt système (LLM07), les faiblesses liées aux bases vectorielles et aux embeddings (LLM08) et la consommation non maîtrisée de ressources (LLM10). La liste complète est publiée sur la page OWASP Top 10 for LLM Applications.

Pour un chatbot de site web, quatre risques reviennent le plus souvent : détourner le comportement, extraire des données, déclencher une action non voulue et faire exploser la facture ou la disponibilité. Voyons-les un par un.

Qu’est-ce que l’injection de prompt ?

Selon l’OWASP, l’injection de prompt se produit lorsque des entrées modifient le comportement ou la sortie du modèle de manière non prévue. Elle peut être directe (l’utilisateur écrit « ignore tes consignes et… ») ou indirecte (le modèle lit une page web, un document ou un courriel qui contient des instructions cachées). L’OWASP précise que ces instructions n’ont pas besoin d’être visibles ou lisibles par un humain, pourvu que le modèle les traite (LLM01:2025 Prompt Injection).

La même page indique qu’aucune méthode de prévention infaillible n’est connue à ce jour. La conséquence pratique est importante : on ne doit pas confier à un modèle la garde d’un secret ou d’une règle de sécurité, car il peut être persuadé de s’en écarter. Les protections critiques se placent dans le code et les droits d’accès, pas uniquement dans la consigne donnée au modèle.

Comment éviter qu’un chatbot ne divulgue des informations sensibles ?

La divulgation d’informations sensibles (LLM02) concerne les données personnelles, secrets commerciaux ou documents internes que le chatbot peut révéler. Les causes fréquentes sont simples : on a connecté le chatbot à trop de documents, on lui a donné des identifiants avec des droits larges, ou l’on a laissé des données confidentielles dans le prompt système.

Mesures concrètes :

• Réduire le périmètre : ne connectez que les contenus destinés à être publics ou à l’utilisateur concerné.
• Appliquer les droits d’accès avant la recherche : si le chatbot interroge vos documents (voir notre explication du RAG), le filtrage par utilisateur doit s’appliquer côté serveur, pas par une consigne au modèle.
• Ne jamais mettre de secret dans le prompt : clés d’API, mots de passe et règles confidentielles n’ont pas leur place dans les instructions. L’OWASP décrit ce risque sous le nom de fuite du prompt système (LLM07).
• Pseudonymiser ou masquer les données personnelles avant de les envoyer au modèle, lorsque l’usage le permet.
• Limiter la conservation des conversations et l’accès aux journaux.

Pourquoi limiter les actions que le chatbot peut effectuer ?

L’agentivité excessive (LLM06) apparaît quand un chatbot dispose de fonctions, d’autorisations ou d’autonomie en trop. Un assistant qui peut seulement répondre à des questions n’a pas le même risque qu’un assistant qui peut envoyer des courriels, modifier un dossier client ou lancer un remboursement.

Parmi les mesures de l’OWASP contre l’injection de prompt figurent l’application du moindre privilège (le chatbot dispose de ses propres jetons d’accès, limités à ce dont il a besoin, et les fonctions privilégiées sont traitées dans le code plutôt que par le modèle) et l’exigence d’une validation humaine pour les actions à risque. Dans la pratique :

• donnez au chatbot des comptes techniques distincts, avec des droits minimaux ;
• listez les actions autorisées, chacune avec ses limites (montants, destinataires, fréquence) ;
• exigez une validation par une personne avant tout envoi externe, toute modification de données ou tout paiement ;
• journalisez les actions demandées et exécutées.

Que faire des réponses du modèle avant de les utiliser ?

La gestion inappropriée des sorties (LLM05) rappelle qu’une réponse du modèle est une entrée non fiable pour le reste de l’application. Si le chatbot produit du code HTML, une requête, une commande ou une adresse que votre système exécute ou affiche sans contrôle, une injection peut se transformer en faille classique.

Traitez donc la sortie comme celle d’un utilisateur : échappez-la avant de l’afficher, validez son format avec du code déterministe, n’exécutez jamais une commande générée sans filtre ni validation. L’OWASP recommande aussi de définir des formats de sortie attendus et de les vérifier par du code. Pour des réponses factuelles, affichez les sources utilisées et indiquez que l’assistant peut se tromper : la désinformation (LLM09) fait partie des risques listés.

Comment contrôler l’usage et les coûts ?

La consommation non maîtrisée (LLM10) recouvre les abus qui épuisent vos ressources ou votre budget : requêtes massives, conversations très longues, boucles automatiques. Protégez le chatbot comme n’importe quel service exposé : limitation du nombre de requêtes par visiteur, longueur maximale des messages, plafond de dépenses chez le fournisseur, alertes en cas de pic. Reliez ces alertes à votre supervision.

Comment tester un chatbot avant la mise en ligne ?

Constituez un jeu de scénarios d’essai avant de publier, et rejouez-le à chaque changement du prompt, du modèle ou des documents :

1. Détournement de rôle : demander au chatbot de changer de consignes, de parler d’un sujet hors périmètre.
2. Extraction : demander ses instructions, la liste de ses outils, les documents qu’il connaît.
3. Données d’autres utilisateurs : demander des informations sur un autre client ou un autre dossier.
4. Contenus indirects : lui faire lire un document de test contenant une consigne cachée.
5. Actions : tenter de lui faire déclencher une action sans validation.
6. Charge : envoyer des messages très longs ou répétés.

Notez les résultats, corrigez, puis recommencez. L’OWASP recommande des tests adverses réguliers, en traitant le modèle comme un utilisateur non fiable. Faites ces essais uniquement sur vos propres systèmes ou avec autorisation écrite. Un test d’intrusion mené par un spécialiste donne une vision plus complète.

Exemple fictif : un assistant de support relié à une base de connaissances

Cet exemple est fictif et ne décrit ni un client ni un résultat mesuré.

Une entreprise connecte un assistant à sa base de connaissances et à son outil de tickets. Lors des essais, un document de test contenant une consigne cachée conduit l’assistant à proposer de modifier un ticket. L’entreprise retire cette autorisation d’écriture, donne à l’assistant un compte en lecture seule, filtre les documents par service côté serveur et impose la validation d’un agent pour toute action. Dans cet exemple, la correction ne rend pas l’injection impossible ; elle en limite les conséquences.

FAQ

Une consigne « ne révèle jamais ces informations » suffit-elle ?

Non. Elle peut aider, mais l’OWASP rappelle qu’aucune prévention infaillible n’existe. Ce qui ne doit pas être révélé ne doit pas être accessible au modèle.

Mon chatbot ne fait que répondre : suis-je concerné ?

Oui, notamment pour la fuite de données, la désinformation et la consommation de ressources. Le risque d’actions non voulues est cependant plus limité.

Peut-on utiliser un chatbot avec des données clients ?

Oui si le cadre RGPD est respecté, les accès sont maîtrisés et les fournisseurs sont encadrés. Voir notre article sur les obligations RGPD et AI Act.

Conclusion

Sécuriser un chatbot, c’est réduire ce qu’il sait, ce qu’il peut faire et ce qu’on lui fait confiance : données minimales, droits limités, sorties contrôlées, validation humaine, tests répétés. Pour examiner votre projet ou votre assistant existant, consultez notre page cybersécurité ou contactez-nous.