Sécuriser chatbot IA interne/L’angle est très juste : il faut sortir du fantasme IA = attaque autonome et revenir à une lecture cyber réaliste. L’ANSSI (et le CERT-FR) rappelle bien que l’IA générative est déjà utilisée à plusieurs étapes d’une attaque (profilage, ingénierie sociale, code malveillant), mais qu’aucun système n’est aujourd’hui capable de mener de manière autonome toute la chaîne d’attaque. En parallèle, les systèmes LLM deviennent eux-mêmes des cibles (empoisonnement, exfiltration, chaîne logicielle). Autrement dit : le risque n’est pas “l’IA remplace « l’attaquant”, mais “l’IA » industrialise, accélère et élargit”.
Pourquoi la sécurité des applications LLM est devenue un enjeu prioritaire
Le déploiement va plus vite que la gouvernance. En Europe, ISACA indiquait en 2025 que 83 % des professionnels IT/métier estimaient que leurs équipes utilisent déjà l’IA, mais seulement 31 % des organisations avaient une politique IA formelle et complète.
La littérature récente met en évidence des signaux convergents :
● AgentDojo (ETH Zurich / Invariant Labs) a construit un benchmark avec 97 tâches réalistes et 629 cas de test sécurité pour agents LLM, et montre que les agents restent difficiles à sécuriser face aux injections et aux données non fiables.
● Greshake et al. ont popularisé le risque d’indirect prompt injection : des instructions malveillantes cachées dans des données (pages, documents, contenus récupérés) peuvent détourner une application LLM sans que l’attaquant parle directement au modèle.
● Une étude JAMA Network Open (2025), dans un contexte médical, a observé des taux de succès d’attaque très élevés (94,4 % sur 216 dialogues simulés) ; ce n’est pas transposable tel quel à tous les secteurs, mais c’est un signal fort sur la fragilité des garde-fous applicatifs.
DEVFORMA vous accompagne dans votre gouvernance IA. Échangez avec nos experts pour cadrer vos risques IA (LLM, RAG, agents) et structurer votre démarche.
Les 10 risques clés et comment les réduire
1) Injection de prompt
Risque :
un utilisateur, un document, une page web, un e-mail ou une source RAG (génération augmentée par recherche) peut introduire des instructions malveillantes qui contournent les règles définies par l’application. Il s’agit du risque n°1. OWASP le place en tête de son classement, et le NCSC souligne qu’il ne s’agit pas d’un simple équivalent de l’injection SQL, mais d’un problème plus structurel, proche du modèle du « confused deputy » (délégation de confiance détournée).
Réduction :
● séparer strictement données non fiables vs instructions système
● limiter les actions outils (email, CRM, fichiers) par capabilités et permissions minimales
● ajouter validation/humain avant action sensible
● journaliser les prompts, tool calls et décisions
2) Divulgation d’informations sensibles
Risque : fuite de données personnelles, extraits de documents internes, prompts système, logs, embeddings, etc. OWASP 2025 en fait une catégorie dédiée.
Réduction :
● minimisation des données envoyées au LLM
● masquage / redaction des données sensibles avant prompt
● DLP sur entrées/sorties
● segmentation des accès RAG (par rôle / équipe / client)
● interdire de mettre des secrets dans les prompts système.
3) Risques de chaîne d’approvisionnement
Risque : dépendances externes (modèle, API, plugins, wrappers, bibliothèques, datasets, outils agents) compromises ou non maîtrisées.
Réduction :
● inventaire des composants IA (modèles, APIs, plugins, datasets)
● revue de sécurité fournisseurs / hébergement / rétention
● pinning de versions et change management
● scans de dépendances + signature/provenance quand possible
● procédures de rollback en cas d’incident.
4) Empoisonnement des données et des modèles
Risque : altération malveillante du corpus documentaire (RAG), du fine-tuning, des embeddings ou des données de référence afin d’influencer les réponses du modèle.
La recherche récente est très parlante :
● PoisonedRAG montre qu’un attaquant peut atteindre 90 % de succès en injectant seulement quelques textes malveillants dans une base volumineuse (dans leur setup : 5 textes par question cible, base de millions de textes).
● CorruptRAG (2025) pousse l’idée vers des attaques plus réalistes avec un seul document empoisonné.
Réduction :
● pipeline d’ingestion contrôlé (source, signature, validation)
● ACL documentaires strictes avant indexation
● scoring de confiance des sources
● détection d’anomalies sur documents/embeddings
● tests de robustesse RAG (poisoning drills) avant mise en prod.
5) Mauvaise gestion des sorties du LLM
Risque : traiter la sortie du LLM comme sûre (exécuter du code, lancer une requête, cliquer un lien, injecter dans un système aval).
Réduction :
● ne jamais exécuter directement une sortie LLM
● validation stricte par schéma (JSON schema, types, allowlists)
● sandbox pour code généré
● escaping/sanitization avant affichage ou transmission
● principe : LLM output = donnée non fiable.
6) Autonomie excessive des agents
Risque : donner trop d’autonomie à l’agent (envoyer des emails, modifier tickets, exécuter scripts, acheter/réserver, écrire en base) sans garde-fous.
Réduction :
● permissions minimales par outil
● actions sensibles en step-up approval
● séparation des rôles (lecture ≠ écriture ≠ admin)
● quotas de commandes et périmètres d’action
● “kill switch” et mode dégradé.
7) Fuite du prompt système
Risque : exposition du prompt système, des règles internes, des workflows ou indices sur l’architecture.
Réduction :
● ne pas mettre de secrets/identifiants dans le prompt
● externaliser politiques et décisions sensibles côté application
● rotation/versioning des prompts
● tests d’extraction (red teaming) réguliers
● surveiller les patterns de requêtes d’exfiltration.
8) Faiblesses des vecteurs et des embeddings
Risque : faiblesses dans la couche vectorielle/RAG (mauvaise isolation, récupérations non autorisées, metadata manipulées, cross-tenant leakage).
Réduction :
● contrôle d’accès au niveau document et chunk
● isolation des index par tenant/environnement
● validation des métadonnées d’ingestion
● observabilité sur retrieval (qui a récupéré quoi, quand)
● tests d’accès croisé et de contournement des filtres.
9) Désinformation / informations trompeuses
Risque : réponses fausses ou trompeuses, parfois plausibles, qui dégradent la qualité, la conformité ou la sécurité (ex : procédures erronées, consignes non conformes).
Réduction :
● grounding sur sources approuvées
● réponse avec citations internes (quand possible)
● seuil de confiance / abstention si incertain
● validation humaine pour décisions à impact (juridique, santé, sécurité, finance)
● jeux de tests métier (factualité + sécurité).
10) Consommation non bornée
Risque : consommation non bornée (tokens, appels outils, contexte, coûts, latence) pouvant créer un DoS (Déni de Service) économique/technique.
Réduction :
● limites de tokens, temps, appels outils, recursion depth
● rate limiting + quotas par utilisateur/app
● budgets/coûts avec alerting
● cache et fallback
● monitoring coût/latence/erreurs comme signaux de sécurité.
Conclusion
La sécurité des applications LLM ne se résume pas à un bon prompt ou à un filtre en sortie : c’est un sujet de gouvernance, d’architecture, de contrôle d’accès, de supervision et de gestion du risque. L’enjeu pour les entreprises n’est pas de freiner les usages, mais de les encadrer correctement pour éviter les fuites de données, les détournements de fonctionnalités et les erreurs à fort impact métier.
Dans ce contexte, les RSSI, DSI, responsables conformité et managers des risques ont besoin d’un cadre clair pour identifier les menaces, prioriser les mesures et piloter la sécurité des usages IA dans le temps. C’est précisément l’objectif d’une démarche structurée de gestion du risque appliquée à l’IA. Pour aller plus loin, la formation Lead AI Risk Manager permet de monter en compétence sur les méthodes, les référentiels et les bonnes pratiques nécessaires pour évaluer, traiter et gouverner les risques liés à l’IA (LLM, agents, données, conformité, sécurité). C’est un excellent point d’entrée pour passer d’une logique d’expérimentation à une maîtrise opérationnelle des risques IA en entreprise.
