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 — plusieurs semaines et un coût de calcul GPU à chaque run). 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 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.

Nous qualifions 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 — 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. Nous utilisons 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 : bonne performance sur le français (à valider sur votre corpus par un test comparatif), et possibilité d'hébergement souverain.

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. 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. Le gain se mesure pendant le POC : temps de recherche documentaire avant et après, et taux de réponses non sourcées via la métrique de fidélité RAGAS (faithfulness).

#2. Assistant commercial RAG sur catalogues produits et ERP

Les équipes commerciales d'ETI industrielles ou de distributeurs passent un temps important à 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 longtemps.

#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 vise à réduire le MTTR (Mean Time To Resolution) ; on le mesure avant et après.

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 — vise à réduire le volume de tickets RH de premier niveau (voir 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 : on y trouve des PDFs scannés (contrats papier numérisés, factures, bons de commande, dossiers techniques anciens), des PDFs natifs (documents Word ou InDesign exportés) et des fichiers Office directement. Notre pipeline RAG traite les trois cas : OCR via Surya (modèle OCR open-source, souvent plus adapté que Tesseract aux 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 — peut être hébergé en France chez un hébergeur de confiance, par exemple OVHcloud (régions GRA ou SBG), voire chez un hébergeur qualifié SecNumCloud si votre contexte l'exige.

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 — c'est une contrainte d'architecture.

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 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 indicative à fixer avec vous : faithfulness élevée en production. Une faithfulness en baisse 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 à fixer avec vous. Context Precision (précision du contexte) : les chunks récupérés sont-ils tous utiles à la réponse, sans bruit inutile ? Cible à fixer avec vous. 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 à fixer avec vous. 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) : sur les cas d'usage à enjeux (juridique, compliance, médical), nous fixons avec vous un objectif strict. Latence p50/p95/p99 : les seuils se fixent avec vous pour une requête RAG complète (retrieval + génération) ; une latence trop longue fait chuter l'adoption.

Taux de "je ne sais pas" (no-answer rate) : un taux trop élevé 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 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 avec alertes PagerDuty si la faithfulness passe sous le seuil convenu ou si la latence 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, audit IA approfondi à partir de 2 125 € 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, à partir de 11 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 un environnement 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, sur devis selon le scope). Indexation full-corpus (selon le volume du 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 (maintenance à partir de 750 €/mois). SLA contractuel défini avec vous, 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, audit sécurité annuel (sécurité OWASP LLM).

#Exemple de situation — un cabinet juridique et sa base documentaire

Prenons un cabinet juridique d'une centaine de personnes, spécialisé en droit des affaires et propriété intellectuelle. Son corpus documentaire compte des dizaines de milliers de documents : 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 : chaque avocat perd un temps important sur les requêtes documentaires complexes (recherche dans les drives SharePoint, dans une base de jurisprudence interne, comparaison manuelle entre versions de contrats). Il s'agit d'un exemple de situation, pas d'un client cité.

La démarche : un POC de 3 semaines sur un périmètre pilote (contrats et jurisprudence uniquement), puis un MVP qui indexe le corpus complet, intègre SharePoint et les autres sources, ajoute une interface conversationnelle dans le portail interne du cabinet et un contrôle d'accès par dossier client et par rôle.

Ce que nous mesurons, sans le promettre à l'avance : le temps moyen de recherche documentaire avant et après, les métriques RAGAS en production (faithfulness, answer relevancy), le taux de « je ne sais pas » (qui signale les documents manquants à ajouter au corpus) et la satisfaction des utilisateurs via un retour inline (pouce haut ou bas). Le temps récupéré par avocat se convertit ensuite en capacité facturable ou en qualité de mission : c'est au cabinet d'en décider.

#Tarification — POC à partir de 11 000 € HT

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

RAG Starter — à partir de 11 000 € HT (12 à 16 semaines). Corpus de quelques milliers à quelques dizaines de milliers de 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.

Adapté aux PME avec un cas d'usage documentaire bien identifié (SAV, support IT, base de connaissances RH). Maintenance à partir de 750 €/mois.

RAG Enterprise — sur devis, chiffré en 48 h après un premier échange (14 à 20 semaines). Corpus plus volumineux, 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 avec plusieurs cas d'usage ou plusieurs départements utilisateurs.

RAG Premium — à partir de 50 000 € HT (16 à 28 semaines). Très grand corpus, 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é, audit sécurité OWASP LLM inclus en fin de déploiement. Adapté aux grandes ETI, cabinets juridiques ou d'audit, directions conformité de secteurs réglementés.

Tous les niveaux incluent : hébergement européen au choix (par exemple OVHcloud France), 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), DPIA incluse, onboarding utilisateurs.