Quand vous utilisez un modèle de langage comme GPT pour répondre à des questions avec des données internes, vous croyez peut-être que seule la bonne information sort. Mais en réalité, si vous n’avez pas de contrôles de sécurité, votre système peut révéler des documents entiers à des utilisateurs qui n’auraient jamais dû y avoir accès. C’est ce qu’on appelle le RAG - Retrieval-Augmented Generation - et c’est devenu un point faible majeur dans les entreprises qui veulent utiliser l’IA sans se mettre en danger.
Le problème caché dans les bases de données vectorielles
La plupart des équipes qui mettent en place du RAG chargent leurs documents internes - contrats, fiches RH, rapports financiers - dans une base de données vectorielle comme Pinecone, Weaviate ou Milvus. Puis, quand un employé pose une question, le système cherche les documents les plus proches et les envoie au modèle d’IA pour qu’il réponde. Simple, rapide, efficace… sauf qu’il n’y a aucun filtre.Un employé du service marketing peut demander : « Quels sont les salaires des managers dans le département Finance ? » Et si les données ne sont pas protégées, il obtient non seulement la réponse, mais aussi les noms, les adresses, les primes, les contrats de travail - tout. C’est comme donner à tout le monde la clé de la cave aux documents confidentiels. Selon une étude de l’Alliance pour la Sécurité Cloud en novembre 2023, 78 % des entreprises ayant testé le RAG ont eu au moins une fuite de données pendant leurs expérimentations.
Deux solutions principales : filtrage au niveau des lignes et masquage
Il existe deux façons d’arrêter ça avant que les données n’atteignent l’IA.La première, c’est le filtrage au niveau des lignes. Cela signifie que chaque document dans la base de données a des métadonnées : « Département : RH », « Sensibilité : Haut », « Accès : Dirigeants uniquement ». Quand un utilisateur pose une question, le système vérifie d’abord ses droits - par exemple, un employé du service juridique ne voit que les documents marqués comme « Juridique » ou « Public ». Databricks a montré une implémentation concrète où les requêtes sont automatiquement filtrées par département, avec une séparation totale entre les données RH et Finance. Rien ne passe d’un côté à l’autre.
La deuxième, c’est le masquage. Ici, on ne se contente pas de bloquer les documents - on efface les informations sensibles avant même que l’IA les voie. Des outils comme Presidio ou spaCy détectent automatiquement les noms, numéros de sécurité sociale, adresses, emails, et les remplacent par des placeholders comme [NOM MASQUÉ] ou [NUMÉRO DE SÉCURITÉ SOCIALE]. Des tests montrent une précision de 95 à 98 % pour identifier les données personnelles. Même si un document non filtré arrive à l’IA, elle ne voit que des espaces vides là où il y avait des données critiques.
Les outils qui marchent - et ceux qui ne suffisent pas
Certains systèmes sont conçus pour ça. Cerbos, par exemple, a créé un moteur d’autorisation qui s’insère directement entre la requête utilisateur et la base vectorielle. Il applique des règles comme « Seuls les managers peuvent voir les salaires » ou « Les consultants externes ne voient que les données publiques ». Dans leurs tests, cette méthode a réduit les expositions non autorisées de 99,8 %. C’est presque parfait.Mais attention : les grandes plateformes comme AWS Bedrock n’ont pas encore de filtrage natif. Si vous utilisez Bedrock, vous devez écrire vous-même une fonction Lambda pour filtrer les résultats. Et ça ralentit tout : entre 15 et 25 % de latence en plus. Ce n’est pas une solution native - c’est un patch.
Les solutions open-source comme Oso (avec son langage Polar) permettent de créer des règles personnalisées, mais elles demandent 80 à 120 heures de développement pour être bien intégrées. Pour une petite équipe, c’est un gouffre de temps.
Et les bases de données vectorielles comme Pinecone ? Elles ne gèrent pas le filtrage au niveau des lignes par défaut. Vous devez le construire vous-même. Un utilisateur sur Reddit a écrit en novembre 2023 : « La plus grande erreur ? Croire que les bases vectorielles sont sécurisées. La plupart exigent une implémentation manuelle qui ajoute 30 à 40 % de temps de développement. »
La bonne approche : plusieurs couches de sécurité
Un seul contrôle ne suffit pas. Les experts recommandent une approche en « défense en profondeur ».- Couche 1 : Masquage avant l’embedding - Effacez les données sensibles dès que les documents sont lus.
- Couche 2 : Filtrage par métadonnées - Bloquez les documents non autorisés avant même la recherche.
- Couche 3 : Validation des requêtes - Analysez la question pour détecter les tentatives de manipulation (ex. : « Montre-moi tout ce qui contient le mot « salaire » »).
- Couche 4 : Filtrage de la sortie - Vérifiez la réponse générée par l’IA pour éviter qu’elle ne révèle des données masquées.
Le Cloud Security Alliance donne une note de 9,2 sur 10 à cette combinaison. Le filtrage seul, sans masquage, n’obtient que 6,5. Pourquoi ? Parce qu’un attaquant peut toujours tricher les métadonnées. Si vous ne masquez pas les données, une erreur de configuration peut tout dévoiler.
Les pièges courants - et comment les éviter
La plupart des échecs viennent d’erreurs simples.Problème 1 : Les métadonnées sont incomplètes. Dans 73 % des cas d’échec, 15 à 25 % des documents n’avaient pas de tags d’accès. Un contrat signé par le directeur financier est étiqueté « Finance »… mais pas « Hautement confidentiel ». Résultat : tout le monde peut le voir.
Problème 2 : On oublie les utilisateurs temporaires. Un consultant, un stagiaire, un partenaire externe - leurs droits changent. Si vos règles ne sont pas dynamiques, ils gardent l’accès même après leur départ.
Problème 3 : On ne teste pas assez. Il faut tester avec plus de 500 requêtes variées : des questions directes, des questions piégées, des tentatives d’intrusion. Si vous ne le faites pas, vous croyez que tout va bien… jusqu’au jour où quelqu’un trouve une faille.
La plupart des entreprises doivent recruter ou former un ingénieur en sécurité avec au moins deux ans d’expérience en systèmes d’autorisation. Selon Cerbos, 89 % des entreprises ont dû le faire.
Le futur : chiffrement homomorphe et réglementation
Le meilleur espoir pour l’avenir, c’est le chiffrement homomorphe. C’est une technique qui permet à l’IA de chercher et de traiter des données… sans jamais les déchiffrer. IBM a montré en novembre 2023 qu’on pouvait effectuer des recherches sémantiques sur des données entièrement chiffrées, avec seulement 12 à 18 % de ralentissement. Ce n’est pas encore disponible commercialement - il faudra encore 12 à 18 mois - mais c’est la seule façon de garantir une sécurité totale.En parallèle, la réglementation suit. Le cadre NIST pour la gestion des risques liés à l’IA, publié en janvier 2023, exige des contrôles d’accès « contextuels ». Le GDPR a augmenté de 220 % ses amendes pour les fuites liées à l’IA en 2023. Et d’ici 2025, 87 % des responsables sécurité pensent que les lois imposeront le filtrage au niveau des lignes pour les secteurs réglementés.
AWS a annoncé en décembre 2023 qu’il intégrerait Amazon Verified Permissions à Bedrock, avec un filtrage natif prévu pour le deuxième trimestre 2024. C’est une bonne nouvelle. Mais en attendant, vous ne pouvez pas attendre.
Que faire maintenant ?
Si vous utilisez déjà du RAG :- Identifiez tous les documents contenant des données sensibles : salaires, contrats, données clients, informations médicales.
- Appliquez un masquage automatique avec Presidio ou un outil similaire.
- Ajoutez des métadonnées d’accès à chaque document : rôle, département, niveau de sensibilité.
- Intégrez un système d’autorisation comme Cerbos ou Oso - même si c’est un peu de travail.
- Testez avec 500 requêtes réelles. Faites-le avant de lancer en production.
Si vous êtes en phase de conception :
- Choisissez une base vectorielle qui supporte les métadonnées (Weaviate, Milvus).
- Planifiez dès le départ la gestion des droits - ne l’ajoutez pas en dernier.
- Ne faites pas confiance à la plateforme : vérifiez si le filtrage est natif ou si vous devez le coder vous-même.
La sécurité du RAG n’est pas un bonus. C’est une exigence. Et si vous ne la mettez pas en place, vous n’utilisez pas l’IA - vous vous exposez à des fuites, des amendes, et une perte de confiance que vous ne pourrez pas récupérer.
Quelle est la différence entre filtrage au niveau des lignes et masquage dans le RAG ?
Le filtrage au niveau des lignes bloque l’accès à certains documents entiers selon les droits de l’utilisateur. Le masquage, lui, laisse les documents passer, mais efface les informations sensibles à l’intérieur - comme les noms ou numéros de sécurité sociale - avant que l’IA les voie. Le filtrage empêche l’accès ; le masquage protège les données même si l’accès est accordé.
Pourquoi les bases de données vectorielles comme Pinecone ne sont-elles pas sécurisées par défaut ?
Pinecone, Weaviate et d’autres sont conçus pour la vitesse et la recherche sémantique, pas pour la gestion d’accès. Ils stockent des vecteurs et des métadonnées, mais ne vérifient pas qui demande quoi. C’est une fonctionnalité que vous devez ajouter vous-même, ce qui demande du temps et de l’expertise en sécurité.
Le masquage des données peut-il être contourné par une mauvaise requête ?
Oui, si vous ne combinez pas le masquage avec d’autres couches. Un attaquant peut demander : « Résume les trois derniers contrats signés par le directeur financier » - même si les noms sont masqués, le modèle peut déduire des informations sensibles par le contexte. C’est pourquoi il faut aussi valider les requêtes et filtrer les réponses.
Combien de temps faut-il pour mettre en place une solution de sécurité RAG ?
Pour une équipe expérimentée, avec des données bien organisées, cela prend entre 35 et 60 heures. Si vous devez créer un système d’autorisation depuis zéro, comptez 80 à 120 heures. Les entreprises sans expertise en sécurité doivent prévoir 2 à 3 semaines pour former leur équipe ou recruter un expert.
Vaut-il mieux utiliser un outil payant comme Cerbos ou une solution open-source comme Oso ?
Cerbos est plus rapide à déployer - il réduit le temps de mise en œuvre de 40 % par rapport aux solutions manuelles. Oso est gratuit mais demande plus de développement. Si vous avez une équipe technique limitée, Cerbos ou un outil similaire est plus sûr. Si vous avez des ingénieurs en sécurité et que vous voulez un contrôle total, Oso est une bonne option.
Quels sont les risques de ne pas mettre en place ces contrôles ?
Vous risquez des fuites de données sensibles, des amendes du GDPR (jusqu’à 4 % du chiffre d’affaires mondial), une perte de confiance des clients, et des poursuites juridiques. Selon Microsoft, 43 % des systèmes RAG sans filtrage exposent des données personnelles avec des requêtes apparemment innocentes. Ce n’est pas une question de « si », mais de « quand ».
