Un LLM n'est jamais neutre quand il touche aux données de l'entreprise
Un LLM devient un composant sensible dès qu'il manipule des données internes, influence une décision ou déclenche une action. Le risque ne se limite pas au modèle : il vient du contexte qu'on lui donne, des sources qu'on lui ouvre, des outils qu'il peut appeler et des sorties que les utilisateurs acceptent sans vérification.
Sécuriser l'usage des LLM demande donc une défense en profondeur. Les garanties fournisseur sont utiles, mais elles ne remplacent pas la classification des usages, les permissions, les journaux, les tests d'abus et la validation humaine sur les sorties critiques.
"Le LLM n'était pas dangereux seul. Il le devenait quand on lui donnait trop de contexte et trop d'actions."
Le risque ne vient pas du modèle seul, mais de ce qu'on lui ouvre
Un chatbot sans accès aux systèmes internes porte un risque différent d'un agent capable de lire un CRM, créer un ticket, interroger une base documentaire et envoyer un message. Plus le contexte et les actions augmentent, plus les contrôles doivent être explicites.
Les risques à traiter en priorité :
- fuite de données sensibles dans un prompt ;
- prompt injection via une source documentaire ou une page web ;
- accès excessif à des documents que l'utilisateur ne devrait pas voir ;
- sortie critique acceptée sans revue ;
- agent trop autonome qui agit au-delà de son périmètre ;
- coûts non bornés sur des usages automatisés.
Le bon niveau de sécurité dépend de l'usage. Un assistant de reformulation interne et un agent connecté à des données clients ne doivent pas partager le même régime de contrôle.
Construire les garde-fous avant d'élargir les usages
Avant d'élargir les usages, définissez ce que l'entreprise autorise, surveille et refuse. Un cadre court, compris par les équipes, vaut mieux qu'une politique longue qui arrive après les contournements.
1. Classer données et usages
Classez les usages par criticité : assistance individuelle, aide à la rédaction, recherche documentaire, analyse de code, support client, décision métier, agent actionnable. Croisez ce classement avec les données manipulées : publiques, internes, confidentielles, personnelles, régulées.
La politique LLM doit expliquer, pour chaque niveau, les outils autorisés, les données interdites, la validation attendue et les traces conservées.
2. Prévenir les fuites de données
La prévention des fuites commence par les droits. Le LLM ne doit pas devenir un raccourci qui contourne les permissions existantes. Si un utilisateur n'a pas accès à un document, l'assistant ne doit pas lui en restituer le contenu.
La matrice de permissions doit couvrir les sources, les rôles utilisateurs, les outils appelables, les logs et les exceptions. Elle doit être testée, pas seulement dessinée.
3. Limiter l'autonomie des agents
Un agent doit avoir un périmètre d'action strict. Lecture, proposition, création de brouillon, action réversible, action critique : chaque niveau demande une validation différente. Les actions sensibles doivent rester soumises à approbation humaine, avec traçabilité.
Le journal d'audit doit permettre de comprendre qui a demandé quoi, quelles sources ont été utilisées, quelle sortie a été produite, quelle action a été proposée ou refusée.
4. Valider les sorties critiques
Les sorties critiques doivent être contrôlées : recommandation juridique, réponse client sensible, décision financière, modification de code en production, action sur un compte. Les tests d'abus doivent inclure prompt injection, extraction de secrets, contournement de rôle, hallucination et demande d'action interdite.
| Étape | Livrable | Signal de qualité |
|---|---|---|
| Classification | Politique LLM | Données et usages sont classés par criticité |
| Permissions | Matrice d'accès | Le LLM respecte les droits existants |
| Traçabilité | Journal d'audit | Sources, sorties et actions sont retrouvables |
| Contrôle | Tests d'abus | Les scénarios de contournement sont testés |
:::
Ce qui change quand la sécurité devient visible dans le workflow
La sécurité devient efficace quand elle se voit dans le workflow : messages bloqués, sources exclues, demandes d'approbation, logs exploitables, refus d'action, explication des limites. L'utilisateur comprend ce qu'il peut faire et pourquoi certaines actions sont refusées.
Ce type de résultat ne vient pas d'une promesse fournisseur. Il vient d'une architecture de contrôle testée avec des cas réels et des scénarios hostiles.
Un pilote de sécurisation qui commence par les usages à risque
Le pilote doit prendre un usage réel avec données internes, pas un assistant générique sans enjeu. L'objectif est de vérifier les contrôles sur un cas suffisamment sensible pour apprendre, mais assez borné pour rester maîtrisable.
Le pilote doit produire :
- une classification de l'usage ;
- une matrice de permissions ;
- des logs exploitables ;
- une série de tests d'abus ;
- une règle claire de validation humaine.
Le pilote sert autant à prouver la valeur qu'à prouver que le risque peut être tenu.
Les signaux à exiger avant d'ouvrir davantage
Avant d'élargir, exigez des signaux précis : aucun accès non autorisé, prompts sensibles bloqués, actions critiques soumises à validation, logs relisibles, coûts bornés, exceptions sécurité traitées.
Si ces signaux ne sont pas disponibles, l'ouverture large crée un risque que l'organisation ne saura ni détecter ni expliquer.
Combien de temps faut-il pour obtenir un signal fiable ?
Deux à quatre semaines suffisent pour tester les contrôles sur un usage borné. Les usages critiques demandent ensuite une surveillance continue.
Faut-il commencer par un outil ou par un cas d'usage ?
Par les données, les actions et le niveau de risque du cas d'usage. L'outil vient après.
Comment éviter les gains déclaratifs ?
Mesurez incidents de données, prompts bloqués, actions refusées, exceptions sécurité et qualité des logs.
Quand faut-il arrêter un pilote IA ?
Quand les droits ne peuvent pas être respectés, que les actions restent trop autonomes ou que les sorties critiques ne sont pas contrôlables.
Les incidents de données coupent court aux débats théoriques
Sécuriser l'usage des LLM en entreprise, c'est réduire ce que le modèle peut voir, faire et affirmer sans contrôle. Les meilleurs garde-fous sont ceux qui restent visibles dans l'usage quotidien : permissions, refus, validation, traces et tests réguliers.