Vector store et embeddings : vos données ne sont pas anonymes, voici pourquoi

Les vecteurs stockés dans votre base d'IA ne sont pas une version anonyme de vos documents : à partir de ces seuls nombres, un attaquant peut reconstituer une part importante du texte d'origine. Un vector store doit donc se protéger comme la base de données sensible qu'il est, pas comme un index technique anodin. C'est exactement l'erreur que je vois le plus souvent sur les projets de recherche augmentée (RAG) : on chiffre soigneusement la base documentaire d'origine, puis on recopie tout son contenu, en clair de fait, dans un index vectoriel laissé ouvert. Voici la méthode en quatre couches pour refermer cette porte.

Le problème : un embedding n'est pas un anonymat

Pour qu'une IA retrouve les bons passages dans vos documents, chaque morceau de texte est transformé en une longue liste de nombres, appelée embedding, puis rangé dans une base spécialisée, le vector store. Beaucoup d'équipes en concluent, à tort, que ces nombres sont illisibles et donc inoffensifs. La réalité est l'inverse : l'embedding est conçu pour conserver le sens du texte, et ce sens suffit à en reconstruire une grande partie.

C'est ce que la recherche appelle une attaque par reconstruction (embedding inversion). Un adversaire qui met la main sur vos vecteurs, ou qui parvient à interroger l'index sans contrôle, peut réassembler des phrases entières : noms de clients, montants, clauses de contrat, fragments de dossier médical. L'OWASP a formalisé ce risque sous le nom de faiblesses des embeddings et des vecteurs (LLM08), l'un des dix risques de son référentiel de sécurité des IA génératives.

Cette confusion a une conséquence directe sur votre conformité. Si vos embeddings encodent des données personnelles, alors le vector store est un traitement de données personnellesau sens du RGPD, avec les mêmes obligations de sécurité, de minimisation et de traçabilité que la base source. Le raisonnement « ce sont des nombres, donc ce n'est pas de la donnée personnelle » ne tient pas devant un régulateur.

La méthode en quatre couches pour protéger votre vector store

Un seul verrou ne suffit pas : c'est l'empilement des quatre couches ci-dessous, entre vos données vectorisées et le monde extérieur, qui rend l'index défendable. Voici comment les poser dans l'ordre.

Couche 1 : classer l'index comme une donnée sensible, et le chiffrer

Tout commence par une décision de classification. Votre vector store hérite du niveau de sensibilité le plus élevéparmi les documents qu'il indexe. Si vous y versez des contrats ou des dossiers patients, l'index est confidentiel, point. De cette classification découlent le chiffrement au repos et en transit, le choix d'un hébergement adapté (localisation dans l'Union européenne quand des données personnelles sont en jeu) et l'interdiction de le dupliquer vers des environnements de test non protégés.

Couche 2 : cloisonner les accès, jamais d'index ouvert

La faille la plus fréquente n'est pas cryptographique, elle est organisationnelle : un index accessible sans authentification forte, ou partagé entre tous les clients d'une application multi-locataires. Chaque requête doit hériter des droits de l'utilisateur qui la déclenche, jamais d'un super-compte. Deux clients, deux périmètres de données : leurs vecteurs ne doivent jamais cohabiter dans un espace où une requête de l'un peut ramener les fragments de l'autre. C'est le même principe de cloisonnement que celui qui évite qu'un LLM ne recrache l'information sensible d'un autre utilisateur.

Couche 3 : minimiser ce que vous indexez et filtrer ce qui ressort

On n'attaque pas ce qui n'existe pas. Avant d'indexer, demandez-vous si chaque champ est réellement utile à la recherche. Un numéro de sécurité sociale ou un identifiant bancaire n'a en général rien à faire dans un embedding : il peut être retiré, masqué ou remplacé par un renvoi. Côté sortie, les métadonnéesassociées aux vecteurs (chemin du fichier, auteur, service) fuient tout autant que le texte : filtrez-les avant de les renvoyer, et n'exposez jamais les vecteurs bruts via une API.

Couche 4 : tracer chaque requête et éprouver la reconstruction

Une protection que vous n'avez jamais testée n'est qu'une hypothèse. Journalisez qui interroge l'index, quand et avec quel volume, pour détecter une aspiration massive. Puis mettez votre propre défense à l'épreuve : tentez, en interne ou avec un tiers, de reconstruire du texte à partir des vecteurs et de faire ressortir la donnée d'un autre périmètre. C'est l'objet d'un red teaming de votre IA, qui transforme chaque faiblesse trouvée en un contrôle vérifiable.

Index anodin ou base sensible : le bon réflexe

Toute la bascule tient dans le tableau ci-dessous. La colonne de gauche est le réflexe qui expose ; celle de droite, le réflexe qui protège.

Si vous ne deviez retenir qu'une phrase : votre vector store mérite exactement le même niveau de protection que la base documentaire d'origine, parce qu'il en est une copie, sous une autre forme.

Le résultat : un RAG que vous pouvez défendre

En posant ces quatre couches, vous passez d'un index ouvert, invisible dans votre cartographie des risques, à un composant identifié, chiffré, cloisonné et testé. Vous savez qui y accède, ce qu'il contient et ce qu'il livrerait en cas de compromission. Ce risque n'est d'ailleurs qu'un des dix du référentiel : pour le replacer dans l'ensemble, le panorama de l'OWASP LLM Top 10vous donne la vue complète et l'ordre de priorité.

C'est précisément l'objet de mon audit Sécurité & Conformité IA : vérifier la façon dont vos données sont vectorisées, stockées et exposées, éprouver la reconstruction de votre index, puis vous remettre une feuille de route priorisée avant un déploiement que vous pourrez défendre.

Questions fréquentes

Un embedding est-il vraiment réversible ?

Pas au sens d'une restitution parfaite, mais suffisamment pour être dangereux. Les travaux de recherche montrent qu'on reconstitue une part importante du texte d'origine à partir des seuls vecteurs, en particulier les entités nommées (noms, montants, dates). Considérer un embedding comme irréversible est une hypothèse de sécurité fausse.

Le vector store est-il concerné par le RGPD ?

Oui, dès que les documents indexés contiennent des données personnelles. L'index devient un traitement à part entière : mêmes obligations de sécurité, de minimisation, de durée de conservation et de traçabilité que la base source. Le fait que la donnée soit « vectorisée » ne la fait pas sortir du champ du règlement.

Le chiffrement du vector store suffit-il ?

Non. Le chiffrement protège l'index au repos et en transit, mais pas contre une requête légitime mal cloisonnée qui ramène la donnée d'un autre périmètre. C'est pour cela que le cloisonnement des accès et le filtrage des sorties comptent autant que le chiffrement.

Par où commencer si mon RAG est déjà en production ?

Par la classification et l'inventaire : quels documents alimentent l'index, quel est leur niveau de sensibilité, qui peut l'interroger. Vous obtenez en quelques jours une image claire de votre exposition, puis vous priorisez les quatre couches dans l'ordre. C'est le point de départ d'un audit.

Cet article a une visée pédagogique et ne constitue pas un conseil juridique. Chaque situation mérite une analyse au cas par cas.