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.
Pourquoi classer à la fois les données et le type d'usage LLM ?
Une donnée interne utilisée pour reformuler un texte ne porte pas le même risque qu'une donnée client accessible à un agent actionnable. Le croisement détermine les outils, validations, traces et interdictions nécessaires.
Comment empêcher le LLM de contourner les droits existants ?
La matrice de permissions doit relier sources, rôles utilisateurs, outils appelables, logs et exceptions. Elle doit garantir qu'un assistant ne restitue jamais un document inaccessible à l'utilisateur, puis être vérifiée par des tests.
Comment graduer l'autonomie d'un agent ?
Il faut distinguer lecture, proposition, brouillon, action réversible et action critique. Chaque niveau reçoit une validation adaptée, les actions sensibles restant soumises à approbation humaine et à une trace d'audit.
Quels scénarios doivent couvrir les tests d'abus ?
Prompt injection, extraction de secrets, contournement de rôle, hallucination et demande d'action interdite doivent être testés sur les sources et outils réellement ouverts au LLM.
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.