RAG : comment construire une base de connaissance qui rend votre chatbot vraiment utile

En 2026, la grande majorité des chatbots IA déployés en entreprise reposent sur du RAG (Retrieval-Augmented Generation). Pourtant, dans nos audits, nous constatons un écart énorme entre les projets qui fonctionnent et ceux qui végètent : ce n'est presque jamais le LLM qui pose problème. C'est la base de connaissance. Un même GPT-4 Turbo ou un même Mistral Large 2, branché sur deux pipelines RAG différents, peut produire un assistant brillant ou un générateur d'hallucinations poli. La différence se joue à 90 % dans l'ingénierie du retrieval.

Cet article est un guide technique pour bâtir un RAG qui rend votre chatbot réellement utile. Nous y détaillons six étapes : audit des sources, chunking, embeddings, base vectorielle, reranking, évaluation. Chaque étape porte un arbitrage concret avec des trade-offs documentés et des chiffres issus de nos projets. L'objectif : vous donner les bonnes questions à poser avant de signer un budget RAG, et les bons signaux pour détecter qu'un projet existant déraille.

Pourquoi le RAG est devenu l'étape décisive en 2026

Les LLM frontaliers ont massivement progressé, mais ils restent fondamentalement ignorants de votre métier. Un assistant interne utile doit répondre sur la base de votre documentation, vos procédures, vos contrats, vos produits. Le fine-tuning reste lourd, coûteux et peu agile face à des sources qui évoluent chaque semaine. Le RAG s'est imposé parce qu'il offre le bon compromis : injecter le contexte pertinent au moment de la requête, sans toucher au modèle, avec une mise à jour quasi temps réel possible.

Mais le RAG est un système complexe à plusieurs étages. Chaque étage peut dégrader l'ensemble. Une source mal nettoyée, un chunking grossier, un embedding inadapté au français, une base vectorielle mal configurée, l'absence de reranking, et la réponse finale sera décevante même si le LLM est excellent. C'est pourquoi nous traitons toujours le RAG comme une discipline d'ingénierie à part entière, avec son cycle de mesure et d'amélioration continue.

1. Auditer et nettoyer les sources

Tout commence par le corpus. Un chatbot RAG n'invente rien : il sélectionne, reformule et synthétise ce que vous lui donnez. Si la documentation interne contient trois versions contradictoires d'une procédure, le RAG ressortira aléatoirement l'une des trois. S'il existe un PDF obsolète de 2019 oublié dans un SharePoint, il finira par le citer. Notre première étape, systématique, est un audit documentaire : cartographier les sources, identifier les doublons, marquer les contenus obsolètes, repérer les contradictions.

Concrètement, nous fonctionnons par lots : 200 à 500 documents passés en revue par un binôme métier-tech, avec une grille de qualification (faisant autorité ? à jour ? cohérent ?). Ce travail est ingrat mais déterminant. Les projets qui sautent cette étape ne rattrapent jamais le retard : ils empilent des couches techniques pour compenser un corpus malade.

• Supprimer les doublons exacts et quasi-doublons
• Marquer les contenus obsolètes avec une date d'expiration
• Trancher les contradictions avec le métier (validation explicite)
• Normaliser les formats (Markdown propre plutôt que PDF scannés)

2. Choisir une stratégie de chunking

Le chunking est l'opération qui découpe chaque document en fragments indexables. Trois paramètres comptent : la taille, l'overlap et la stratégie. Trop petit (sous 200 tokens), chaque chunk perd son contexte et le retrieval ramène des fragments incohérents. Trop grand (au-delà de 1500 tokens), les chunks deviennent flous et l'embedding moyenne trop d'idées différentes. Notre fourchette par défaut : 512 tokens avec un overlap de 64 à 128 tokens. Mais cette valeur n'est jamais sacrée : nous la calibrons sur le golden dataset.

La stratégie compte autant que la taille. Un chunking fixed (toutes les N tokens) est rapide à implémenter mais brutal sur les documents structurés. Un chunking semantic (basé sur des embeddings de phrases) respecte mieux les unités de sens. Un chunking structure-aware (qui exploite les balises HTML, les titres Markdown, la structure PDF) est presque toujours supérieur sur de la documentation technique. Pour un site e-commerce, une fiche produit doit rester un chunk. Pour un manuel technique, chaque section H2 ou H3 forme un chunk naturel.

3. Sélectionner les embeddings

Les embeddings transforment chaque chunk en vecteur. C'est l'organe de recherche du RAG. Le choix dépend de trois critères : la qualité sur votre langue (le français reste mal couvert par les modèles purement anglophones), la dimension (512 à 3072 selon les modèles, impact direct sur le coût de stockage et la latence) et le coût. Nos quatre candidats récurrents en 2026 : OpenAI text-embedding-3-large (3072 dimensions, qualité multilingue excellente, ~0,13 € par million de tokens), Cohere Embed v3 (1024 dimensions, très bon en multilingue, supporte la recherche sémantique typée), BGE-M3 open-source (1024 dimensions, performance remarquable, self-hostable), et les modèles français spécialisés comme Solon ou CamemBERT-large pour les corpus très francophones.

Notre méthode : tester au moins deux modèles d'embeddings sur le golden dataset client. Mesurer recall@5 et recall@10. L'écart est parfois spectaculaire — nous avons vu un BGE-M3 battre OpenAI sur un corpus juridique français très spécifique, et l'inverse sur un corpus technique multilingue. Aucun modèle n'est universellement meilleur.

4. Choisir la base vectorielle

La base vectorielle stocke les embeddings et exécute la recherche par similarité (cosinus, dot-product, L2). Cinq options dominent. Pinecone managé reste imbattable en time-to-market : quelques lignes de code, scaling automatique, mais coût récurrent et dépendance à un fournisseur US. Qdrant open-source, self-hostable, performant, écrit en Rust : notre choix par défaut quand la souveraineté compte. pgvector si vous avez déjà Postgres : pas besoin d'ajouter un service, parfait jusqu'à quelques millions de vecteurs. Weaviate pour les schémas riches et la recherche hybride avancée. Chroma pour les POC rapides en local.

Coût indicatif : 50 à 500 € par mois selon le volume et le mode (managé vs self-host). Au-delà de 10 millions de vecteurs ou de fortes contraintes de souveraineté, le self-host devient quasi obligatoire. Nous déconseillons d'enchaîner les outils : un seul vector store bien maîtrisé vaut mieux que trois mal intégrés.

5. Mettre en place le reranking

Le reranking est l'étape la plus sous-estimée du RAG. Le retrieval initial ramène typiquement un top-20 ou top-50 de chunks candidats par similarité vectorielle. Mais la similarité d'embedding est une approximation grossière de la pertinence réelle. Un reranker — modèle plus lourd, type cross-encoder — réordonne ces candidats en évaluant chaque paire (question, chunk) finement. Sur nos projets, ajouter un reranking apporte 10 à 15 % de précision en plus sur le top-3, qui est exactement ce qui sera injecté dans le prompt final.

Deux options dominent. Cohere Rerank v3 est un service managé excellent, multilingue, environ 1 € pour 1 000 requêtes. BGE-reranker est open-source, self-hostable, presque aussi performant, idéal en contexte souverain. L'investissement est minime — quelques heures d'intégration, quelques dizaines de millisecondes de latence — pour un gain de qualité largement supérieur à un changement de LLM.

6. Évaluer en continu

Un RAG sans évaluation est une boîte noire qui dérive silencieusement. Notre standard : construire dès le cadrage un golden dataset interne de 50 à 100 questions-réponses validées par le métier, et mesurer à chaque itération les métriques structurantes avec RAGAS : faithfulness (la réponse colle-t-elle aux sources ?), answer relevance (répond-elle à la question ?), context precision, context recall. Ces quatre métriques tracent le pipeline complet et permettent de localiser précisément où une régression apparaît.

À cela s'ajoute l'évaluation en production : feedback utilisateur (pouce haut/bas avec commentaire), monitoring des questions sans réponse satisfaisante, A/B testing entre deux configurations (par exemple chunking 512 vs 768, avec ou sans reranker). LangChain et LlamaIndex offrent désormais des hooks d'instrumentation natifs pour ces mesures, et des outils comme Langfuse ou Phoenix d'Arize les agrègent proprement.

Les pièges qui font échouer un RAG

Quatre erreurs reviennent systématiquement dans nos audits. Premièrement, un chunking trop fin ou trop large, défini une fois pour toutes sans jamais le recalibrer. Deuxièmement, des embeddings choisis par défaut sans test sur le français, alors que la langue fait une différence majeure sur certains corpus. Troisièmement, l'absence de reranking — étape la plus rentable du pipeline, pourtant régulièrement omise. Quatrièmement, l'absence de pipeline de mise à jour : la base de connaissance est figée à la date du déploiement, et le chatbot répond à des questions sur des produits qui n'existent plus.

À ces pièges techniques s'ajoute un piège méthodologique : juger un RAG « à l'œil ». Sans golden dataset, sans RAGAS, sans A/B, toute discussion sur la qualité est subjective et donc ingérable. Nous imposons la mesure dès la première itération, parce qu'on n'améliore que ce qu'on mesure.

Et maintenant ?

Un RAG performant n'est pas un projet de quelques jours. C'est un système qui se conçoit, se mesure et s'entretient. Mais c'est précisément cet investissement qui fait la différence entre un chatbot que vos équipes utilisent vraiment et un gadget abandonné après trois semaines. Chez DevHighWay, nous traitons le RAG comme la colonne vertébrale de chaque chatbot que nous livrons : sources auditées, chunking calibré, embeddings testés, reranker en place, évaluation continue.

• Prenez contact pour un cadrage RAG (atelier 1 jour, plan de bataille technique chiffré)
• Consultez nos tarifs — nos forfaits incluent la maintenance et l'évaluation continue du RAG
• Notre audit peut aussi couvrir la visibilité de votre assistant côté SEO et GEO

Si vous retenez une seule idée de cet article : la qualité d'un chatbot RAG ne se joue pas dans le choix du LLM, elle se joue dans l'ingénierie du retrieval. Les six étapes décrites ici ne sont pas optionnelles, elles forment un système. En sauter une, c'est accepter une dégradation systémique de la qualité finale. Les traiter sérieusement, avec méthode et mesure, c'est se donner les moyens de livrer un assistant que vos équipes utiliseront chaque jour — et qui, à terme, deviendra un actif stratégique de votre organisation.