RAG Documents Internes — Votre Base Documentaire Devient Interrogeable en Langage Naturel

#Pourquoi vos documents internes restent inexploités

Les ETI et grands comptes possèdent un très grand nombre de documents internes actifs : contrats fournisseurs et clients, procédures qualité, documentation technique produit, notes de service RH, avis juridiques, rapports d'audit, cahiers des charges, spécifications fonctionnelles, comptes-rendus de réunion.

Ces documents sont éparpillés dans des GED (SharePoint, Alfresco, M-Files), des wikis internes (Confluence, Notion), des drives (OneDrive, Google Drive), des ERP et des boîtes email.

Le problème concret : un chef de projet qui cherche la clause de pénalité dans un contrat signé il y a trois ans passe un temps considérable à fouiller dans SharePoint avant de trouver le bon document. Un ingénieur qualité qui vérifie si une procédure ISO a été mise à jour consulte quatre référentiels différents. Un juriste d'entreprise qui analyse la cohérence entre trois contrats-cadres relit manuellement 120 pages.

Le RAG résout ce problème en rendant l'ensemble de votre base documentaire interrogeable en langage naturel. Pas un moteur de recherche à mots-clés amélioré — un système qui comprend la question, identifie les passages pertinents dans vos documents, et formule une réponse synthétique avec citations des sources. Cf glossaire RAG retrieval augmented generation.

#Architecture RAG complète — De l'ingestion à la génération

Un pipeline RAG documentaire se décompose en six étapes. Chaque étape a ses choix techniques et ses pièges. Voici le détail de l'architecture que Nehos déploie.

#Étape 1 — Ingestion documentaire

Récupérer les documents depuis leurs sources (SharePoint API, Confluence REST API, connecteurs S3, SFTP, API ERP). Les formats à traiter sont variés : PDF (le plus courant et le plus problématique), DOCX, XLSX, PPTX, HTML, Markdown, emails (.eml, .msg). Pour les PDF, la qualité d'extraction du texte dépend du type de PDF : les PDF natifs (générés par un traitement de texte) sont faciles à parser ; les PDF scannés nécessitent un OCR (Tesseract, ou un modèle de vision multimodal pour les documents complexes avec tableaux et schémas).

Les tableaux dans les PDF restent le point dur : Nehos utilise une combinaison de Camelot (extraction tabulaire) et de parsing structuré pour préserver la logique des tableaux dans les chunks.

Point de vigilance : l'ingestion doit gérer le versionning documentaire. Si la version 3 d'une procédure remplace la version 2, le pipeline doit désindexer l'ancienne version pour éviter des réponses contradictoires. Nehos implémente un mécanisme de hash documentaire + timestamps : chaque document reçoit un identifiant unique, et la réindexation ne traite que les documents modifiés depuis la dernière exécution.

#Étape 2 — Chunking intelligent

Le chunking est l'étape la plus sous-estimée et souvent la première cause de mauvaises performances RAG. Découper un document en segments trop grands noie l'information pertinente dans du bruit ; trop petits, le contexte est perdu.

Trois stratégies de chunking, classées par ordre de sophistication. (1) Chunking récursif : découpe par séparateurs hiérarchiques (paragraphes, phrases, mots) avec overlap configurable (typiquement 10-20 % de chevauchement entre chunks). Simple, rapide, efficace sur des documents bien structurés.

(2) Chunking sémantique : utilise un modèle d'embedding pour détecter les ruptures thématiques dans le texte et découper aux frontières sémantiques naturelles. Plus coûteux en calcul, mais préserve la cohérence thématique de chaque chunk. (3) Chunking document-aware : exploite la structure du document (titres H1-H4, sections numérotées, articles de contrat, annexes) pour découper en respectant la hiérarchie originale.

Chaque chunk hérite des métadonnées de sa section parente (titre du chapitre, numéro d'article, référence documentaire). C'est la stratégie que Nehos privilégie pour les corpus juridiques et techniques.

Taille de chunk optimale : il n'existe pas de valeur universelle. On part en général de chunks de 512 à 768 tokens pour les embeddings Mistral Embed (1024 dimensions) et de 256 à 512 tokens pour les embeddings CamemBERT, avec un overlap de 64 à 128 tokens, puis on ajuste sur votre corpus en mesurant la précision du retrieval.

#Étape 3 — Embeddings souverains

Chaque chunk est transformé en vecteur numérique (embedding) par un modèle spécialisé. Le choix du modèle d'embedding conditionne directement la qualité du retrieval.

Trois modèles que Nehos déploie selon le contexte. (1) Mistral Embed (1024 dimensions) : modèle natif Mistral AI, auto-hébergé sur GPU A100 OVHcloud. Très bon en français. Choix par défaut pour les déploiements souverains. (2) CamemBERT-large fine-tuné : modèle BERT français (INRIA/ALMAnaCH), fine-tunable sur votre corpus spécifique pour maximiser la précision sur un vocabulaire métier (juridique, médical, industriel).

Choix optimal quand le corpus est très spécialisé et que le vocabulaire généraliste ne suffit pas. (3) multilingual-e5-large : modèle multilingue (Microsoft Research, open source) performant en français, anglais, allemand. Choix privilégié pour les corpus multilingues (groupes internationaux avec documentation en plusieurs langues).

Tous ces modèles sont auto-hébergés sur OVHcloud. Aucun chunk documentaire ne transite par une API externe. Cf service IA souveraine Nehos.

#Étape 4 — Vector store (Qdrant vs Weaviate vs Chroma)

Les embeddings sont stockés dans une base de données vectorielle qui permet la recherche par similarité. Trois options que Nehos évalue systématiquement pour chaque projet.

Recommandation Nehos par défaut : Qdrant pour les déploiements production souverains (performances Rust, sparse vectors natifs pour l'hybrid search, isolation collection-level, API gRPC rapide). Weaviate si le projet nécessite du multi-tenancy natif (plateforme SaaS avec données isolées par client). Chroma uniquement pour les POC en phase d'exploration.

Qdrant et Weaviate sont déployés auto-hébergés sur OVHcloud, avec réplication haute disponibilité pour la production. Documentation technique : Qdrant documentation.

#Étape 5 — Retrieval : hybrid search + reranking

La recherche vectorielle seule (dense retrieval) a une limitation connue : elle privilégie la similarité sémantique mais peut manquer des correspondances lexicales exactes. Un utilisateur qui cherche le numéro d'article spécifique "L.1111-8 du Code de la santé publique" a besoin d'une correspondance exacte, pas sémantique.

L'hybrid search combine deux approches. Dense retrieval : recherche vectorielle par similarité cosine dans Qdrant (capture le sens). Sparse retrieval (BM25) : recherche par correspondance lexicale pondérée (capture les termes exacts). Qdrant supporte nativement les sparse vectors, ce qui permet d'exécuter les deux recherches en une seule requête et de fusionner les résultats via Reciprocal Rank Fusion (RRF).

Après la fusion, un reranker affine le classement. Deux options. (1) Cross-encoder (modèle BERT fine-tuné qui évalue la pertinence de chaque paire question-chunk) : plus précis, plus lent, adapté quand le top-k initial est large (50-100 résultats réduits à 5-10). (2) Reranker Cohere (API) ou modèle de reranking Mistral auto-hébergé : compromis vitesse/précision.

Pour les déploiements souverains, Nehos déploie un cross-encoder auto-hébergé sur GPU A100 OVHcloud. Cf service agents IA Nehos.

L'hybrid search avec reranking améliore généralement le recall par rapport au dense retrieval seul : nous le vérifions sur votre corpus avec le jeu de test d'évaluation.

#Étape 6 — Génération augmentée

Le LLM (Mistral Large 2 auto-hébergé sur OVHcloud) reçoit la question de l'utilisateur + les chunks pertinents récupérés par le retrieval. Il formule une réponse synthétique en citant les sources documentaires. Le prompt système impose au LLM de ne répondre qu'à partir de s documents fournis et de signaler explicitement quand l'information n'est pas disponible dans le corpus.

Guardrails anti-hallucination : (1) Citation obligatoire — chaque affirmation de la réponse doit être rattachée à un chunk source identifié par son document_id et son numéro de page. (2) Score de confiance — le système calcule un score de grounding (proportion d'affirmations couvertes par les sources) et affiche un indicateur visuel vert/orange/rouge à l'utilisateur.

(3) Fallback humain — si le score de confiance est inférieur au seuil configurable (typiquement 0,6), la réponse est flagée et un expert métier est notifié.

#Évaluation qualité RAG — Framework RAGAS

Déployer un RAG sans mesurer sa qualité revient à piloter à l'aveugle. Nehos intègre systématiquement le framework RAGAS (Retrieval Augmented Generation Assessment) pour évaluer quatre métriques.

Faithfulness (fidélité) : la réponse générée est-elle fidèle aux documents sources ? Mesure le taux d'hallucination. Nous fixons un seuil avec vous avant le pilote. Answer relevancy (pertinence) : la réponse répond-elle bien à la question posée ? Context recall (rappel) : le retriever a-t-il récupéré tous les passages pertinents du corpus ? Context precision (précision) : les passages récupérés sont-ils pertinents (pas de bruit) ?

Ces métriques sont calculées sur un jeu de test annoté par des experts métier (quelques dizaines à quelques centaines de paires question-réponse attendue). Le monitoring continu via Langfuse auto-hébergé détecte le drift de qualité dans le temps : si le faithfulness chute sous le seuil après un ajout massif de documents, une alerte déclenche une investigation. Documentation de référence : LangChain RAG documentation.

#RGPD et conformité — RAG sur données sensibles

Le RAG documentaire traite potentiellement des données à caractère personnel (contrats nominatifs, fiches RH, correspondances juridiques). Trois principes de conformité RGPD appliqués par Nehos.

Minimisation des données : le pipeline d'ingestion intègre une couche de détection NER (Named Entity Recognition) qui identifie les noms, adresses, numéros de sécurité sociale, IBAN, et les pseudonymise avant l'indexation dans la vector database. L'utilisateur final reçoit une réponse avec des identifiants pseudonymisés, et une couche d'autorisation vérifie ses droits avant de révéler les données originales.

Hébergement souverain : toute la stack (LLM, embeddings, vector database, Postgres, Langfuse) tourne sur OVHcloud, opérateur français non soumis au CLOUD Act. Aucune donnée documentaire ne transite par un serveur américain. Pour les données de santé, déploiement sur instances HDS-certifiées OVHcloud. Cf service cloud souverain Nehos.

Traçabilité AI Act : chaque requête utilisateur et chaque réponse générée sont loggées dans Postgres (pgaudit) avec timestamp, user_id pseudonymisé, documents sources utilisés, score de confiance. Cet audit trail satisfait les exigences AI Act Art.12 (journalisation) et Art.14 (supervision humaine). Voir blog guide RGPD et IA souveraine.

#Exemples de situation

#Entreprise industrielle — un grand corpus de documents techniques

Exemple de situation, sans client cité. Un équipementier industriel multi-sites dispose d'un grand nombre de documents techniques (fiches produits, procédures de maintenance, rapports qualité, normes ISO internes, plans de fabrication). Les techniciens de maintenance perdent du temps à chercher la procédure applicable dans Confluence et SharePoint.

Un pipeline RAG souverain (Qdrant + Mistral Embed + Mistral Large 2 sur OVHcloud), un chunking document-aware qui respecte la structure ISO des procédures et une interface mobile accessible depuis les tablettes terrain répondent à ce besoin. On mesure pendant le pilote le temps de recherche par intervention, la pertinence des réponses validée par les experts métier et la faithfulness RAGAS.

#Cabinet juridique — contrats et jurisprudences

Exemple de situation, sans client cité. Un cabinet d'avocats d'affaires veut retrouver plus vite des précédents contractuels et des clauses similaires dans sa base documentaire (contrats-cadres, pactes d'actionnaires, notes de due diligence, mémos juridiques). Un RAG avec CamemBERT-large fine-tuné sur le vocabulaire juridique français, Qdrant avec filtrage par métadonnées (type de contrat, date, domaine juridique), hybrid search dense + BM25 et reranking cross-encoder répond à ce besoin, avec contrôle d'accès par dossier client. On mesure pendant le pilote le temps de recherche de précédents et le context recall RAGAS.

#Tarification

Trois niveaux de projet selon la complexité.

Entrée (MVP agent IA, à partir de 11 000 € HT) : RAG sur un corpus unique (une GED, un wiki, ou un répertoire de fichiers), chunking récursif ou document-aware, embeddings Mistral Embed, Qdrant auto-hébergé, dense retrieval, interface web basique. Typique : ETI non-réglementée, assistant documentaire interne.

Intermédiaire (sur devis) : RAG multi-sources (SharePoint + Confluence + ERP + emails), plusieurs dizaines de milliers de documents, chunking sémantique ou document-aware, hybrid search dense+BM25, reranking cross-encoder, intégrations SSO, évaluation RAGAS, monitoring Langfuse, conformité RGPD documentée.

Avancé (plateforme multi-agents, à partir de 50 000 € HT) : secteurs réglementés (HDS santé, DORA finance, défense), très gros corpus, CamemBERT fine-tuné sur vocabulaire métier, multi-agents RAG (agent de recherche + agent de synthèse + agent de vérification), guardrails anti-hallucination avancés, audit AI Act. Maintenance mensuelle ensuite : sur devis selon volumes et niveau de service.

Chiffrage en 48 h après un premier échange de 30 minutes : Calendly RDV RAG documentaire. Voir aussi blog agents IA RAG retour expérience et comparatif Qdrant vs Weaviate vs Pinecone.