RAG privé sur données internes

Pourquoi le RAG change la donne pour un LLM local

Un LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire local, aussi bien réglé soit-il, ne connaît que ce qu'il a vu à l'entraînement. Il ignore le dernier avenant contractuel signé la semaine passée, la procédure interne mise à jour hier, ou le ticket de support ouvert ce matin. Deux solutions existent pour combler cet écart : le fine-tuningFine-tuningIAAjustement des poids d'un modèle pré-entraîné sur un jeu de données spécifique pour adapter son comportement à un domaine ou une tâche cible.Voir dans le glossaire, coûteux et à refaire à chaque mise à jour documentaire, ou le retrieval-augmented generation (RAGRAGIATechnique consistant à rechercher les documents pertinents et à les fournir au modèle dans son contexte. Elle permet des réponses à jour et citables, ce que l'affinage ne permet pas.Voir dans le glossaire), qui consiste à injecter dans le promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire les extraits de documents pertinents au moment de la question.

Le RAG a un avantage décisif dans un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire de souveraineté : il permet de garder le modèle générique et de faire porter toute la confidentialité sur la couche de récupération documentaire, qui reste sous votre contrôle direct. C'est aussi ce qui en fait un sujet délicat : la sécurité du système ne dépend plus seulement du modèle, mais de tout le pipeline qui alimente son contexte.

Un RAG mal conçu peut faire fuiter des informations qu'un modèle sans RAG n'aurait jamais pu produire, simplement parce qu'elles ne faisaient pas partie de son entraînement. Le contrôle d'accès documentaire devient alors aussi critique que le contrôle d'accès à une base de donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire classique — voire plus, car les résultats passent par un texte généré, plus difficile à auditer qu'une ligne de SQL.

Vue d'ensemble du pipeline

Un RAG privé repose sur quatre étages qui doivent tous rester on-prem si l'objectif est la souveraineté complète :

1. Ingestion — extraction du texte depuis les sources (PDF, Confluence, partages réseau, CRM...).
2. ChunkingChunkingIADécoupage d'un document en segments de taille fixe ou sémantique avant indexation vectorielle, pour optimiser la récupération RAG.Voir dans le glossaire et embeddingsembeddingIAReprésentation numérique dense d'un texte, d'une image ou d'un objet dans un espace vectoriel, utilisée pour la similarité et la recherche sémantique.Voir dans le glossaire — découpage en fragments et transformation en vecteurs numériques.
3. Stockage vectoriel — indexation dans une base vectoriellebase vectorielleIABase spécialisée qui indexe des embeddings pour retrouver rapidement les passages les plus proches d'une requête (cœur du RAG).Voir dans le glossaire interrogeable par similarité.
4. Retrieval et génération — recherche des fragments pertinents à la question, injection dans le prompt, génération de la réponse avec citations.

Embeddings locaux : quel modèle choisir

Les embeddings transforment un fragment de texte en un vecteur numérique dont la proximité géométrique reflète la proximité sémantique. Pour un RAG souverain, il faut un modèle d'embedding exécutable localement, distinct du LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire de génération.

Les familles les plus utilisées en 2026 pour un déploiement on-prem restent les modèles de type BGE (BAAI General Embedding), E5 (Microsoft) et GTE (Alibaba), disponibles en plusieurs tailles. Un modèle de 300 à 500 millions de paramètres suffit largement pour la majorité des cas d'usage documentaires internes, et tourne confortablement sur CPU si le volume de requêtes reste modéré.

Ce sont deux briques indépendantes avec des cycles de vie différents. Changer de LLM de génération ne doit pas obliger à ré-indexer toute la base documentaire — et inversement, améliorer la qualité des embeddings ne doit pas nécessiter de retoucher le prompt de génération. Gardez ces deux services séparés dans votre architecture, même s'ils tournent sur la même machine.

Un point souvent sous-estimé : la dimension du vecteur produit (384, 768, 1024...) a un impact direct sur la taille de l'index et la vitesse de recherche, pour un gain de qualité qui n'est pas toujours perceptible sur des corpus internes homogènes. Il est raisonnable de commencer avec un modèle compact et de ne monter en dimension que si les tests de pertinence le justifient.

Le chunking : l'étape la plus sous-estimée

Le découpage des documents en fragments (chunks) conditionne directement la qualité du retrieval. Un chunk trop long dilue le signal sémantique et gaspille du contexte au moment de la génération ; un chunk trop court perd le sens global et complique la reconstitution d'une réponse cohérente.

Quelques règles pratiques, validées sur des corpus d'entreprise :

• Respecter la structure du document. Découper aux frontières naturelles (titres, paragraphes, sections) plutôt qu'à un nombre de caractères fixe. Un chunking naïf qui coupe au milieu d'une clause contractuelle produit des réponses tronquées et parfois trompeuses.
• Prévoir un recouvrement (overlap). Un chevauchement de 10 à 20 % entre chunks consécutifs limite la perte d'information aux frontières de découpe.
• Taille cible entre 200 et 500 tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire pour la majorité des documents texte. Les tableaux et données structurées méritent un traitement à part, car leur découpage naïf casse souvent le sens.
• Conserver les métadonnées : titre du document, date, auteur, service émetteur, niveau de confidentialité. Ces métadonnées serviront au filtrage et aux citations.

Une procédure de 12 pages sur les congés payés est découpée section par section (« Acquisition des droits », « Pose des congés », « Cas particuliers »). Chaque chunk conserve en métadonnée le titre de la section et la date de dernière révision de la procédure. Ainsi, une question sur les congés sans solde ne remonte que la section pertinente, avec une citation précise vers « Procédure congés v4, section Cas particuliers, révisée le 03/2026 ».

Pipeline d'ingestion documentaire

L'ingestion est le processus récurrent qui alimente la base vectorielle à partir des sources vivantes de l'entreprise. Un pipeline robuste comprend typiquement :

1. Connecteurs de source : lecture des partages de fichiers, export de wiki interne, API du CRM ou de la GED, avec authentification propre à chaque système.
2. Extraction de texte : conversion PDF, DOCX, HTML, feuilles de calcul vers du texte brut structuré, en conservant si possible la hiérarchie des titres.
3. Nettoyage : suppression des en-têtes/pieds de page répétitifs, des mentions légales redondantes, des artefacts de mise en page.
4. Chunking et enrichissement des métadonnées décrits plus haut.
5. Calcul des embeddings et écriture dans la base vectorielle.
6. Détection des changements : comparaison avec l'état précédent pour ne ré-indexer que les documents modifiés.

Si personne ne surveille les échecs d'extraction (PDF scannés sans OCR, fichiers corrompus, documents protégés par mot de passe), une partie du corpus devient silencieusement invisible pour le RAG. Mettez en place des métriques simples : nombre de documents traités, nombre d'échecs, taux de couverture par source.

Base vectorielle on-premise

Plusieurs solutions permettent d'héberger un index vectoriel sans dépendance à un service cloud managé :

Le choix dépend surtout de l'existant : une équipe qui opère déjà PostgreSQL gagnera du temps avec pgvector. À l'inverse, un volume documentaire important avec des besoins de filtrage complexes justifie une base dédiée comme Qdrant.

Contrôle d'accès documentaire : le cœur du sujet

C'est le point le plus souvent négligé dans les premiers déploiements de RAG interne. Un document confidentiel indexé dans la base vectorielle devient récupérable par n'importe quel utilisateur du système, même si cet utilisateur n'a jamais eu accès au document original, sauf si le filtrage d'accès est appliqué au moment du retrieval.

Le principe à retenir : les droits d'accès de la source documentaire doivent être répliqués dans les métadonnées de chaque chunk, et appliqués comme un filtre systématique avant toute recherche par similarité.

recherche_vectorielle(
  requete = question_utilisateur,
  filtre = { groupes_autorises: groupes_de(utilisateur_courant) }
)

Filtrer les résultats après coup (« je récupère les 10 meilleurs chunks puis j'écarte ceux non autorisés ») est une erreur classique : si les meilleurs résultats appartiennent tous à des documents restreints, l'utilisateur se retrouve avec une réponse vide ou dégradée sans que la restriction n'ait empêché une fuite partielle en amont, notamment si le moteur de recherche journalise ou met en cache les résultats bruts. Le filtre doit faire partie de la requête elle-même, exécuté par la base vectorielle au moment du scan.

Dans une organisation avec des niveaux de confidentialité (public interne, confidentiel service, confidentiel direction), il est recommandé de dupliquer cette hiérarchie dans un champ dédié plutôt que de s'appuyer uniquement sur l'appartenance à un groupe applicatif, qui évolue plus vite que la classification documentaire.

Citations et traçabilité

Un RAG privé qui ne cite pas ses sources perd une grande partie de son intérêt en entreprise : l'utilisateur ne peut pas vérifier la réponse, et l'organisation ne peut pas auditer ce que le système a réellement utilisé pour répondre.

Bonnes pratiques pour des citations exploitables :

• Faire porter la citation au niveau du chunk, pas seulement du document, pour permettre de retrouver le passage exact.
• Afficher systématiquement la date de dernière mise à jour de la source, particulièrement critique pour des procédures ou des données financières.
• Structurer le prompt de génération pour forcer le modèle à indiquer explicitement quand une information ne provient d'aucun chunk récupéré, plutôt que de la combler par une extrapolation.
• Conserver un journal des requêtes et des chunks utilisés pour permettre un audit a posteriori, notamment en cas de réponse contestée.

Même avec des extraits fournis dans le contexte, un modèle peut mal les synthétiser ou en extrapoler le contenu au-delà de ce qui est écrit. La citation permet à l'utilisateur de vérifier la réponse ; elle ne garantit pas à elle seule son exactitude.

Piège n°1 : la fuite via le retrieval

Au-delà du contrôle d'accès documentaire déjà évoqué, une fuite plus subtile peut survenir par inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire indirecte. Un utilisateur sans accès direct à un document confidentiel peut parfois reconstituer une information sensible en posant plusieurs questions ciblées, si des fragments annexes du même document (sommaire, glossaire, pièce jointe publique) restent indexés sans restriction.

Un autre vecteur classique : des journaux applicatifs qui conservent en clair les chunks récupérés pour chaque requête, accessibles à une population plus large que les documents eux-mêmes.

Avant une mise en production, faites tester le système par une personne qui connaît la sensibilité des documents internes, avec pour mission explicite de tenter de faire remonter une information qu'elle ne devrait pas pouvoir obtenir. C'est souvent la seule façon de détecter un trou de filtrage qui ne serait pas apparu dans des tests fonctionnels classiques.

Piège n°2 : l'index qui se périme (stale index)

Un index vectoriel n'est jamais synchronisé en temps réel avec les sources, sauf architecture spécifiquement conçue pour cela. Le décalage entre la dernière modification d'un document et sa ré-indexation crée une fenêtre pendant laquelle le RAG répond avec une information obsolète, sans que rien ne le signale à l'utilisateur.

Ce problème est particulièrement dangereux sur des documents à forte volatilité : grilles tarifaires, procédures de sécurité, statuts de projet.

Quelques leviers pour limiter ce risque :

• Programmer une ré-indexation incrémentale fréquente (toutes les heures ou à chaque webhook de modification côté source, selon la criticité du corpus).
• Afficher systématiquement la date de dernière indexation dans la citation, pas seulement la date du document source.
• Mettre en place une date de péremption sur certains types de documents (grilles tarifaires, procédures réglementaires), après laquelle le chunk est exclu du retrieval tant qu'il n'a pas été revalidé.
• Prévoir un mécanisme de suppression propagée : quand un document est supprimé ou archivé côté source, les chunks correspondants doivent disparaître de l'index dans le même mouvement, pas seulement à la prochaine ré-indexation complète.

Architecture de référence sans cloud

Une architecture RAG souveraine typique s'articule autour de composants déployés sur une infrastructure interne ou un cloud privé maîtrisé :

• Orchestrateur d'ingestion (cron ou file de messages) déclenchant l'extraction et le chunking à intervalle régulier ou sur événement.
• Service d'embeddings exposé en API interne, appelé à la fois par l'ingestion et par le retrieval au moment de la requête utilisateur.
• Base vectorielle (Qdrant ou pgvector) stockant vecteurs et métadonnées d'accès.
• Service de retrieval appliquant le filtrage d'accès avant toute recherche par similarité.
• Serveur d'inférence (Ollama ou vLLM, traité au chapitre précédent) recevant le prompt enrichi des chunks récupérés.
• Couche d'interface affichant la réponse et les citations, avec journalisation des requêtes pour audit.

Aucun de ces composants n'a besoin de sortir du réseau interne. La seule dépendance externe éventuelle concerne le téléchargement initial des poids des modèles, qui peut être fait une fois puis mis en miroir sur un registre interne.

Un corpus de quelques milliers de documents tient largement sur une base vectorielle mono-instance, sans sharding ni cluster dédié. Il est plus utile de passer du temps sur la qualité du chunking et sur le contrôle d'accès que sur une architecture distribuée dont le besoin ne se fera sentir qu'à une échelle bien supérieure à la plupart des déploiements internes.

Ce qu'il faut retenir

Un RAG privé n'est pas qu'un ajout de fonctionnalité au-dessus d'un LLM local : c'est un système de gestion documentaire à part entière, avec ses propres exigences de fraîcheur, de traçabilité et de contrôle d'accès. La qualité perçue par l'utilisateur final dépend davantage du soin apporté au chunking, à l'ingestion et au filtrage qu'au choix du modèle de génération lui-même. Garder l'ensemble du pipeline on-prem permet de traiter des documents réellement sensibles, à condition de traiter le contrôle d'accès et la fraîcheur de l'index comme des exigences de premier plan.