RAG en entreprise : construire un assistant IA sur vos données

Le LLM seul ne suffit pas

Vous avez testé ChatGPT. Impressionnant. Vous avez voulu l’appliquer à vos données internes. Catastrophe. Le modèle hallucine, invente des procédures qui n’existent pas, cite des documents fictifs.

C’est normal. Un LLM (Large Language Model) est entraîné sur des données publiques. Il ne connaît ni vos processus internes, ni votre documentation technique, ni vos contrats clients. Et le fine-tuning ? Trop coûteux, trop rigide, obsolète dès que vos données changent.

La solution s’appelle RAG — Retrieval-Augmented Generation. Le principe : au lieu de tout injecter dans le modèle, on va chercher l’information pertinente dans vos données, puis on la fournit au LLM comme contexte pour générer une réponse fiable.

Le RAG transforme un LLM généraliste en expert de votre entreprise, sans ré-entraînement.

Architecture RAG : les 4 étapes clés

1. Ingestion et chunking

Tout commence par vos données. Documents PDF, pages Confluence, tickets Jira, bases de connaissances, emails archivés. Ces documents sont découpés en chunks — des morceaux de texte de taille optimale.

Le chunking est critique. Trop petit : le contexte est perdu. Trop grand : le bruit noie le signal.

Stratégies de chunking efficaces :

• Chunking par paragraphes sémantiques — Respecte la structure logique du document. Le plus fiable pour des documents techniques.
• Chunking à fenêtre glissante — Overlap de 10-20% entre chunks pour ne pas couper une idée en deux.
• Chunking récursif — Découpe d’abord par sections, puis par paragraphes, puis par phrases. Adaptatif et performant.
• Chunking par tokens — Taille fixe en tokens (512-1024). Simple mais moins sémantique.

La taille optimale dépend de votre cas d’usage. Pour de la documentation technique : 512-1024 tokens. Pour du support client : 256-512 tokens. Testez, mesurez, itérez.

2. Embedding vectoriel

Chaque chunk est transformé en vecteur — une représentation numérique qui capture le sens sémantique du texte. Deux textes qui parlent du même sujet auront des vecteurs proches, même s’ils utilisent des mots différents.

Choisir son modèle d’embedding :

• OpenAI text-embedding-3-large — Référence du marché. 3072 dimensions, excellent en multilingue. Coût modéré.
• Cohere Embed v3 — Très performant, bon rapport qualité/prix. Supporte nativement le français.
• BGE-M3 (open source) — Hébergeable en interne. Idéal si vos données ne doivent pas quitter votre infrastructure.
• Mistral Embed — Solution européenne, conforme RGPD nativement. Performances solides.

Pour une entreprise française manipulant des données sensibles, la question de la souveraineté est centrale. Privilégiez un modèle hébergeable on-premise ou un fournisseur européen.

3. Stockage dans une base vectorielle

Les vecteurs sont stockés dans une base de données vectorielle optimisée pour la recherche par similarité.

Comparatif des solutions :

• pgvector (extension PostgreSQL) — Vous avez déjà Postgres ? Commencez par là. Simple, intégré, suffisant jusqu’à 1 million de vecteurs. Pas d’infrastructure supplémentaire.
• Pinecone — Managé, scalable, performant. La solution la plus simple en SaaS. Coût proportionnel au volume.
• Weaviate — Open source, hybride (vecteur + full-text). Excellent pour des recherches combinées. Hébergeable en interne.
• Qdrant — Open source, très performant, filtrage avancé. Bon choix pour des architectures complexes avec métadonnées riches.
• ChromaDB — Léger, idéal pour le prototypage. Ne pas utiliser en production à grande échelle.

Commencez avec pgvector pour valider votre POC. Migrez vers une solution dédiée quand les performances ou le volume l’exigent.

4. Retrieval et génération

Quand un utilisateur pose une question, le système :

1. Encode la question en vecteur avec le même modèle d’embedding.
2. Recherche les chunks les plus similaires dans la base vectorielle (top-k, typiquement k=5 à 10).
3. Construit un prompt avec la question + les chunks récupérés comme contexte.
4. Génère la réponse via le LLM, en s’appuyant strictement sur le contexte fourni.

La qualité du retrieval fait 80% de la qualité de la réponse finale. Un mauvais retrieval = une mauvaise réponse, quel que soit le LLM.

Techniques avancées pour un RAG production-grade

Hybrid search : le meilleur des deux mondes

La recherche purement vectorielle a ses limites. Elle rate parfois des correspondances exactes (noms de produit, codes internes, acronymes). La solution : combiner recherche vectorielle et recherche full-text (BM25).

Cette recherche hybride utilise un algorithme de fusion (Reciprocal Rank Fusion) pour combiner les résultats des deux approches. Résultat : +15-25% de recall sur la plupart des benchmarks.

Re-ranking

Les résultats du retrieval initial sont repassés dans un modèle de re-ranking (Cohere Rerank, BGE-Reranker) qui réordonne les chunks par pertinence réelle par rapport à la question. Coût additionnel minime, gain de précision significatif.

Query expansion et reformulation

L’utilisateur pose rarement la question optimale. Un module de query expansion reformule la question en plusieurs variantes pour maximiser les chances de trouver les bons chunks. Exemple : “congés” devient aussi “vacances”, “RTT”, “absence”, “jours de repos”.

Metadata filtering

Chaque chunk embarque des métadonnées : source, date, département, niveau de confidentialité. Le système filtre les résultats avant le re-ranking pour ne retourner que les documents auxquels l’utilisateur a accès.

C’est la clé de la sécurité et du contrôle d’accès en RAG entreprise. Un commercial ne doit pas voir les documents RH. Un stagiaire ne doit pas accéder aux données financières confidentielles.

Évaluer et monitorer un système RAG

Les métriques qui comptent

Sans évaluation rigoureuse, vous ne saurez jamais si votre RAG fonctionne. Voici les métriques essentielles :

• Faithfulness (fidélité) — La réponse est-elle cohérente avec les chunks récupérés ? Mesure les hallucinations.
• Answer relevance — La réponse répond-elle effectivement à la question posée ?
• Context precision — Les chunks récupérés sont-ils pertinents pour la question ?
• Context recall — Les chunks nécessaires pour répondre sont-ils tous récupérés ?

Des frameworks comme RAGAS ou DeepEval automatisent ces évaluations. Intégrez-les dans votre CI/CD.

Monitoring en production

Un RAG qui fonctionne en mars peut dégrader en juin si les données sources changent. Monitorez en continu :

• Taux de questions sans réponse — L’utilisateur n’obtient pas de résultat pertinent.
• Latence p95 — Le temps de réponse perçu par l’utilisateur.
• Coût par requête — Embeddings + LLM + infrastructure.
• Feedback utilisateur — Thumbs up/down sur chaque réponse. La métrique la plus fiable.

Réduire les hallucinations

L’hallucination est le risque numéro 1 d’un système RAG. Voici les garde-fous :

1. Instruction explicite dans le prompt — “Réponds uniquement à partir du contexte fourni. Si l’information n’est pas dans le contexte, dis-le.”
2. Citation des sources — Chaque réponse cite le document source. L’utilisateur peut vérifier.
3. Score de confiance — Calculez un score basé sur la similarité cosinus des chunks récupérés. Sous un seuil, affichez un avertissement.
4. Modération post-génération — Un second LLM vérifie que la réponse est cohérente avec le contexte. Double contrôle automatisé.

Un RAG bien conçu réduit les hallucinations de 80-90% par rapport à un LLM utilisé seul. Le risque zéro n’existe pas, mais le risque maîtrisé, oui.

Déploiement en production : les patterns qui fonctionnent

Architecture de référence

Pour un déploiement enterprise, visez cette stack :

• API Gateway — Authentification, rate limiting, logging.
• Service de retrieval — Microservice dédié, scalable horizontalement.
• Cache sémantique — Les questions similaires réutilisent les réponses précédentes. Réduction de 30-40% des appels LLM.
• Queue asynchrone — Pour l’ingestion de nouveaux documents sans impacter les requêtes.
• Observabilité — Traces distribuées (LangSmith, Langfuse) pour debugger chaque étape du pipeline.

Coûts à anticiper

Le coût d’un RAG en production n’est pas que le LLM. Décomposition typique pour 10 000 requêtes/jour :

• Embeddings — 5-15% du coût total. Amortis car calculés une seule fois par document.
• Base vectorielle — 10-20%. Dépend du volume de vecteurs et des requêtes par seconde.
• LLM (génération) — 50-70%. Le poste principal. Optimisez la taille du contexte et le choix du modèle.
• Infrastructure — 10-20%. Serveurs, cache, monitoring.

Pour un usage enterprise moyen, comptez entre 2 000 et 8 000 euros par mois. Le ROI se mesure en heures de travail économisées par les équipes qui n’ont plus à chercher l’information manuellement.

Par où commencer

1. Identifiez un cas d’usage précis — Documentation technique interne, FAQ support, base de connaissances RH. Un seul cas, bien défini.
2. Constituez un jeu de test — 50 à 100 couples question/réponse attendue. Indispensable pour mesurer la qualité.
3. Démarrez simple — pgvector + OpenAI embeddings + GPT-4o. Pas de sur-ingénierie au départ.
4. Mesurez, itérez — Évaluez avec RAGAS, collectez le feedback utilisateur, améliorez le chunking et le retrieval.
5. Industrialisez — Une fois le POC validé, migrez vers une architecture production avec monitoring et sécurité.

Chez Les Artisans du Digital, on accompagne les entreprises de la phase exploratoire au déploiement production de systèmes RAG. Notre approche : architecturer juste, mesurer tout, itérer vite.

FAQ

Le RAG est-il adapté à toutes les entreprises ?

Le RAG est pertinent dès que vous avez une base documentaire interne conséquente (> 100 documents) et des équipes qui passent du temps à chercher de l’information. PME ou grand groupe, le cas d’usage dicte la complexité de l’architecture, pas la taille de l’entreprise. Un RAG simple avec pgvector peut se déployer en 2 semaines.

Quelle est la différence entre RAG et fine-tuning ?

Le fine-tuning modifie les poids du modèle pour qu’il intègre vos connaissances. C’est coûteux, rigide, et doit être refait à chaque mise à jour des données. Le RAG garde le modèle intact et lui fournit le contexte pertinent à chaque requête. C’est plus flexible, moins cher, et les données restent toujours à jour. En pratique, 90% des cas d’usage enterprise se résolvent mieux avec du RAG qu’avec du fine-tuning.

Comment gérer la confidentialité des données avec un RAG ?

Trois niveaux de protection. D’abord, le contrôle d’accès : chaque chunk porte des métadonnées de permission, et le système filtre les résultats selon le profil de l’utilisateur. Ensuite, le choix d’infrastructure : modèle d’embedding et LLM hébergeables on-premise ou chez un fournisseur européen (Mistral, OVH). Enfin, le chiffrement : données chiffrées au repos et en transit, logs anonymisés. La conformité RGPD est atteignable avec une architecture bien pensée dès le départ.

Combien de temps faut-il pour mettre en production un RAG ?

Comptez 2 à 4 semaines pour un POC fonctionnel sur un périmètre restreint. 2 à 3 mois pour une version production avec sécurité, monitoring et intégration dans vos outils existants. Le facteur limitant est rarement la technique — c’est la qualité et l’accessibilité de vos données sources. Préparez vos données avant de coder.