Quand un assistant basé sur le RAG — ceux qui répondent en s'appuyant sur les documents de l'entreprise — donne de mauvaises réponses, la réaction instinctive est toujours la même : « il faut un modèle plus puissant », ou bien « réécrivons le prompt ». C'est presque toujours le mauvais réflexe, et aussi le plus coûteux. Le goulot d'étranglement se situe en amont, dans un composant dont on parle peu : le retrieval, c'est-à-dire la recherche qui décide quels documents passent sous les yeux du modèle. Si le document contenant la réponse n'arrive pas sur sa table, aucun modèle — aussi grand soit-il — ne peut l'inventer.
C'est la suite naturelle des cinq leçons tirées de notre plateforme RAG, où nous écrivions que « la qualité se joue dans le retrieval ». Ici, nous expliquons pourquoi — et surtout comment s'en apercevoir avant de dépenser.
Le chiffre qui circule dans les présentations
La formule « 95 % des projets d'IA générative échouent » circule partout. Elle vient d'un rapport du MIT (The GenAI Divide, 2025), selon lequel 95 % des projets pilotes ne produisent aucun impact mesurable sur le compte de résultat, pour 30–40 milliards de dollars investis.
Trois précisions d'honnêteté avant d'utiliser ce chiffre : ce n'est pas une donnée spécifique au RAG mais sur les pilotes GenAI en général; « aucun impact mesurable sur les comptes » ne signifie pas « le système ne fonctionne pas »; et la méthodologie du rapport a été contestée pour la fragilité de l'échantillon au regard du titre.
Cela dit, le rapport pointe une cause qui coïncide avec notre expérience de terrain : le problème ne tient pas à la qualité des modèles, mais à l'intégration — au contexte qu'on leur donne. La thèse de cet article est donc plus circonscrite et plus défendable : dans la majorité des projets RAG que nous avons vus s'enliser, la cause première est la recherche, pas le modèle. Et c'est une thèse qui peut se mesurer, pas seulement se raconter.
Le plafond qu'aucun modèle ne peut crever
Un système RAG est une chaîne à deux maillons : un composant qui cherche les passages pertinents dans vos documents, et un modèle qui rédige la réponse en lisant ces passages. Toute l'attention (et le budget) va d'ordinaire au second maillon. Mais une règle aussi banale qu'ignorée s'applique :
La qualité maximale des réponses est limitée par la qualité de la recherche : si le bon passage n'est pas trouvé, le modèle ne peut que dire « je ne sais pas » — ou inventer.
Il n'existe pas de troisième option. Changer de modèle déplace le choix entre ces deux issues, il ne résout pas le problème. Voilà pourquoi le premier investissement sensé n'est pas un modèle plus grand : c'est mesurer à quelle fréquence la recherche apporte le bon document. Si elle le fait 6 fois sur 10, le plafond de précision de tout le système est de 60 % — et aucun réglage du prompt ne le relèvera.
Pourquoi la recherche se trompe
Les causes récurrentes sont peu nombreuses et concrètes :
- Des documents mal découpés. Pour être cherchés, les documents sont divisés en fragments. Si la découpe est mécanique, un tableau se retrouve coupé en deux, une règle est séparée de son exception, et le fragment « dans ce cas le délai est ramené à 15 jours » ne dit plus de quel cas il parle.
- Des mots différents pour la même chose. L'utilisateur demande « puis-je payer en plusieurs fois une facture échue? », le document parle de « plan d'apurement des positions impayées ». Zéro mot en commun : la recherche par mots-clés ne le trouvera jamais.
- La correction qui crée le problème inverse. La réponse habituelle consiste à passer à la recherche « sémantique », qui comprend le sens au-delà des mots. C'est vrai — mais elle est faible précisément là où l'autre est forte : codes produit, sigles, numéros d'article, noms propres. Le code erreur
ERR_5012, la recherche par mots-clés le trouve du premier coup; la recherche sémantique le « noie » parmi des concepts voisins. - Aucun test de recette. Le péché originel : sans un jeu de questions réelles avec la réponse attendue, chaque modification est un pari et chaque réunion une confrontation d'opinions.
La solution : faire travailler deux recherches ensemble
Le point clé : la recherche par mots et la recherche par sens se trompent sur des questions différentes et complémentaires. Ce n'est pas un choix entre les deux — il faut les deux.
La recherche hybride fait exactement cela : elle exécute les deux recherches en parallèle et fusionne leurs classements selon un critère qui récompense le consensus — un document trouvé par les deux, même s'il n'est pas en tête, bat un document classé premier par une seule. Et c'est le bon comportement : un passage trouvé à la fois par les mots et par le sens est presque certainement celui qu'il faut.
Un exemple réel, que nous avons vérifié chiffres en main. Question : « puis-je échelonner une facture déjà échue? ». Le bon document — celui sur le « plan d'apurement des créances impayées » — était cinquième dans le classement de la recherche par mots et quatrième dans celui de la recherche par sens : avec une seule des deux techniques, il ne serait jamais entré parmi les trois premiers passages lus par le modèle, et la réponse aurait été fausse. Avec la fusion des deux classements, il est monté à la première place — parce qu'il était le seul présent dans les deux.
| Stratégie de recherche | Position du bon document | Le modèle le lit-il? |
|---|---|---|
| Mots-clés seuls | 5e | ✗ |
| Sens seul | 4e | ✗ |
| Hybride (fusion des deux) | 1re | ✓ |
Deux choses importantes pour qui décide. Premièrement : ce n'est pas une technologie exotique — la recherche hybride est intégrée d'origine dans les principaux moteurs de recherche d'entreprise (Elasticsearch, OpenSearch, Azure AI Search) : elle s'active, elle ne s'invente pas. Deuxièmement : après la recherche, il faut une étape de reclassement des résultats, parce que les modèles lisent mieux ce qui se trouve en haut du contexte — un détail documenté dans la littérature qui, à lui seul, change sensiblement la qualité perçue.
C'est la même philosophie que notre plateforme ACME ECMS IA & RAG Integration : plusieurs axes de recherche sur la base de connaissances et reclassement des passages avant la génération. Ce n'est pas de la théorie : c'est le schéma publié sur cette page.
Comment savoir si cela fonctionne (avant de faire confiance)
Le test de recette est étonnamment simple, et presque personne ne le fait. On construit un jeu d'essai : 50–100 questions réelles — recueillies auprès de ceux qui utiliseront le système, pas inventées en salle de réunion — chacune accompagnée du document qui contient la réponse. Puis on mesure une seule chose, sur la recherche isolée, avant même d'impliquer le modèle : combien de fois le bon document apparaît-il parmi les premiers résultats?
Ce chiffre est le plafond de tout le projet. Mesuré avant et après chaque intervention — activation de la recherche hybride, reclassement, meilleur découpage des documents — il transforme les discussions en décisions : on voit dans un tableau ce qui a amélioré les choses et de combien, et on cesse d'imputer au « modèle médiocre » des fautes qui sont ailleurs.
Les cinq questions à poser à qui vous le construit
- Existe-t-il un jeu d'essai avec nos propres questions et les réponses attendues? Pouvons-nous le voir?
- Quel est le pourcentage de fois où la recherche fait remonter le bon document parmi les premiers résultats, mesuré sur notre fonds documentaire?
- La recherche utilise-t-elle les deux axes — mots-clés et sens — ou un seul?
- Y a-t-il une étape de reclassement des résultats avant que le modèle ne les lise?
- Quand une réponse est fausse, savez-vous nous dire si le bon document avait été trouvé? (Si oui, le problème est la génération; si non, c'est la recherche. Dans notre expérience, c'est presque toujours la seconde.)
Si ces questions n'obtiennent que des réponses vagues, le projet navigue à vue — quel que soit le modèle en dessous.
L'essentiel
Le RAG n'échoue pas parce que le modèle est stupide. Il échoue parce qu'on lui donne à lire le mauvais document — puis qu'on l'accuse d'avoir mal répondu.
Avant d'investir dans un modèle plus grand : mesurer la recherche, activer l'axe manquant, ajouter le reclassement. Dans notre expérience, c'est l'ordre d'interventions offrant le meilleur rapport entre résultat et coût — mais c'est une expérience, pas un théorème : le jeu d'essai construit sur vos questions est le seul arbitre qui compte.
Si votre assistant documentaire s'est enlisé en phase pilote, nous pouvons y regarder ensemble — en commençant, bien sûr, par la mesure.
Sources.
- MIT Media Lab, Project NANDA — The GenAI Divide: State of AI in Business 2025 (juillet 2025); synthèse dans Fortune, 18 août 2025. La méthodologie a fait l'objet de critiques indépendantes pour la fragilité de son échantillon.
- Sur la fusion des classements (Reciprocal Rank Fusion) : Cormack, Clarke, Büttcher, SIGIR 2009; documentation d'Azure AI Search, d'Elastic et d'OpenSearch. L'exemple numérique cité a été recalculé et vérifié par la rédaction.
- Sur la dégradation de lecture dans les contextes longs : Liu et al., Lost in the Middle, TACL 2024.
