Explication
Comment fonctionne le RAG pour les assistants IA en entreprise (et quand c'est le mauvais outil)
Le Retrieval-Augmented Generation est la technique derrière la plupart des assistants IA d'entreprise utiles. On décortique ce qu'il fait vraiment, où il vaut son coût, et les cinq situations où c'est la mauvaise réponse.
L'essentiel
Le RAG permet à un modèle IA de répondre en s'appuyant sur vos documents, vos données et vos systèmes privés, sans ré-entraîner le modèle. C'est la bonne approche quand le contenu évolue souvent, quand les réponses doivent citer une source, et quand fine-tuner un modèle sur vos données est démesuré. C'est la mauvaise approche quand la réponse n'existe pas dans un document, quand la latence est critique, ou quand vous cherchez à changer la façon de raisonner du modèle plutôt que ce qu'il sait.
En clair
Ce qu'est vraiment le RAG
Le RAG, pour Retrieval-Augmented Generation, est une façon de faire répondre un modèle IA généraliste à partir de votre connaissance spécifique. Au lieu de bourrer chaque document dans le prompt, ou de payer pour fine-tuner le modèle sur vos données, le RAG va chercher uniquement les quelques passages qui comptent pour la question, les donne au modèle, et lui demande de répondre en s'appuyant sur ces passages comme preuves.
Concrètement, vous montez un petit pipeline qui transforme vos documents en vecteurs cherchables, retrouve les plus pertinents pour chaque question, et les transmet au modèle avec la question utilisateur. Le modèle rédige alors la réponse, idéalement en citant les passages utilisés. Le but : ancrer l'IA générique dans votre contenu réel, pour que l'assistant parle de votre business, vos politiques, vos tickets, vos factures, pas d'internet en général.
Pourquoi vous en voudriez
Pourquoi les entreprises finissent par avoir besoin du RAG
Trois douleurs qui déclenchent généralement la conversation.
L'IA générique ne voit pas vos données
Les assistants prêts-à-l'emploi ne connaissent que ce qui était dans leur jeu d'entraînement. Vos politiques, vos tickets, votre catalogue produit, vos conditions fournisseurs leur sont invisibles. Sans récupération, le modèle refuse, devine, ou invente.
Votre connaissance change tout le temps
Les prix changent. Les politiques sont réécrites. De nouveaux SKU sortent. Le fine-tuning fige un instantané, qui devient obsolète en quelques semaines. Le RAG lit votre stock de documents en direct : quand vous mettez à jour la source, l'assistant suit.
Vous devez pouvoir faire confiance à la réponse
Les utilisateurs métier ne font pas confiance à une réponse qu'ils ne peuvent pas vérifier. Le RAG récupère de vrais passages de vrais documents, donc l'assistant peut montrer son travail : la réponse, plus le paragraphe source et le lien vers le document original. Cette seule fonctionnalité fait souvent la différence entre adoption et abandon.
Dans le pipeline
Les quatre pièces mobiles
Un système RAG qui marche, c'est quatre étapes branchées ensemble. Chacune cache de vraies décisions d'ingénierie.
- 1
Ingestion
Récupérez les documents qui doivent alimenter l'assistant : PDF, pages wiki, articles de base de connaissances, historique de tickets, données ERP, notes CRM, SharePoint interne, tout ce où la réponse peut vivre. Puis découpez-les en passages assez petits pour être utiles mais assez gros pour garder du contexte. La qualité de cette étape décide de la qualité du système plus que tout choix de modèle.
- 2
Embedding et indexation
Transformez chaque passage en vecteur via un modèle d'embedding, et stockez les vecteurs dans une base vectorielle. Le vecteur est une empreinte numérique du sens : deux passages qui disent la même chose autrement finissent proches. Les choix ici ne sont pas cosmétiques : quel modèle d'embedding, quelle base vectorielle, à quelle fréquence ré-embedder quand le contenu change.
- 3
Recherche
Quand un utilisateur pose une question, la question est embeddée et la base vectorielle renvoie les quelques passages les plus pertinents. Une bonne recherche reclasse aussi les résultats, mélange du keyword search pour les requêtes à noms propres, et filtre par permissions utilisateur pour que chacun ne voie que ce qu'il a le droit de voir. La qualité de recherche est là où la plupart des systèmes RAG en production vivent ou meurent.
- 4
Génération
Le modèle reçoit la question utilisateur plus les passages récupérés, et rédige la réponse en s'appuyant dessus comme preuves. Le prompt instruit le modèle de s'en tenir aux passages, de citer lesquels, et de refuser si la réponse n'y est pas. Les bons systèmes affichent ensuite les citations à l'utilisateur, pour que la réponse soit vérifiable plutôt qu'une boîte noire.
À lire avant de construire
Quand le RAG est le mauvais outil
Cinq situations où le RAG est démesuré, la mauvaise abstraction, ou activement nuisible.
La réponse n'existe pas dans un document
Si l'assistant doit calculer quelque chose, interroger une base de données en direct, ou déclencher une action dans votre CRM, le RAG seul ne le fera pas. Il vous faut du function calling, des agents, ou un hybride : RAG pour la connaissance, outils structurés pour les actions. Construire du RAG pur quand le vrai besoin est du workflow est le piège de sur-ingénierie le plus courant.
Votre base de connaissances est minuscule
Si vous avez 20 pages de FAQ et qu'elles sont stables, vous n'avez pas besoin d'un pipeline de récupération. Mettez-les juste dans le prompt. L'infrastructure RAG rentabilise quand le contenu est trop gros pour une context window, ou change fréquemment. En dessous de ce seuil, c'est de la complexité pour rien.
La latence est critique
Chaque requête RAG ajoute une étape d'embedding, une recherche vectorielle, souvent une passe de reranking, puis la génération. Ça fait des centaines de millisecondes, parfois des secondes. Pour des agents temps-réel gérant des appels clients en direct ou des décisions sub-secondes, il faut peut-être des réponses cachées, des modèles plus petits, ou une architecture toute autre.
Vous voulez changer la façon de raisonner du modèle
Le RAG change ce que le modèle sait. Il ne change pas comment le modèle écrit, le ton qu'il prend, ou comment il raisonne sur un problème spécifique à un domaine. Si vous avez besoin d'un modèle qui parle comme votre voix de marque ou pense comme un expert d'une niche, c'est le territoire du fine-tuning. Les deux techniques sont complémentaires, pas interchangeables.
Vos sources ne sont pas fiables
Le RAG récupère ce que vous avez indexé. Si votre base de connaissances est pleine de contradictions, de brouillons obsolètes, ou de fils d'email non structurés, l'assistant remontera fidèlement ce désordre. Garbage in, citations out. Curer les sources compte avant l'architecture de recherche.
RAG vs les alternatives
RAG, fine-tuning, prompt engineering
Trois techniques qu'on confond souvent. Elles résolvent des problèmes différents et se cumulent plus qu'elles ne s'opposent.
| Dimension | RAG | Fine-tuning | Prompt engineering |
|---|---|---|---|
| Change | Ce que le modèle sait | Comment le modèle écrit et raisonne | Comment le modèle est instruit pour une tâche |
| Coût de mise à jour | Ré-indexer les documents changés, instantané | Ré-entraîner le modèle, heures à jours | Éditer le prompt, instantané |
| Idéal pour | Connaissance privée, mises à jour fréquentes, citations | Style, ton, raisonnement métier, sorties structurées | Quick wins, assistants mono-tâche, prototypes |
| Limite | La qualité de recherche plafonne la qualité de réponse | Snapshot figé, pas de connaissance vivante | Taille de la context window, pas de mémoire inter-appels |
| Signal qu'il vous le faut | Les utilisateurs posent des questions spécifiques à l'entreprise | Le format de sortie ou le ton est régulièrement faux | Premier prototype, avant l'infra |
Change
- RAG
- Ce que le modèle sait
- Fine-tuning
- Comment le modèle écrit et raisonne
- Prompt engineering
- Comment le modèle est instruit pour une tâche
Coût de mise à jour
- RAG
- Ré-indexer les documents changés, instantané
- Fine-tuning
- Ré-entraîner le modèle, heures à jours
- Prompt engineering
- Éditer le prompt, instantané
Idéal pour
- RAG
- Connaissance privée, mises à jour fréquentes, citations
- Fine-tuning
- Style, ton, raisonnement métier, sorties structurées
- Prompt engineering
- Quick wins, assistants mono-tâche, prototypes
Limite
- RAG
- La qualité de recherche plafonne la qualité de réponse
- Fine-tuning
- Snapshot figé, pas de connaissance vivante
- Prompt engineering
- Taille de la context window, pas de mémoire inter-appels
Signal qu'il vous le faut
- RAG
- Les utilisateurs posent des questions spécifiques à l'entreprise
- Fine-tuning
- Le format de sortie ou le ton est régulièrement faux
- Prompt engineering
- Premier prototype, avant l'infra
Ce qui fait monter la facture
Ce que coûte vraiment une implémentation
On ne donne pas de fourchettes dans les articles parce que la variance est réelle. Les facteurs, par ordre d'impact : à quel point les sources sont en désordre (ça domine), combien de sources distinctes doivent être unifiées (chacune est son propre pipeline d'ingestion), à quel point le modèle de permissions est strict (filtrer la récupération par utilisateur, c'est du travail d'ingénierie), si l'assistant doit prendre des actions ou seulement répondre, et combien de charge de production il doit tenir.
Le motif qu'on voit : les clients sous-estiment le travail data et surestiment le travail IA. Le modèle est la partie facile. La partie difficile est de transformer votre contenu éparpillé, incohérent, à moitié indexé, en quelque chose qu'un pipeline de récupération peut vraiment utiliser. Un vrai chiffre se donne au bout de la revue de 30 minutes, après qu'on ait regardé vos sources réelles, pas avant.
Questions fréquentes
Ce que les entreprises demandent avant de construire leur premier assistant RAG.
En quoi le RAG est-il différent de ChatGPT ?
ChatGPT (et tout assistant général) ne sait que ce qui était dans son entraînement, plus ce que vous collez dans une conversation. Le RAG branche un assistant sur votre connaissance privée : il peut répondre sur vos contrats, vos politiques, vos tickets, vos produits, avec des citations vers le paragraphe source réel. ChatGPT est un assistant générique. Le RAG transforme un modèle en votre assistant.
Le RAG est-il meilleur que le fine-tuning ?
Ils résolvent des problèmes différents. Le RAG change ce que le modèle sait. Le fine-tuning change comment le modèle écrit et raisonne. La plupart des assistants en production utilisent les deux : RAG pour ancrer le modèle dans la connaissance vivante, fine-tuning pour verrouiller le ton et les formats de sortie structurés. Faire du fine-tuning seul pour la connaissance est une erreur courante : ça fige un snapshot qui devient obsolète en semaines.
Combien de temps prend un projet RAG ?
Un prototype fonctionnel qui interroge une seule source peut sortir en quelques semaines. Un système en production qui gère plusieurs sources, des permissions, du monitoring et de l'évaluation qualité prend plus longtemps, principalement parce que le travail data est réel. Le modèle et l'infra sont la partie rapide. Nettoyer, structurer et découper le contenu source, c'est ça qui donne le rythme.
Quel type de sources le RAG peut-il lire ?
Tout ce dont on peut extraire du texte : PDF, Word, pages wiki, articles de base de connaissances, tickets de support, notes CRM, enregistrements ERP, SharePoint interne, Notion, Confluence, archives email. La question dure : permissions et fraîcheur. Qui a le droit de voir quoi, et combien de temps la réponse peut-elle être obsolète. Les deux se résolvent, mais elles façonnent l'architecture.
Le RAG peut-il halluciner ?
Oui, moins souvent qu'un modèle brut, mais ça arrive. Deux scénarios : la recherche a raté le bon passage et le modèle a comblé ; ou la recherche a trouvé quelque chose qui semble pertinent mais ne l'est pas. Les bons systèmes RAG atténuent ça par des prompts stricts ('réponds seulement à partir des passages, refuse si la réponse n'y est pas'), des citations cliquables, et une boucle d'évaluation qui détecte les régressions. L'hallucination ne disparaît pas, mais elle devient auditable.
Le RAG peut-il tourner sur une infrastructure privée ?
Oui. Le modèle, le service d'embedding et la base vectorielle peuvent tous tourner sur une infrastructure privée si la résidence des données ou la conformité l'exige. Le compromis : du travail d'ingénierie. Les services gérés sortent plus vite, une infrastructure dédiée vous donne le contrôle. On aide les clients à choisir le bon point sur ce spectre, basé sur la sensibilité réelle des données, pas sur le théâtre.
Vous envisagez de construire un assistant RAG ?
Réservez une revue de 30 minutes. On regarde vos sources réelles, votre cas d'usage réel, et à quoi ressemblerait un pipeline taillé pour. Vous repartez avec une recommandation 1-page adaptée à vos données et contraintes, même si vous ne nous engagez pas.