RAG expliqué à un Product Owner : quand et pourquoi l'utiliser

RAG revient dans presque toutes les conversations sur les agents IA. “On va faire du RAG” est devenu une réponse réflexe à beaucoup de problèmes. Voici ce que ça veut dire concrètement, et quand c’est vraiment la bonne solution.

Le problème que RAG résout

Un LLM a deux limitations fondamentales :

La knowledge cutoff. Les modèles sont entraînés jusqu’à une certaine date. Ils ne connaissent pas vos données internes, vos documents récents, votre base de connaissances.

La fenêtre de contexte. Même avec 200k tokens, vous ne pouvez pas tout mettre dans chaque requête. Sur une base documentaire de 10 000 pages, c’est impossible.

RAG résout ces deux problèmes en combinant une recherche dans vos données avec la génération du LLM.

Comment ça marche, simplement

1. Vos documents sont découpés en morceaux et transformés en vecteurs (embeddings)
2. Ces vecteurs sont stockés dans une base de données vectorielle
3. Quand un utilisateur pose une question, elle est aussi transformée en vecteur
4. On cherche les morceaux de documents les plus proches de la question
5. Ces morceaux sont injectés dans le contexte du LLM avec la question
6. Le LLM répond en s’appuyant sur ces extraits

Les cas d’usage où RAG brille

FAQ et support client sur documentation propriétaire. C’est le cas d’usage le plus mature. Un agent qui répond aux questions en s’appuyant sur vos manuels, vos procédures internes, votre base de connaissances.

Recherche dans des archives volumineuses. Contrats, emails, rapports — quand le volume dépasse ce qu’on peut mettre en contexte.

Agent métier avec référentiel produit. Un agent commercial qui peut répondre à des questions précises sur votre catalogue, vos tarifs, vos conditions.

Quand RAG n’est pas la solution

Quand la fenêtre de contexte suffit. Si vos documents font moins de 50 pages, mettez-les directement en contexte. Plus simple, plus fiable.

Quand le problème est la qualité du LLM, pas les données. J’ai vu des équipes implémenter du RAG pour “améliorer les réponses” alors que le vrai problème était un prompt système mal écrit.

Quand vous n’avez pas encore validé le cas d’usage. RAG ajoute de la complexité (pipeline d’ingestion, base vectorielle, gestion des embeddings). Ne le faites pas sur un POC — commencez avec du contexte direct.

Ce que vous devez savoir en tant que PO

La qualité du découpage des documents est critique. Un mauvais chunking (découpage trop petit, trop grand, mal structuré) dégrade les résultats même avec le meilleur LLM.

Les métriques d’évaluation sont différentes. En plus d’évaluer les réponses du LLM, vous devez évaluer la qualité de la récupération : est-ce que les bons extraits sont retrouvés pour chaque question ?

Le RAG ne supprime pas les hallucinations. Il les réduit en donnant des sources au modèle, mais un LLM peut toujours ignorer les sources et inventer. Il faut tester explicitement ce comportement.

Les coûts sont plus complexes. API LLM + hébergement base vectorielle + pipeline d’ingestion + coût des embeddings. Chiffrez tout ça avant de vous engager.