Agentic RAG : quand le RAG classique ne suffit plus

Vous avez déployé un système RAG en entreprise. Il fonctionne bien sur les questions simples : trouver une clause dans un contrat, résumer une procédure interne, répondre à une FAQ technique. Mais dès qu'un utilisateur pose une question qui croise plusieurs documents, qui nécessite une comparaison ou qui demande un raisonnement en plusieurs étapes, le système décroche.

Ce n'est pas un bug. C'est une limitation architecturale du RAG classique. Le retrieval en un seul passage (single-shot) ne peut pas résoudre des problèmes qui exigent de la planification, de l'itération et du jugement. C'est exactement ce que l'Agentic RAG apporte : un agent qui raisonne avant de chercher, qui évalue ce qu'il trouve, et qui reformule si le résultat n'est pas satisfaisant.

Voici ce que ça change concrètement, quand c'est pertinent, et quand le RAG classique reste le meilleur choix.

Pourquoi le RAG classique atteint ses limites

Le RAG classique fonctionne en trois étapes : l'utilisateur pose une question, le système cherche les passages pertinents dans une base vectorielle, puis un LLM génère une réponse à partir de ces passages. C'est un pipeline linéaire, en un seul passage (single-shot retrieval).

Ce fonctionnement est parfaitement adapté à la majorité des cas d'usage en entreprise. Mais il échoue systématiquement dans trois situations.

Les questions multi-hop

Une question multi-hop nécessite de croiser plusieurs informations issues de documents différents pour construire la réponse. Par exemple : "Quel fournisseur propose le meilleur rapport qualité/prix pour les composants électroniques, en tenant compte des délais de livraison et des conditions de garantie ?"

Le RAG classique va chercher les passages les plus similaires à cette requête. Mais la réponse n'existe dans aucun document unique. Il faudrait comparer les fiches fournisseurs, croiser avec les conditions commerciales, et synthétiser. Un seul passage de retrieval ne peut pas faire ce travail.

Les requêtes ambiguës

Quand un utilisateur demande "Qu'est-ce qu'on risque si on ne respecte pas les délais ?", le système ne sait pas s'il parle de pénalités contractuelles, de risques réglementaires ou de conséquences commerciales. Le RAG classique va chercher les passages les plus similaires à la requête telle quelle, sans demander de précision ni explorer plusieurs pistes.

L'analyse comparative et la synthèse

Comparer les clauses de responsabilité dans 15 contrats, ou synthétiser les non-conformités d'un audit réglementaire à travers 200 pages de documentation : le RAG classique ne peut pas gérer ces tâches. Il est limité par sa fenêtre de contexte et par le fait qu'il ne sait pas planifier une stratégie de recherche.

Qu'est-ce que l'Agentic RAG

L'Agentic RAG (ou RAG agentique) est une architecture où un agent IA orchestre l'ensemble du processus de recherche et de génération. Au lieu d'un pipeline linéaire, l'agent opère dans une boucle de raisonnement : il planifie, exécute, évalue, et corrige.

Concrètement, voici ce qui change :

1. Planification : l'agent analyse la question et décide d'une stratégie de recherche avant de lancer le moindre retrieval.
2. Décomposition : si la question est complexe, il la découpe en sous-questions indépendantes, chacune traitable par un retrieval ciblé.
3. Exécution multi-sources : pour chaque sous-question, l'agent choisit le bon outil (base vectorielle, requête SQL, appel API) et récupère les informations.
4. Évaluation : l'agent juge si les résultats sont suffisants. Si un passage est hors sujet ou incomplet, il reformule et relance la recherche.
5. Synthèse : une fois toutes les sous-réponses collectées, l'agent les agrège en une réponse cohérente et sourcée.

La différence fondamentale, c'est que l'agent a la capacité de dire "je n'ai pas assez d'information, je dois chercher autrement". Le RAG classique, lui, fait toujours un seul passage et génère avec ce qu'il a trouvé, même si c'est insuffisant.

Les patterns concrets de l'Agentic RAG

L'Agentic RAG n'est pas une technologie monolithique. C'est un ensemble de patterns qu'on peut combiner selon le cas d'usage. Voici les quatre principaux.

Query decomposition (décomposition de requête)

C'est le pattern le plus impactant. Avant toute recherche, l'agent analyse la question et la décompose en sous-questions atomiques.

Exemple : "Compare les conditions de paiement et les pénalités de retard entre nos trois principaux fournisseurs."

L'agent décompose en :

• Quelles sont les conditions de paiement du fournisseur A ?
• Quelles sont les conditions de paiement du fournisseur B ?
• Quelles sont les conditions de paiement du fournisseur C ?
• Quelles sont les pénalités de retard du fournisseur A, B, C ?

Chaque sous-question cible un document précis, ce qui améliore drastiquement la qualité du retrieval. Ensuite, l'agent synthétise les résultats dans un tableau comparatif.

Self-reflection (auto-évaluation)

Après chaque étape de retrieval, l'agent évalue la pertinence et la complétude des résultats. Si les passages récupérés ne répondent pas à la sous-question, il peut :

• Reformuler la requête avec des termes différents
• Élargir le périmètre de recherche (plus de chunks, filtres différents)
• Changer de source (passer de la base vectorielle à une recherche SQL par exemple)
• Signaler une lacune si l'information n'existe tout simplement pas dans les données disponibles

Ce pattern est crucial pour éviter les hallucinations. Au lieu de générer une réponse à partir de passages non pertinents, l'agent reconnaît ses limites et agit en conséquence.

Tool use (utilisation d'outils)

Le RAG classique est limité à la recherche vectorielle. L'Agentic RAG donne à l'agent un ensemble d'outils qu'il peut appeler dynamiquement :

• Recherche vectorielle : pour les questions sémantiques sur des documents non structurés
• Requêtes SQL : pour les données structurées (chiffre d'affaires, stocks, dates)
• Appels API : pour les données en temps réel (cours, météo, statut de commande)
• Calculs : pour les opérations mathématiques que le LLM ne sait pas faire de manière fiable

L'agent décide quel outil utiliser en fonction de la nature de la question. Une question sur un montant contractuel appellera la base vectorielle. Une question sur l'évolution du chiffre d'affaires sur 12 mois appellera la base SQL.

Multi-step reasoning (raisonnement en chaîne)

Ce pattern combine les trois précédents dans une boucle itérative. L'agent avance étape par étape, chaque résultat intermédiaire alimentant l'étape suivante.

Exemple concret dans un contexte de due diligence :

1. L'agent identifie les 12 contrats fournisseurs à analyser
2. Pour chaque contrat, il extrait les clauses de résiliation et les conditions de renouvellement
3. Il détecte les incohérences entre contrats (durées différentes, clauses contradictoires)
4. Il génère un rapport de synthèse avec les risques identifiés, classés par criticité

Chaque étape dépend du résultat de la précédente. C'est impossible à réaliser avec un seul passage de retrieval.

RAG classique vs Agentic RAG : comparaison directe

Le point essentiel : l'Agentic RAG n'est pas un remplacement du RAG classique. C'est une couche supplémentaire pour les cas d'usage qui exigent un raisonnement complexe. Les deux architectures coexistent souvent dans le même système.

Cas d'usage concrets où l'Agentic RAG change la donne

Voici les situations que nous rencontrons régulièrement chez nos clients où le passage à l'Agentic RAG a transformé la qualité des réponses.

Analyse de contrats multi-documents

Un cabinet juridique doit comparer les clauses de non-concurrence dans 20 contrats de travail. Le RAG classique ne peut pas gérer cette tâche : il récupère au mieux 3 à 5 passages similaires, sans garantie de couvrir tous les contrats. En support client, la même logique agentique s'applique quand un agent doit croiser l'historique CRM, les tickets précédents et la documentation produit pour répondre à une demande complexe : voir notre article sur l'architecture RAG pour base de connaissances support N1, qui illustre comment l'itération et la boucle de feedback transforment un simple retrieval en un système apprenant.

L'agent Agentic RAG planifie l'analyse : il identifie les 20 contrats, extrait systématiquement la clause de non-concurrence de chacun, les compare sur des critères précis (durée, périmètre géographique, indemnité), et génère un tableau de synthèse. Temps gagné : plusieurs heures de travail d'un juriste senior.

Audit réglementaire

Un bureau d'études vérifie la conformité d'un projet aux normes DTU et RE2020. Les exigences sont réparties dans des dizaines de documents techniques. L'agent décompose la vérification point par point, croise chaque exigence avec la documentation du projet, et identifie les écarts de conformité.

Due diligence financière

Lors d'une acquisition, l'équipe M&A doit analyser les engagements hors bilan, les litiges en cours et les contrats clés d'une entreprise cible. L'agent parcourt systématiquement les rapports annuels, les procès-verbaux d'assemblées générales et les contrats majeurs pour construire une cartographie des risques.

Comparaison de spécifications techniques

Un acheteur industriel doit sélectionner un équipement parmi 8 offres fournisseurs. L'agent extrait les spécifications de chaque offre, les normalise dans un format commun, identifie les écarts par rapport au cahier des charges, et produit une matrice de sélection pondérée.

Stack technique pour l'Agentic RAG

Plusieurs frameworks permettent d'implémenter un Agentic RAG. Le choix dépend de la complexité du cas d'usage et du niveau de contrôle souhaité.

LangGraph

LangGraph (par LangChain) modélise le workflow de l'agent comme un graphe d'état. Chaque noeud représente une étape (planification, retrieval, évaluation, génération) et les arêtes définissent les transitions conditionnelles. C'est l'option la plus flexible pour des workflows complexes avec des boucles de rétroaction.

Point fort : le contrôle fin des transitions et la gestion native des états. Point faible : la courbe d'apprentissage et la verbosité du code.

LlamaIndex Workflows

LlamaIndex propose un système de workflows événementiels qui s'intègre naturellement avec ses composants de retrieval. C'est un bon choix si votre stack repose déjà sur LlamaIndex et que vous souhaitez ajouter de l'agenticité progressivement.

CrewAI

CrewAI est orienté multi-agents : chaque agent a un rôle spécialisé (chercheur, analyste, rédacteur) et ils collaborent pour résoudre la tâche. C'est pertinent pour les cas d'usage qui nécessitent plusieurs perspectives ou compétences distinctes.

L'approche custom

Pour les projets en production, nous recommandons souvent un orchestrateur léger construit sur mesure. Les frameworks génériques ajoutent de l'abstraction qui complique le debugging. Un script Python bien structuré avec des appels directs aux API (OpenAI, Anthropic, base vectorielle) offre plus de transparence et de contrôle pour le monitoring en production.

L'important n'est pas le framework. C'est de maîtriser les patterns (decomposition, reflection, tool use) et de les implémenter de manière traçable. Si vous partez de zéro, commencez par optimiser votre RAG classique avant d'ajouter la couche agentique.

Limites et compromis de l'Agentic RAG

L'Agentic RAG n'est pas une solution miracle. Il faut être lucide sur ses contraintes avant de s'engager.

Coût multiplié

Chaque requête peut déclencher 3 à 10 appels LLM (planification + sous-requêtes + évaluation + synthèse). Sur un modèle comme GPT-4o ou Claude 3.5 Sonnet, cela peut représenter 0,05 à 0,30 dollar par requête complexe, contre 0,01 à 0,03 dollar pour un RAG classique. À 1 000 requêtes par jour, la facture mensuelle peut passer de 300 à 3 000 dollars.

Latence accrue

Le temps de réponse passe de 1 à 3 secondes (RAG classique) à 5 à 30 secondes (Agentic RAG), selon le nombre d'itérations. C'est acceptable pour de l'analyse documentaire en back-office, mais incompatible avec un chatbot qui doit répondre en temps réel à des clients.

Complexité de debugging

Le RAG classique est un pipeline linéaire : si la réponse est mauvaise, on vérifie les chunks récupérés, puis le prompt, puis la génération. Avec l'Agentic RAG, chaque requête génère un arbre de décisions qu'il faut pouvoir tracer et inspecter. Sans un système de logging structuré (LangSmith, Arize Phoenix, ou un système maison), le debugging devient un cauchemar.

Risque de boucles

Un agent mal configuré peut tourner en boucle : reformuler indéfiniment une requête, chercher sans trouver, consommer des tokens sans produire de résultat. Il faut impérativement implémenter des limites d'itération (max 5 à 10 étapes) et des conditions d'arrêt explicites.

Quand passer du RAG classique à l'Agentic RAG

La décision n'est pas binaire. Voici les critères concrets pour évaluer si l'Agentic RAG se justifie dans votre contexte.

Dans la pratique, la meilleure approche est souvent hybride : un routeur intelligent qui envoie les questions simples vers le RAG classique (rapide, peu coûteux) et les questions complexes vers l'Agentic RAG (plus lent, plus cher, mais plus fiable). Ce routeur peut être un simple classificateur LLM qui évalue la complexité de la requête en amont.

En résumé : l'Agentic RAG est une évolution, pas une révolution

L'Agentic RAG ne remplace pas le RAG classique. Il le complète pour les 20 à 30 % de requêtes que le pipeline linéaire ne peut pas traiter correctement. La clé est de savoir quand l'utiliser, pas de l'appliquer partout.

Si votre système RAG actuel donne des résultats satisfaisants sur les questions simples mais échoue sur l'analyse multi-documents ou la synthèse comparative, l'Agentic RAG est la prochaine étape logique. Mais avant de vous lancer, assurez-vous d'avoir d'abord optimisé les fondamentaux : hybrid search, parsing intelligent, chunking sémantique et reranking.

L'IA n'est pas magique. C'est un système qu'on construit brique par brique, en partant du besoin métier. L'Agentic RAG est une brique puissante, mais elle ne compense jamais des données mal préparées ou un cas d'usage mal cadré.

Questions fréquentes

Articles recommandés

• RAG en entreprise : comprendre les fondamentaux du Retrieval-Augmented Generation.
• Optimiser un RAG : hybrid search, semantic chunking, reranking et les 5 leviers pour passer de la démo à la production.
• 5 erreurs qui font échouer les projets RAG : les pièges à éviter avant d'ajouter de l'agenticité.
• Agents IA vs chatbots : comprendre la différence entre un outil qui répond et un outil qui agit.
• RAG vs fine-tuning : comment choisir la bonne approche pour exploiter vos données.
• Rechercher la jurisprudence sur internet avec ChatGPT et Claude : un cas concret d'IA agentique qui combine recherche web et vérification de sources.
• Prompts IA pour bureaux d'études : un cas typique d'agent RAG appliqué aux livrables BET, avec les prompts pour notes de calcul, rapports techniques et synthèses CCTP.

Aller plus loin

Découvrez notre offre d'assistant IA interne RAG pour les PME et ETI, ou consultez nos cas clients pour voir des exemples concrets de déploiement. Pour un accompagnement personnalisé, contactez notre équipe à Toulouse.