LLM08 : votre IA documentaire expose vos données internes.

LLM08 : Vector and Embedding Weaknesses : ce que votre IA "se souvient" peut vous coûter cher

De plus en plus de PME franchissent le pas : elles connectent leur IA à leurs propres documents. Contrats, fiches produits, notes internes, procédures RH, historiques clients — tout ça devient la mémoire de l'assistant. Résultat : un chatbot capable de répondre à des questions précises sur votre activité, en temps réel, sans avoir à tout retaper à la main.

C'est ce qu'on appelle le RAG — Retrieval Augmented Generation. Et franchement, quand c'est bien fait, c'est impressionnant.

Sauf que derrière cette mémoire documentaire se cache une mécanique technique que presque personne ne regarde de près : les vecteurs et les embeddings. Et c'est précisément là que l'OWASP a identifié une famille de vulnérabilités classée 8e risque mondial sur les applications IA — LLM08:2025 : Vector and Embedding Weaknesses.

Si votre PME utilise un assistant IA connecté à vos documents, ou envisage de le faire, cet article vous concerne directement. Cet article fait partie de notre série sur le Top 10 OWASP LLM, après LLM02 – Fuite de données sensibles, LLM04 – Data Poisoning et LLM07 – System Prompt Leakage.

RAG, vecteurs, embeddings : trois mots techniques traduits en clair

Qu'est-ce qu'un système RAG et pourquoi les PME l'utilisent-elles ?
RAG signifie Retrieval Augmented Generation. C'est une architecture qui permet à une IA d'aller chercher des informations dans une base documentaire avant de répondre — comme un employé qui consulte ses dossiers avant de vous rappeler. Concrètement : vous fournissez vos documents à l'IA, elle les "digère", et peut ensuite répondre à des questions précises en s'appuyant dessus.

Pour stocker et retrouver ces documents efficacement, le système utilise ce qu'on appelle des embeddings — des représentations mathématiques du contenu de chaque document, sous forme de coordonnées dans un espace multidimensionnel. Ces coordonnées sont stockées dans une base vectorielle. Ça semble très abstrait, mais en pratique c'est simple : chaque document devient une sorte d'empreinte digitale, et la base vectorielle est le classeur dans lequel ces empreintes sont rangées.

Le problème ? Ce classeur n'est pas toujours bien verrouillé.

Ce que contient vraiment votre base documentaire IA

Avant de parler de failles, il faut comprendre ce qui entre dans cette base. Et c'est souvent là que les PME sous-estiment le sujet.

Quand on met en place un assistant IA documentaire, on y intègre naturellement les fichiers "utiles" : catalogues produits, tarifs, procédures internes, fiches techniques. Mais avec le temps, on y glisse aussi des choses plus sensibles — parfois sans le réaliser : des contrats clients, des conditions négociées au cas par cas, des notes de réunion avec les retours terrain de l'équipe commerciale, des documents RH ou des échanges internes consignés dans des notes de synthèse.

Voilà ce que votre IA "sait". Et si la base n'est pas correctement cloisonnée, protégée et surveillée — tout ça peut être exposé, détourné ou falsifié.

Le risque documenté par l'ANSSI dans ses recommandations sur les systèmes d'information est clair : toute donnée stockée dans un système accessible par réseau doit faire l'objet de contrôles d'accès, de journalisation et de supervision — sans exception. Les bases vectorielles ne dérogent pas à cette règle, même si elles reposent sur des technologies récentes.

Les cinq failles identifiées par l'OWASP sur les systèmes RAG

1. Comment une base RAG mal configurée expose-t-elle vos données ? (Accès non autorisé)

C'est la faille la plus directe. Si les contrôles d'accès sur la base vectorielle sont absents ou mal configurés, n'importe qui — un utilisateur interne non habilité ou un attaquant externe — peut interroger la base et récupérer des informations confidentielles. En pratique, ça ressemble à un collaborateur qui pose une question anodine au chatbot et obtient en retour des éléments qui ne le concernent pas : les tarifs d'un autre client, les salaires d'un autre service, les notes d'un autre projet.

Ce risque est directement lié à ce qu'on a documenté dans notre article sur la fuite de données sensibles via les LLM : sans cloisonnement strict, votre IA peut devenir un moteur de recherche interne accessible à tous. Et lorsqu'une injection de prompt (LLM01) vient s'y greffer, l'attaquant peut forcer l'IA à restituer des documents qu'elle n'aurait jamais dû partager.

2. Que risquez-vous si votre outil RAG est mutualisé avec d'autres entreprises ? (Contamination entre contextes)

Beaucoup d'outils RAG sont mutualisés : plusieurs utilisateurs, plusieurs services, parfois plusieurs entreprises partagent la même base ou le même moteur. Dans ces configurations, il existe un risque de "contamination" entre contextes. La requête d'un utilisateur externe peut ramener des fragments issus de vos propres documents si la séparation logique entre les espaces de données n'est pas correctement appliquée par le fournisseur.

Pour les PME qui utilisent des solutions SaaS mutualisées — et elles sont nombreuses — ce risque est particulièrement prégnant. Votre prestataire assure-t-il une isolation stricte de vos données par rapport aux autres clients ?

3. Peut-on reconstituer vos documents à partir de vos embeddings ? (Attaque par inversion)

Celle-là est plus technique, mais elle vaut la peine d'être comprise. Les embeddings sont censés être une représentation abstraite du contenu — pas le contenu lui-même. Sauf que des chercheurs ont démontré qu'il est possible, dans certaines conditions, de reconstruire tout ou partie du texte source à partir de ses seuls embeddings. C'est ce qu'on appelle une attaque par inversion.

En clair : un attaquant qui accède à votre base vectorielle peut potentiellement reconstituer le contenu textuel des documents originaux, même s'il n'a pas accès à vos serveurs de fichiers. Voler vos coordonnées mathématiques revient à voler vos documents en clair. Ce n'est plus de la science-fiction.

4. Qu'est-ce qu'un document empoisonné dans une base RAG ? (Data Poisoning)

Ça, c'est le scénario qui illustre le mieux pourquoi LLM08:2025 est une menace concrète. Un attaquant — ou un utilisateur interne malveillant — glisse dans la base documentaire un fichier contenant des instructions cachées (du texte blanc sur fond blanc ou des métadonnées invisibles dans un PDF). Ce document est "digéré" par le système RAG et ses fausses instructions s'intègrent dans la mémoire de l'IA.

Résultat : l'IA commence à donner de mauvaises réponses, à orienter les utilisateurs dans la mauvaise direction, ou à exécuter des actions non souhaitées. C'est une variante de ce qu'on a documenté dans notre article sur le data poisoning IA, appliquée spécifiquement aux bases documentaires RAG.

5. Peut-on manipuler les vecteurs pour aveugler votre IA ? (Vulnérabilité des algorithmes de recherche)

La dernière faille touche à la mécanique même de la recherche vectorielle. Pour trouver la bonne information, le système calcule la "proximité" mathématique entre votre question et les documents. Un attaquant peut exploiter les faiblesses de ces algorithmes de recherche de similarité pour manipuler l'espace vectoriel. Il peut ainsi forcer l'IA à ignorer des documents critiques (comme une alerte de sécurité ou une procédure d'exclusion) ou, au contraire, fausser la pertinence des résultats pour faire remonter de fausses informations en priorité.

Ce que vous pouvez faire : Testez régulièrement votre assistant IA avec un jeu de questions représentatives de vos usages réels. Si les documents pertinents cessent soudainement de remonter ou si des anomalies de ciblage apparaissent, c'est le signal d'une dérive ou d'une manipulation de votre index vectoriel. Ce suivi doit être formalisé dans une procédure de recette IA régulière.

Usages RAG courants en PME et niveau d'exposition associé

Le piège le plus fréquent en PME : la base documentaire sans contrôle d'accès

Soyons directs : dans la majorité des déploiements RAG que nous voyons en PME, la base documentaire est configurée avec un accès global. Tout le monde voit tout. Parfois, c'est un choix délibéré de simplicité. Le plus souvent, c'est parce que personne n'a posé la question.

Le problème, c'est que les assistants documentaires IA ne font pas naturellement la distinction entre ce qu'un utilisateur a le droit de voir et ce qu'il ne devrait pas voir. Ils répondent à la question posée en cherchant dans toute la base. Si un collaborateur pose une question sur les processus d'achat et que la base contient les fiches de paie de l'équipe dirigeante, il y a un risque réel que ces informations ressortent dans la réponse.

C'est une violation directe du principe du moindre privilège appliqué à l'IA : chaque utilisateur ne doit avoir accès qu'aux documents auxquels son rôle lui donne droit — pas à l'ensemble de la base. Et ce cloisonnement doit être appliqué au niveau du système de stockage des vecteurs, pas simplement confié à la bonne volonté du modèle de langage.

Ce type de configuration défaillante fait directement écho aux risques de cyberattaques exploitant les outils IA — des attaques de plus en plus ciblées sur les couches d'intégration documentaire.

Ce qu'on met en place concrètement pour sécuriser un système RAG

1. Cloisonner la base vectorielle par profil utilisateur. C'est le prérequis non négociable. La base documentaire doit être partitionnée : chaque groupe d'utilisateurs n'accède qu'aux documents qui lui sont attribués. Cette segmentation doit être gérée au niveau du moteur de recherche vectoriel via des solutions dites permission-aware (qui se synchronisent nativement avec les droits d'accès de votre entreprise comme SharePoint ou Google Drive). Si votre prestataire ne l'a pas configuré ainsi, c'est à corriger en priorité.
2. Valider et auditer chaque document avant intégration. Tout fichier ajouté à la base documentaire doit passer par une vérification : extraction du texte brut (pour détecter le texte caché), analyse du contenu et validation de la source. Un document mal contrôlé peut devenir un vecteur d'empoisonnement. Ce processus s'inscrit dans la logique de sécurisation de la chaîne d'approvisionnement IA que nous avons documentée dans cette série.
3. Étiqueter et classifier les documents par niveau de confidentialité. Tous les documents n'ont pas le même niveau de sensibilité. Les mettre sur un pied d'égalité dans une base RAG est une erreur. Définissez des catégories (public, interne, confidentiel, restreint) et appliquez ces classifications dans la base vectorielle pour contrôler quels segments sont interrogeables selon l'identité du demandeur.
4. Mettre en place une journalisation complète des requêtes. Chaque interrogation de la base vectorielle doit générer un log précis : qui a demandé quoi, quel document a été récupéré, à quelle heure. Ces traces sont indispensables pour détecter un comportement anormal — un utilisateur qui interroge massivement des zones confidentielles, par exemple. C'est exactement le périmètre de surveillance couvert par un service MDR.
5. Réviser régulièrement le contenu de la base. La base documentaire n'est pas un coffre qu'on ferme après remplissage. Des documents périmés, des informations obsolètes ou des fichiers oubliés s'y accumulent. Une revue périodique — au minimum trimestrielle — permet de purger ce qui ne devrait plus y être et de vérifier l'intégrité du contenu. Ce sujet est directement lié au cycle de vie des données.
6. Faire auditer la configuration de votre système RAG. Si vous avez déployé ou envisagez de déployer un assistant documentaire IA, un audit de conformité de l'intégration permettra de vérifier le cloisonnement des accès, la validation des documents, la journalisation des requêtes et la résistance aux tentatives d'empoisonnement.

Ce que disent le RGPD, NIS2 et l'EU AI Act sur les systèmes RAG

RGPD : les données personnelles dans une base RAG sont un traitement à risque

Si votre base documentaire contient des données permettant d'identifier des personnes — et c'est presque inévitable dès qu'on y intègre des documents clients, des fiches RH ou des contrats — vous êtes soumis aux obligations du RGPD. Cela inclut : une Analyse d'Impact sur la Protection des Données (AIPD) si le traitement est jugé à risque élevé, des mesures de sécurité adaptées, et en cas de fuite, une notification à la CNIL sous 72 heures. La CNIL rappelle régulièrement que les outils d'IA intégrant des données personnelles entrent pleinement dans le périmètre de ses contrôles.

NIS2 : la base documentaire comme composant critique

Dans le cadre de la directive NIS2, toute composante de votre système d'information susceptible de contenir ou de traiter des données sensibles est un composant à risque. Une base vectorielle mal sécurisée — accessible sans authentification stricte, non journalisée, non supervisée — constitue une non-conformité majeure. Cybermalveillance.gouv.fr recommande aux organisations de cartographier l'ensemble de leurs assets numériques, y compris les nouvelles couches IA, pour évaluer leur exposition.

EU AI Act : des obligations strictes et immédiates

Le règlement européen sur l'IA impose des exigences strictes de robustesse, de résistance aux attaques et de traçabilité. Un système RAG utilisé dans un contexte RH, commercial ou financier structurant entre directement sous le coup de ces obligations. L'absence de contrôle d'accès et de journalisation sur la base vectorielle constitue un défaut de conformité grave, exposant l'entreprise à des sanctions d'ores et déjà applicables.

Ce qu'il faut retenir

• LLM08:2025 concerne tous les systèmes IA qui s'appuient sur une base documentaire (RAG) — chatbots, assistants internes, moteurs de recherche documentaire.
• Les cinq risques principaux sont : la fuite de données par accès non autorisé, la contamination entre contextes utilisateurs, la reconstitution de documents via l'inversion d'embeddings, l'empoisonnement de la base et la manipulation des algorithmes de recherche.
• Le piège le plus fréquent en PME est la base documentaire sans cloisonnement par profil : tout le monde peut interroger l'intégralité des fichiers.
• La protection passe par la segmentation des accès, la validation des documents, la classification des données et la journalisation des requêtes.
• Le RGPD, la directive NIS2 et l'EU AI Act imposent de sécuriser ces systèmes et engagent votre responsabilité en tant que dirigeant.
• Ce que votre IA "sait" sur votre entreprise n'est sécurisé que si la base vectorielle dans laquelle elle puise l'est aussi.

Conclusion : votre IA est aussi sûre que sa mémoire

On investit souvent beaucoup d'attention dans l'interface de l'IA — le chatbot, l'assistant, l'expérience utilisateur. Et on oublie ce qui se passe en coulisses : la base documentaire qui l'alimente, le moteur qui la fait tourner, les droits d'accès qui la gouvernent. C'est pourtant là que se jouent les vraies questions de sécurité.

LLM08:2025 n'est pas un risque réservé aux équipes techniques. C'est un risque de gouvernance des données, de contrôle des accès et de cycle de vie documentaire. Des sujets que tout dirigeant doit maîtriser — même sans savoir ce qu'est un embedding.

La bonne nouvelle : sécuriser un système RAG n'est pas une opération extraordinaire. C'est une question de configuration rigoureuse, d'audit et de supervision continue. Exactement ce qu'on fait avec les autres systèmes critiques de votre SI.

Vous avez déployé un assistant documentaire IA dans votre PME, ou vous y réfléchissez ? Nos experts basés à Paris peuvent réaliser un diagnostic de votre configuration RAG et identifier les points d'exposition avant qu'ils ne soient exploités.