Les défaillances du RAG peuvent commencer avant même la recherche : documents obsolètes, tableaux mal restitués, sources sans responsable, métadonnées d’autorisation perdues, vecteurs non supprimés, couches de texte cachées contradictoires ou fichiers dangereux.
L’ingestion sécurisée des documents permet de maîtriser les sources de connaissances de l’entreprise. Elle détermine ce qui entre dans le système de recherche, qui peut y accéder, comment la fraîcheur des sources est suivie, comment les suppressions sont propagées et comment les entrées défectueuses sont détectées.
Cet article couvre la couche d’ingestion : PDF, OCR, métadonnées, autorisations, conservation et vérifications opérationnelles.
Si un utilisateur ne doit pas accéder à un document dans le système source, il ne doit pas davantage accéder à ses fragments, à ses représentations vectorielles, à ses résumés ni aux réponses mises en cache dans le système RAG. Les métadonnées d’autorisation sont obligatoires.
Le pipeline d’ingestion
Un pipeline de production doit comporter des étapes explicites :
- Enregistrement de la source.
- Classification des données.
- Vérifications de sécurité des fichiers.
- Extraction du texte et OCR.
- Préservation de la structure.
- Association des métadonnées.
- Mappage des autorisations.
- Fragmentation et vectorisation.
- Vérifications de qualité.
- Publication de l’index.
- Gestion de la conservation et de la suppression.
- Responsabilité opérationnelle.
Les outils exacts peuvent varier. Les points de contrôle ne doivent pas changer.
Étape 1 : enregistrement de la source
N’ingérez pas des dossiers choisis au hasard au seul motif qu’ils sont faciles à connecter.
Pour chaque source, enregistrez :
- le nom de la source,
- le système de référence,
- le responsable de la source,
- le responsable des données,
- les utilisateurs ou rôles autorisés,
- les types de documents,
- le niveau de sensibilité,
- la règle de conservation,
- la fréquence de mise à jour,
- le comportement en cas de suppression,
- le calendrier de revue.
Exemples de sources :
- centre d’aide public,
- manuel interne d’assistance,
- supports commerciaux,
- contrats clients,
- politiques des ressources humaines,
- manuels techniques d’ingénierie,
- documentation produit,
- transcriptions de réunions.
Ces sources ne doivent pas toutes atterrir dans le même index avec les mêmes autorisations.
Étape 2 : classez les données avant l’extraction
Classez la source avant que le modèle ou le fournisseur du service de vectorisation n’en voie le contenu.
Classes utiles :
| Classe | Exemple | Posture par défaut |
|---|---|---|
| Publique | documents publiés, pages marketing | Autorisé pour une recherche large |
| Interne | manuels, documents de processus | Entreprise uniquement, filtré par rôle |
| Confidentiel | contrats, détails clients, finance | Rôles restreints, journalisation renforcée |
| Réglementé ou sensible | santé, droit, RH, paie, incidents de sécurité | À éviter sauf approbation explicite |
La classification n’est pas une simple formalité de conformité. Elle détermine si le contenu peut être envoyé à une API de vectorisation hébergée, stocké dans une base vectorielle partagée, inclus dans les journaux ou utilisé dans des exemples d’évaluation.
Étape 3 : vérifications de sécurité des fichiers
Les documents peuvent être hostiles ou simplement défectueux.
Avant l’extraction :
- vérifiez le type de fichier par rapport à une liste d’autorisation,
- appliquez les limites de taille de fichier,
- analysez les fichiers pour détecter les logiciels malveillants si votre environnement l’exige,
- rejetez les fichiers chiffrés sauf s’il existe un processus de déchiffrement approuvé,
- rejetez les fichiers avec des objets intégrés non pris en charge,
- normalisez les noms de fichiers,
- stockez le hachage du fichier original,
- enregistrez qui a téléversé ou connecté le fichier.
Ces contrôles sont particulièrement importants si des utilisateurs sans droits d’administration peuvent importer des documents. Réserver l’ingestion aux administrateurs réduit une voie d’attaque, mais ne rend pas sûr un document compromis, malveillant, surdimensionné ou malformé. Les connecteurs et l’ingestion d’URL exigent aussi une liste d’origines autorisées, des contrôles des redirections et du DNS, des droits d’authentification limités au strict nécessaire, des limites de débit et des tests contre les attaques SSRF.
Si des utilisateurs non fiables peuvent téléverser des fichiers, mettez en place une couche de sécurité avant leur analyse. Prenez comme référence la fiche pratique OWASP sur le téléversement de fichiers, maintenue à jour, et modélisez les menaces propres aux analyseurs retenus et au parcours de stockage. Pour le modèle de menace plus large du RAG — empoisonnement, fuite liée aux autorisations, injection de prompt et sorties non sécurisées — consultez aussi la fiche pratique OWASP sur la sécurité du RAG.
Les contrôles possibles comprennent une liste d’autorisation des types de fichiers vérifiés à partir du contenu, des limites de taille et d’expansion des archives, des noms de stockage aléatoires, la recherche de signatures malveillantes, une analyse isolée sans accès réseau sortant et avec des ressources limitées, ainsi que le désarmement et la reconstruction du contenu lorsque le modèle de menace le justifie. Aucun outil d’analyse ne peut, à lui seul, établir qu’un fichier est sûr.
Étape 4 : extraction du texte et OCR
En pratique, tous les PDF ne se ressemblent pas. Certains contiennent du texte sélectionnable, d’autres des pages numérisées. Ils peuvent aussi comporter des colonnes, des tableaux, des notes de bas de page, des formulaires, des commentaires, des tampons ou des couches de texte cachées.
Choisissez la méthode d’extraction selon le type de document : comparez les extracteurs privilégiant le texte pour les PDF numériques natifs, les convertisseurs qui tiennent compte de la mise en page pour les documents structurés et l’OCR pour les pages numérisées. Le choix doit reposer sur une mesure de la précision de la mise en page et des tableaux, la prise en charge des langues, la licence, le processus de mise à jour corrective et le périmètre autorisé pour les données.
Pour les seuils, n’adoptez pas une valeur universelle de confiance de l’OCR trouvée dans un article de blog : étalonnez-la sur un échantillon de vos propres documents. Une méthode utile consiste à définir deux seuils. En dessous du seuil inférieur, la page est rejetée ; entre les deux, elle est envoyée en validation humaine ; au-dessus du seuil supérieur, elle est acceptée automatiquement. Ces valeurs dépendent de votre scanner, de l’âge des documents et de leur langue.
Pour les archives estoniennes et multilingues, incluez dans l’évaluation des signes diacritiques, d’anciennes pages dactylographiées, des tableaux, des tampons ainsi que des exemples en estonien et en russe. Vérifiez que le moteur OCR retenu dispose des données linguistiques nécessaires, puis mesurez la précision au niveau des caractères, des mots, des champs et des tableaux sur des pages représentatives. Ne promettez pas de durée universelle pour un pilote.
Suivez la qualité d’extraction :
- méthode d’extraction,
- confiance OCR,
- nombre de pages,
- nombre de caractères extraits,
- statut d’extraction des tableaux,
- langue détectée,
- pages sans texte,
- avertissements de l’analyseur.
Une extraction de mauvaise qualité ne doit pas entrer discrètement dans l’index. Envoyez-la en validation ou marquez-la comme peu fiable.
Problèmes courants :
- colonnes lues dans le mauvais ordre,
- lignes de tableaux fusionnées incorrectement,
- en-têtes répétés dans chaque fragment,
- pages numérisées entièrement manquantes,
- notes manuscrites ignorées,
- couche de texte cachée en contradiction avec la page numérisée visible,
- OCR convertissant incorrectement les numéros de compte.
Pour les documents à forte valeur, contrôlez par sondage la page rendue par rapport au texte extrait.
Étape 5 : préservez la structure
Les systèmes RAG ont besoin de plus que du texte. Ils ont besoin d’assez de structure pour produire des réponses utiles et ancrées dans la source.
Préservez :
- le titre,
- la hiérarchie des titres,
- le numéro de section,
- le numéro de page,
- les légendes de tableaux,
- les limites des listes,
- la version du document,
- la date d’effet,
- l’URL source ou le chemin de stockage.
Conservez les titres et les références de page dans chaque fragment. Un fragment qui dit « Ce qui suit s’applique » sans le titre qui le précède constitue un élément probant faible.
Pour les tableaux, décidez si vous devez :
- conserver le tableau au format Markdown,
- le convertir en JSON structuré,
- stocker à la fois le texte et les lignes structurées,
- l’exclure jusqu’à ce qu’un meilleur analyseur soit disponible.
Ne prétendez pas que l’extraction de tableaux est résolue si votre cas d’utilisation dépend de prix, de dates, de limites ou de seuils exacts.
Étape 6 : associez les métadonnées
Chaque fragment doit porter des métadonnées qui restent disponibles lors de la recherche :
{
"sourceId": "policy-2026-expenses",
"documentId": "doc_123",
"tenantId": "tenant_a",
"visibility": "internal",
"allowedRoles": ["finance", "leadership"],
"sensitivity": "confidential",
"sourceOwner": "Finance",
"version": "2026-02",
"lastReviewedAt": "2026-02-10",
"effectiveFrom": "2026-03-01",
"page": 7,
"headingPath": ["Travel", "Hotel limits"],
"contentHash": "sha256:..."
}
Les métadonnées fournissent les données nécessaires à l’application des règles, mais ne les font pas respecter à elles seules. L’application doit vérifier que ces métadonnées proviennent d’une source fiable et appliquer les autorisations lors de la publication, de la recherche, de la mise en cache, de la citation, de la génération et de l’exportation.
Étape 7 : mappage des autorisations
Les autorisations doivent être appliquées avant que les résultats de recherche n’atteignent le modèle, puis vérifiées de nouveau lors de toute réponse, citation, mise en cache ou exportation si l’identité ou les règles ont pu changer.
Bonne pratique :
- L’utilisateur pose une question.
- L’application déduit de l’authentification l’organisation cliente, l’utilisateur, ses rôles, ses groupes et ses autorisations d’accès aux données.
- Le module de recherche filtre les fragments possibles selon ces autorisations.
- Le classement s’effectue au sein des fragments autorisés.
- Le modèle ne reçoit que les fragments autorisés.
Mauvaise pratique :
- Récupérer largement.
- Envoyer au modèle tous les fragments susceptibles d’être pertinents.
- Indiquer dans le prompt : « Répondez uniquement à partir des fragments auxquels l’utilisateur a accès. »
La mauvaise pratique a déjà exposé les données au contexte du modèle.
Si les autorisations du système source sont complexes, commencez avec un périmètre plus étroit. Mieux vaut manquer une réponse que divulguer un document confidentiel.
Étape 8 : fragmentation et vectorisation
La fragmentation relève de la sécurité et de la qualité, pas seulement du réglage de la recherche.
Directives :
- Maintenez les fragments à l’intérieur de leur périmètre d’autorisation.
- Ne fusionnez pas du texte public et confidentiel dans un même fragment.
- Incluez les en-têtes et références source.
- Évitez les fragments géants qui réunissent des sections sans rapport.
- Évitez les fragments trop petits qui perdent leur contexte.
- Recalculez les vecteurs lorsque le texte source ou les métadonnées changent.
- Consignez le modèle de vectorisation et sa version.
Pour les sources sensibles, confirmez que le fournisseur du service de vectorisation, la base vectorielle et les journaux sont approuvés pour cette classe de données.
Étape 9 : contrôles de qualité
Avant de publier une source dans le RAG de production, exécutez des vérifications :
- tous les documents ont un responsable,
- tous les fragments ont des métadonnées d’autorisation,
- les documents obsolètes sont signalés,
- les pages dont l’extraction a échoué sont exclues ou validées,
- les questions échantillon récupèrent les sources attendues,
- les utilisateurs non autorisés ne récupèrent aucun fragment restreint,
- les documents supprimés disparaissent de la recherche,
- les citations pointent vers des emplacements source valides,
- les instructions suspectes dans les documents sont isolées comme contenu, pas suivies.
Le dernier point est important. Les documents peuvent contenir une injection de prompt. Le pipeline d’ingestion ne doit pas supprimer discrètement ce texte : les utilisateurs peuvent avoir besoin de connaître le contenu réel du document, et sa suppression peut altérer les éléments probants. À l’exécution, le contenu récupéré doit rester dans un canal de données ; il ne doit ni donner accès à des outils ni modifier les règles. Validez indépendamment les arguments transmis aux outils et exigez une approbation humaine pour les actions lourdes de conséquences.
Étape 10 : publiez une version de l’index de façon atomique
Ne laissez ni des documents partiellement ingérés ni un mélange d’anciennes et de nouvelles autorisations se retrouver dans l’index actif. Construisez un index candidat ou un espace de noms versionné, puis :
- figez le manifeste source/version et les hachages de contenu ;
- vérifiez le nombre de documents, les échecs d’extraction, la couverture des autorisations, la politique de déduplication, le modèle et la version de vectorisation, ainsi qu’un échantillon représentatif de requêtes autorisées et interdites ;
- consignez la version candidate, les versions des sources, le résultat du test, la personne qui a approuvé et la version cible en cas de retour arrière ;
- faites basculer de manière atomique un alias ou un pointeur de l’application vers la version approuvée, lorsque la base le permet ;
- invalidez ou versionnez les caches de recherche et de réponse ;
- surveillez les erreurs, les refus d’accès, les recherches sans résultat et le trafic vers une version obsolète après la mise en service.
Si la base vectorielle ne peut pas changer de version de façon atomique, mettez en place côté application un état de publication qui exclut les enregistrements incomplets et testez les lectures concurrentes pendant la mise en service. La révocation d’une autorisation ou la suppression urgente d’une source ne doit pas attendre une reconstruction complète : appliquez les autorisations actuelles en dehors de l’index, bloquez immédiatement la source concernée, purgez les caches correspondants et terminez le nettoyage des données dérivées par le processus de cycle de vie.
Le retour arrière doit restaurer le dernier pointeur d’index approuvé sans rétablir un accès révoqué ni des données supprimées. Vérifiez qu’il ne réactive pas une liste de contrôle d’accès obsolète, un document supprimé, une source empoisonnée ou une ancienne réponse mise en cache.
Étape 11 : conservation et suppression
Les systèmes RAG conservent souvent accidentellement les données plus longtemps que le système source.
L’article 17 du RGPD prévoit un droit à l’effacement assorti de conditions et d’exceptions. Un professionnel qualifié doit déterminer l’obligation applicable et les éventuelles durées de conservation légales. Le système doit néanmoins inventorier chaque copie et chaque donnée dérivée, et leur appliquer un processus de cycle de vie :
- cache du fichier original,
- texte extrait,
- fragments,
- vecteurs,
- résumés,
- vignettes ou pages rendues,
- échantillons d’évaluation,
- journaux, avec des règles approuvées de minimisation et de conservation,
- sauvegardes, avec expiration documentée et comportement de restauration.
Lorsqu’un document est supprimé ou que son accès est révoqué, les caches de recherche et de réponses doivent cesser de le renvoyer dans le délai documenté. Le processus de suppression doit couvrir les stockages dérivés et empêcher qu’une ancienne sauvegarde ou une tâche d’ingestion différée ne rétablisse l’enregistrement.
Suivez :
- deletedAt,
- deletedBy ou événement source,
- raison de la suppression,
- statut du nettoyage en aval,
- résultat de vérification.
Ne vous contentez pas de dire : « Nous l’avons retiré de l’interface utilisateur. » Les bases vectorielles et les caches sont faciles à oublier.
Étape 12 : responsabilité opérationnelle
Chaque source de production doit avoir un responsable désigné ainsi qu’un événement déclencheur ou une fréquence de revue définis selon son rythme de changement et son impact.
Pour chaque source, définissez :
- qui approuve l’ingestion,
- qui approuve les changements d’autorisation,
- qui révise les documents obsolètes,
- qui gère les échecs d’extraction,
- qui répond aux demandes de suppression de données,
- qui enquête sur les erreurs de recherche.
Si personne n’est responsable d’une source, elle ne devrait pas se trouver dans un système RAG de production.
Gouvernance des sources, pas de garanties
L’ingestion sécurisée pour le RAG est une gouvernance délibérée des sources. Elle rend le comportement et les échecs de recherche plus observables et plus faciles à tester, mais ne rend pas les réponses générées intrinsèquement correctes ou sûres.
Les contrôles principaux :
- enregistrez les sources,
- classez les données,
- vérifiez les fichiers avant leur analyse,
- mesurez la qualité d’extraction,
- préservez la structure,
- associez les métadonnées,
- appliquez les autorisations avant la recherche,
- testez l’accès non autorisé,
- prenez en charge la suppression,
- désignez des responsables.
La qualité et les contrôles des sources sont nécessaires à la qualité et à la sécurité des réponses, mais ne les garantissent pas. Validez de bout en bout la recherche, les autorisations, l’ancrage dans les sources, le refus, l’utilisation des outils et le comportement du cycle de vie.
