RAG ou pas RAG ? Comment décider intelligemment

"On va faire un RAG." Cette phrase, on l'entend de plus en plus dans les réunions de lancement de projets SaaS IA. Et pour cause : le Retrieval-Augmented Generation est devenu le couteau suisse des développeurs qui veulent personnaliser un LLM sans passer par la case fine-tuning. Quand on veut créer un SaaS IA, un RAG apparaît souvent comme la voie la plus simple et la plus évidente. Sauf que voilà : le RAG n'est pas une solution miracle. C'est un outil parmi d'autres, avec ses forces, ses faiblesses, et surtout, des alternatives souvent plus adaptées selon votre contexte.

Chez Lonestone, on accompagne des dizaines de projets SaaS intégrant l'IA. Et on a vu passer autant de RAG mal dimensionnés que de projets qui auraient gagné un temps fou en choisissant une autre approche dès le départ. Alors avant de vous lancer tête baissée dans une architecture de RAG, prenons le temps de poser les bonnes questions.

Un RAG n'est pas magique : quand ça marche (et quand ça coince)

Les cas d'usage où un RAG excelle vraiment

Commençons par rendre à César ce qui appartient à César : le RAG est une solution brillante pour certains cas d'usage. Et quand le contexte s'y prête, c'est même souvent le meilleur choix.

Le cas parfait : la base de connaissances structurée

Un assistant qui répond aux questions sur le droit du travail ou la réglementation ? le RAG est roi. Avec plusieurs milliers de documents structurés (lois, jurisprudences, notes internes), des questions factuelles précises ("quel est le délai légal pour...", "quelle jurisprudence couvre..."), et un besoin absolu de citer les sources, le RAG excelle naturellement. Les documents sont homogènes, les questions prévisibles, et le besoin est purement consultatif.

Le cas où le RAG s'impose : la documentation technique

Autre contexte idéal : un assistant sur une documentation produit. Des centaines de pages de guides utilisateurs, mises à jour trimestriellement, et des utilisateurs qui posent des questions factuelles ("comment configurer X ?", "où trouver l'option Y ?"). Le RAG est le choix évident : la documentation est déjà bien structurée, elle évolue à un rythme gérable, et la recherche vectorielle fonctionne parfaitement sur ce type de contenu.

Dans ces contextes, essayer de faire du fine-tuning aurait été absurde (la doc change trop souvent), et une architecture agent serait du over-engineering (pas besoin d'actions, juste de consultation).

Mais les limites du RAG apparaissent vite hors de ce cadre

Le problème, c'est que beaucoup de projets sortent rapidement de ce périmètre idéal. Et là, les limites techniques du RAG deviennent des vrais blocages.

Limite #1 : Quand il faut faire des actions, pas juste consulter

Imaginez maintenant un assistant commercial qui doit non seulement consulter l'historique client, mais aussi créer un rendez-vous, mettre à jour le CRM, et envoyer un email de confirmation. Un RAG ne sait pas faire d'actions. Il lit, il synthétise, point final. Vous vous retrouvez alors à empiler des couches de code autour du RAG pour orchestrer ces actions, transformant votre architecture en usine à gaz. C'est exactement là qu'une architecture agent devient plus pertinente.

Limite #2 : Les données en temps réel

Un RAG fonctionne sur des données pré-vectorisées. Cela signifie qu'il y a toujours un décalage entre la réalité et ce que voit votre assistant. Pour une base de connaissances qui évolue trimestriellement, aucun problème. Mais si vous voulez accéder au statut d'une commande, au solde d'un compte, ou à la disponibilité d'un produit en stock ? Vous êtes coincé : soit vous re-vectorisez en permanence (coût prohibitif et latence inacceptable), soit vos données sont obsolètes.

Certains essaient de contourner le problème en faisant de la "pseudo-temps réel" avec des mises à jour toutes les 15 minutes. Résultat : une architecture hybride baroque où il faut gérer à la fois le RAG pour les données "stables" et des appels API directs pour les données "vivantes". Vous multipliez les couches de complexité pour un résultat bancal.

Limite #3 : La qualité de recherche dépend de la formulation

Même dans son cas d'usage idéal, un RAG a un talon d'Achille : la recherche vectorielle. Si votre utilisateur demande "montrez-moi les clients mécontents", votre système doit comprendre que "mécontent" = "insatisfait" = "feedback négatif" = "note NPS basse". Vous passez alors des semaines à enrichir vos embeddings, créer des synonymes, ajuster vos paramètres... pour atteindre au mieux 80% de précision.

La recherche vectorielle peut ramener des passages sémantiquement proches mais factuellement inadaptés. Par exemple, à la question "comment changer mon mot de passe sur mobile ?", un système de RAG peut renvoyer la documentation desktop simplement parce que les embeddings des deux textes sont très similaires. Les techniques de métadonnées et de filtrage aident, mais ne résolvent pas complètement ce problème fondamental.

Limite #4 : Les hallucinations paradoxales persistent

Même avec un RAG, votre LLM peut inventer. Pire : il peut combiner maladroitement plusieurs passages récupérés et créer des informations fausses qui semblent cohérentes parce qu'elles utilisent du vocabulaire issu de vos vraies données. Par exemple, mélanger les conditions de deux contrats différents pour créer des clauses qui n'existent nulle part. Un RAG réduit les hallucinations, mais ne les élimine pas.

La question du coût du RAG: pas toujours celle qu'on croit

Beaucoup voient le RAG comme une solution économique parce qu'elle évite le fine-tuning. Et c'est vrai... dans certains contextes. Mais la réalité des coûts est plus nuancée.

Les coûts prévisibles : L'infrastructure de base vectorielle (Pinecone, Weaviate, Qdrant) représente 300 à 1000€/mois selon votre volume. La préparation initiale des données demande quelques jours d'un ingénieur data. Pour un projet avec une base documentaire stable, ces coûts sont tout à fait raisonnables et prévisibles.

Là où ça se complique : C'est quand vos données évoluent fréquemment. Chaque mise à jour significative nécessite de re-vectoriser, de vérifier que la qualité de retrieval ne se dégrade pas, d'ajuster les paramètres si nécessaire. La maintenance continue peut facilement mobiliser 15 à 20% du temps d'un ingénieur senior – un coût souvent sous-estimé en phase de cadrage.

Et il y a un coût plus insidieux : le debugging. Quand votre RAG donne une mauvaise réponse, identifier la cause prend du temps. Est-ce le contexte récupéré qui était mauvais ? Le prompt system mal formulé ? Le LLM qui a mal interprété ? Les trois à la fois ? Là où une architecture agent avec un MCP vous donne une traçabilité complète (chaque action est loggée), un RAG reste partiellement opaque.

Pour une base documentaire stable avec des mises à jour trimestrielles, le RAG reste souvent le choix le plus économique. Pour des données qui bougent quotidiennement ou des besoins d'actions multiples, d'autres approches peuvent s'avérer plus rentables à moyen terme.

RAG et données en temps réel : l'impasse

Un autre piège classique : vous voulez que votre assistant accède à des données en temps réel. Le statut d'une commande. Le solde d'un compte. La disponibilité d'un produit en stock. Avec un RAG, vous êtes coincé : soit vous re-vectorisez en permanence (coût prohibitif et latence), soit vos données sont obsolètes.

Certains essaient de contourner le problème en faisant de la "pseudo-temps réel" avec des mises à jour toutes les 15 minutes. Résultat : une architecture hybride où il faut gérer à la fois le RAG pour les données "stables" et des appels API directs pour les données "vivantes". Vous multipliez les couches de complexité pour un résultat bancal.

C'est exactement là que les agents IA + MCP changent la donne. Au lieu de pré-charger toutes les données possibles dans une base vectorielle, l'agent interroge directement les systèmes sources quand il en a besoin. Besoin du statut d'une commande ? Il appelle l'API de votre système de gestion. Besoin de l'historique client ? Il interroge le CRM. Les données sont toujours fraîches, sans infrastructure de vectorisation à maintenir.

4 alternatives au RAG pour votre SaaS IA

Agents IA + MCP : la réponse aux problèmes du RAG

L'architecture par agents ne se contente pas d'enrichir le contexte d'un LLM : elle lui donne des capacités d'action. Et c'est là que tout change. Le Model Context Protocol (MCP), récemment standardisé par Anthropic, formalise cette approche en définissant comment un LLM peut interagir avec des outils externes de manière sûre et traçable.

Résolution du problème #1 : les actions

Contrairement à un RAG qui ne peut que lire et synthétiser, un agent peut faire. Prenons l'assistant commercial évoqué plus haut. Avec un MCP, il va :

• Interroger votre CRM pour l'historique client (outil #1)

• Analyser les derniers emails échangés (outil #2)

• Vérifier les disponibilités dans le calendrier (outil #3)

• Créer le rendez-vous directement (outil #4)

• Envoyer l'invitation automatiquement (outil #5)

Chaque action est atomique, loggée, et peut être validée ou annulée. Vous avez une traçabilité complète de ce que fait votre IA, là où le RAG est une boîte noire.

Résolution du problème #2 : les données temps réel

Avec les agents, fini la galère de vectorisation permanente. L'agent interroge directement les sources de données quand il en a besoin. Le statut d'une commande est récupéré en temps réel depuis votre système logistique. Le solde d'un compte vient directement de votre API bancaire. Plus d'infrastructure de vectorisation à maintenir, plus de décalage temporel, plus de risque d'obsolescence.

Résolution du problème #3 : le debugging

C'est peut-être l'avantage le moins évident mais le plus précieux en production. Avec un MCP, chaque appel d'outil est tracé : quel outil a été appelé, avec quels paramètres, quelle réponse a été obtenue. Quand votre assistant donne une mauvaise réponse, vous voyez immédiatement si c'est l'outil qui a renvoyé de mauvaises données ou si c'est le LLM qui a mal interprété. Chez Lonestone, on observe une division par 5 du temps moyen de résolution d'incident entre nos architectures de RAG et nos architectures agent.

Résolution du problème #4 : la scalabilité

Ajouter une nouvelle source de données dans un RAG ? Il faut re-penser votre stratégie de chunking, potentiellement changer votre modèle d'embedding, re-vectoriser l'ensemble, tester la cohérence. Dans une architecture agent + MCP, vous ajoutez simplement un nouveau "tool" à la liste. L'agent apprend à l'utiliser via sa description, et c'est opérationnel. La différence en termes de vélocité est considérable quand votre périmètre fonctionnel évolue.

Notre stack MCP standard combine un orchestrateur d'agents (LangGraph ou framework propriétaire), une couche de sécurité qui valide chaque appel d'outil, et un système de fallback intelligent. Si un outil échoue, l'agent peut réessayer avec des paramètres ajustés, utiliser une source alternative, ou demander explicitement de l'aide à l'utilisateur. Cette robustesse est difficile à atteindre avec un simple RAG.

Bien sûr, les agents ont aussi leurs contraintes. La complexité initiale est plus élevée : il faut concevoir chaque outil, définir ses paramètres, gérer les erreurs. Les coûts d'appels API peuvent augmenter de 50 à 200% par rapport à un RAG basique, car l'agent fait plusieurs appels pour composer sa réponse. Et il faut des compétences solides en architecture logicielle pour bien structurer le système.

Mais dans la majorité des cas d'usage réels – ceux qui sortent du cadre "chatbot FAQ sur base documentaire" – les agents + MCP résolvent des problèmes que le RAG ne peut tout simplement pas adresser.

Fine-tuning ciblé : quand moins c'est plus

Le fine-tuning a mauvaise réputation : trop cher, trop long, trop compliqué. C'est faux. Pour des tâches spécifiques et répétitives, c'est souvent l'approche la plus efficace.

Prenons un cas concret : vous devez classifier automatiquement des emails clients dans 15 catégories métier. Avec 2 000 exemples bien labelisés, un fine-tuning d'un modèle comme GPT-3.5 ou Mistral vous donnera :

• 95%+ de précision (contre 75-80% avec du prompt engineering seul)

• Des temps de réponse ultra-rapides (pas de retrieval, pas de contexte massif)

• Des coûts prévisibles (pas de base vectorielle à maintenir)

La clé ? Avoir des données homogènes et une tâche bien définie. Le fine-tuning excelle dans la spécialisation, pas dans la polyvalence.

Quand choisir cette approche : Vous avez une tâche récurrente bien identifiée, au moins 1 000 exemples de qualité, et les besoins évoluent lentement (trimestriellement, pas quotidiennement).

Prompt engineering avancé : l'art du prompting

Avant de construire une cathédrale technique, demandez-vous si un prompt bien conçu ne suffirait pas. Le prompt engineering avancé a beaucoup évolué ces derniers mois.

Les techniques modernes incluent :

• Few-shot learning structuré : fournir 3-5 exemples parfaits qui guident le modèle

• Chain-of-thought prompting : forcer le modèle à décomposer son raisonnement

• Templates dynamiques : ajuster le prompt selon le contexte sans modifier l'architecture

Un générateur de contenus marketing peut parfaitement fonctionner avec des prompts élaborés et des templates métier, sans nécessiter de RAG ni de fine-tuning. L'avantage ? Une itération ultra-rapide. Vous pouvez tester 10 approches différentes dans la journée.

Quand choisir cette approche : Phase de prototypage, budgets serrés, besoin d'itérer rapidement, ou cas d'usage qui nécessitent plus de créativité que de précision factuelle.

Architecture hybride : combiner plusieurs approches

La réalité des SaaS IA matures ? Ils combinent plusieurs approches. Un système de routing intelligent analyse la requête et décide quelle technique utiliser.

Exemple d'architecture hybride que nous déployons régulièrement :

• Requêtes factuelles simples → RAG sur la base de connaissances

• Tâches répétitives → Modèle fine-tuné spécialisé

• Actions multi-systèmes → Agents avec un MCP

• Génération créative → Prompt engineering avancé

Le routing peut être basé sur des règles simples (détection de mots-clés) ou utiliser lui-même un petit modèle classifieur. L'essentiel est de monitorer finement pour comprendre quelle approche est réellement utilisée et optimiser chaque branche indépendamment.

Cette sophistication technique se justifie quand votre SaaS atteint une certaine maturité et que l'optimisation des coûts devient critique. Pour un MVP, restez simple.

Grille de décision : choisir la bonne approche pour votre projet

Matrice de décision par critères

La bonne approche dépend de quatre critères principaux qu'il faut pondérer selon vos priorités :

Volume et nature des données

Si vous avez moins de 100 documents, un RAG est probablement overkill. Au-dessus de 10 000 documents hétérogènes, il devient incontournable. Entre les deux, regardez plutôt la structure : des données homogènes appellent le fine-tuning, des données diverses privilégient le RAG ou les agents.

Fréquence de mise à jour

Vos données changent toutes les heures ? RAG. Tous les mois ? Fine-tuning. Quotidiennement ? Ça dépend du volume. Le point de bascule se situe généralement autour de mises à jour hebdomadaires : en-dessous, fine-tuning ; au-dessus, RAG.

Budget infrastructure

Un RAG demande une base vectorielle (300-1000€/mois selon la taille), fine-tuning un coût ponctuel (100-500€ par entraînement), les agents augmentent vos coûts d'API LLM de 50-200%. Faites le calcul sur 12 mois, pas sur le premier mois.

Compétences en interne

Soyons honnêtes : un RAG production-ready nécessite des compétences en ML ops. Le fine-tuning demande de l'expertise data. Le prompt engineering est accessible à des profils moins techniques. Les agents requièrent de solides bases en architecture logicielle.

Template de décision Lonestone

Chez Lonestone, on utilise un scorecard simple : pour chaque critère, on attribue un score de 1 à 5, puis on multiplie par un coefficient d'importance (1x, 2x ou 3x selon les priorités business du client). L'approche avec le score le plus élevé devient notre recommandation de départ, que nous validons ensuite avec un POC rapide.

5 questions pour trancher définitivement sur le RAG

Au-delà des matrices, ces cinq questions permettent souvent de trancher rapidement :

1. Vos données changent-elles plus vite que votre capacité à déployer ?

Si oui → RAG ou agents. Si non → Fine-tuning reste une option.

2. Avez-vous besoin de citer vos sources ?

Si oui → RAG obligatoire (traçabilité native). Si non → toutes les options sont ouvertes.

3. Votre IA doit-elle déclencher des actions ?

Si oui → Agents. Si non → RAG ou fine-tuning.

4. Avez-vous 6 mois ou 6 semaines ?

6 semaines → Prompt engineering + éventuellement RAG simple. 6 mois → Tout est possible, privilégiez la scalabilité.

5. Votre produit est-il un assistant ou un outil spécialisé ?

Assistant polyvalent → RAG ou agents. Outil spécialisé → Fine-tuning.

La décision technique est une décision business. Chez Lonestone, on ne choisit jamais une approche par dogmatisme technologique. On commence toujours par comprendre votre besoin métier, vos contraintes de délai et de budget, puis on dimensionne la solution en conséquence.

Un RAG est un outil puissant, mais ce n'est qu'un outil. Parfois, un bon prompt fait le job. Parfois, il faut une architecture hybride complexe. L'intelligence, c'est de savoir faire la différence avant d'investir six mois de développement.

Vous hésitez encore sur l'approche technique la plus adaptée à votre projet SaaS IA ? Contactez-nous pour un atelier de cadrage. En deux heures, on pose les bonnes questions, on challenge vos hypothèses, et on vous donne une recommandation claire avec un plan d'action pour les 3 premiers mois.