Introduction
Le RAG (Retrieval Augmented Generation) est devenu l'architecture de référence pour les entreprises qui veulent utiliser l'IA générative sur leurs propres données. Le principe : au lieu de se fier uniquement aux connaissances encodées dans le modèle de langage, on va chercher l'information pertinente dans la base documentaire de l'entreprise, puis on la passe au modèle pour générer une réponse contextualisée.
C'est ce qui fait la différence entre un ChatGPT générique et un assistant IA qui connaît vos produits, vos clients et vos processus.
Mais entre le concept et un déploiement fiable en production, il y a un écart considérable. Ce guide couvre les cinq étapes clés d'un projet RAG en entreprise, avec les choix techniques qui comptent à chaque étape.
1. Architecture d'un système RAG
Un pipeline RAG se décompose en deux flux :
Flux d'indexation (offline)
- Collecte des documents sources : PDF, pages web internes, wikis, emails archivés, fichiers Office, bases de données.
- Extraction du texte : parsing des différents formats avec préservation de la structure (titres, paragraphes, tableaux).
- Découpage en chunks : segmentation du texte en morceaux de taille optimale pour la recherche.
- Génération des embeddings : transformation de chaque chunk en vecteur numérique.
- Stockage dans une base vectorielle : indexation des vecteurs pour permettre la recherche par similarité.
Flux de requête (online)
- L'utilisateur pose une question en langage naturel.
- La question est transformée en vecteur (embedding).
- Les chunks les plus similaires sont récupérés depuis la base vectorielle.
- Les chunks pertinents sont injectés dans le prompt envoyé au modèle de langage.
- Le modèle génère une réponse basée sur le contexte fourni.
Cette architecture sépare clairement la connaissance (vos données) du raisonnement (le modèle). C'est ce qui permet de garder le contrôle sur vos données tout en bénéficiant des capacités de génération des LLM.
2. Stratégie de chunking
Le chunking est l'étape la plus sous-estimée d'un projet RAG — et celle qui a le plus d'impact sur la qualité des réponses.
Les approches courantes
| Méthode | Principe | Quand l'utiliser |
|---|---|---|
| Taille fixe | Découper tous les N tokens avec chevauchement | Documents homogènes (articles, FAQ) |
| Par structure | Suivre les titres, paragraphes, sections | Documents structurés (rapports, manuels) |
| Sémantique | Regrouper par cohérence thématique | Documents longs et hétérogènes |
| Récursif | Découper progressivement du plus gros au plus fin | Cas général, bon compromis |
Recommandations pratiques
- Taille optimale : entre 256 et 1024 tokens par chunk selon le cas d'usage. Les chunks trop courts perdent le contexte ; les chunks trop longs diluent la pertinence.
- Chevauchement : 10 à 20 % de chevauchement entre les chunks adjacents pour éviter de couper une information en deux.
- Métadonnées : enrichir chaque chunk avec sa source, sa date, son auteur, et sa position dans le document. Ces métadonnées permettent un filtrage pré-recherche indispensable en entreprise.
- Test et itération : il n'y a pas de stratégie universelle. Testez plusieurs configurations sur un échantillon représentatif de vos documents et mesurez la qualité des réponses.
3. Choix du modèle d'embedding
Le modèle d'embedding détermine la qualité de la recherche sémantique. C'est lui qui transforme du texte en vecteurs et qui définit donc ce que le système considère comme "similaire".
Critères de choix
- Langue : pour des données en français, privilégiez des modèles entraînés ou fine-tunés sur du français. Les modèles multilingues récents (comme les séries E5, BGE, ou les modèles de Mistral et Voyage AI) fonctionnent bien.
- Dimension des vecteurs : plus la dimension est élevée, plus le modèle capture de nuances — mais plus le stockage et la recherche coûtent cher. 768 à 1536 dimensions est un bon compromis.
- Performance sur vos données : le benchmark MTEB donne une indication, mais rien ne remplace un test sur votre propre corpus. Un modèle excellent sur des articles scientifiques peut être médiocre sur des emails commerciaux.
- Déploiement : certains modèles peuvent tourner localement (Sentence Transformers, Ollama), d'autres nécessitent un appel API (OpenAI, Cohere, Voyage AI). Le choix dépend de vos contraintes de confidentialité et de latence.
Attention aux pièges
- Ne mélangez pas les modèles d'embedding entre l'indexation et la requête. Le même modèle doit être utilisé pour les deux.
- Ré-indexer tout le corpus quand vous changez de modèle d'embedding. Les vecteurs ne sont pas interchangeables.
4. Base de données vectorielle
La base vectorielle stocke les embeddings et exécute les recherches par similarité. Le choix dépend de votre volume de données, de vos contraintes d'infrastructure et de votre stack technique.
Comparatif des solutions courantes
| Solution | Type | Hébergement | Points forts |
|---|---|---|---|
| Qdrant | Dédié | Self-hosted ou cloud | Performance, filtrage avancé, Rust natif |
| Weaviate | Dédié | Self-hosted ou cloud | Recherche hybride, modules IA intégrés |
| Pinecone | Dédié | Cloud managé | Simplicité, serverless, scaling automatique |
| pgvector | Extension | Self-hosted (PostgreSQL) | Intégration PostgreSQL existant, SQL familier |
| ChromaDB | Dédié | Local / embedded | Prototypage rapide, léger |
Recommandations pour l'entreprise
- Prototypage : ChromaDB ou pgvector pour valider le concept rapidement sans infrastructure supplémentaire.
- Production PME : pgvector si vous avez déjà PostgreSQL, Qdrant si vous voulez une solution dédiée performante.
- Production grande échelle : Qdrant ou Weaviate en cluster, ou Pinecone si vous préférez le managé.
N'oubliez pas la recherche hybride : combiner la recherche vectorielle (sémantique) avec la recherche par mots-clés (BM25) améliore significativement la pertinence, surtout sur des termes techniques ou des acronymes spécifiques à votre métier.
5. Évaluation et amélioration continue
Un système RAG en production sans évaluation est un système dont vous ne connaissez pas la fiabilité. Et en entreprise, la fiabilité n'est pas optionnelle.
Métriques clés
- Recall : le système retrouve-t-il les chunks pertinents ? Testez avec un jeu de questions-réponses de référence.
- Précision : les chunks retournés sont-ils effectivement pertinents, ou y a-t-il du bruit ?
- Fidélité (faithfulness) : la réponse générée est-elle fidèle aux chunks fournis, ou le modèle hallucine-t-il ?
- Pertinence de la réponse : la réponse répond-elle réellement à la question posée ?
Outils d'évaluation
- RAGAS : framework open source dédié à l'évaluation RAG (faithfulness, answer relevancy, context precision, context recall).
- LangSmith ou Langfuse : plateformes d'observabilité pour tracer chaque requête, les chunks récupérés, et la réponse générée.
- Évaluation humaine : indispensable en complément des métriques automatiques. Faites relire un échantillon de réponses par des experts métier.
Boucle d'amélioration
- Collecter les questions utilisateurs et les retours (pouce haut/bas).
- Identifier les cas d'échec : mauvais chunks récupérés, hallucinations, questions hors périmètre.
- Ajuster la stratégie de chunking, les métadonnées, ou le prompt système.
- Ré-évaluer et itérer.
Conclusion
Déployer un RAG en entreprise n'est pas un projet de week-end, mais ce n'est pas non plus un programme de R&D de 18 mois. Avec la bonne architecture, une stratégie de chunking adaptée à vos documents, un modèle d'embedding performant sur le français, et un processus d'évaluation continue, un premier système RAG fonctionnel peut être en production en 4 à 8 semaines.
Les clés du succès : commencer petit (un corpus limité, un cas d'usage précis), mesurer la qualité dès le début, et itérer rapidement.
Chez The Shift AI, nous intégrons le RAG dans nos agents Donna et Jarvis pour qu'ils accèdent aux données spécifiques de chaque client. Si vous envisagez un projet RAG dans votre organisation, parlons-en — nous pouvons vous aider à cadrer l'architecture et éviter les écueils les plus courants.
Sources et références
- Anthropic — Contextual Retrieval : le Contextual Retrieval réduit les échecs de récupération de 49 %, et jusqu'à 67 % avec reranking. anthropic.com
- Towards Data Science — Six Lessons Learned Building RAG in Production : 80 % des échecs RAG proviennent des décisions de chunking, pas de la récupération ni de la génération. towardsdatascience.com
- Jason Liu — Systematically Improving RAG Applications : méthode systématique pour améliorer un RAG en production — mesurer le recall, segmenter les échecs, router les requêtes, boucler avec le feedback utilisateur. jxnl.co
- Benchmarks MTEB-French 2026 : Qwen3-Embedding-8B domine avec un score de 69,8, devant Gemini Embedding (66,2), Cohere Embed v4 (65,8) et OpenAI text-embedding-3-large (62,4). ailog.fr
- Comparatif bases vectorielles 2026 : Qdrant offre la latence la plus basse (30-40 ms à 100M vecteurs), Weaviate propose le hybrid search natif le plus mature, Pinecone reste le choix le plus simple pour démarrer. firecrawl.dev
- @jxnlco — « Most RAG systems are just recommendation systems in disguise. » Les vrais systèmes doivent combiner des encodeurs spécialisés au lieu de tout forcer à travers des modèles texte.
- @jxnlco — « RAG is overrated. Reports are the real game-changer. » L'avenir de l'IA n'est pas le chat, c'est de créer le template de rapport parfait.
- @weaviate_io — Late chunking : encoder le document entier avant de découper les embeddings, pour préserver le contexte inter-chunks que le chunking classique perd.
