RAG d'entreprise : quand ça suffit, quand ça ne suffit pas

« Le modèle ne connaît pas nos produits, il faudrait l'entraîner sur nos données. » Cette phrase, entendue dans presque tous les comités de pilotage IA, contient une confusion coûteuse. Dans la grande majorité des cas, le besoin réel n'est pas d'entraîner quoi que ce soit : c'est de donner au modèle accès aux bons documents au bon moment. C'est exactement ce que fait le RAG — et savoir où s'arrête son territoire évite de financer six mois de fine-tuning pour un problème qui se réglait en six semaines.

Qu'est-ce que le RAG ?

Le RAG (retrieval-augmented generation, ou génération augmentée par recherche) est une architecture qui connecte un modèle de langage à votre base documentaire : à chaque question, le système recherche d'abord les passages pertinents dans vos documents, puis les fournit au modèle pour qu'il rédige une réponse sourcée — sans jamais réentraîner le modèle lui-même.

La nuance est décisive : le modèle reste inchangé, générique, remplaçable. Ce qui devient intelligent, c'est le système autour de lui — l'indexation de vos documents, la recherche, l'assemblage du contexte. Vos connaissances restent dans vos documents, à jour et gouvernables, au lieu d'être figées dans les poids d'un modèle.

Quand le RAG suffit-il ?

Le RAG est la bonne réponse quand le problème est un problème d'accès à la connaissance. Les signatures typiques :

• Répondre à des questions sur un corpus : procédures internes, contrats, documentation produit, réglementation sectorielle. « Que dit notre police d'assurance sur les dégâts des eaux ? » est une question de RAG, pas d'entraînement.
• Exiger des réponses sourcées. Le RAG cite les passages sur lesquels il s'appuie ; l'utilisateur vérifie en un clic. Pour tout usage sérieux — juridique, conformité, support technique —, cette traçabilité n'est pas un luxe, c'est la condition d'adoption.
• Travailler sur une connaissance qui bouge. Tarifs, stocks, procédures, jurisprudence : un document mis à jour est réindexé en quelques minutes. Un modèle fine-tuné, lui, resterait à réentraîner à chaque évolution.
• Respecter des droits d'accès. Un système RAG bien conçu filtre les documents selon les habilitations de l'utilisateur : le commercial ne voit pas les documents RH. Une connaissance absorbée dans les poids d'un modèle, elle, ne se filtre plus.

Si votre cas d'usage coche ces cases, le RAG suffit — et il suffit d'autant mieux que les modèles récents acceptent des contextes très longs, ce qui pardonne davantage d'imprécision dans la recherche.

Quand le RAG ne suffit-il pas ?

Le RAG apporte des connaissances ; il n'apprend pas des comportements. Les limites apparaissent précisément là :

• Le style et le format. Si vous voulez qu'un modèle rédige systématiquement dans le ton de votre maison, respecte un gabarit métier strict ou produise un format de sortie très codifié, injecter des exemples dans le contexte a ses limites. Le fine-tuning — réentraîner légèrement un modèle sur vos exemples — excelle à ancrer ces comportements répétitifs.
• Le vocabulaire très spécialisé. Quand le langage de votre domaine s'écarte fortement de ce que le modèle a vu — nomenclatures internes, jargon technique dense, langues peu couvertes —, la recherche documentaire elle-même se dégrade, et le fine-tuning du modèle ou des composants de recherche devient pertinent.
• Le volume à coût serré. Pour une tâche simple, répétée des millions de fois — classer des tickets, extraire des champs —, un petit modèle fine-tuné coûte souvent moins cher à l'exécution qu'un grand modèle généraliste alimenté par un contexte volumineux à chaque appel.
• Le raisonnement multi-étapes sur les systèmes. Si la réponse exige d'interroger l'ERP, croiser avec le CRM et déclencher une action, le sujet n'est plus le RAG mais l'orchestration d'outils — le territoire des agents et de protocoles comme MCP.

Et une limite qui ne se résout ni par l'un ni par l'autre : si vos documents sont contradictoires, obsolètes ou introuvables, aucune architecture ne compensera. Le RAG expose la qualité documentaire de l'entreprise ; il ne la crée pas.

Les trois erreurs classiques des projets RAG

1. Tout indexer, sans curation

Le réflexe « on branche le serveur de fichiers et on verra » produit des systèmes qui répondent avec la version 2019 d'une procédure abrogée. Le classement des résultats ne distingue pas le document faisant foi du brouillon qui lui ressemble. Un RAG sérieux commence par un périmètre documentaire délimité, des sources faisant autorité identifiées, et une règle simple : ce qui n'est pas fiable n'entre pas dans l'index. Mieux vaut deux cents documents maîtrisés que vingt mille douteux.

2. Négliger le découpage et la structure des documents

Entre l'indexation et la réponse, il y a une étape invisible et déterminante : le découpage des documents en fragments (chunking). Découpez un tableau en deux, séparez une clause de son exception, et le modèle recevra des morceaux dépourvus de sens — puis répondra avec assurance à partir de ces morceaux. Les documents d'entreprise réels — PDF scannés, tableaux, présentations — exigent un traitement adapté à leur structure. C'est un travail ingrat, et c'est là que se joue une grande partie de la qualité finale.

3. Évaluer à l'œil nu, sans jeu de test

Beaucoup de pilotes RAG sont validés parce que « les réponses ont l'air bonnes » sur dix questions posées en démonstration. Puis la production révèle les 15 % de questions où le système invente. La discipline minimale : un jeu de cent à deux cents questions représentatives avec les réponses attendues et leurs sources, une mesure systématique avant tout changement, et un suivi des réponses signalées par les utilisateurs. Sans cela, chaque évolution du système est un pari, et la confiance des utilisateurs ne survit pas au troisième pari perdu.

RAG et fine-tuning ne s'opposent pas

La question « RAG ou fine-tuning ? » est souvent mal posée : les architectures matures combinent les deux. Le schéma le plus fréquent : le RAG fournit les connaissances — à jour, sourcées, gouvernées — pendant qu'un fine-tuning léger règle le comportement — ton, format, respect des consignes métier. L'ordre des investissements, lui, ne fait guère débat : commencez par le RAG, qui résout la majorité des besoins, se déploie vite et reste réversible ; n'ajoutez le fine-tuning que lorsqu'un besoin résiduel précis le justifie, preuve à l'appui.

Du pilote à la production

Un RAG de démonstration se construit en une semaine ; un RAG de production — avec la curation, les droits d'accès, l'évaluation et la supervision — est un projet d'ingénierie à part entière. C'est ce que couvre notre offre d'ingénierie IA : architecture, qualité documentaire, jeux d'évaluation et mise en production. Et quand vos documents ne peuvent pas quitter votre périmètre — secret bancaire, données de santé, infrastructures critiques —, le RAG se déploie intégralement sur vos infrastructures dans le cadre de notre offre d'IA souveraine. Pour situer votre cas d'usage, échangeons.