RAG vs Agentique — Comment choisir, et comment livrer du RAG quand c'est le bon choix (2026)

Pourquoi ce guide existe

La plupart des tutoriels RAG s'arrêtent à "charger les documents → embedder → chercher → interroger le LLM." Ça fonctionne en démo. Pas en production.

Mais il y a une étape encore plus en amont que personne ne couvre : devez-vous vraiment faire du RAG ? Sur les produits que nous avons livrés, le RAG était rarement le bon choix par défaut — un seul de notre portfolio en avait réellement besoin (un moteur de narration longue forme sur un large corpus markdown, où chaque question est fondamentalement sémantique). Pour tout le reste — dashboards SaaS, agents de workflow, copilotes opérationnels — une architecture agentique avec des tool calls structurés vers la base de données existante a surpassé le RAG sur tous les indicateurs qui comptaient.

Ce guide est ce que nous aurions aimé avoir il y a deux ans. Il couvre (1) quand choisir RAG plutôt qu'une approche agentique + tool calls, et (2) comment livrer du RAG correctement quand c'est la bonne option.

Il s'adresse aux PME — des équipes sans plateforme ML interne, mais avec de vrais utilisateurs qui remarquent quand l'agent hallucine.

Quand ne PAS faire de RAG — l'alternative agentique

Avant d'embedder le moindre chunk, posez-vous la question : vos données sont-elles textuelles et non structurées, ou relationnelles et déjà dans une base de données ?

Si elles sont relationnelles, le RAG est presque toujours le mauvais outil. Le réflexe habituel — découper toutes vos tables et emails en tranches de 500 tokens, les embedder, les indexer — détruit la structure qui rendait ces données utiles. Une question comme "quels enregistrements sont incomplets ce mois-ci" est un db.find(), pas une recherche de similarité vectorielle sur du texte fragmenté.

L'alternative que nous livrons par défaut pour les produits SaaS / ops internes :

• Un agent construit sur le claude-agent-sdk d'Anthropic (ou équivalent), avec des tool calls fortement typés qui traduisent la question de l'utilisateur en requêtes structurées sur le store de données existant
• Le contexte documentaire (politiques, SOPs, base de connaissances) réside dans un petit ensemble de fichiers markdown, injecté directement dans le system prompt avec du prompt caching — pas découpé, pas embedé
• Les outils retournent des données structurées que le LLM formate ; aucune récupération sémantique sur du texte fragmenté n'est impliquée

Ce pattern gère "combien d'enregistrements actifs ce mois", "quel compte a manqué la dernière facture", "montrer les contrats non signés cette semaine" avec une précision O(1) et zéro risque d'hallucination sur les chiffres. Le RAG perdrait toutes ces requêtes.

Grille de décision

La décision est par produit, pas par agence. Un moteur de narration longue forme sur un large corpus markdown est un cas RAG classique. Un bot de gestion opérationnelle sur un schéma structuré est un cas agentique classique.

Si vous êtes tenté de tout passer au RAG : arrêtez, listez vos 20 principales questions utilisateurs, et vérifiez combien sont réellement relationnelles. Le nombre est généralement plus élevé que prévu.

Le socle RAG honnête

Si vous avez consulté la grille et que le RAG est le bon choix, voici comment le faire sans y passer six semaines.

Le RAG naïf ressemble à :

1. Découper les documents en chunks
2. Embedder chaque chunk avec un modèle (OpenAI, Cohere, BGE)
3. Stocker les embeddings dans une vector DB
4. À la requête : embedder la question, trouver les top-k chunks similaires, les injecter dans le prompt LLM
5. Retourner la réponse

Ça fonctionne pour 70% des questions quand :

• Les documents sont propres et raisonnablement homogènes
• Les questions sont courtes et bien formulées
• Le domaine n'est pas saturé de jargon
• Les utilisateurs ne posent pas de questions multi-sauts

Pour les 30% restants, ça déraille. C'est là que se situe le vrai travail.

Le chunking — la décision la plus sous-estimée

Le tutoriel standard dit "découper par tranches de 500 tokens avec 50 de chevauchement." C'est presque toujours mauvais.

De meilleures valeurs par défaut :

• Markdown / docs structurés : découper par hiérarchie de titres. Un chunk = une section logique. Utiliser le texte du titre en préambule pour conserver le contexte.
• Texte longue forme (articles, transcriptions) : chunking sémantique — découper là où les sujets changent. Nous utilisons un petit LLM comme splitter (Claude Haiku ou gpt-4o-mini) ; les chunkers sémantiques des frameworks fonctionnent aussi si vous préférez ne pas le coder vous-même.
• Code ou contrats : chunker par unité structurelle (fonction, clause). Conserver le contexte parent.
• Tableaux : ne pas chunker. Embedder chaque ligne comme son propre chunk, avec les en-têtes de colonnes en contexte.

Nous avons vu la qualité de récupération passer de 60% à 88% rien qu'en corrigeant le chunking. C'est le levier le plus rentable que vous puissiez actionner.

Embeddings — choisir une fois, évaluer en continu

En 2026, les options managées réalistes sont OpenAI text-embedding-3-small / text-embedding-3-large, la famille Voyage AI voyage-3, Mistral mistral-embed, et gemini-embedding de Google. Les quatre sont bons. Choisissez celui qui gagne sur vos données, pas sur le MTEB.

Ce qu'il faut éviter pour les PME : héberger soi-même un modèle comme BGE-M3. La qualité open source est excellente, mais vous payez un GPU (ou acceptez 200 ms+ de latence CPU par embedding) pour des gains marginaux sur text-embedding-3-small à $0.02 par million de tokens, managé, sub-50 ms. Les embeddings auto-hébergés ont du sens pour les très grandes entreprises avec des mandats de confidentialité ou des millions de QPS — pas pour les projets que ce guide cible.

Pour les corpus à dominante française, mistral-embed est le point de test le plus solide — il est compétitif avec OpenAI sur des données exclusivement en français. Nous l'avons utilisé dans des pipelines OCR sur des PDFs réglementaires longs ; même dans ce cas, ça vaut la peine de faire un A/B test contre text-embedding-3-small sur VOS documents avant de verrouiller.

L'erreur à éviter : choisir des embeddings en fonction des benchmarks plutôt que de vos propres données. Les scores MTEB ne se traduisent pas dans votre domaine. Construisez un petit ensemble d'évaluation (50 questions, réponses de référence) et testez 2–3 modèles d'embedding. Choisissez ce qui gagne sur VOS données.

Vector store — utiliser ce que l'app fait déjà tourner

La plupart des projets RAG pour PME n'ont pas besoin d'une vector DB dédiée. Adaptez le store au stack existant :

• MongoDB Atlas Vector Search quand l'app est sur MongoDB. Atlas expose $vectorSearch comme étape d'agrégation avec des index HNSW, un filtrage par métadonnées en syntaxe Mongo standard, et la recherche hybride via Atlas full-text. Zéro nouvelle infra. (Nous utilisons $vectorSearch en production aujourd'hui sur des cas d'usage non-RAG — vecteurs de features sur des enregistrements structurés — nous connaissons donc bien le profil opérationnel.)
• pgvector quand l'app est sur Postgres. Même logique, DB différente.
• Pinecone est un bon choix pour les produits narratifs / textuels non structurés, surtout associé à LangChain. Pour les corpus larges, textuels et sémantiques — moteurs de narration longue forme, bibliothèques de contenu, bases de connaissances d'articles — il s'associe naturellement à RecursiveCharacterTextSplitter et un modèle d'embedding managé.

Passez à des vector DBs dédiées (Pinecone, Weaviate, Qdrant) quand :

• Vous atteignez 10 M+ vecteurs
• Vous avez besoin d'une latence p95 sub-50 ms à fort QPS
• Vous voulez un scaling serverless et la recherche hybride intégrés

Pour 90% des projets RAG PME, la base de données que l'app utilise déjà est le bon choix. Ne pas introduire Postgres juste pour pgvector si votre stack est Mongo — c'est un fork d'infra inutile. Atlas Vector Search est comparable en capacité pour les volumes que les PME livrent.

Reranking — seulement quand ça vaut la peine

Le conseil standard est "toujours reranker avec Cohere ou un cross-encoder." La version honnête : rerankez seulement quand vous avez plus de ~50 candidats après récupération. En dessous de ce seuil, le LLM peut les lire tous et l'appel API supplémentaire ne vous apporte rien.

Si vous avez vraiment besoin de reranker : un petit appel LLM "juge" (Haiku, gpt-4o-mini) suffit généralement — top-50 → rerank → top-10. Un reranker managé comme celui de Cohere a du sens au-delà de ~200 candidats ou avec des budgets de latence élevés en QPS. En dessous de ces seuils, c'est du surdimensionnement.

Coût : un appel API supplémentaire par requête. Latence : +100–300 ms. Souvent rentable. Parfois non.

Recherche hybride — ne pas l'ignorer

La recherche vectorielle pure rate les requêtes de correspondance exacte (codes produits, noms, chiffres). La recherche par mots-clés pure rate la similarité sémantique. Combinez les deux avec Reciprocal Rank Fusion ou un ranker appris.

Sous MongoDB : Atlas Vector Search + Atlas full-text search, fusionnés à la requête. Sous Postgres : pgvector pour les vecteurs + tsvector pour le full-text. La variante MongoDB s'associe naturellement aux apps déjà sur Mongo (sans infra supplémentaire), ce qui est le point de départ le plus courant.

Évaluation — la partie que tout le monde zappe

On ne peut pas améliorer ce qu'on ne mesure pas. Construisez un ensemble d'évaluation :

1. Collectez 50–100 vraies questions utilisateurs (depuis les logs, ou synthétiques depuis votre corpus)
2. Faites écrire la bonne réponse par un expert du domaine pour chacune
3. Faites tourner votre pipeline RAG, scorez chaque réponse avec un LLM-as-judge (GPT-4o ou Claude) sur :
   • Fidélité (pas d'hallucination)
   • Pertinence (répond à la question)
   • Citations (chunks sources corrects)

Lancez cette évaluation après chaque changement. Si le score baisse, revertez.

Outils : Ragas, DeepEval, ou roulez le vôtre avec un ensemble d'évaluation JSON. Ne zappez pas cette étape. C'est la différence entre un système RAG qui s'améliore et un qui dérive.

Contrôle des hallucinations

Trois couches :

1. Au niveau du prompt : instruire le LLM à répondre UNIQUEMENT à partir du contexte, et à dire "je ne sais pas" si le contexte ne contient pas la réponse.
2. Enforcement des citations : exiger que le LLM cite les IDs de chunks pour chaque affirmation. Rejeter les réponses sans citations.
3. Vérification post-hoc : un second appel LLM qui vérifie chaque affirmation contre la source. Plus lent, mais attrape les pires cas.

Pour les domaines à forts enjeux (juridique, médical, finance), utilisez les trois.

Maîtrise des coûts

Une requête RAG typique à notre échelle :

• Embedding : $0.00001 (négligeable)
• Recherche vectorielle : $0 (déjà sur MongoDB Atlas, inclus dans votre tier)
• Reranker : $0.001
• Appel LLM : $0.005–0.02 (selon la taille du contexte)

Votre coût est dominé par le LLM, lui-même dominé par la taille du contexte. Une troncature agressive du top-k, la compression du prompt, ou un LLM plus petit (Claude Haiku, GPT-4o-mini) peut réduire les coûts de 5–10× avec une perte de qualité minimale.

Un cas RAG en production — quand c'est le bon choix

Le pattern RAG le plus clair que nous livrons ressemble à ceci : un produit de narration longue forme ou de contenu avec un corpus markdown large et croissant. De nouveaux éléments sont produits régulièrement, doivent rester cohérents avec tout ce que le corpus a précédemment établi, et les questions sont fondamentalement sémantiques ("étant donné tout ce que nous savons sur ce personnage / sujet / arc, générer le prochain chapitre / réponse / continuation").

C'est un cas RAG classique : le corpus est textuel, large, et les questions sont sémantiques, pas relationnelles. Il n'y a pas de db.find() pour "produire un nouveau chapitre qui respecte la lore".

Un stack raisonnable sur ce profil :

• Un vector store managé (Pinecone, ou Atlas Vector Search si vous êtes déjà sur MongoDB)
• RecursiveCharacterTextSplitter avec chunkSize: 1000 et chunkOverlap: 100 — basique mais efficace pour du markdown narratif
• Un modèle d'embedding managé (Google ou OpenAI), benchmarké sur votre propre corpus avant de verrouiller
• Récupération top-5 comme contexte narratif, injecté dans le prompt
• Un LLM orienté raisonnement avec le mode thinking activé pour le passage de génération ; si le produit nécessite une continuité visuelle, un appel vision séparé sur des images de référence
• Des garde-fous narratifs hardcodés dans le system prompt (tropes interdits, ancres obligatoires, contraintes de voix)

Ce profil est l'exception. La plupart des produits reçoivent une architecture agentique + tool calls à la place — et sont plus fiables et moins coûteux à opérer pour ça.

La leçon : laisser la forme des données décider de l'architecture, pas le stack préféré de l'équipe.

Quand NE PAS utiliser RAG

• Le corpus est petit (< 100 documents) : mettez-le simplement dans le prompt
• Le corpus change toutes les heures : les stratégies de caching s'effondrent, les coûts explosent
• Les utilisateurs ont besoin de réponses issues de données nécessitant un raisonnement sur de nombreuses sources simultanément : le RAG ne remplace pas les agents analytiques

Conclusion

Le RAG est un outil, pas un produit. La première mission est de décider si votre problème en a réellement besoin. La plupart non — la plupart ont besoin d'un agent capable d'interroger les données que vous avez déjà, avec des tool calls et du prompt caching, le contexte documentaire injecté directement. Le RAG entre en jeu quand vous avez un vrai corpus de texte non structuré dont le contenu sémantique compte.

Si vous avez décidé que le RAG est le bon choix : commencez avec la DB que votre app utilise déjà (Atlas Vector Search ou pgvector), text-embedding-3-small ou mistral-embed pour les embeddings (ne vous auto-hébergez pas BGE pour une PME), la recherche hybride, le reranking seulement au-delà de ~50 candidats, et un ensemble d'évaluation dès le premier jour. Itérez chaque semaine.

Si vous n'êtes pas sûr de quel côté de la décision vous vous trouvez, ou si vous voulez un regard extérieur sur un stack qui dérive vers la sur-ingénierie, parlons-en. Nous avons livré les deux, et assez du mauvais au mauvais endroit pour connaître la différence.