La promesse du RAG est séduisante. Vous connectez vos documents internes à un LLM, et l'assistant lit automatiquement contrats, procédures, comptes rendus et notes clients pour répondre aux questions de vos équipes. En démo, ça fonctionne presque toujours. Le modèle retrouve les bons passages, synthétise avec fluidité, et l'audience est convaincue.
Six semaines plus tard, l'ambiance est différente. Les réponses ne sont pas fausses : elles sont approximatives. Le système retrouve des documents proches mais pas les bons. Il répond sur un sujet voisin au lieu du sujet exact. Les utilisateurs perdent confiance progressivement, se remettent à chercher manuellement, et le projet stagne entre deux revues de direction. Pas d'échec spectaculaire : une lente érosion de l'adhésion.
La cause profonde n'est presque jamais le modèle de langage. Elle n'est pas dans le choix entre GPT-4o et Claude 3.7, ni dans la configuration du prompt système. Elle est dans la qualité de ce qu'on donne à récupérer : la façon dont les documents sont découpés, la pertinence du modèle d'embedding choisi, l'absence d'un mécanisme d'évaluation continu. Un projet RAG qui tient en production est avant tout un projet de qualité de données, avec un LLM en sortie. Cette distinction change tout à la façon dont on le conçoit.
La mauvaise question de départ
Quand une équipe démarre un projet RAG, la première décision porte presque invariablement sur les outils : LangChain ou LlamaIndex ? Pinecone ou Weaviate ? GPT-4o ou Claude ? Ces choix ont leur importance, mais ils arrivent trop tôt. Ils présupposent que le goulot d'étranglement est dans la tuyauterie, pas dans ce qu'on y fait passer.
La vraie question de départ est : dans quel état sont vos documents source ? Sont-ils structurés de façon cohérente ? Contiennent-ils beaucoup de doublons, de versions périmées côtoyant des versions actuelles ? Ont-ils été extraits de PDFs avec un OCR de mauvaise qualité qui produit des caractères corrompus à chaque changement de colonne ? Les sections pertinentes sont-elles noyées dans des documents de 200 pages remplis d'annexes réglementaires qui ne servent à rien pour la requête ?
Ce diagnostic amont est rarement fait, parce qu'il n'est pas glamour. Il ne demande pas de GPU et ne fait pas l'objet de démos. Mais il détermine la qualité de tout ce qui vient après. Un index vectoriel construit sur des documents de mauvaise qualité produira des récupérations de mauvaise qualité, quelle que soit la sophistication du reste du pipeline. Le principe "garbage in, garbage out" s'applique au RAG avec une force particulière : les approximations se propagent à chaque étape, du découpage à l'embedding, jusqu'à la réponse finale que lira l'utilisateur.
Le chunking : l'endroit où tout commence à dérailler
Le chunking est l'opération qui divise un document en fragments avant leur indexation. C'est l'étape la plus sous-estimée du pipeline RAG, et souvent la première source d'échec silencieux.
Le problème du découpage à taille fixe
La stratégie la plus courante est le découpage à taille fixe : on coupe le texte tous les 512 tokens, avec un chevauchement de 50 tokens pour éviter de couper au milieu d'une phrase. C'est simple, rapide, et ça produit des résultats médiocres sur des documents métier réels.
Un document de procédure opérationnelle standard, par exemple, alterne des titres de section, des listes d'actions, des tableaux de conformité et des notes de bas de page. Couper à 512 tokens sans tenir compte de la structure sémantique donne des fragments qui mélangent la fin d'une étape et le début de la suivante, ou qui séparent un tableau de son contexte introductif. Le fragment est techniquement présent dans l'index, mais pratiquement inutilisable pour répondre à une question précise.
Une étude comparative publiée dans PMC en 2025 sur l'aide à la décision clinique illustre l'écart de façon saisissante : le découpage adaptatif aligné sur les frontières logiques de topic atteignait 87% d'exactitude sur le même corpus, contre 13% pour le découpage à taille fixe. Le domaine médical est exigeant par nature, mais le mécanisme est le même sur des documents juridiques, des procédures internes ou des spécifications techniques.
Vers un découpage structurel et sémantique
La stratégie qui donne les meilleurs résultats sur des documents d'entreprise est le découpage conscient de la structure du document : on respecte les titres et sous-titres comme frontières naturelles, on ne coupe jamais un tableau en deux, et on utilise le contenu sémantique pour identifier les limites thématiques à l'intérieur d'une section.
Le guide de NVIDIA sur les stratégies de chunking pose un principe pratique : pour les requêtes factuelles (une date, un montant, un nom), des fragments de 256 à 512 tokens suffisent. Pour les requêtes analytiques (une comparaison, une explication de processus, une recommandation), des fragments de 1024 tokens ou davantage sont nécessaires pour que le LLM dispose du contexte à synthétiser.
La règle pratique que l'on applique en mission : chaque fragment doit pouvoir répondre à une question de façon autonome. Si le fragment récupéré nécessite de connaître ce qui précède ou ce qui suit pour être compréhensible, le découpage est à revoir.
Embeddings : choisir pour vos documents, pas pour le leaderboard
Une fois les fragments créés, il faut les transformer en vecteurs. Le modèle d'embedding est la couche qui détermine dans quelle mesure "politique de remboursement frais kilométriques" et "comment se faire rembourser ses déplacements ?" sont proches dans l'espace vectoriel. Plus le modèle est adapté à votre domaine et à votre langue, plus les récupérations seront pertinentes.
L'erreur du benchmark général
Le réflexe habituel est de choisir le modèle en tête du classement MTEB (Massive Text Embedding Benchmark), la référence du secteur sur 56 tâches. C'est un point de départ raisonnable, mais un oracle trompeur : le score MTEB est une moyenne sur des tâches de classification, clustering, similarité sémantique et récupération. Un modèle qui domine la classification peut sous-performer sur la récupération, qui est précisément la tâche qui compte pour le RAG.
En 2026, les modèles bien classés pour la récupération multilingue incluent Qwen3-Embedding-8B d'Alibaba et Cohere embed-v4, conçu pour les contextes longs en environnement entreprise. Pour un déploiement en français avec des documents mixtes, le score global ne suffit pas à trancher.
Le test obligatoire sur vos propres données
Il n'y a pas de raccourci : avant de figer le choix du modèle d'embedding, on constitue un jeu de test représentatif (100 à 300 paires question/document attendu) et on mesure le recall@5 et le MRR (Mean Reciprocal Rank) de chaque modèle candidat. Un modèle classé douzième sur MTEB peut très bien dépasser le modèle classé premier sur votre corpus spécifique, surtout si vos documents sont techniques, sectoriels, ou en français soutenu.
Cette étape prend une journée. Elle économise des semaines de debugging une fois en production, et souvent une migration coûteuse d'un modèle à l'autre après six mois.
Le reranking : le levier rapide sur la précision
Même avec un bon modèle d'embedding et un bon découpage, la première passe de récupération vectorielle n'est pas parfaite. La recherche par similarité cosinus retourne les fragments les plus proches dans l'espace d'embedding, mais la proximité vectorielle n'est pas exactement la pertinence sémantique pour une requête donnée.
Le reranking apporte une deuxième passe : on récupère d'abord 50 à 100 candidats avec la recherche vectorielle rapide, puis un cross-encoder les reclasse en examinant chaque paire (requête, fragment) ensemble, avec une compréhension bidirectionnelle beaucoup plus fine.
Bi-encoder et cross-encoder : deux rôles distincts
Un bi-encoder (le modèle d'embedding standard) encode la requête et le document séparément, puis calcule une similarité. C'est rapide et scalable à des millions de documents. Un cross-encoder les examine ensemble, ce qui lui permet de capturer des relations sémantiques que la comparaison de vecteurs indépendants manque systématiquement.
Le guide de Pinecone sur les rerankers documente des améliorations NDCG@10 de 15 à 30% sur des benchmarks représentatifs, pour un surcoût de latence de 100 à 150 millisecondes sur un lot de 50 candidats. Sur des requêtes métier complexes, ce délai est largement justifié.
Quand mettre un reranker en priorité : sur des corpus de plus de 10 000 documents, sur des requêtes analytiques (pas uniquement factuelles), et dès que les utilisateurs signalent des récupérations "proches mais pas exactes". C'est souvent la modification avec le meilleur ratio impact/effort dans un pipeline RAG existant.
L'évaluation continue : la seule façon de ne pas dériver
La raison principale pour laquelle des projets RAG stagnent sans jamais vraiment échouer est l'absence de mesure. Le projet fonctionne au lancement, les premiers retours sont positifs, et personne ne mesure ce qui se passe ensuite. La qualité se dégrade progressivement : les documents source vieillissent, de nouveaux types de requêtes apparaissent, et le système répond à côté sans que personne ne puisse le quantifier.
Les quatre métriques de RAGAS
Le framework RAGAS (Retrieval Augmented Generation Assessment) propose quatre métriques complémentaires pour évaluer un pipeline RAG sans annotations humaines coûteuses :
Faithfulness. La réponse est-elle entièrement fondée sur les fragments récupérés ? Une réponse fidèle n'invente pas d'information absente du contexte.
Answer Relevancy. La réponse répond-elle à la question posée, sans contenu redondant ni hors sujet ?
Context Precision. Les fragments pertinents sont-ils classés en tête des résultats ?
Context Recall. Les fragments récupérés contiennent-ils toutes les informations nécessaires pour répondre ?
Un pipeline RAG sain a des scores élevés sur les quatre axes. Un pipeline qui récupère bien mais hallucine a un bon context recall et une mauvaise faithfulness. Un pipeline qui ne récupère pas les bons documents a une mauvaise context precision, et tout le reste en souffre mécaniquement.
Le golden dataset, actif le plus précieux du projet
Les métriques RAGAS s'appliquent sur un jeu d'évaluation propriétaire : 100 à 300 questions représentatives des requêtes réelles de vos utilisateurs, avec les réponses de référence et les documents source attendus.
Ce golden dataset est l'actif le plus précieux de votre projet RAG. Il permet de tester l'impact de chaque modification (nouveau modèle d'embedding, nouvelle stratégie de découpage, ajout de sources) avant de la déployer. Et de mesurer la dérive dans le temps : si le score de faithfulness chute entre janvier et mars, quelque chose a changé dans vos documents ou dans les patterns de requêtes.
En pratique, on intègre l'évaluation dans la CI/CD : chaque modification du pipeline repasse sur le golden dataset, et un score en dessous du seuil bloque le déploiement. Ce n'est pas différent des tests unitaires sur un logiciel classique, et c'est la seule façon de savoir si une modification améliore réellement les choses.
La gouvernance documentaire : le chantier que personne ne veut toucher
Derrière tous les problèmes de découpage, d'embedding et d'évaluation, il y a souvent un problème plus profond : personne ne sait vraiment ce que contient la base documentaire qu'on a indexée.
Le syndrome du disque dur partagé
La plupart des projets RAG en entreprise démarrent avec "l'ensemble des documents" : le SharePoint, le Google Drive, la GED. En pratique, cela signifie des contrats signés côtoyant des brouillons jamais finalisés, des procédures de 2019 jamais mises à jour, des fichiers en double avec des noms légèrement différents, des comptes rendus de réunion sans contexte, et des PDFs issus de scans de mauvaise qualité dont l'OCR produit du charabia.
Un index vectoriel construit sur ce corpus retournera tous ces artefacts indistinctement. Le système peut répondre à une question de conformité en citant une procédure périmée depuis trois ans, sans que rien dans le pipeline ne le signale. Un travail publié sur arxiv en novembre 2025, RAG-Driven Data Quality Governance for Enterprise ERP Systems, documente précisément comment les pipelines RAG déployés sur des ERPs d'entreprise se dégradent en l'absence de gouvernance documentaire active : données dupliquées, métadonnées absentes, absence de TTL sur les documents, impossibilité de tracer une réponse vers son document source.
Quatre règles pratiques
Propriétaire par collection. Chaque collection de documents a un owner désigné, responsable de sa mise à jour et de l'archivage des versions obsolètes. Sans owner, personne ne retire les documents périmés.
Date d'expiration sur les documents sensibles. Les procédures, les contrats et les politiques internes ont une date de validité. On la stocke en métadonnée et on filtre les documents expirés en amont de l'indexation, ou on les tag pour que le LLM puisse les signaler explicitement.
Contrôle d'accès hérité. Le RAG ne doit pas exposer via ses réponses des documents qu'un utilisateur n'aurait pas le droit de consulter directement. Le périmètre d'indexation d'un utilisateur doit refléter ses droits documentaires réels. C'est un sujet d'architecture à traiter dès le départ, pas en correctif.
Qualité OCR vérifiée avant indexation. Un pipeline de pré-traitement vérifie la lisibilité des documents extraits de PDFs avant leur insertion dans l'index. Un document dont 20% des tokens sont corrompus nuit à toute la collection qui l'entoure.
La gouvernance documentaire n'est pas un sujet IA. C'est un sujet de gestion de l'information, que la plupart des organisations ont délégué à personne. Le RAG le rend visible parce qu'il amplifie la qualité des sources, dans les deux sens.
Ce qu'on fait concrètement en mission
Quand un client nous sollicite sur un projet RAG qui stagne, on commence toujours par le même audit en quatre points : qualité des sources (OCR, doublons, périmés), stratégie de découpage actuelle (taille, chevauchement, respect de la structure), présence ou absence d'un reranker, et existence d'un golden dataset avec des métriques de suivi.
Sur les projets que l'on reprend, la majorité des problèmes de qualité de réponse se règlent par une combinaison de deux correctifs : révision de la stratégie de chunking, et mise en place d'un premier reranker cross-encoder. Ce n'est pas spectaculaire, mais c'est ce qui fait la différence entre un assistant qui répond à côté et un assistant que les équipes utilisent vraiment au quotidien.
Le reste des problèmes est documentaire : corpus trop large et non gouverné, documents périmés, absence d'ownership. C'est le chantier le plus long, mais aussi le seul qui garantisse une qualité durable dans le temps. Un RAG de qualité en 2026 est une infrastructure de gestion documentaire autant qu'un projet IA.
Vous voulez qu'on regarde votre cas ensemble ? Réservez un créneau, on bloque 30 minutes pour auditer la qualité de vos sources documentaires et identifier les leviers qui débloqueront votre projet RAG.