RAG + Agent : architecture des applications IA de nouvelle génération

Une entreprise a passé trois mois à monter un système RAG. La première semaine en production, le patron l’a recadré : « Comment ça ne répond même pas à une simple question de remboursement de frais de déplacement ? »

La RAG traditionnelle, c’est l’étudiant qui ne sait que feuilleter le dictionnaire : vous posez une question, il cherche — sans réfléchir à l’intention derrière. Demandez « Mon remboursement de déplacement du mois dernier a été refusé, pourquoi ? », et il peut remonter une pile de politiques de voyage sans jamais consulter votre dossier de remboursement.

C’est précisément ce que la RAG agentique veut corriger.

Cet article parle de l’architecture fusion RAG + Agent — une approche qui redessine les applications IA en entreprise. De l’évolution architecturale au choix de framework, jusqu’à une feuille de route concrète. Un cas de service client intelligent est aussi partagé, pour vous donner des pistes.

De la RAG traditionnelle à la RAG agentique : évolution architecturale

Le principe de la RAG traditionnelle est simple : question → recherche vectorielle → documents pertinents → LLM qui génère la réponse. Trois étapes, terminé.

Les avantages sont évidents : rapide, peu coûteux, facile à mettre en place. Les limites aussi.

Retrieval imprécis. Sur une question floue, la similarité vectorielle peut remonter des documents « qui ressemblent » mais ne sont pas pertinents. « Comment configurer la connexion à la base ? » peut mélanger MySQL et PostgreSQL ; l’utilisateur doit trier lui-même.

Pas de raisonnement. La RAG classique enchaîne « retrieve → generate ». Sur un problème en plusieurs étapes, elle bloque. « Compare les avantages et inconvénients des options A et B » peut ne récupérer qu’un seul dossier — puis inventer le reste avec assurance.

"Enquête McKinsey : 47 % des utilisateurs de GenAI ont subi des conséquences négatives ; seulement 27 % vérifient toutes les sorties"

Ce que change la RAG agentique

L’idée centrale : l’IA réfléchit activement à la résolution, au lieu d’exécuter mécaniquement retrieve-generate.

Sa boucle :

Plan → Retrieve → Act → Reflect → Answer

Étape par étape :

Plan (planification) : analyser la question et la découper. « Mon remboursement de déplacement du mois dernier a été refusé » devient : consulter le dossier, lire la politique voyage, comparer pour expliquer le refus.

Retrieve (récupération) : décider où et quoi chercher — base de connaissances, base de données, API externe.

Act (action) : exécuter retrieval, appeler des outils, collecter l’information ; de nouvelles questions peuvent relancer la planification.

Reflect (réflexion) : le contexte est-il suffisant ? la réponse tient-elle la route ? Sinon, retour à Plan.

Answer (réponse) : réponse finale avec sources citées.

En bref : la RAG classique, c’est le dictionnaire ; la RAG agentique, un assistant de recherche qui analyse, creuse, vérifie, puis répond de façon fiable.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Derrière ce chiffre, l’attente entreprise passe de « ça marche » à « c’est vraiment utile ». La RAG agentique est une étape clé de cette montée en gamme.

10 modèles d’architecture RAG en détail

Beaucoup de matière — l’essentiel ici ; le tableau comparatif complet suit.

Naive RAG : niveau débutant

Architecture minimale : question → recherche vectorielle → réponse. Idéal pour valider une idée ; en production, rarement suffisant.

Problèmes typiques : faible précision de retrieval, fenêtre de contexte gaspillée, hallucinations. Je ne le recommande que pour un POC ou un outil interne.

Hybrid RAG : standard entreprise

C’est devenu la référence en production. Deux modes combinés : recherche lexicale (mots-clés) et sémantique (similarité vectorielle).

Pourquoi ? Chaque mode a ses forces : le lexique pour la correspondance exacte, le sémantique pour l’intention. Ensemble, le résultat s’améliore.

En pratique : BM25 pour le lexique, base vectorielle (Pinecone, Weaviate, Milvus…), fusion par Reciprocal Rank Fusion (RRF).

Graph RAG : le multi-sauts

Si vos cas exigent « pourquoi » et « comment c’est lié », la Graph RAG vaut le coup.

Entités extraites des documents → graphe de connaissances → raisonnement multi-sauts. « Quels produits utilisent des pièces de ce fournisseur ? » : on suit les relations du graphe.

Coût : souvent 3 à 5× une RAG de base — construction et maintenance du graphe.

RAG agentique : pensée active

Boucle déjà détaillée plus haut. À ajouter : la flexibilité est une arme à double tranchant.

Elle gère les cas complexes, mais latence et coût montent vite — une question simple peut déclencher plusieurs retrievals et appels d’outils. En déploiement, on route : questions simples → RAG classique ; complexes → flux agentique.

Self-RAG : auto-correction

Le modèle juge sa propre sortie : documents assez pertinents ? réponse hallucinée ?

Si le contrôle échoue, nouvelle recherche ou correction. Prometteur, mais coût de raisonnement plus élevé — et l’évaluation peut elle-même se tromper.

RAG agentique + graphe : plafond actuel

Mode le plus avancé : orchestration Agent dans le retrieval sur graphe — multi-sauts et planification active.

Coût au même niveau — réservé aux scénarios métier critiques.

Tableau comparatif des modèles

Je conseille de partir en Hybrid RAG et de monter selon le besoin réel. Viser tout de suite le mode le plus avancé, c’est souvent se planter.

Choix de framework : LangChain vs LlamaIndex vs CrewAI vs AutoGen

J’ai déjà pris une mauvaise décision : un projet, un framework choisi trop tôt, écosystème incomplet à mi-parcours — refactor obligatoire. Moral de l’équipe en chute libre.

Le choix compte. Voici une synthèse des frameworks majeurs pour éviter les détours.

LangChain / LangGraph : écosystème le plus complet

En cas de doute, LangChain reste un choix sûr. Documentation riche, communauté active, plus de 25 K stars GitHub (LangGraph).

LangGraph est la machine à états en graphe de l’équipe LangChain pour des workflows Agent avec état. Atout production : persistance — état en base, reprise sur erreur, débogage « time travel ».

Cas typiques : workflows de production, état persistant, orchestration Agent complexe.

# Exemple simplifié LangGraph : agent de planification de requête
from langgraph.graph import StateGraph

def plan_query(state):
    """Analyser la question et planifier les étapes de retrieval"""
    query = state["query"]
    # Décomposer la question, générer des sous-requêtes
    sub_queries = decompose(query)
    return {"sub_queries": sub_queries}

def retrieve(state):
    """Exécuter le retrieval"""
    results = []
    for q in state["sub_queries"]:
        docs = retriever.invoke(q)
        results.extend(docs)
    return {"context": results}

# Construire le workflow
workflow = StateGraph(AgentState)
workflow.add_node("plan", plan_query)
workflow.add_node("retrieve", retrieve)
workflow.add_edge("plan", "retrieve")

LlamaIndex : priorité data-intensive

Beaucoup de données non structurées (documents, bases, API) ? LlamaIndex est souvent le meilleur fit.

Moteurs de requête solides : vectoriel, mots-clés, hybride, graphe. Connecteurs vers de nombreuses sources.

Cas typiques : RAG data-intensive, multiples sources, qualité de retrieval prioritaire.

CrewAI : prototypage rapide

Argument clé : « équipe multi-agents pilotée par les rôles ». Plusieurs Agents avec objectifs et outils distincts collaborent.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Exemple équipe contenu : chercheur (sources), rédacteur (texte), éditeur (relecture).

Cas typiques : prototype rapide, automatisation de processus, tâches à rôles clairs.

Communauté de plus de 100 000 développeurs, plus de 20 K stars GitHub — croissance rapide.

AutoGen : multi-agents soutenu par Microsoft

Framework open source Microsoft Research, collaboration par dialogue. Plusieurs Agents conversent pour accomplir la tâche — adapté aux interactions multi-tours.

Particularité : human-in-the-loop — un humain peut corriger la direction à tout moment.

Cas typiques : recherche, tâches complexes avec humain, interaction conversationnelle.

Plus de 50 K stars GitHub — le framework Agent le plus suivi à ce jour.

Arbre de décision

Logique simplifiée :

Quel type de projet ?
├── Workflow persistant de production → LangGraph
├── RAG data-intensive → LlamaIndex
├── Prototype rapide / processus métier → CrewAI
├── Recherche / multi-agents conversationnels → AutoGen
└── Incertain / flexibilité maximale → LangChain + LangGraph

Pas de réponse universelle : alignez sur la stack de l’équipe et les besoins du projet, et surveillez la cadence des mises à jour et la vitalité de la communauté — cela fixe le coût de maintenance.

Feuille de route d’implémentation entreprise

Modèle sur 90 jours, issu de retours d’expérience chez plusieurs entreprises. Chaque organisation a son rythme ; adaptez.

Phase 1 : J0-15, définir le problème et les KPI

Erreur fréquente : sauter directement sur la techno. D’abord : quel problème résout-on ?

Questions clés :

1. Qui sont les utilisateurs ? Employés internes ou clients externes ?
2. Quel scénario central ? Q&R, recherche, raisonnement complexe ?
3. Comment mesurer le succès ? Précision, temps de réponse, satisfaction ?

Je recommande une mini-enquête utilisateur : 50 à 100 questions réelles — base de tests et d’évaluation ensuite.

Phase 2 : J16-45, données et couche retrieval

Préparer les données, c’est du travail de fond — et ça plafonne la qualité du système.

Nettoyage : doublons, contenu obsolète ou sensible. Souvent négligé ; des données sales dégradent fortement le retrieval.

Découpage (chunking) : taille selon le type — doc technique 500-1000 mots par bloc ; textes juridiques par article.

Embeddings : séries text-embedding-3 d’OpenAI, Cohere, BGE… Comparez sur un petit jeu de données.

Couche retrieval : partir en Hybrid RAG, BM25 + vectoriel.

Phase 3 : J46-75, orchestration Agent et intégration d’outils

On introduit les capacités Agent.

Routage : toutes les questions n’ont pas besoin d’un Agent. FAQ simples → RAG classique ; complexité → flux Agent — pour maîtriser coût et latence.

Outils : protocole MCP vers les systèmes internes — requêtes base, appels API, retrieval documentaire.

Orchestration : LangGraph ou équivalent ; commencer en ReAct simple, complexifier progressivement.

Phase 4 : J76-90, évaluation, tests et durcissement

Évaluation : framework RAGAS, trois métriques principales :

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

• Faithfulness (fidélité) : la réponse respecte-t-elle les documents récupérés ? objectif >= 0.8
• Answer Relevance : la réponse traite-t-elle la question ?
• Context Relevance : le contexte récupéré est-il pertinent ?

Autres indicateurs techniques :

• Recall@K >= 0.85 : rappel sur les K premiers résultats
• Latence P95 <= 2,5 s : 95 % des requêtes
• Coût : appels API et tokens par requête

Pièges courants

Quatre alertes :

1. Contournement des contrôles d’accès : un Agent peut appeler des outils hors périmètre — tests sécurité indispensables
2. Contexte expiré : en long dialogue, les infos anciennes se perdent — stratégie de gestion du contexte
3. Coût qui explose : multi-tours de retrieval → facture API qui grimpe vite

Cas pratique : architecture d’assistant service client

Retour d’expérience chez une entreprise — résultats solides.

Contexte : le support doit répondre sur produits, commandes, SAV, politiques — infos éparpillées entre base de connaissances, CRM, commandes, ERP.

Problème : la RAG classique ne consulte que la base documentaire, pas le statut de commande ni l’historique client.

Conception architecturale

Architecture Agent à trois niveaux :

Niveau 1 : Routing Agent (agent de routage)

Analyse la question et choisit la branche :

• « Comment utiliser le produit » → retrieval base de connaissances
• « Où en est ma commande » → requête système commandes
• « Quelle est la politique de remboursement » → docs politique

Niveau 2 : Query Planning Agent (agent de planification)

Pour les questions complexes, découpage en sous-requêtes. « Le téléphone acheté le mois dernier peut-il être retourné ? » implique :

1. Historique commandes de l’utilisateur
2. Politique de retour
3. Comparaison date d’achat et délais légaux

Niveau 3 : ReAct Agent (agent raisonnement-action)

Exécute retrieval et appels d’outils, avec itérations multiples.

Intégration d’outils

Connexion aux systèmes internes via MCP :

tools:
  - name: knowledge_search
    type: vector_retrieval
    source: product_docs

  - name: order_query
    type: api_call
    endpoint: /api/orders/{user_id}

  - name: policy_search
    type: hybrid_retrieval
    sources: [policy_docs, faq]

Comparaison des résultats

Après mise en production, RAG classique vs RAG agentique :

+33 points de résolution, intervention humaine divisée par plus de deux. Contrepartie : latence plus élevée — compromis inévitable avec l’architecture Agent.

Conclusion

RAG + Agent devient l’architecture de référence des applications IA en entreprise. Du retrieval passif au raisonnement actif, elle traite des problèmes réellement complexes.

Quatre recommandations :

1. Commencer simple. Pas de RAG agentique + graphe d’emblée : Hybrid RAG, valider la valeur, puis monter.

2. Maîtriser les coûts. La flexibilité Agent a un prix ; routage et cache sont indispensables.

3. Construire l’évaluation. Sans métriques, impossible de juger. RAGAS + jeu de tests maison : le minimum.

4. Suivre les protocoles ouverts. MCP standardise la connexion d’outils ; A2A travaille l’interopérabilité entre frameworks. Ils façonneront l’écosystème Agent.

Voilà l’essentiel. Si vous montez un système RAG, j’espère que cet article vous aide. Questions en commentaires.