La plupart des défaillances d’un RAG commencent avant la récupération. Le document était obsolète. L’OCR n’a pas reconnu un tableau. La source n’avait pas de responsable. Les métadonnées d’autorisation ont été perdues. Un contrat supprimé subsistait dans la base vectorielle. Un PDF numérisé comportait une couche de texte cachée que personne n’avait vérifiée. Le système a répondu avec assurance parce que le pipeline d’ingestion assimilait « du texte existe » à « ces connaissances peuvent être utilisées sans risque ».
L’ingestion sécurisée des documents contrôle les sources des connaissances de l’entreprise. Elle détermine ce qui entre dans le système de récupération, qui peut y accéder, comment l’actualité est suivie, comment les suppressions sont propagées et comment les entrées défectueuses sont détectées.
Cet article aborde la couche d’ingestion : les PDF, l’OCR, les métadonnées, les autorisations, la conservation et les vérifications opérationnelles.
Si un utilisateur ne doit pas accéder à un document dans le système source, il ne doit pas non plus accéder à ses segments, embeddings, résumés ou réponses mises en cache dans le RAG. Les métadonnées d’autorisation sont indispensables.
Le pipeline d’ingestion
Un pipeline de production doit avoir 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.
- Ajout des métadonnées.
- Cartographie des autorisations.
- Découpage et génération des embeddings.
- Vérifications de qualité.
- Publication de l’index.
- Gestion de la conservation et de la suppression.
Les outils exacts peuvent varier. Les points de contrôle ne doivent pas.
Étape 1 : enregistrement de la source
N’ingérez pas des dossiers au hasard simplement parce qu’ils sont faciles à connecter.
Pour chaque source, enregistrez :
- nom de la source,
- système de référence,
- propriétaire de la source,
- propriétaire des données,
- utilisateurs autorisés ou rôles,
- types de documents,
- niveau de sensibilité,
- règle de conservation,
- fréquence de mise à jour,
- comportement de suppression,
- calendrier de revue.
Exemples de sources :
- centre d’aide public,
- guide interne du support,
- documents commerciaux,
- contrats clients,
- politiques RH,
- procédures d’exploitation technique,
- documentation produit,
- transcriptions de réunions.
Ces sources ne devraient pas toutes se retrouver dans le même index avec les mêmes autorisations.
Étape 2 : classer les données avant l’extraction
Classifiez la source avant que le modèle ou le fournisseur d’embeddings n’accède au contenu.
Classes utiles :
| Classe | Exemple | Posture par défaut |
|---|---|---|
| Public | documents publiés, pages de marketing | Autorisé pour une récupération large |
| Interne | guides, documents de processus | Réservé à l’entreprise, avec filtrage par rôle |
| Confidentiel | contrats, détails clients, finances | Rôles restreints, journalisation plus forte |
| Réglementé/sensible | santé, juridique, 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 d’embeddings 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 des limites de taille de fichier,
- recherchez les logiciels malveillants si votre environnement l’exige,
- rejetez les fichiers chiffrés sauf s’il existe une procédure de déchiffrement approuvée,
- rejetez les fichiers contenant des objets intégrés non pris en charge,
- normalisez les noms de fichiers,
- stockez l’empreinte numérique du fichier original,
- enregistrez qui a téléchargé ou connecté le fichier.
Cela est particulièrement important si des utilisateurs non administrateurs peuvent télécharger des documents. L’ingestion uniquement par administrateurs réduit le risque, mais ne l’élimine pas.
Les contrôles antivirus et de désarmement du contenu ne sont pas automatiques dans la plupart des piles RAG. Si des utilisateurs non fiables peuvent importer des fichiers, ajoutez une véritable couche de sécurité avant leur analyse.
En pratique, cette couche comprend, par ordre de prudence croissante : au minimum, un analyseur de signatures de type ClamAV ; une analyse dans un conteneur isolé et sans accès sortant — les parseurs PDF et bureautiques présentent un long historique de vulnérabilités, et doivent donc être considérés comme une surface d’attaque ; enfin, pour les entrées réellement non fiables, le désarmement et la reconstruction du contenu (CDR), qui recrée une copie saine du fichier au lieu de faire confiance à l’original. La plupart des pipelines de PME nécessitent les deux premiers niveaux ; ajoutez le CDR lorsque des tiers peuvent soumettre des documents.
Étape 4 : extraction du texte et OCR
En pratique, les PDF ne sont pas un seul format. Certains contiennent du texte sélectionnable. Certains sont des scans. Certains ont 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 : un extracteur privilégiant le texte pour les PDF natifs (de type PyMuPDF ou pdfplumber), un convertisseur tenant compte de la mise en page pour les documents structurés (de type Docling ou Unstructured, qui préserve bien mieux les tableaux et l’ordre de lecture), et l’OCR uniquement pour les véritables scans (Tesseract comme référence auto-hébergée ; un service OCR cloud si la qualité du scan est faible et si la classification des données l’autorise).
Concernant les seuils, n’adoptez pas une valeur universelle de confiance OCR trouvée dans un article : calibrez-la sur un échantillon de vos propres documents. Utilisez deux seuils. En dessous du seuil inférieur, la page est rejetée ; entre les deux seuils, elle est soumise à une revue humaine ; au-dessus du seuil supérieur, elle poursuit le traitement. Leur position dépend du scanner, de l’âge des documents et de la langue.
Remarque propre à notre marché : l’OCR de l’estonien est plus difficile que celui de l’anglais. Tesseract fournit un modèle estonien, mais sa précision sur õ/ä/ö/ü, les anciennes archives dactylographiées et les documents mixtes estonien-russe varie suffisamment pour justifier un pilote comparatif sur un échantillon représentatif de vos archives avant de choisir un moteur. Pour une entreprise estonienne, cette demi-journée de test peut éviter ultérieurement un quart des échecs silencieux de récupération.
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 du parseur.
L’extraction de faible qualité ne doit pas entrer silencieusement dans l’index. Dirigez-la vers la revue ou marquez-la comme faible confiance.
Problèmes courants :
- les colonnes lues dans le mauvais ordre,
- les lignes de table fusionnées incorrectement,
- les en-têtes répétés dans chaque segment,
- les pages scannées manquantes entièrement,
- les notes manuscrites ignorées,
- la couche de texte cachée contredisant le scan visible,
- l’OCR convertissant incorrectement les numéros de compte.
Pour les documents à forte valeur, comparez visuellement la page rendue au texte extrait.
Étape 5 : préservation de la structure
Les systèmes RAG ont besoin de plus que du texte. Ils ont besoin d’une structure suffisante pour produire des réponses utiles, ancrées dans la source.
Préservez :
- titre,
- chemin des en-têtes,
- numéro de section,
- numéro de page,
- légendes de tableaux,
- limites de listes,
- version du document,
- date d’entrée en vigueur,
- URL de source ou chemin de stockage.
Conservez les titres et les références de page dans les segments. Un segment indiquant « Les dispositions suivantes s’appliquent » sans le titre qui le précède constitue une preuve insuffisante.
Pour les tableaux, décidez si vous souhaitez :
- garder le tableau en Markdown,
- le convertir en JSON structuré,
- stocker à la fois le texte et les lignes structurées,
- l’exclure jusqu’à ce qu’un meilleur parseur soit disponible.
N’ignorez pas le fait que l’extraction des tableaux n’est pas résolue si votre cas d’utilisation dépend de prix exacts, de dates, de limites ou de seuils.
Étape 6 : attacher les métadonnées
Chaque segment doit conserver des métadonnées disponibles après la récupération :
{
"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 sont la manière dont l’application applique les politiques après la récupération. Sans elles, le modèle reçoit du texte détaché des règles qui le rendent sûr à utiliser.
Étape 7 : cartographie des autorisations
La cartographie des autorisations doit avoir lieu avant que les résultats de la récupération ne parviennent au modèle.
Bon modèle :
- L’utilisateur pose une question.
- L’application dérive le locataire, l’utilisateur, les rôles, les groupes et les autorisations de données à partir de l’authentification.
- Le moteur de récupération filtre les segments candidats selon les autorisations.
- Le classement s’effectue uniquement parmi les segments autorisés.
- Le modèle ne reçoit que les segments autorisés.
Mauvais modèle :
- Récupérer largement.
- Envoyer au modèle tous les segments jugés pertinents.
- Ajouter une consigne indiquant « ne répondez qu’en utilisant les segments auxquels l’utilisateur peut accéder ».
Le mauvais modèle a déjà exposé les données au contexte du modèle.
Si les autorisations de la source sont complexes, commencez par un périmètre plus étroit. Mieux vaut ne pas trouver une réponse que divulguer un document confidentiel.
Étape 8 : découpage et génération des embeddings
Le découpage est une décision de sécurité et de qualité, pas seulement de réglage de recherche.
Directives :
- Maintenez les segments à l’intérieur des périmètres d’autorisation.
- Ne fusionnez pas du texte public et confidentiel dans un même segment.
- Incluez les en-têtes et les références de source.
- Évitez les segments trop grands qui regroupent des sections sans rapport.
- Évitez les segments trop petits qui perdent leur contexte.
- Régénérez les embeddings lorsque le texte source ou les métadonnées changent.
- Stockez le nom et la version du modèle d’embeddings.
Pour les sources sensibles, vérifiez que votre fournisseur d’embeddings, votre base vectorielle et vos journaux sont approuvés pour cette classe de données.
Étape 9 : critères de qualité
Avant de publier une source dans la récupération de production, exécutez des vérifications :
- tous les documents ont des propriétaires,
- tous les segments disposent de métadonnées d’autorisation,
- les documents obsolètes sont signalés,
- les pages avec extraction échouée sont exclues ou revues,
- des questions d’exemple récupèrent les sources attendues,
- les utilisateurs non autorisés ne récupèrent aucun segment à diffusion restreinte,
- les documents supprimés disparaissent de la recherche,
- les citations pointent vers des emplacements de source valides,
- les instructions suspectes dans les documents sont isolées comme contenu, non suivies.
Le dernier point est important. Les documents peuvent contenir une injection de consignes. Le pipeline d’ingestion ne doit pas supprimer systématiquement ce texte, car les utilisateurs doivent parfois connaître le contenu exact du document. En revanche, l’environnement d’exécution doit le traiter comme un contenu documentaire non fiable.
Étape 10 : conservation et suppression (l’article 17 du RGPD vit ici)
Les systèmes RAG conservent souvent par inadvertance des données plus longtemps que le système source.
C’est à cette étape que le droit à l’effacement prévu par l’article 17 du RGPD devient une exigence technique plutôt qu’une simple déclaration de principe. Lorsqu’une demande d’effacement est reçue, affirmer que « le fichier source a été supprimé » n’est pas défendable si des copies subsistent ailleurs dans le pipeline. La suppression doit couvrir :
- cache du fichier original,
- texte extrait,
- segments,
- embeddings,
- résumés,
- miniatures ou pages rendues,
- échantillons d’évaluation,
- journaux où cela est légalement requis,
- sauvegardes selon la politique.
Lorsqu’un document est supprimé ou que son accès est révoqué, la récupération doit cesser de renvoyer ses segments. Idéalement, le système doit prendre en charge la suppression définitive des sources sensibles et appliquer aux sauvegardes une conservation documentée.
Suivez :
- deletedAt,
- deletedBy ou événement source,
- raison de suppression,
- statut de nettoyage en aval,
- résultat de vérification.
Ne comptez pas sur « nous l’avons supprimé de l’interface utilisateur ». Les bases de données vectorielles et les caches sont faciles à oublier.
Étape 11 : responsabilité opérationnelle
Chaque source doit avoir un responsable, et chaque responsable un calendrier de révision.
Pour chaque source, définissez :
- qui approuve l’ingestion,
- qui approuve les changements d’autorisation,
- qui examine 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 récupération.
Si personne n’est responsable d’une source, celle-ci ne doit pas figurer dans un système RAG de production.
À retenir
L’ingestion sécurisée d’un RAG est délibérément peu spectaculaire. Elle rend la récupération prévisible.
Les contrôles principaux :
- enregistrer les sources,
- classer les données,
- vérifier les fichiers avant leur analyse,
- mesurer la qualité d’extraction,
- préserver la structure,
- attacher les métadonnées,
- appliquer les autorisations avant la récupération,
- tester l’accès non autorisé,
- prendre en charge la suppression,
- désigner des responsables.
De bonnes réponses proviennent de bonnes sources. Des réponses sûres reposent sur de bons contrôles de ces sources.
