RAG en entreprise : quand l'utiliser vraiment (et quand l'éviter)

Le RAG, ou retrieval augmented generation, est devenu la réponse par défaut à presque toutes les demandes d'IA en entreprise. Un dirigeant veut un assistant qui répond sur ses documents internes ? On propose du RAG. Une équipe veut interroger sa base de connaissances ? Du RAG. Un service veut un chatbot ? Encore du RAG. Le problème n'est pas que le RAG soit une mauvaise technologie, c'est qu'il est souvent choisi avant même d'avoir compris le besoin réel. Et un mauvais choix d'architecture coûte cher : des mois de développement, une base vectorielle à maintenir, et un assistant que personne n'utilise parce qu'il répond à côté.

Commençons par rappeler ce que fait vraiment le RAG. On découpe vos documents en morceaux, on les transforme en vecteurs, on les stocke dans une base spécialisée, puis à chaque question on retrouve les passages les plus proches et on les injecte dans le prompt envoyé au modèle. Le modèle ne "connaît" donc pas vos documents : il lit des extraits qu'on lui tend. Toute la qualité du système dépend de la qualité de cette étape de recherche.

Les cas où le RAG est le bon choix

Le RAG brille quand trois conditions sont réunies : le volume de connaissances est important, ces connaissances changent régulièrement, et les réponses doivent citer des sources vérifiables.

Un exemple concret : une PME industrielle avec 400 procédures qualité, mises à jour chaque mois. Un modèle affiné serait obsolète à peine entraîné. Un RAG branché sur le dossier partagé reste à jour automatiquement. Autre cas typique : un support client qui doit répondre en s'appuyant sur la documentation produit officielle, avec obligation de citer la version du manuel. Le RAG permet de dire "d'après la procédure v3.2, section 4" — ce qu'aucun modèle seul ne peut faire de façon fiable.

Le RAG est aussi pertinent quand vous devez cloisonner les accès. Si un commercial ne doit voir que les documents de son secteur, le filtrage se fait au moment de la recherche, pas dans le modèle. C'est un argument de sécurité majeur en entreprise.

Les cas où il faut l'éviter

Si votre base de connaissances tient en dix pages, ne construisez pas un pipeline RAG. Collez simplement ces dix pages dans le prompt système. C'est plus simple, moins cher, et plus fiable. J'ai vu des équipes passer trois mois sur une architecture vectorielle pour un contenu qui tenait dans un seul appel API.

Si vos données sont très structurées — tableaux de prix, stocks, plannings — le RAG est un détour coûteux. Une requête SQL bien écrite, exposée au modèle via un outil, donnera des résultats exacts là où la recherche sémantique approximera. Le RAG est fait pour du texte ambigu, pas pour des chiffres précis.

Autre piège : le besoin est en réalité une reformulation ou une synthèse de documents fournis à la volée. Là, aucun besoin de base vectorielle : l'utilisateur téléverse son fichier, on l'envoie au modèle, terminé.

Enfin, méfiez-vous du RAG quand la question est "le modèle doit-il adopter un ton ou un format très spécifique ?" Si le problème est le style et non la connaissance, c'est vers le fine-tuning ou un simple prompt engineering poussé qu'il faut regarder. RAG vs fine-tuning n'est pas un match : le RAG apporte des faits, le fine-tuning apporte un comportement. On les combine parfois, mais on ne les confond pas.

Les questions à poser avant de décider

Avant d'écrire une ligne de code, posez ces questions à votre équipe ou à votre prestataire.

• Quelle est la source de vérité, et à quelle fréquence change-t-elle ? Si elle change tous les jours, oubliez le fine-tuning. Si elle ne change jamais, demandez-vous si le RAG est justifié.
• Les réponses doivent-elles être exactes ou approximatives ? Pour un montant, une date, une référence légale, la recherche sémantique ne suffit pas.
• Combien de documents, et quelle qualité ? Un RAG sur des PDF scannés mal océrisés produira du bruit. Le nettoyage des données représente souvent 60 % de l'effort réel.
• Qui a le droit de voir quoi ? Le cloisonnement se conçoit dès le départ, pas après.
• Comment saurez-vous que ça marche ? Définissez dix à trente questions de test avec les réponses attendues avant de développer. Sans jeu d'évaluation, vous ne pourrez jamais améliorer le système.

Un assistant IA sur documents internes réussi n'est presque jamais un problème de modèle. C'est un problème de recherche, de découpage, de métadonnées et de tests. Le modèle, on peut le changer en une journée. La qualité du pipeline, non.

Et si on en parlait ?

Chaque projet a sa logique propre, et la bonne architecture n'est jamais celle qu'on applique par habitude. Si vous hésitez entre RAG, recherche classique, appel API direct ou une combinaison, le plus utile est d'en discuter tôt, avant d'investir dans la mauvaise direction. Décrivez votre contexte — les documents concernés, les utilisateurs, ce que vous attendez concrètement — et on regardera ensemble ce qui tient debout. Vous pouvez me joindre à contact@hamzabelgacem.com.