RAG en entreprise : exploiter vos bases documentaires sans fuiter vos données

Imaginez un assistant qui, à chaque question, va d'abord chercher les bons documents dans votre base interne, lit les passages pertinents, puis vous formule une réponse en s'appuyant explicitement sur ces passages. C'est exactement ce que fait un RAG.

Sous le capot, deux étapes : la recherche (retrieval) qui sélectionne les passages les plus proches de la question dans une base vectorielle, et la génération (generation) qui demande au LLM de produire une réponse en utilisant uniquement ces passages comme contexte. La sortie peut inclure les sources, ce qui rend la réponse vérifiable.

Le RAG répond à un problème concret : un LLM seul ne connaît pas vos documents internes, ne peut pas les apprendre sans entraînement coûteux, et hallucine quand on lui pose des questions sur un sujet qu'il ne connaît pas. Le RAG résout les trois problèmes en injectant la connaissance fraîche au moment de la requête.

Quatre briques distinctes et complémentaires, souvent confondues dans le marketing IA :

• LLM (Large Language Model) : un modèle entraîné qui génère du texte. Connaît le monde général, ne connaît pas vos documents.
• Recherche sémantique : trouve les passages dont le sens est proche d'une requête, pas seulement les mots. Repose sur des embeddings (vecteurs numériques qui représentent le sens d'un texte).
• Vector database : stocke les embeddings de vos documents et permet de retrouver très vite les plus proches d'une requête. Exemples : pgvector (PostgreSQL), Qdrant, Weaviate, Pinecone.
• RAG : l'architecture qui combine recherche sémantique + LLM, avec des étapes intermédiaires (réécriture de la requête, filtrage, reranking, citation des sources).
• Un bon RAG, ce n'est pas seulement un LLM branché sur une base vectorielle. C'est une chaîne d'étapes orchestrées, chacune mesurée et améliorable indépendamment.

Trois raisons principales. D'abord, la valeur cachée des documents internes : la plupart des PME et ETI ont accumulé des milliers de documents (procédures, contrats, retours d'expérience, support, RH) que personne ne retrouve. Le RAG en fait un actif activable, sans imposer une refonte de la base documentaire.

Ensuite, la maintenance. Un RAG se met à jour à chaque ajout ou modification d'un document : il suffit de re-indexer. C'est radicalement plus simple qu'un fine-tuning de LLM, qui doit être refait à chaque changement majeur de contenu et coûte plusieurs milliers d'euros à chaque itération.

Enfin, la traçabilité. Un RAG bien conçu cite ses sources : l'utilisateur sait sur quels documents la réponse s'appuie, peut vérifier, et peut signaler les erreurs. Cette traçabilité est indispensable dans les contextes réglementés (santé, finance, secteur public) et utile partout.

Un RAG ne crée pas de la valeur à partir de rien. Il a besoin de documents exploitables et d'une gouvernance d'accès claire. Sans ces deux conditions, le projet s'enlise.

Côté données : il faut au minimum quelques centaines à quelques milliers de documents pertinents, dans des formats lisibles (PDF, Word, Markdown, HTML, plutôt que scans non OCRisés ou présentations PowerPoint mal structurées). Les documents obsolètes doivent être identifiés, sinon le RAG répondra avec des informations périmées.

Côté droits d'accès : chaque document a des permissions (qui peut le lire ?). Un RAG d'entreprise doit respecter ces permissions au moment de la recherche : un commercial ne doit pas voir un document RH confidentiel via une question naïve. Cette gestion des accès est souvent le sujet le plus complexe d'un projet RAG, surtout en environnement Microsoft 365.

Côté sécurité : choix du LLM (offre entreprise sans réutilisation des données), choix de l'hébergement (cloud public, votre tenant, on-premise), chiffrement des embeddings, journalisation des requêtes. Le RAG n'est pas plus risqué qu'un autre système IA, mais il manipule potentiellement de la donnée sensible.

Le RAG a plusieurs déclinaisons selon le périmètre fonctionnel et l'audience.

• Support client : RAG sur la documentation produit, les FAQ et les tickets résolus. Aide le support N1, peut alimenter un agent autonome pour les questions simples.
• RH : RAG sur les politiques, processus, conventions collectives. Réduit massivement les questions répétitives aux RH, surtout en phase d'onboarding.
• Knowledge base interne : RAG sur Confluence, Notion, SharePoint, drives. L'usage le plus courant et le plus rentable.
• Documentation produit / R&D : RAG sur les specs, designs, retours utilisateurs. Accélère la discovery et le travail des PM.
• Slack / Teams : RAG sur l'historique des conversations (avec respect des droits). Très utile en équipes techniques pour retrouver des décisions passées.
• CRM : RAG sur les notes commerciales, mails, contrats. Permet à un commercial de retrouver instantanément le contexte d'un client.
• Base métier spécifique : RAG sur des bases sectorielles (juridique, médical, technique). Souvent combiné à des règles métier pour éviter les hallucinations à fort impact.

Le RAG réduit fortement les hallucinations par rapport à un LLM seul, mais ne les supprime pas. Quand la base ne contient pas l'information cherchée, un LLM mal cadré peut inventer une réponse plausible. La parade : forcer le modèle à répondre 'je ne sais pas' quand les passages retrouvés ne couvrent pas la question, et afficher les sources systématiquement.

La fraîcheur des données dépend du processus d'indexation. Si vos documents évoluent en continu, l'indexation doit être incrémentale et idéalement temps réel. Beaucoup de RAG en production fonctionnent avec une indexation hebdomadaire, ce qui est suffisant pour la plupart des cas mais inacceptable pour d'autres (support produit en évolution rapide, par exemple).

La gouvernance des accès est le piège classique. Un RAG mal configuré peut exposer des documents confidentiels à des utilisateurs non autorisés via la sortie du LLM, même si la source ne s'affiche pas. La conception doit intégrer ce point dès le premier sprint, pas en post-livraison.

Enfin, le RAG a un coût récurrent : embeddings (typiquement 0,01 à 0,10 € par million de tokens), stockage vectoriel, appels LLM à chaque requête. Sur un usage à 10 000 requêtes/mois, comptez 200 à 1 500 € mensuels selon le modèle et la taille des contextes.

Nous traitons un projet RAG comme un projet produit, pas comme un projet d'intégration technique. Cela change tout : on commence par le cas d'usage, l'utilisateur cible et le critère de qualité, puis on choisit la stack.

• Cadrage (1 à 2 semaines) : périmètre documentaire, persona utilisateur, scénarios, critère de qualité (taux de réponses correctes attendu).
• Construction du gold standard (1 semaine) : 50 à 100 questions/réponses validées par des experts métier, qui servent à mesurer la qualité du RAG tout au long du projet.
• Indexation et architecture (2 à 3 semaines) : pipeline d'extraction de texte, chunking, embeddings, vector store, intégration des permissions.
• Première version interrogeable (2 à 3 semaines) : interface basique, mesure sur le gold standard, premiers ajustements (chunking, reranking, prompt).
• Pilote contrôlé (3 à 5 semaines) : 10 à 30 utilisateurs réels, recueil des retours, amélioration continue.
• Mise en production : interface définitive, observabilité, plan de mise à jour des index, formation utilisateurs.

Le RAG, les agents IA et l'automatisation ne sont pas concurrents, ils sont complémentaires. Un système IA d'entreprise mature combine généralement les trois.

Le RAG fournit la couche de connaissance : il transforme vos documents en un service interrogeable, utilisé par tout le reste du système. Un agent IA s'appuie sur le RAG pour décider en connaissance de cause. Une automatisation classique enclenche les actions déterministes (créer un ticket, envoyer un mail, mettre à jour un statut).

Exemple concret : un agent de support reçoit un ticket → interroge le RAG pour trouver les éléments de réponse dans la documentation et les tickets résolus → décide d'une action (répondre, escalader, créer une tâche) → déclenche l'automatisation correspondante. Le RAG est la fondation, l'agent est le décideur, l'automatisation est l'exécutant.

PME industrielle (180 salariés) : RAG sur 8 000 documents qualité, procédures et contrats. Réduit de 60 % le temps passé par les responsables qualité à chercher de l'information. Investissement : 38 000 € + 280 €/mois de coûts récurrents.

Scale-up SaaS (60 salariés) : RAG sur Confluence, Notion et historique Slack des équipes tech et produit. Utilisé quotidiennement par 45 collaborateurs. Particulièrement utile pour les nouveaux arrivants. Investissement : 32 000 €.

ETI services (450 salariés) : RAG juridique sur la base contrats et la jurisprudence interne, avec gestion fine des droits par direction. Réduit le temps de recherche moyen de 22 à 4 minutes par requête. Investissement : 75 000 €, justifié par un volume de 3 500 requêtes/mois.

Le RAG est le cas d'usage IA le plus mature en entreprise : il transforme vos documents internes en un service interrogeable, sans fuiter vos données et sans réentraîner de modèle. Il se déploie en 8 à 14 semaines pour un budget de 30 000 à 90 000 €, avec un coût récurrent maîtrisé.

Les conditions de succès tiennent en trois points : un périmètre documentaire défini et de qualité, une gouvernance d'accès intégrée dès la conception, et une mesure continue de la qualité sur un gold standard. Sans ces trois conditions, le RAG produit des résultats inégaux et perd la confiance des utilisateurs en quelques mois.