RAG en entreprise : pourquoi ça casse dès qu'on dépasse trois documents

La démo était parfaite. Trois documents, cinq questions, cinq bonnes réponses. Le comité de direction valide : « on branche tout le Drive ».

Trois semaines plus tard, l’assistant répond à côté une fois sur trois, mélange une procédure RH avec une consigne de production, et cite un document que personne ne reconnaît. Personne ne comprend ce qui a changé, sauf que quelque chose a changé : l’échelle.

TL;DR

• Le RAG ne dégrade pas linéairement. Il fonctionne remarquablement sur peu de documents, puis chute brutalement quand le corpus s’élargit.
• La cause principale n’est pas la qualité du modèle, c’est la collision entre documents proches mais non équivalents : deux procédures similaires appartenant à deux métiers différents.
• La solution n’est pas un meilleur RAG, c’est un RAG plus petit : un index par silo métier, avec un routage explicite en amont.
• Beaucoup de cas n’ont pas besoin de RAG du tout. Si le corpus tient dans le contexte, ou si la connaissance est une procédure stable, il existe des réponses plus simples et plus fiables.

Que se passe-t-il vraiment entre 3 et 3 000 documents ?

Rappel du mécanisme : le RAG (Retrieval-Augmented Generation) ne fait pas comprendre tes documents au modèle. Il fait deux choses successives, retrouver les passages jugés pertinents, puis les donner au modèle comme contexte de sa réponse.

Toute la fragilité est concentrée dans la première étape.

Sur trois documents traitant de sujets distincts, la recherche ne peut presque pas se tromper : le bon passage est le seul candidat plausible. Sur trois mille documents, la situation change de nature :

• Il existe désormais plusieurs passages plausibles pour une même question.
• Certains sont obsolètes mais formulés de façon très proche des passages valides.
• Certains appartiennent à un autre métier tout en employant exactement le même vocabulaire.

C’est ce dernier point qui fait le plus de dégâts, et il est spécifique à l’entreprise.

La collision de vocabulaire entre métiers

Le mot « commande » ne désigne pas la même chose aux achats, à la production et au service client. Une « validation » n’a pas le même sens en qualité et en comptabilité. Un « dossier » n’est pas le même objet aux RH et au juridique.

Un système de recherche sémantique voit des textes très similaires. Le métier, lui, sait que ces documents ne doivent jamais être confondus. Le modèle reçoit alors un mélange de deux univers et produit une réponse cohérente en apparence, fausse en pratique. C’est le pire type d’erreur : elle ne ressemble pas à une erreur.

Il ne s’agit pas d’un problème de qualité documentaire, même une base parfaitement tenue produit ces collisions. C’est un problème d’architecture de la recherche, distinct de la question de la gouvernance de la connaissance traitée dans l’article sur le rôle de Knowledge Manager. Les deux sont nécessaires : l’un rend les documents fiables, l’autre empêche de chercher au mauvais endroit.

Comment découper par silo métier ?

Le réflexe naturel est de vouloir un assistant unique qui répond à tout. C’est précisément ce qui ne marche pas. L’architecture qui tient repose sur une idée simple : un index par domaine métier, et un routage explicite avant la recherche.

1. Définir les silos sur des frontières métier, pas techniques

Le découpage ne suit ni l’arborescence du Drive ni les outils. Il suit les domaines de responsabilité : RH, production, commercial, qualité, juridique. Le test de validité : si deux domaines emploient les mêmes mots pour désigner des choses différentes, ce sont deux silos.

2. Router avant de chercher

Avant toute recherche, une étape détermine le silo concerné. Deux options, selon le contexte :

• Le routage implicite : l’utilisateur pose sa question depuis un espace déjà rattaché à un domaine (l’assistant du service qualité ne cherche que dans le silo qualité). C’est le plus fiable, et le plus souvent le bon choix.
• Le routage explicite : un premier appel au modèle classe la question dans un domaine parmi une liste fermée, avant de lancer la recherche dans le silo correspondant.

Dans les deux cas, le principe est le même : on ne cherche jamais dans l’ensemble du corpus.

3. Assumer le « je ne sais pas »

Un silo restreint va nécessairement rencontrer des questions hors périmètre. C’est une bonne nouvelle, à condition que le système le dise. Un assistant qui répond « cette question relève du domaine juridique, je n’y ai pas accès » est infiniment plus utile qu’un assistant qui invente une réponse plausible.

Cela suppose une consigne explicite et un seuil : si aucun passage récupéré n’est suffisamment pertinent, on ne répond pas. C’est le garde-fou le plus rentable de toute l’architecture.

4. Traiter la fraîcheur comme un critère de recherche

Un document obsolète correctement retrouvé reste une mauvaise réponse. La date de validité doit être une métadonnée exploitée au moment de la recherche, pas seulement une information affichée après coup.

Quand ne faut-il pas faire de RAG du tout ?

C’est la question qu’on ne pose jamais, et elle élimine une bonne partie des projets.

Cas 1 : le corpus tient dans le contexte

Les fenêtres de contexte des modèles actuels se comptent en centaines de milliers de tokens. Si ta base de connaissance utile fait quarante pages, tu n’as pas besoin de RAG : envoie tout, à chaque fois.

Tu supprimes ainsi l’intégralité de l’étape la plus fragile du système. Le coût supplémentaire est réel mais souvent modeste, surtout avec un cache de contexte, comme détaillé dans l’article sur le coût réel de l’IA en entreprise. Et la fiabilité obtenue n’a rien à voir.

Règle pratique : en dessous de quelques dizaines de milliers de tokens de connaissance stable, la question du RAG ne devrait même pas se poser.

Cas 2 : la connaissance est une procédure, pas un corpus

Beaucoup de besoins présentés comme « il faut que l’IA connaisse nos process » ne sont pas des problèmes de recherche documentaire. Ce sont des besoins de procédure appliquée : comment traiter tel type de demande, dans quel ordre, avec quelles règles.

Une procédure n’a pas besoin d’être retrouvée par similarité sémantique : elle doit être appliquée intégralement quand le cas se présente. C’est exactement ce que couvrent les mécanismes de type skills, où une instruction complète est chargée quand elle est pertinente, la documentation Anthropic sur les Agent Skills décrit ce fonctionnement de chargement à la demande.

L’écart de fiabilité est considérable : dans un cas tu espères que le bon paragraphe remonte, dans l’autre tu as la garantie que la procédure entière est présente.

Cas 3 : la donnée est structurée

Si la réponse se trouve dans une base, un ERP ou un tableur, la bonne architecture est une requête, pas une recherche sémantique. Vectoriser des lignes de base de données pour retrouver approximativement ce qu’un SELECT aurait renvoyé exactement est une régression.

Le bon pattern : le modèle comprend la question de l’utilisateur et la traduit en requête ; la base répond avec certitude ; le modèle met le résultat en forme. On garde le probabiliste pour le langage et le déterministe pour la donnée.

L’ordre dans lequel poser les questions

Avant de lancer un projet de recherche documentaire assistée par IA, dans cet ordre :

1. De quel volume de connaissance parle-t-on vraiment ? Souvent bien moins qu’annoncé une fois les doublons et les documents morts retirés.
2. Est-ce un corpus ou une procédure ? La réponse change complètement l’architecture.
3. La donnée est-elle déjà structurée quelque part ? Alors une requête vaut mieux qu’une recherche.
4. Combien de domaines métier distincts ? C’est le nombre de silos, et donc d’index.
5. Que doit-il se passer quand le système ne sait pas ? Si la réponse n’est pas « il le dit », l’architecture n’est pas prête.

Cette séquence relève du même travail de cadrage que celui qui évite qu’un POC finisse au placard : le temps investi ici se rembourse en semaines de développement épargnées.

Checklist : concevoir une recherche documentaire qui tient

• J’ai mesuré le volume réel du corpus utile, après suppression des doublons et documents obsolètes.
• J’ai vérifié si le corpus tient simplement dans le contexte, auquel cas pas de RAG.
• J’ai distingué ce qui est un corpus de ce qui est une procédure à appliquer.
• Les données déjà structurées sont interrogées par requête, pas par recherche sémantique.
• Le corpus est découpé par domaine métier, pas par arborescence de fichiers.
• Une étape de routage détermine le silo avant la recherche.
• Le système sait répondre « je ne sais pas » sous un seuil de pertinence.
• La date de validité est exploitée pendant la recherche, pas seulement affichée.
• J’ai testé sur 30 questions réelles tirées au hasard, pas sur des questions choisies.

FAQ

À partir de combien de documents un RAG global commence-t-il à décrocher ?

Il n’y a pas de seuil universel : ce qui compte n’est pas le nombre de documents mais le nombre de documents proches et confusables. Un corpus de mille documents portant sur mille sujets distincts pose peu de problèmes. Cent documents dont vingt sont des variantes d’une même procédure en posent immédiatement. Le bon indicateur de risque, c’est la densité de vocabulaire partagé entre domaines.

Un modèle plus puissant règle-t-il le problème ?

Non, parce que l’erreur se produit avant lui. Quand la recherche a remonté trois passages dont deux appartiennent au mauvais domaine métier, le modèle reçoit un contexte contradictoire, il produira une réponse cohérente à partir d’informations qui n’auraient jamais dû être réunies. Améliorer le modèle améliore la formulation, pas la sélection. Le levier est dans le découpage et le routage.

Comment détecter que le problème vient de la recherche et pas du modèle ?

Trace systématiquement les passages récupérés à chaque réponse, et relis-les sur les cas d’erreur. Dans la grande majorité des cas, la cause saute aux yeux : le bon document n’a jamais été remonté, ou un document d’un autre domaine s’est glissé dans le lot. Sans cette traçabilité, tu débogues à l’aveugle, c’est le premier équipement à mettre en place, avant toute optimisation.

Faut-il un index par service, ou peut-on en regrouper certains ?

Regrouper est possible quand deux domaines ne partagent pas de vocabulaire ambigu et que leurs documents ne risquent pas d’être confondus. Le test est simple : prends dix questions typiques de chaque domaine et vérifie qu’aucune ne pourrait légitimement remonter un document de l’autre. Si un doute existe, sépare, le coût d’un index supplémentaire est très inférieur au coût d’une réponse fausse qui passe pour vraie.

Conclusion

Le RAG n’est pas une mauvaise technologie : c’est une technologie dont la difficulté est mal située. Tout le monde regarde le modèle, alors que l’erreur se produit dans l’étape de recherche, avant que le modèle n’intervienne.

Les projets qui tiennent en production font tous la même chose : ils cherchent dans un périmètre restreint et connu, ils savent dire qu’ils ne savent pas, et ils n’utilisent le RAG que là où aucune solution plus simple ne suffisait.

Commence par mesurer ton corpus réel. Il y a de bonnes chances que ton problème n’en soit pas un.

Ce sujet est abordé dans la MasterClass « Les vrais cas d’usage de l’IA » ainsi que dans l’épisode Radio Vibe Code #7.