Ce qu'il faut retenir
- Le RAG (Retrieval-Augmented Generation) permet de connecter un LLM à votre documentation interne sans réentraîner le modèle.
- C'est aujourd'hui l'architecture standard pour 80 % des cas d'usage IA générative en entreprise.
- La qualité du RAG dépend à 70 % de la qualité des données source -- pas du modèle LLM utilisé.
- Le choix entre vector search, hybride et BM25 doit être fait selon la nature du corpus, pas par défaut.
- Un RAG mal évalué est un RAG qui hallucine : la mise en place de métriques (recall, précision, fidelity) est indispensable.
Pourquoi le RAG est-il devenu incontournable ?
Quand une entreprise veut utiliser un LLM sur ses propres données (procédures, contrats, documentation produit, historique de tickets, base de connaissance), deux options existent : réentraîner le modèle (fine-tuning) ou lui fournir l'information au moment de la requête (RAG). Le RAG s'est imposé comme standard pour cinq raisons : moins cher, plus rapide à déployer, plus facile à mettre à jour, plus compatible RGPD, et meilleure traçabilité des sources.
Les chiffres publiés par les éditeurs (Anthropic, OpenAI, Mistral) et les intégrateurs convergent : sur les projets entreprise 2024-2026, plus de 80 % des déploiements LLM reposent sur du RAG, pas sur du fine-tuning.
Comment fonctionne le RAG en pratique ?
Un système RAG se décompose en deux phases :
Phase 1 : indexation (offline)
- Les documents source sont découpés en chunks (paragraphes, sections)
- Chaque chunk est transformé en vecteur via un modèle d'embedding
- Les vecteurs sont stockés dans une base vectorielle (Qdrant, Weaviate, Pinecone, pgvector)
Phase 2 : interrogation (temps réel)
- La question de l'utilisateur est transformée en vecteur
- La base vectorielle retourne les N chunks les plus similaires
- Ces chunks sont injectés dans le prompt du LLM
- Le LLM répond en s'appuyant sur ces chunks
Cette architecture a deux vertus : elle borne la réponse du LLM aux documents fournis (moins d'hallucinations), et elle permet de citer les sources.
Quels choix techniques structurants au démarrage ?
Cinq décisions à prendre :
- Le modèle d'embedding : OpenAI ada-3, Mistral embed, BGE, E5. Impact direct sur la qualité du retrieval.
- La base vectorielle : Qdrant (open source, performant), pgvector (si Postgres existe), Pinecone (managed), Weaviate (riche en fonctionnalités).
- La stratégie de chunking : taille fixe (simple mais imparfaite), par paragraphe, par section, hiérarchique. Clé pour la qualité du retrieval.
- La recherche : vectorielle pure, hybride (vectoriel + BM25), reranking. L'hybride donne presque toujours de meilleurs résultats.
- Le LLM final : Claude, GPT-4, Mistral Large -- selon contraintes de coût, latence, confidentialité.
Ces décisions ne sont pas indépendantes : un mauvais chunking ne peut pas être rattrapé par un meilleur modèle.
Pourquoi la qualité des données source compte plus que tout ?
Le RAG hérite mécaniquement de la qualité des documents indexés. Trois problèmes récurrents :
- Documents obsolètes : si vos procédures de 2019 cohabitent avec celles de 2025, le LLM peut citer les anciennes. Solution : métadonnées de version, filtrage temporel.
- Documents incohérents : même information présentée différemment dans plusieurs sources. Le LLM choisit aléatoirement.
- Documents incomplets ou implicites : information évidente pour un humain mais absente du texte ("notre tarif inclut bien sûr la TVA"). Le LLM ne devine pas.
Avant de construire un RAG, il faut auditer le corpus. Ce travail représente souvent 40-60 % de l'effort projet. C'est aussi la phase qui révèle les problèmes de gouvernance documentaire pré-existants.
Comment évaluer un RAG ?
L'erreur la plus répandue : juger le RAG sur quelques cas favoris. Une évaluation sérieuse repose sur trois métriques :
- Recall@K : la bonne information est-elle dans les K chunks remontés ? (souvent K=5 ou 10)
- Précision : les chunks remontés sont-ils pertinents pour la question ?
- Fidelity : la réponse du LLM est-elle fidèle aux chunks fournis, ou hallucine-t-elle ?
Ces métriques se mesurent sur un jeu de test (50 à 500 questions avec réponses attendues), construit avec les utilisateurs métier. Sans ce jeu de test, impossible de savoir si une modification améliore ou dégrade le système.
Quels sont les pièges classiques d'un projet RAG ?
- Sauter l'audit du corpus : on construit un RAG sur des documents qui se contredisent, puis on accuse le LLM.
- Choisir le chunking par défaut : découper tous les documents en 500 tokens est rarement optimal. Adapter au type de contenu.
- Négliger les métadonnées : pouvoir filtrer par date, source, département, niveau de confidentialité change tout.
- Ignorer la latence : un RAG qui répond en 8 secondes est inutilisable. Le retrieval doit être optimisé.
- Ne pas tracer les usages : sans log des requêtes et des réponses, impossible d'améliorer.
Combien coûte un RAG d'entreprise ?
Pour une PME ou ETI, ordres de grandeur typiques :
- Pilote sur un corpus limité (1000-5000 documents) : 30-80 k€ sur 3-4 mois
- Déploiement étendu (50000+ documents, intégration aux outils métier) : 100-300 k€ sur 6-12 mois
- Coûts récurrents : 500-3000 €/mois (infrastructure + API LLM) selon volume d'usage
Les coûts ont fortement baissé depuis 2023 grâce à la maturité des frameworks (LlamaIndex, LangChain, Haystack) et à la baisse des prix des API LLM.
Quel impact concret pour les entreprises ?
Le RAG transforme deux usages principaux : l'assistance interne (support, RH, conformité, technique) et l'assistance client (FAQ avancée, chatbot documenté). Dans les deux cas, le gain mesurable est le même : réduction du temps passé à chercher l'information, augmentation du taux de première réponse correcte, déport des questions répétitives.
Nous accompagnons des PME et ETI sur la définition de leur stratégie IA et le prototypage de cas d'usage RAG. L'enjeu est de choisir le bon périmètre initial -- ni trop ambitieux (corpus immense qui n'est jamais maintenu), ni trop restreint (gain invisible pour les utilisateurs).
Conclusion : le RAG est une discipline d'ingénierie, pas un sujet de modèle
Construire un RAG qui marche réellement n'a rien de magique : c'est un travail rigoureux d'audit documentaire, de choix techniques argumentés, d'évaluation systématique, et d'amélioration continue. Les entreprises qui réussissent traitent le RAG comme un produit qui s'améliore avec l'usage, pas comme un projet à livrer une fois pour toutes.
Lire aussi : Agent IA gratuit : comparatif des outils freemium pour l'entreprise
Vous voulez construire une base de connaissances IA sur votre documentation interne ? Vous avez testé un premier RAG et il hallucine ? Parlons-en -- nous vous aidons à définir votre stratégie IA et à prototyper un RAG avec évaluation rigoureuse.
