RAG sur documents sensibles : comment définir le périmètre de données

Pour un RAG sur des documents sensibles, le périmètre de données ne se résume pas à une liste de dossiers connectés. Il doit préciser quelle tâche est assistée, quels documents peuvent être recherchés, qui peut les consulter, quelles transformations sont admises et comment un changement ou un retrait devient effectif. Sans ce dossier de décision, l’équipe ne peut ni limiter le pilote, ni expliquer une réponse, ni étendre le système de façon maîtrisée.

En bref

• Commencez par la tâche et la population autorisée. Un connecteur ne définit pas un usage acceptable à lui seul.
• Décrivez chaque source jusqu’aux sorties du système : document, extraction, chunks, index, contexte envoyé au modèle, réponse et traces.
• Séparez les données admises, exclues, conditionnelles et en attente de décision. Un document indexable n’est pas automatiquement exploitable dans tous les parcours.
• Testez les cas de retrait, de changement de droits et d’absence de source avant d’ouvrir un périmètre plus large.

Ici, « sensible » désigne une information dont l’exposition, la mauvaise interprétation ou la conservation excessive peut créer un impact important pour l’organisation ou les personnes. Cela peut recouvrir des secrets d’affaires, des éléments RH, des données financières, des informations juridiques ou des données personnelles. Cette qualification de travail ne remplace pas une qualification juridique ou une politique de classification propre à l’organisation.

Pourquoi une liste de documents ne suffit-elle pas ?

Un même document peut être utile à une équipe, réservé à un autre rôle, obsolète, partiellement diffusable ou autorisé seulement dans un contexte donné. Le transformer en chunks et le rendre recherché ajoute aussi de nouveaux lieux où sa portée doit rester comprise : extraction, métadonnées, index, contexte de génération, citations, journaux et sauvegardes.

Le bon objet de travail n’est donc pas un inventaire de connecteurs. C’est une fiche qui permet de répondre à une question opérationnelle : « cette information peut-elle être utilisée par ce système, pour cette tâche, par cette personne, dans cette étape de la chaîne ? »

La CNIL recommande de partir de l’objectif du système, du contexte d’utilisation, des contextes exclus, des sources mobilisées et des données strictement nécessaires. Ses fiches concernent la conception et le développement de systèmes d’IA impliquant des données personnelles. Pour un RAG déjà envisagé en déploiement, elles ne remplacent pas l’analyse applicable au cas concret, mais donnent une discipline utile pour éviter de partir du volume disponible plutôt que du besoin réel.

Quelles huit dimensions faut-il décider avant l’indexation ?

Une fiche de périmètre de données peut rester courte. Elle doit toutefois couvrir les décisions qui changent réellement ce que le système voit ou restitue.

Dimension	Décision à écrire	Exemple de preuve à conserver
Tâche	Quelle recherche ou préparation de réponse est assistée ?	Description de tâche validée par le propriétaire métier
Population	Quels rôles utilisent le RAG et dans quel contexte ?	Rôles, espaces et cas d’usage exclus
Source	Quel système fait autorité pour le document et ses droits ?	Propriétaire, identifiant, version et statut de publication
Catégories	Quelles familles de données sont admises, conditionnelles ou exclues ?	Classification interne et motifs de décision
Transformations	Quelles étapes sont autorisées : OCR, extraction, chunking, enrichissement, résumé ?	Diagramme de flux et règles de traitement
Accès	Comment les droits de la source limitent-ils la récupération et les citations ?	Règle d’autorisation et scénarios de refus
Sorties et traces	Que peut contenir une réponse, une citation, un journal ou un feedback ?	Contrat de réponse et politique de journalisation
Cycle de vie	Comment gérer la mise à jour, le retrait, la rétention et les incidents ?	Déclencheur, propriétaire et test de révocation

Cette fiche doit être spécifique à un cas d’usage. « Documentation interne » est une étiquette trop large. Elle ne dit rien sur les versions applicables, les règles d’accès, les pièces jointes, les brouillons, les décisions en cours ou les informations qui ne doivent pas quitter une équipe.

Comment classer les sources sans créer un registre abstrait ?

Pour chaque source candidate, attribuez un statut d’usage plutôt qu’un simple indicateur « connecté » :

1. Admise. La source est utile au cas d’usage, son propriétaire est identifié et ses règles peuvent être appliquées puis testées.
2. Admise sous condition. Une restriction doit être respectée, par exemple un périmètre de rôles, une partie du corpus, une validation métier ou un traitement de données spécifique.
3. Exclue. Le contenu ne sert pas la tâche, son statut est incertain ou son exposition créerait un risque non accepté pour ce pilote.
4. En attente de décision. L’équipe n’a pas encore la réponse sur le propriétaire, le cycle de vie, les droits, les transformations ou le chemin de retrait.

Ce classement évite une erreur fréquente : traiter l’absence de décision comme une autorisation temporaire. Un pilote peut avancer avec un corpus réduit. Il ne devrait pas absorber silencieusement les sources qui n’ont pas encore de propriétaire ou de règle vérifiable.

La méthode de cadrage d’un projet RAG aide à rattacher ce choix à une décision métier. Le périmètre de données en est le volet concret : il rend visible ce que le prototype est autorisé à apprendre du corpus et ce qu’il doit ignorer.

Comment suivre un document dans toute la chaîne RAG ?

Un document peut être autorisé dans son application d’origine sans être autorisé dans toutes les représentations créées pour le RAG. Cartographiez donc le trajet complet avant de brancher un modèle :

1. Lecture par le connecteur. Quelle identité lit la source et avec quelle portée ?
2. Extraction et normalisation. Quel texte, tableau, métadonnée ou pièce jointe est conservé après conversion ?
3. Découpage et enrichissement. Quels chunks sont produits et à quel document, version et règle d’accès restent-ils rattachés ?
4. Indexation et récupération. Quel filtre limite les résultats au rôle qui pose la question ?
5. Contexte de génération. Quels passages peuvent être transmis au modèle pour répondre ?
6. Réponse et citation. Qu’est-ce qui peut être reformulé, affiché ou référencé à l’utilisateur ?
7. Traces et retours. Quels éléments sont conservés pour diagnostiquer un écart, avec quels accès et quelle durée ?

Cette carte transforme une discussion vague sur la confidentialité en contrôles testables. Si l’équipe ne sait pas où un passage est stocké, transmis ou réutilisé, elle ne peut pas démontrer qu’un retrait ou une restriction a pris effet.

Les recommandations de sécurité de l’ANSSI sur les systèmes d’IA générative rappellent que l’architecture comprend plusieurs populations, des composants de récupération, des filtres et des connexions à des ressources métier. Elles portent sur la sécurité de l’architecture, et non sur l’ensemble des questions de vie privée ou de protection des données. Il faut donc organiser ces deux lectures sans les confondre.

Comment décider ce qui est exclu du premier pilote ?

Le premier corpus ne doit pas viser la couverture maximale. Il doit permettre de tester une tâche utile, des sources réalistes et les limites du système. Préférez des exclusions explicites aux promesses de traitement ultérieur.

Une source peut être exclue du pilote lorsqu’au moins une question reste sans réponse :

• le propriétaire métier ne confirme pas son usage pour la tâche choisie ;
• la version qui fait autorité n’est pas identifiable ;
• les droits ne peuvent pas être propagés ou vérifiés sur des cas de refus ;
• le document contient une catégorie de données qui exige une décision ou une revue non encore obtenue ;
• l’équipe ne sait pas comment retirer le contenu, ses chunks et ses représentations dérivées ;
• la qualité du contenu ne permet pas de distinguer une information applicable d’un brouillon, d’une note préparatoire ou d’une version remplacée.

Cette règle ne signifie pas qu’une source exclue est définitivement inutilisable. Elle signifie qu’elle ne doit pas devenir un effet de bord du premier connecteur activé. Un pilote réduit peut produire une décision plus défendable qu’un index volumineux dont personne ne maîtrise les frontières.

Pourquoi les droits d’accès ne remplacent-ils pas le périmètre ?

Un filtre de droits est nécessaire, mais il répond à une seule partie de la décision : qui peut récupérer quoi. Il ne répond pas seul à ces questions : cette source est-elle pertinente pour la tâche, cette version est-elle encore applicable, la réponse peut-elle citer ce passage, le contenu peut-il être transmis à un service externe ou conservé dans les traces ?

Documentez d’abord la règle métier, puis le chemin technique qui l’applique. Notre guide sur les choix d’architecture de contrôle d’accès dans un RAG détaille les éléments à relier entre identité, source, index, refus, révocation et audit. La fiche de périmètre complète ce travail en décidant quels objets ont le droit d’entrer dans cette chaîne.

Quand associer les fonctions sécurité et protection des données ?

La réponse dépend de la nature des données, de l’usage et du niveau de risque. Ne transformez pas cette page en avis juridique. En revanche, déclenchez une revue explicite lorsque le périmètre fait apparaître des données personnelles, des informations sensibles ou hautement personnelles, une population vulnérable, des ensembles de données combinés, des décisions qui affectent des personnes, ou une exposition difficile à maîtriser.

La CNIL indique qu’une analyse d’impact relative à la protection des données peut être nécessaire lorsqu’un traitement est susceptible d’engendrer un risque élevé pour les droits et libertés. Elle précise aussi que son appréciation doit évoluer avec les caractéristiques du traitement et les risques observés. Pour un RAG, la fiche de périmètre constitue un support pratique : elle rend lisibles les opérations, les données, les populations, les contrôles et les hypothèses que les fonctions compétentes doivent examiner.

Comment vérifier que le périmètre reste valide en production ?

Le périmètre n’est pas un document de lancement figé. Il doit être rejoué lorsqu’un changement ouvre un nouveau risque ou modifie le comportement observé. Préparez des déclencheurs simples : nouvelle source, nouvelle catégorie de document, nouveau rôle, changement de connecteur, modification de règle d’accès, nouveau fournisseur, évolution de la journalisation ou incident signalé. Pour faire suivre ce changement dans les versions, chunks, index et tests, consultez aussi notre méthode pour versionner, mettre à jour et retirer un document source dans un RAG.

À chaque changement, l’équipe doit pouvoir répondre :

1. quelle décision de périmètre change ;
2. quelles données, utilisateurs et sorties sont affectés ;
3. quels tests de récupération, de refus et de retrait doivent être rejoués ;
4. qui valide l’extension, la limitation ou le retour arrière ;
5. quelle version du corpus et des règles permet d’expliquer le résultat.

Le profil du NIST consacré à l’IA générative propose une approche volontaire de gestion des risques à adapter au contexte, aux objectifs et aux ressources de l’organisation. Cette logique est particulièrement utile ici : le périmètre n’a pas vocation à certifier un système, mais à relier ses risques, ses preuves et ses décisions au cas d’usage réellement ouvert.

Pour vérifier les effets d’un changement sur la récupération, la réponse, les droits, la latence et le coût, utilisez aussi notre méthode pour évaluer un RAG en production. Les tests ne prouvent pas qu’un périmètre est parfait. Ils permettent de constater que les limites déclarées sont encore appliquées.

Quelle preuve faut-il obtenir avant d’ouvrir un corpus plus large ?

Avant d’élargir le périmètre, réunissez au minimum les sept éléments suivants :

1. une tâche et une population clairement décrites ;
2. une liste de sources avec propriétaire, statut, version et règles d’usage ;
3. des exclusions explicites et les raisons associées ;
4. une carte des transformations et des emplacements où le contenu est conservé ou transmis ;
5. une règle d’accès testable, avec des scénarios autorisés et refusés ;
6. un mécanisme de mise à jour et de retrait dont l’effet peut être vérifié ;
7. une décision écrite sur les risques ouverts, les responsables et les conditions d’extension.

Si l’un de ces éléments manque, l’équipe peut encore apprendre avec un périmètre plus limité. Elle ne doit pas présenter le système comme prêt à parcourir l’ensemble de la documentation sensible de l’organisation.

FAQ

• Peut-on indexer un espace documentaire complet pour aller plus vite ?

  Pas par défaut. Commencez par les sources nécessaires à une tâche précise et vérifiez leur propriétaire, leur statut, leurs droits, leurs transformations et leur cycle de vie. Un corpus réduit mais testable aide davantage à décider qu’un ensemble très large dont les limites restent inconnues.

• Les documents qui contiennent des données personnelles doivent-ils être exclus ?

  Pas automatiquement. Leur traitement doit être justifié, limité au besoin, associé aux règles applicables et revu par les fonctions compétentes selon le contexte. Lorsqu’une décision manque, classez la source en attente ou excluez-la du pilote plutôt que de supposer qu’un accès technique suffit.

• Un filtre d’accès dans la base vectorielle suffit-il ?

  Non. Il peut limiter la récupération, mais il ne décide pas si la source est pertinente, à jour, autorisée pour le cas d’usage, transmissible au modèle ou conservable dans les traces. Le périmètre doit couvrir toute la chaîne, de la source à la réponse et au retrait.

• Quand faut-il mettre à jour la fiche de périmètre ?

  À chaque changement qui touche les sources, les catégories de données, les rôles, les droits, les connecteurs, les sorties, les journaux ou les règles de conservation. La mise à jour doit conduire à une revue et à des tests adaptés, pas seulement à une nouvelle date dans un document.

Méthodologie et sources

• CNIL, Tenir compte de la protection des données dans la conception du système, 8 avril 2024, consulté le 21 septembre 2026. La fiche traite notamment de l’objectif, des contextes exclus, des sources, de la minimisation et de la validation des choix de conception pour les systèmes d’IA impliquant des données personnelles.
• CNIL, Réaliser une analyse d’impact si nécessaire, 8 avril 2024, consulté le 21 septembre 2026. La fiche présente les situations où une AIPD peut être requise et son évolution au regard des risques du traitement.
• ANSSI, Recommandations de sécurité pour un système d’IA générative, 29 avril 2024, consulté le 21 septembre 2026. Le guide porte sur la sécurité de l’architecture d’un système d’IA générative, dont les composants de récupération et les ressources métier connectées.
• NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024, consulté le 21 septembre 2026. Ce profil volontaire propose des actions de gouvernance, cartographie, mesure et gestion des risques à adapter au contexte.

Cette page est une méthode de cadrage technique. Elle ne qualifie pas juridiquement les données, ne détermine pas les obligations applicables et ne constitue pas une promesse de sécurité ou de conformité. Les décisions de périmètre doivent être validées avec les responsables métier, sécurité, protection des données et exploitation concernés.

---

Vous devez décider quelles données un RAG peut réellement consulter avant d’ouvrir un connecteur ? Décrivez votre contexte à IgnitionAI. Un premier échange peut aider à transformer les sources, les droits, les exclusions et les preuves attendues en périmètre de décision.