RAG Entreprise — Connecter votre LLM à votre base de connaissances interne

#Pourquoi le RAG est l'approche standard pour les LLM d'entreprise en 2026

Trois approches coexistent pour doter un LLM de connaissances métier spécifiques à votre organisation : le prompt stuffing (injecter des documents directement dans le contexte de la requête), le fine-tuning (réentraîner le modèle sur vos données), et le RAG — RAG (Retrieval-Augmented Generation). Comprendre quand choisir laquelle change radicalement l'architecture et le budget.

Le prompt stuffing fonctionne bien sur des bases documentaires très réduites (quelques dizaines de pages) et des cas d'usage ponctuels. Dès que le corpus dépasse quelques milliers de documents, les limites deviennent structurelles : fenêtre de contexte saturée (même Mistral Large 2 plafonne à 128 000 tokens, soit environ 100 000 mots — soit peut-être 400 pages PDF), coût de tokens prohibitif (chaque requête ré-injecte l'ensemble du contexte), latence élevée, et impossibilité de maintenir la base à jour sans refactoriser l'ensemble de la logique de prompting.

Le fine-tuning ajuste les poids du modèle sur votre corpus pour que le LLM internalise des patterns de réponse propres à votre domaine. C'est le bon outil quand le problème est stylométrique (ton éditorial précis, jargon très technique, format de sortie structuré spécifique) ou quand les données d'entraînement sont stables dans le temps. C'est le mauvais outil pour les bases de connaissances documentaires dynamiques : chaque mise à jour significative du corpus exige un nouveau cycle de fine-tuning (préparation dataset, entraînement, évaluation, déploiement — 2 à 6 semaines, plusieurs dizaines de milliers d'euros par run sur un modèle 70B+). Personne ne re-fine-tune toutes les semaines parce qu'un avocat a mis à jour un contrat type.

Le RAG est l'approche de référence — validée par l'article fondateur RAG (Lewis et al. 2020, NeurIPS) et adoptée comme standard de fait par l'industrie depuis 2023 — précisément parce qu'il découple connaissance et modèle. Les documents sont indexés une fois (ou re-indexés incrémentalement dès qu'un document change), transformés en vecteurs et stockés dans une base vectorielle. À chaque requête utilisateur, le système récupère dynamiquement les chunks les plus pertinents, les injecte dans le prompt de génération, et le LLM synthétise une réponse fondée uniquement sur ces extraits — avec citations précises des passages sources. Résultats : réponses actualisées en temps réel, taux d'hallucination fortement réduit (les hallucinations IA sont la principale source de méfiance des directions juridiques et compliance), coût d'inférence maîtrisé, et traçabilité complète des sources citées.

Le RAG n'est pas non plus une solution universelle. Sur des problèmes de complétion de code (GitHub Copilot style), le fine-tuning reste souvent supérieur. Sur des tâches de raisonnement pur sans besoin d'accès documentaire, un LLM standard sans RAG suffit. Sur des cas où les documents sont très courts et peu nombreux (moins de 500 pages), le prompt stuffing est plus simple à déployer. Nehos qualifie systématiquement cette décision d'architecture en amont — pas de RAG par défaut, mais RAG quand c'est le bon outil.

#Architecture RAG souveraine Nehos — Composants et flux de données

Notre architecture RAG est conçue autour d'un principe fondateur : zéro transfert de données hors Union Européenne, à aucune étape du pipeline — ni à l'indexation, ni à l'inférence, ni au monitoring. Voici le détail des composants et des choix techniques.

Ingestion documentaire. Le pipeline d'ingestion commence par les connecteurs sources (SharePoint, Confluence, SAP, Cegid, Salesforce — détail dans la section Connecteurs). Les documents sont récupérés via API ou flux sécurisés, pré-traités (extraction du texte depuis PDF natif via PyMuPDF, depuis PDF scanné via OCR Tesseract/Surya, depuis DOCX/XLSX via python-docx/openpyxl), nettoyés (suppression des headers/footers répétitifs, normalisation des caractères) et enrichis en métadonnées (auteur, date de création, date de dernière modification, périmètre d'accès, type de document, département émetteur, langue). Ces métadonnées sont critiques pour le filtrage et le contrôle d'accès en phase de retrieval.

Stratégie de chunking. Le découpage des documents en chunks est l'une des décisions les plus impactantes sur la qualité du RAG — et l'une des moins bien traitées par les implémentations naïves. Nehos utilise trois stratégies selon le type de document. Chunking sémantique (late chunking via embeddings de phrases) pour les textes prose non structurés (notes internes, rapports, analyses) : les chunks correspondent à des unités de sens plutôt qu'à des tailles fixes. Chunking structurel pour les documents hiérarchisés (contrats, manuels, procédures, CGV) : chaque article, section ou clause devient un chunk indépendant, avec le titre de section préfixé pour conserver le contexte. Chunking à taille fixe avec overlap (512 tokens, overlap 64 tokens) comme fallback sur les documents mal structurés. Dans tous les cas, un chunk ne contient jamais de coupure de phrase — nous ne tronquons pas une phrase en deux chunks différents.

Embedding et indexation. Mistral Embed transforme chaque chunk en vecteur dense de 1 024 dimensions. Nous choisissons Mistral Embed par défaut sur les corpus francophones pour deux raisons : performance supérieure sur le français vs text-embedding-ada-002 d'OpenAI (validée sur les benchmarks MTEB français), et hébergement souverain (l'API Mistral Embed est disponible sur OVHcloud AI Deploy). Les vecteurs sont indexés dans Qdrant avec l'algorithme HNSW (Hierarchical Navigable Small World) qui permet une recherche approximative en temps sublinéaire sur des corpus de plusieurs millions de chunks. Nous configurons également un index BM25 sparse (via Qdrant native sparse vectors) pour la recherche lexicale exacte.

Retrieval hybride et reranking. À chaque requête utilisateur, le système exécute en parallèle une recherche dense (vecteur Mistral Embed de la requête, top-k=20 par similarité cosinus) et une recherche sparse (BM25, top-k=20). Les 40 candidats sont fusionnés via Reciprocal Rank Fusion (RRF), puis rerankés par un cross-encoder (Mistral ou modèle léger dédié au reranking) qui calcule une score de pertinence query-chunk en lisant les deux en parallèle — contrairement au bi-encoder de l'étape précédente. Les top-5 à top-10 chunks rerankés sont injectés dans le prompt de génération. Ce pipeline hybride améliore le recall@5 de 18 à 26 points selon nos benchmarks internes sur corpus juridiques et techniques francophones, vs recherche dense seule.

Génération et citation. Mistral Large 2 (123B paramètres, quantisé INT8 en production pour optimiser la VRAM) génère la réponse finale en se fondant exclusivement sur les chunks récupérés. Le prompt système impose trois règles : ne répondre que sur la base des documents fournis (pas de connaissance paramétrique injectée), citer systématiquement le document source et le numéro de chunk pour chaque affirmation facturée, et indiquer explicitement si la réponse ne se trouve pas dans les documents indexés plutôt que d'halluciner. Ce dernier point est critique : un RAG bien configuré doit savoir dire "je ne sais pas" plutôt que d'inventer.

Contrôle d'accès documentaire (authorization-aware retrieval). Le RAG ne doit restituer que les documents auxquels l'utilisateur a accès dans le SI source. Nous implémentons ce contrôle via des filtres de métadonnées Qdrant appliqués avant le retrieval : chaque chunk porte les ACLs du document source (rôles LDAP/AD autorisés, périmètre géographique, niveau de confidentialité). La requête de retrieval est toujours filtrée par l'identité et les rôles de l'utilisateur authentifié. Un utilisateur de la direction juridique ne voit jamais les chunks d'un document RH confidentiel, même si ce document est techniquement dans le même index.

#7 cas d'usage RAG majeurs en entreprise

#1. Base de connaissances juridique — Contrats, CGV, jurisprudence interne

Le cas d'usage le plus mature et le plus ROI-positif que Nehos déploie en 2026. Un corpus de contrats clients (MSA, SOW, NDA, SLA), CGV, CGU, jurisprudence interne (décisions de justice passées, mémos juridiques, avis d'avocats), réglementations sectorielles — indexé dans Qdrant — et accessible à l'ensemble des avocats, juristes et paralégaux via une interface conversationnelle. Questions typiques : "Quelle est notre clause de limitation de responsabilité standard dans les contrats SaaS B2B ?" / "Y a-t-il un précédent jurisprudentiel interne sur la résiliation anticipée pour ce type de clause ?" / "Quels contrats clients contiennent une clause de benchmarking ?" Le système répond en citant le document source, le numéro d'article et la date de version. Notre cas client référence (cabinet juridique parisien 80 avocats, 120 000 documents) a mesuré une réduction du temps de recherche documentaire de 68 % (de 47 min à 15 min en moyenne par requête documentaire), avec un taux de faithfulness RAGAS de 0,97 — soit moins de 0,3 % de réponses contenant une affirmation non sourcée.

#2. Assistant commercial RAG sur catalogues produits et ERP

Les équipes commerciales d'ETI industrielles ou de distributeurs passent en moyenne 35 à 50 minutes par jour à rechercher des informations produits dispersées entre le catalogue PDF, l'ERP (SAP, Cegid), le CRM (Salesforce, HubSpot), les fiches techniques et les tarifs. Un agent RAG connecté à ces sources permet de répondre en quelques secondes à des questions comme "Quel est le délai de livraison standard pour la référence XY-4521 depuis notre entrepôt Lyon ?", "Quelle est la compatibilité entre le composant A et le composant B d'après la fiche technique v3.2 ?", "Quelles sont les conditions tarifaires de ce client pour le volume commande 500+ unités ?". Les données ERP et CRM sont synchronisées quotidiennement (ou en quasi-temps réel via webhooks selon la criticité), ce qui garantit que le RAG répond sur la base des données à jour — pas sur un catalogue PDF imprimé il y a 18 mois.

#3. RAG conformité réglementaire — RGPD, AI Act, NIS2, sectoriels

Les directions compliance et juridique des ETI doivent naviguer dans un corpus réglementaire en expansion constante : RGPD et ses guidelines EDPB/CNIL, AI Act (Règlement UE 2024/1689) et ses actes délégués, NIS2 (Directive UE 2022/2555), réglementations sectorielles (DORA pour la finance, MDR pour le médical, DSA pour les plateformes...). Un RAG indexant ces textes officiels, les guidelines d'autorités de régulation, les positions internes du DPO, les politiques de conformité maison, et les registres de traitement permet aux équipes conformité de répondre en quelques secondes à des questions comme "Notre nouveau service de scoring crédit est-il soumis à l'article 22 du RGPD et/ou à l'Annexe III de l'AI Act ?" avec citation des passages réglementaires pertinents. La documentation Mistral API intègre ce type de cas d'usage dans ses exemples officiels.

#4. Support IT Helpdesk RAG sur documentation technique

Les équipes IT support Niveau 1 et Niveau 2 passent une part significative de leur temps à rechercher dans des documentations techniques volumineuses et mal organisées (runbooks, procédures d'incident, notes de release, configurations réseau, architecture SI, guides d'administration). Un RAG indexant l'ensemble de cette documentation (Confluence, Jira, fichiers Markdown, PDFs techniques, emails d'incident archivés) et accessible aux techniciens support via une interface conversationnelle réduit le MTTR (Mean Time To Resolution) de 25 à 40 % selon nos cas clients ETI industriels. Questions typiques : "Quelle est la procédure de basculement vers le DC secondaire en cas d'indisponibilité du VPN principal ?", "Comment reconfigurait-on le load balancer en 2024 lors de l'incident similaire ?". Le système cite les runbooks sources et les tickets d'incident archivés.

#5. RAG RH — Convention collective, accords d'entreprise, procédures internes

Les DRH et HRBP d'ETI reçoivent quotidiennement des questions sur l'interprétation de la convention collective applicable, des accords d'entreprise, des procédures internes (notes de service, charte télétravail, politique de mobilité, règlement intérieur). Un RAG indexant ce corpus RH interne — et accessible aux salariés et managers en libre-service — réduit le volume de tickets RH N1 de 40 à 65 % selon nos clients (voir cas agent IA d'assistance RH). Questions fréquentes : "Combien de jours de congé pour mariage selon notre convention ?", "Quelle est la procédure d'indemnisation des déplacements au-delà de 200 km ?", "La charte télétravail de 2025 autorise-t-elle le télétravail depuis l'étranger UE ?". Le RAG répond en citant l'article précis de la convention ou l'accord d'entreprise — pas une interprétation libre.

#6. RAG R&D sur publications scientifiques et brevets

Les équipes R&D d'ETI industrielles et de scale-ups deeptech gèrent des corpus de publications scientifiques (PubMed, arXiv, revues sectorielles), de brevets (WIPO, INPI, USPTO), de rapports d'études internes et de notes techniques. Un RAG sur ce corpus permet aux chercheurs et ingénieurs de R&D de faire de la veille documentaire accélérée, d'identifier des antériorités brevets avant un dépôt, ou de retrouver rapidement les paramètres d'une expérience menée il y a 3 ans. La clé sur ce cas d'usage est le traitement multilingue (publications en anglais, brevets en plusieurs langues) et la gestion des formules, tableaux et figures — Mistral Large 2 multimodal traite les images de figures scientifiques en mode vision.

#7. RAG multimodal — Documents scannés et PDF natifs mixtes

Les corpus documentaires réels des ETI sont rarement propres : un tiers des documents sont des PDFs scannés (contrats papier numérisés, factures, bons de commande, dossiers techniques anciens), un tiers sont des PDFs natifs (documents Word ou InDesign exportés), et un tiers sont des fichiers Office directement. Notre pipeline RAG traite les trois : OCR via Surya (modèle OCR open-source, supérieur à Tesseract sur le français et les tableaux) pour les scans, extraction directe PyMuPDF pour les PDFs natifs, python-docx/openpyxl pour les Office. Les tableaux sont extraits structurellement (pas comme du texte brut) pour permettre des requêtes sur les données tabulaires. La précision OCR est auditée sur un échantillon représentatif avant de lancer l'indexation full-corpus.

#Connecteurs sources de données — SharePoint, Confluence, ERP, CRM

La valeur d'un RAG d'entreprise dépend directement de l'exhaustivité et de la fraîcheur de l'indexation des sources documentaires. Nehos maintient des connecteurs natifs pour les principales plateformes documentaires et SI d'entreprise francophones.

Pour les plateformes de collaboration : SharePoint Online et SharePoint on-premise (via Graph API et CSOM), Microsoft Teams (fichiers de canaux), Confluence Cloud et Confluence Server/Data Center (via REST API Atlassian, avec respect des permissions Confluence space-by-space), Notion (via API officielle), Google Workspace (Drive, Docs, Sheets via Workspace API).

Pour les ERP et SIRH : SAP S/4HANA et SAP ECC (via RFC/BAPI ou OData selon version), Cegid XRP Flex et Cegid HR (API REST), Sage 100 et Sage X3, Sylob, Generix. L'indexation ERP cible principalement les modules documentation (fiches articles, nomenclatures, procédures de fabrication, fiches fournisseurs) — pas les données transactionnelles en temps réel, qui relèvent d'une architecture différente (data streaming).

Pour les CRM : Salesforce (via API REST et Bulk API 2.0), HubSpot (via API v3), Microsoft Dynamics 365 (via Web API OData). L'indexation CRM cible les objets documentaires : fiches produits, playbooks commerciaux, emails archivés, notes d'opportunités, FAQ clients.

Pour les ticketing et support : Jira Service Management, Zendesk, Freshdesk, Intercom. Indexation des tickets historiques résolus comme base de connaissances helpdesk — pattern très efficace sur les cas d'usage IT support et SAV.

Pour les sources fichiers : emails Exchange/Gmail (via Graph API / Gmail API — indexation sélective par folder ou label, jamais des boîtes complètes sans consentement explicite), fichiers PDF/DOCX/XLSX/PPTX via stockage objet (S3-compatible, OVHcloud Object Storage), bases SQL (PostgreSQL, MySQL, MariaDB, SQL Server — via des requêtes SQL pré-définies sur des vues dénormalisées, pas d'accès en lecture directe sur les tables de production sans validation DPO).

Le cycle de synchronisation est configurable par source : temps réel via webhooks (SharePoint, Confluence Cloud, Salesforce avec Change Data Capture), quotidien pour les ERP (fenêtre de nuit), sur demande pour les sources fichiers archivées. La re-indexation incrémentale ne reprocesse que les documents créés ou modifiés depuis la dernière synchronisation.

#Sécurité et conformité RGPD du système RAG

Un système RAG d'entreprise est, par nature, le point de convergence de l'ensemble des documents sensibles de l'organisation. La sécurité n'est pas une option : elle est intégrée dès la conception.

Résidence des données. L'ensemble du pipeline — ingestion, embedding, stockage Qdrant, inférence Mistral Large 2 — est hébergé sur OVHcloud France (régions GRA ou SBG selon la région du client). OVHcloud est qualifié SecNumCloud par l'ANSSI pour ses offres Hosted Private Cloud et remplit les exigences de résidence des données RGPD (article 46). Aucune donnée ne transite vers OpenAI, Anthropic, Google, AWS ou Azure US à aucune étape. La souveraineté numérique n'est pas un argument commercial chez Nehos — c'est une contrainte architecturale.

Authorization-aware retrieval. Le contrôle d'accès documentaire est le point de sécurité le plus souvent négligé dans les implémentations RAG naïves. Si un collaborateur de la direction financière peut interroger le RAG et obtenir des réponses issues de documents RH confidentiels ou de stratégies M&A non publiques, le système crée une faille de confidentialité majeure. Notre implémentation porte les ACLs (Access Control Lists) directement dans les métadonnées Qdrant de chaque chunk, synchronisées depuis le SI source à chaque re-indexation. Chaque requête RAG est filtrée en amont du retrieval par les rôles et périmètres de l'utilisateur authentifié (via LDAP/Active Directory, SSO SAML 2.0 ou OIDC). Un utilisateur ne peut jamais obtenir de chunk d'un document auquel il n'a pas accès dans le SI source.

Chunking sans fuite de PII. Sur les corpus contenant des données personnelles (contrats avec données de clients physiques, dossiers RH, emails clients), nous appliquons une pseudonymisation au niveau du chunk avant indexation sur les données particulièrement sensibles, tout en maintenant la traçabilité vers le document source dans un registre séparé. Sur les données moins sensibles, nous documentons la base légale RGPD du traitement (intérêt légitime de l'entreprise pour la gestion documentaire interne, avec analyse de proportionnalité) dans la DPIA réalisée avant déploiement.

Audit logs et traçabilité. Chaque requête RAG est loguée : identifiant utilisateur pseudonymisé, timestamp, requête (hashée si sensible), chunks récupérés (références document + chunk ID), réponse générée (hashée), score RAGAS post-évaluation. Ces logs sont stockés dans Postgres 16 avec extension pgaudit, immuables (append-only, chiffrement au repos). Conservation : 12 mois glissants par défaut, paramétrable selon politique de l'organisation. Ces logs permettent de répondre à un audit CNIL, à un contentieux interne ("quelle source a été utilisée pour cette réponse ?"), ou à une revue DSI trimestrielle.

DPIA. Une DPIA (analyse d'impact relative à la protection des données) est réalisée par Nehos en amont de tout déploiement RAG, validée avec le DPO du client. Les flux de données, les bases légales, les durées de conservation, les droits des personnes concernées (droit d'accès, rectification, suppression) et les mesures techniques sont documentés. La sécurité OWASP LLM est appliquée sur le périmètre applicatif du RAG (protection contre prompt injection, jailbreak, data poisoning sur le corpus source).

#Évaluation et monitoring RAG — RAGAS et métriques opérationnelles

Déployer un RAG sans framework d'évaluation, c'est piloter à l'aveugle. Nehos intègre le RAGAS framework évaluation RAG dès le POC, avec monitoring continu en production.

Les quatre métriques RAGAS fondamentales. Faithfulness (fidélité) : la réponse générée est-elle entièrement fondée sur les chunks récupérés, sans affirmation extérieure ? Cible Nehos : faithfulness ≥ 0,95 en production. En dessous de 0,90, c'est un signal de prompt system à ajuster ou de retrieval insuffisant. Answer Relevancy (pertinence de la réponse) : la réponse adresse-t-elle bien la question posée ? Cible : ≥ 0,90. Context Precision (précision du contexte) : les chunks récupérés sont-ils tous utiles à la réponse, sans bruit inutile ? Cible : ≥ 0,80. Context Recall (rappel du contexte) : tous les éléments nécessaires à la réponse étaient-ils présents dans les chunks récupérés ? Cible : ≥ 0,85. Un recall bas indique un problème de chunking (les informations pertinentes sont découpées entre trop de chunks) ou d'indexation (certains documents ne sont pas indexés ou mal tokenisés).

Métriques opérationnelles supplémentaires. Taux d'hallucination (= 1 - faithfulness en pratique) : notre objectif sur les cas d'usage à enjeux (juridique, compliance, médical) est inférieur à 2 %. Latence p50/p95/p99 : notre SLA standard est p50 < 2s, p95 < 5s, p99 < 10s pour une requête RAG complète (retrieval + génération) sur un corpus de 100 000 chunks. Au-delà de 3s en p50, l'adoption utilisateur chute significativement. Taux de "je ne sais pas" (no-answer rate) : un taux trop élevé (> 20 %) indique que le corpus n'est pas assez exhaustif ou que les requêtes utilisateurs sortent du périmètre documentaire couvert — signal pour élargir le scope d'indexation. Un taux trop bas (< 2 %) est suspect — le modèle répond peut-être quand il devrait s'abstenir. Taux de satisfaction utilisateur : mesuré via feedback inline (pouce haut/bas sur chaque réponse), agrégé par cas d'usage et par département.

Le dashboard monitoring est déployé sur Grafana (stack standard Nehos) avec alertes PagerDuty si faithfulness passe sous 0,90 ou si la latence p95 dépasse le SLA. Un rapport mensuel RAGAS est fourni au client avec évolution des métriques, top 10 des requêtes sans réponse satisfaisante (signal pour enrichir le corpus), et recommandations d'amélioration.

#Méthodologie de déploiement — POC 3 semaines, MVP 10-16 semaines

Phase 1 — Audit documentaire et cadrage (1 semaine, 5 000 à128 000 € HT). Cartographie de l'ensemble des sources documentaires disponibles (volumes, formats, langues, qualité, fréquence de mise à jour, périmètre d'accès actuel dans le SI), identification du ou des cas d'usage prioritaires (quel département a le plus à gagner, quels types de questions génèrent le plus de friction documentaire aujourd'hui), définition des critères d'acceptation du POC (métriques RAGAS cibles, latence acceptable, périmètre documentaire pilote). Livrable : rapport d'audit documentaire + architecture cible proposée + devis POC détaillé.

Phase 2 — POC (3 semaines, 12 000 à320 000 € HT). Déploiement du pipeline RAG complet sur un périmètre documentaire réduit (5 000 à 20 000 documents représentatifs du cas d'usage pilote), sur environnement OVHcloud dédié. Mise en place de l'interface conversationnelle pilote (web app légère ou intégration Slack/Teams selon préférence). Groupe pilote 5 à 20 utilisateurs. Mesure RAGAS après 1 000 requêtes pilotes minimum. Itération sur le chunking, le retrieval et le prompt système si les métriques sont sous cibles. Livrable : rapport RAGAS POC, retours utilisateurs pilotes qualifiés, recommandations architecture MVP.

Phase 3 — MVP en production (10 à 16 semaines, 30 000 à2 400 000 € HT selon scope). Indexation full-corpus (100 000 à 500 000+ documents selon projet), développement des connecteurs sources finaux, implémentation du contrôle d'accès documentaire complet (authorization-aware retrieval synchronisé avec LDAP/AD), intégration dans le portail métier existant (SSO SAML2/OIDC, interface UI/UX en accord avec la charte graphique client), déploiement du monitoring RAGAS continu sur Grafana, formation des équipes utilisateurs et des administrateurs, documentation technique et fonctionnelle complète. Mise en production progressive par département (cohortes de 20 à 100 utilisateurs par vague, avec validation métriques entre chaque vague).

Phase 4 — Exploitation et amélioration continue (forfait MCO mensuel 2 500 à144 000 € HT/mois). SLA 99,5 % uptime, rapport RAGAS mensuel, re-indexation incrémentale des nouvelles sources documentaires, fine-tuning du retrieval et du prompt système sur la base des retours utilisateurs, évolution des connecteurs sources (nouvelles intégrations, montées de version SI), veille sur les nouvelles versions Mistral (migration vers Mistral Large 3 ou successeur dès disponibilité en hébergement souverain OVHcloud), audit sécurité annuel (sécurité OWASP LLM).

#ROI mesurable — Cas ETI juridique 120 000 documents

Cas client référence : cabinet juridique parisien de 80 avocats (anonymisé NDA), spécialisé en droit des affaires et propriété intellectuelle. Corpus documentaire : 120 000 documents indexés (contrats clients MSA/SOW/NDA, avis juridiques internes, jurisprudence commerciale annotée, manuels de procédures internes, CGV et CGU types par secteur, mémos réglementaires). Problème initial : chaque avocat passait en moyenne 47 minutes par requête documentaire complexe (recherche dans les drives SharePoint, recherche dans la base de jurisprudence interne Notion, comparaison manuelle entre versions de contrats). Sur 80 avocats effectuant 4 à 6 requêtes documentaires complexes par jour, cela représentait 250 à 380 heures perdues quotidiennement sur de la recherche à faible valeur ajoutée.

Déploiement Nehos : POC 3 semaines (indexation de 30 000 documents pilote — contrats et jurisprudence uniquement), puis MVP 14 semaines (indexation full-corpus 120 000 documents, intégration SharePoint + Notion + base emails Exchange archivée, interface conversationnelle intégrée dans le portail interne du cabinet, contrôle d'accès par dossier client et par rôle). Investissement total : 2160 k€ HT (POC + MVP, hors MCO).

Résultats à 12 mois : temps moyen de recherche documentaire passé de 47 minutes à 15 minutes (-68 %), soit 32 minutes récupérées par requête documentaire. Sur 80 avocats x 5 requêtes/jour x 220 jours ouvrés/an x 32 minutes = 9 387 heures récupérées annuellement. À un taux horaire facturable moyen de4 7 680 € HT, cela représente 42,1 M€ HT de capacité facturable libérée — dont une partie est effectivement convertie en chiffre d'affaires additionnel, une partie est réinvestie dans la qualité des missions. Retour sur investissement net positif dès le 8e mois. Métriques RAGAS en production : faithfulness 0,97, answer relevancy 0,93, taux de "je ne sais pas" 7 % (signaux documentaires manquants traités mensuellement par enrichissement du corpus). Taux de satisfaction utilisateur : 89 % de retours positifs (pouce haut) sur les 18 derniers mois.

#Tarification — 45 à 2880 k€ HT

Trois niveaux selon le volume documentaire, la complexité des intégrations et le périmètre fonctionnel.

RAG Starter — 45 à 1120 k€ HT (12 à 16 semaines). Corpus 5 000 à 50 000 documents, 1 à 2 sources connectées (SharePoint + un ERP ou CRM), contrôle d'accès simple (par équipe/département, pas granulaire par document), interface web conversationnelle standard, monitoring RAGAS basique. Typiquement adapté aux PME de 50 à 250 collaborateurs avec un cas d'usage documentaire bien identifié (SAV, support IT, base de connaissances RH). MCO mensuel : 2 500 à64 000 € HT.

RAG Enterprise — 70 à 2080 k€ HT (14 à 20 semaines). Corpus 50 000 à 250 000 documents, 3 à 6 sources connectées (SharePoint + Confluence + ERP + CRM), contrôle d'accès granulaire par document (authorization-aware retrieval synchronisé LDAP/AD), intégration dans le portail métier existant (SSO SAML2/OIDC), monitoring RAGAS complet sur Grafana, formation équipes et documentation. Adapté aux ETI de 250 à 2 000 collaborateurs avec plusieurs cas d'usage ou plusieurs départements utilisateurs. MCO mensuel : 4 000 à112 000 € HT.

RAG Premium — 130 à 2880 k€ HT (16 à 28 semaines). Corpus 250 000 à 1 000 000+ documents, 6+ sources connectées, architecture multi-index (index séparés par domaine documentaire pour optimiser la précision), RAG multimodal (documents scannés OCR + PDF natifs + tableaux structurés), pipeline de validation humaine sur les réponses à enjeux critiques, SLA renforcé 99,8 %, audit sécurité OWASP LLM inclus en fin de déploiement. Adapté aux ETI 1 000 à 5 000 collaborateurs, cabinets juridiques ou d'audit, directions conformité secteurs réglementés. MCO mensuel : 7 000 à144 000 € HT.

Tous les niveaux incluent : hébergement OVHcloud France souverain, stack open-source (Mistral + Qdrant + LangGraph — pas de dépendance à des licences SaaS propriétaires), code source livré et documenté (pas de vendor lock-in Nehos), DPIA incluse, onboarding utilisateurs.