Ces 18 derniers mois, presque chaque réunion de cadrage que nous démarrons avec une PME se termine par la même phrase : « nous voulons un ChatGPT, mais avec nos documents ». La réponse du marché est toujours la même — le RAG (Retrieval-Augmented Generation). Et parfois, c’est la bonne réponse. D’autres fois, il vous faudra 6 mois pour découvrir que non.
Cet article décrit le cadre que nous utilisons chez K2 Labs pour décider, en moins d’une semaine de travail, si un projet RAG va fonctionner pour un client donné. Ce n’est pas définitif. Mais cela nous a évité trois engagements qui auraient été catastrophiques.
Le RAG, en clair ?
Le RAG est le pattern « trouve les documents pertinents, donne ces documents au modèle, et fais-le répondre avec ces informations ». C’est la différence entre poser une question à un modèle à froid et lui donner top-k fragments de contexte avant la question.
Mécaniquement, ce sont trois pièces :
- Indexation : vos documents sont découpés en chunks, vectorisés avec des embeddings et stockés dans un vector store.
- Récupération : face à une question, vous récupérez les chunks les plus similaires.
- Génération : vous passez la question + les chunks au LLM, qui répond.
En 2026, brancher tout ça avec LangChain ou llama-index, c’est un vendredi après-midi. Le difficile, c’est qu’il réponde bien.
Quand ça a du sens
Le sweet spot du RAG est assez spécifique. Il fonctionne très bien quand :
- L’utilisateur pose des questions factuelles dont la réponse canonique est dans un document.
- Votre corpus est relativement stable et curé — manuels, politiques, bases de connaissances internes.
- Il y a assez de volume d’usage pour justifier la maintenance du système.
- Vous acceptez que la réponse cite ses sources et que l’utilisateur puisse les lire pour valider.
Un cas réel : un distributeur industriel avec 4 000 fiches techniques en PDF. Les techniciens du centre d’appels passaient 40 % de leur temps à chercher des spécifications. Le RAG a ramené ce chiffre à 8 %, avec un ROI clair en 3 mois. Ici, toutes les cases étaient cochées.
Quand ça n’en a PAS
Et voici la nuance que l’on discute rarement. Le RAG est une mauvaise idée quand :
- Les réponses exigent un raisonnement sur plusieurs documents à la fois qui se contredisent.
- Le contenu change en permanence et l’indexation a de la latence.
- Les questions sont procédurales ou transactionnelles — c’est une API, pas une recherche sémantique.
- Le corpus est petit (moins de 100 docs). Un bon prompt avec les docs en contexte fait aussi bien, voire mieux.
Si le problème se résout avec une recherche full-text + un LLM à la fin, vous n’avez pas besoin de RAG. Vous avez besoin d’Elasticsearch et d’un prompt.
Le cadre de décision en 5 questions
Lors de la première réunion, nous passons cette batterie. Si trois réponses ou plus sont « non », nous recommandons une autre approche.
- La question de l’utilisateur a-t-elle une réponse concrète dans le corpus ?
- Le corpus compte-t-il plus de 500 documents significatifs ?
- Le contenu est-il mis à jour chaque semaine ou plus lentement ?
- Existe-t-il une référence humaine pour mesurer la précision ?
- Les utilisateurs acceptent-ils une réponse avec citations ?
Conclusion
Le RAG n’est pas une solution miracle, mais ce n’est pas un échec non plus. C’est une architecture spécifique pour un problème spécifique. La partie difficile du métier de consultant en 2026 n’est plus de monter le pipeline — c’est d’avoir la conversation honnête sur l’adéquation de votre problème.
Si vous envisagez un projet de ce type et souhaitez un deuxième avis avant de vous engager, écrivez-nous. Une heure de discovery peut vous épargner un semestre.