RAG contre MCP : lequel votre application d’IA a réellement besoin ?

Les gens se demandent souvent s’ils ont besoin de RAG ou de MCP, comme si ces deux solutions étaient des options concurrentes sur un menu. Ce n’est pas le cas, et une fois chacune d’elles comprise, le choix devient presque mécanique. Voici la version courte.

• RAG fournit à un modèle des connaissances qu’il n’a jamais vues pendant son entraînement en récupérant du texte pertinent et en le plaçant dans le prompt. Le modèle lit ensuite ce texte.
• MCP est un protocole standard permettant à un modèle d’appeler des outils et d’interagir avec des systèmes. Dans ce cas, le modèle effectue une action concrète.
• La manière simple de les distinguer : RAG concerne le contenu de vos documents, tandis que MCP concerne les capacités de vos systèmes.
• Ils ne sont pas concurrents. RAG est une technique et MCP est un protocole, donc la question « RAG ou MCP ? » revient un peu à demander « mémoïsation ou HTTP ? »
• Tout ce qui change, comme les prix, les stocks ou les soldes de compte, ne convient pas bien au RAG. Une base de données vectorielle renvoie ce qui a été indexé, et non ce qui est vrai en ce moment.
• Une grande quantité de texte principalement statique, telle que de la documentation, des contrats ou des politiques, est gaspilleuse à servir uniquement via MCP. Cela impliquerait des appels API pour des questions que un index bien conçu répondrait instantanément.
• La plupart des systèmes en production en 2026 combinent les deux : MCP pour récupérer des données fraîches et effectuer des actions, RAG pour ancrer le modèle dans des connaissances sectorielles stables.

Prenons une question qui semble simple mais ne l’est pas : quel est le ratio P/E d’Apple aujourd’hui ? Si on l’aborde avec RAG, la réponse obtenue est sûre d’elle, bien formulée, mais fausse. Si on l’aborde avec MCP, elle fonctionne correctement.

Même domaine, même utilisateur, architecture complètement différente. Ce qui suit aborde ces deux concepts depuis leurs principes fondamentaux, construit un assistant financier de trois manières différentes, et se termine par une règle de décision que vous pouvez appliquer sans beaucoup réfléchir.

Qu’est-ce que RAG ?

Ce nom signifie Retrieval-Augmented Generation. En termes simples, il s’agit de trois étapes : récupérer les extraits de texte les plus pertinents pour la question de l’utilisateur, enrichir le prompt en y intégrant ces extraits, puis générer une réponse à partir de ce contexte emprunté.

Imaginez un examen où les notes ne sont pas autorisées, mais où un assistant de recherche attend à l’extérieur de la salle. Une question est glissée sous la porte, l’assistant se rend à la bibliothèque, sélectionne les trois meilleures pages et les passe à nouveau sous la porte, et la réponse est rédigée à partir de ces pages. Rien n’a été appris ; les bonnes pages sont simplement arrivées au bon moment.

C’est cela, le RAG. Les poids du modèle ne changent jamais, car ce qui est modifié, c’est la requête et non le modèle lui-même.

Pourquoi une base de données vectorielle entre en jeu

La partie difficile concerne la première étape : trouver les pages appropriées. La recherche par mots-clés échoue souvent ici, car les questions des utilisateurs utilisent rarement les mêmes mots que le texte source. Quelqu’un demande des informations sur « les entreprises qui perdent de l’argent », tandis que le document parle de « revenu net négatif » : pas de mots en commun, mais un sens identique.

Les embeddings résolvent ce problème. Un tel modèle transforme le texte en un vecteur, c’est-à-dire une liste de nombres, disposés de telle manière que des significations similaires se trouvent proches les unes des autres. « Les entreprises qui perdent de l’argent » et « revenu net négatif » deviennent ainsi des voisins, même s’ils ne partagent pas de vocabulaire commun. Une base de données vectorielle stocke ces vecteurs et permet de répondre rapidement à une question : qu’est-ce qui est le plus proche de celui-ci ?

RAG en code

Voici une implémentation minimale sans framework, de sorte que toutes les composantes sont visibles. Elle contient quelques extraits financiers, les insère, les classe selon leur similarité cosinus par rapport à la question, et transmet les résultats les plus pertinents à un modèle de chat.

from openai import OpenAI
client = OpenAI()
# Your knowledge base, already chunked.
DOCUMENTS = [
    "The P/E ratio divides share price by earnings per share. "
    "When earnings are negative, P/E is undefined and usually shown as N/A.",
    "EV/EBITDA is often preferred over P/E for capital-intensive companies "
    "because it is unaffected by capital structure and depreciation policy.",
    "The PEG ratio adjusts P/E by the expected earnings growth rate. "
    "A PEG below 1.0 is traditionally read as undervalued.",
]

def embed(text: str) -> list[float]:
    """Turn text into a vector."""
    response = client.embeddings.create(
        model="text-embedding-3-small",
        input=text,
    )
    return response.data[0].embedding

def cosine_similarity(a: list[float], b: list[float]) -> float:
    """How close are two vectors? 1.0 means identical direction."""
    dot = sum(x * y for x, y in zip(a, b))
    norm_a = sum(x * x for x in a) ** 0.5
    norm_b = sum(y * y for y in b) ** 0.5
    return dot / (norm_a * norm_b)

# Index once, reuse many times. In production this lives in a vector DB.
INDEX = [(doc, embed(doc)) for doc in DOCUMENTS]

def retrieve(question: str, k: int = 2) -> list[str]:
    """Step 1: find the most relevant chunks."""
    q_vector = embed(question)
    scored = [
        (cosine_similarity(q_vector, vector), doc)
        for doc, vector in INDEX
    ]
    scored.sort(reverse=True)
    return [doc for _, doc in scored[:k]]

def answer(question: str) -> str:
    """Steps 2 and 3: augment the prompt, then generate."""
    context = "\n\n".join(retrieve(question))
    prompt = (
        f"Answer using only the context below.\n\n"
        f"Context:\n{context}\n\n"
        f"Question: {question}"
    )
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[{"role": "user", "content": prompt}],
    )
    return response.choices[0].message.content

print(answer("What do I use when a company has negative earnings?"))

Regardez ce qui s’est passé. Le modèle n’a jamais été entraîné sur ces trois extraits, pourtant il a donné la bonne réponse parce que le fragment pertinent figurait dans son prompt.

Regardez également le plafond des possibilités. RAG ne peut restituer que ce qui a été indexé. Si le ratio P/E d’Apple a changé ce matin et que l’index a été créé le mois dernier, RAG citera la valeur du mois dernier en affichant une certitude absolue. C’est précisément cette limitation qui explique l’existence de MCP.

Qu’est-ce que MCP ?

MCP, le Model Context Protocol, a été introduit par Anthropic en novembre 2024. Selon certaines sources, il a été transféré en décembre 2025 à l’Agentic AI Foundation, un projet de Linux Foundation, ce qui lui permet désormais d’être pris en charge par Claude, ChatGPT, Gemini, Cursor et VS Code, sans être un format réservé à un seul fournisseur.

C’est une norme permettant de relier des modèles d’IA à des outils. Il ne s’agit pas d’une technique mais d’un protocole, appartenant à la même famille qu’HTTP ou SQL.

Avant USB-C, chaque appareil disposait de son propre connecteur, ce qui signifiait que quinze appareils nécessitaient quinze câbles incompatibles. Les outils d’IA fonctionnaient de cette manière avant l’apparition de MCP. Relier 10 applications d’IA à 100 outils pouvait exiger la création de jusqu’à 1 000 intégrations personnalisées, chacune spécifique et à entretenir séparément. MCP réduit cela à une seule forme : un fournisseur d’outils implémente le protocole une seule fois, et tous les clients compatibles peuvent l’utiliser, tandis qu’une application d’IA implémente une seule fois la partie client pour accéder à tout.

Ce qu’un serveur MCP expose

• Les outils sont des fonctions appelables. L’appel à une commande comme get_stock_price("AAPL.US") exécute du code réel et renvoie un résultat réel.
• Les ressources sont des données que le modèle peut lire, telles que de la documentation ou le contenu de fichiers.
• Les prompts sont des modèles qui peuvent être réutilisés, et ils permettent de regrouper plusieurs outils en un flux de travail complet.

MCP en code

Un serveur fonctionnel est simple. Le suivant inclut une recherche de cotation et une comparaison de deux actions boursières, c’est tout.

from mcp.server.fastmcp import FastMCP
import httpx
mcp = FastMCP("finance-tools")

@mcp.tool()
def get_current_price(ticker: str) -> dict:
    """Get the latest price for a stock ticker.
    The docstring matters more than you'd think. It is what the
    model reads to decide whether to call this tool at all.
    """
    response = httpx.get(f"https://api.example.com/quote/{ticker}")
    return response.json()

@mcp.tool()
def compare_tickers(ticker_a: str, ticker_b: str) -> dict:
    """Compare two tickers on price, market cap and P/E ratio."""
    return {
        "a": get_current_price(ticker_a),
        "b": get_current_price(ticker_b),
    }

if __name__ == "__main__":
    mcp.run()

Une seule commande suffit pour l’enregistrer dans Claude Code :

claude mcp add finance -- python /path/to/server.py

Le modèle peut maintenant effectuer des actions. Il ne lit pas des informations sur les prix, il les récupère directement.

Détail souvent sous-estimé : la documentation est l’interface. Le fait que le modèle utilise ou non un outil dépend de la manière dont cet outil est décrit. Une description vague entraîne un outil que personne n’utilise, ce qui est généralement la raison pour laquelle un serveur MCP correctement installé semble ne rien faire.

La différence pratique

Comparés côte à côte, les deux diffèrent par leur nature et leur fonction. RAG est une technique qui lit dans un index ; MCP est un protocole qui interagit avec des systèmes en temps réel. RAG permet au modèle d’être mieux informé, tandis que MCP lui confère des capacités. RAG est peu coûteux et rapide par requête, car il s’agit d’une recherche vectorielle, tandis que MCP coûte autant que l’API sous-jacente. RAG devient obsolète lorsque l’index le devient, tandis que MCP renvoie ce que la source indique en ce moment même.

La règle tient en une phrase. Répondre dans un document ? RAG. Répondre dans un système ? MCP.

Essayez avec des questions réelles. « Qu’est-ce que le ratio PEG ? » se trouve dans un document, donc RAG. « À quel cours Microsoft est-il échangé ? » se trouve dans un système, donc MCP. « Passer une commande » ou « envoyer ce rapport » est une action, donc MCP quel que soit le cas, car la récupération ne peut pas agir sur quoi que ce soit. « Que dit notre politique de remboursement concernant les articles ouverts ? » est un ensemble de texte statique, donc RAG.

Pourquoi les gens se demandent constamment s’ils sont identiques

La confusion a une seule cause. Un serveur MCP peut publier de la documentation en tant que ressource, ce qui ressemble à la récupération. Ce qui les distingue, c’est la taille et le mécanisme. Les ressources correspondent à un ensemble limité de documents que le modèle peut trouver par identifiant, tandis que RAG prend en compte des milliers de documents où un classement sémantique doit identifier les trois plus pertinents.

Ces deux approches peuvent également être combinées. À l’intérieur d’un serveur MCP, vous pouvez exécuter toute une chaîne de traitement RAG et la présenter au modèle sous forme d’outil search_knowledge_base. Le modèle appelle alors cet outil, qui fait partie de l’architecture MCP, et cet outil s’occupe de la récupération des informations, ce qui correspond à la partie RAG.

Un assistant, construit de trois manières

Les comparaisons abstraites ont leurs limites ; envisagez donc un assistant d’analyse financière conçu selon chacune de ces méthodes pour voir où elles échouent. Les finances constituent un bon cas d’école, car ce domaine comprend à la fois des définitions immuables et des chiffres qui changent en permanence. Pour les données de marché, un fournisseur comme EODHD convient bien à cette démonstration, car il propose une API REST conventionnelle ainsi qu’un serveur MCP officiel, ce qui permet de comparer les architectures sans devoir changer de fournisseur de données en cours de route.

Version A : uniquement RAG

Indexez un corpus de connaissances financières, puis répondez à partir de celui-ci. Le corpus est une liste de définitions courtes ; un système réel en contient plusieurs milliers de fragments supplémentaires.

# Building a knowledge base of financial concepts
CORPUS = [
    "Market capitalization equals share price multiplied by shares outstanding.",
    "The P/E ratio compares share price to earnings per share.",
    "Free cash flow is operating cash flow minus capital expenditures.",
    "A dividend yield above 6% often signals either a falling share price "
    "or an unsustainable payout ratio.",
    # ...plus a few thousand more chunks
]

Après l’indexation, une question conceptuelle est posée :

# Index them, then:
answer("Explain what a high dividend yield might indicate")

Ce cas fonctionne très bien. Le concept ne change pas avec le temps, la réponse se trouve dans le corpus et le système de recherche la localise. Ensuite, une question en direct :

answer("What is Apple's current dividend yield?")

Cela échoue, et de la pire des manières. Le modèle récupère un extrait expliquant ce qu’est le rendement des dividendes, se souvient qu’il a absorbé quelques données d’Apple pendant l’entraînement, et produit quelque chose comme « Le rendement des dividendes d’Apple est d’environ 0,5 % ». Le texte est présenté avec assurance, bien formaté, mais peut être dépassé de plusieurs mois, sans que rien dans le processus ne le signale. C’est ce mode d’échec du RAG que les gens sous-estiment : il ne génère pas d’erreur, il renvoie simplement un texte fluide mais obsolète.

Version B : uniquement MCP

Ici, le modèle est connecté à des données en temps réel.

# EODHD publishes two endpoints. v2 uses OAuth, v1 uses an API key.
claude mcp add --transport http eodhd https://mcp.eodhd.com/v2/mcp

Lorsqu’on pose à nouveau la même question, elle emprunte désormais une voie différente. Le modèle appelle resolve_ticker("Apple") pour obtenir AAPL.US, puis il utilise un outil de données fondamentales pour obtenir la valeur d’aujourd’hui. Ce chiffre est fiable car il a été récupéré plutôt que mémorisé.

Deux choix de conception présents sur ce serveur méritent d’être étudiés, quel que soit le fournisseur utilisé, car ils résolvent les problèmes rencontrés par tout système d’appel d’outils. Tout d’abord, la résolution des codes boursiers constitue un outil de première classe. Les utilisateurs disent « Apple », tandis que les API exigent AAPL.US ; de même, les utilisateurs mentionnent « Deutsche Bank », mais l’API nécessite DBK.XETRA. Un outil de résolution capable de gérer les noms, les codes boursiers partiels et les ISIN, et qui propose des alternatives lorsque une entreprise est cotée sur plusieurs bourses au lieu de deviner en silence, élimine un point de défaillance. De nombreux échecs dans les appels d’outils au sein des agents financiers surviennent précisément à cet étape.

Deuxièmement, la documentation est intégrée en tant que ressources. Le serveur fournit apparemment plus d’une centaine de pages de documents API propres à celui-ci sous forme de ressources MCP, permettant ainsi au modèle de vérifier quels paramètres un point d’entrée accepte sans avoir à effectuer d’appel API. C’est intéressant sur le plan architectural : un petit schéma de type RAG fonctionnant à l’intérieur d’un serveur MCP, avec des matériaux de référence statiques en tant que ressources et des données en temps réel en tant qu’outils, chacun faisant ce pour quoi il est le mieux adapté.

Version C : les deux, c’est ce qui est livré

Seul, aucun de ces deux formats ne constitue un produit satisfaisant. La version basée sur RAG ne peut pas indiquer le prix actuel, tandis que la version MCP gaspille un appel API pour expliquer un ratio P/E. Une véritable conception envoie chaque question au sous-système approprié.

def route(question: str) -> str:
    """Decide which subsystem answers this question."""
# Signals that the question is about live state
    live_signals = ["current", "today", "now", "latest", "price", "quote"]
    if any(signal in question.lower() for signal in live_signals):
        return "mcp"      # fetch it
    return "rag"          # look it up

Le test de mot-clé présenté ci-dessus est délibérément simpliste. Les routeurs de production sont généralement conçus de cette manière : on leur fournit l’outil de recherche et les outils de données en temps réel, on les décrit en détail et on les laisse choisir. La répartition indiquée ci-dessous reste inchangée.

En pratique, cela se déroule comme suit :

• « Qu’est-ce que le ratio P/E mesure ? » est traité par RAG : instantané et presque gratuit.
• « Quel est le ratio P/E de Microsoft en ce moment ? » est traité par MCP : en temps réel, avec une seule appel API.
• « Le ratio P/E de Microsoft est-il élevé pour son secteur ? » nécessite les deux : MCP pour obtenir le chiffre et RAG pour le contexte sectoriel qui permet de l’interpréter.

C’est ce troisième type de question où la combinaison des outils est avantageuse, et il correspond également à la plupart des questions réelles des utilisateurs.

Comparaisons qui se mélangent avec celle-ci

Trois autres associations apparaissent souvent dans la confusion entre RAG et MCP, et chacune s’éclaircit rapidement.

MCP contre une API. Un serveur MCP est généralement un enveloppement autour d’une API et non son remplaçant. La différence réside dans le public cible. Une API REST convient à un développeur qui consulte la documentation et écrit du code d’intégration, tandis qu’un serveur MCP convient à un modèle qui découvre des outils en temps de exécution et lit leurs descriptions pour décider de quelle opération utiliser. L’API sous-jacente reste nécessaire, et MCP standardise la manière dont un modèle la trouve et l’appelle. Appeliez l’API directement depuis du code d’application déterministe, et utilisez MCP lorsque un modèle doit choisir une opération en temps de exécution.

MCP contre un agent. Ces deux éléments évoluent à des niveaux différents, ce qui rend toute comparaison entre eux une erreur de catégorie. L’agent est la partie qui raisonne, planifie et prend des décisions ; MCP est le moyen par lequel il interagit avec le monde extérieur. Sans MCP, un agent peut penser mais pas agir, et un serveur MCP sans agent n’a aucun interlocuteur. Claude Code est l’agent ici, et les serveurs MCP agissent comme ses mains.

RAG contre l’ajustement fin. Chacun modifie les capacités d’un modèle, mais par des voies différentes. L’ajustement fin modifie les poids et enseigne un comportement : ton, format, style de domaine, structure cohérente. Il est coûteux et lent à itérer, et mettre à jour les connaissances nécessite un reconditionnement. RAG laisse les poids inchangés, modifie la demande et enseigne des faits ; mettre à jour signifie simplement réindexer un document, ce qui ne prend que quelques secondes. En règle générale, utilisez l’ajustement fin pour définir le comportement du modèle et RAG pour déterminer ce qu’il doit savoir. Si la réponse change lorsque le document change, c’est RAG. Si elle change lorsque le guide de style change, il s’agit peut-être d’un ajustement fin.

Choix de la technologie

Toute personne développant l’une ou l’autre composante peut choisir parmi un marché très concurrentiel en 2026.

Pour la partie RAG, vous avez besoin d’une base de données vectorielle. Qdrant s’installe facilement en self-hosting dans Docker et fournit un serveur MCP officiel, ce qui permet d’accéder à un index depuis un script ou depuis Claude Code. Chroma constitue le point de départ le plus simple, fonctionnant en quelques minutes sans nécessiter d’infrastructure. Weaviate et Pinecone complètent les options sérieuses, Pinecone étant entièrement géré pour les équipes qui préfèrent ne rien gérer elles-mêmes. En ce qui concerne l’orchestration, LlamaIndex reste le framework le plus ciblé pour le problème de récupération et d’indexation, tandis que LangChain est plus généraliste et plus lourd.

Du côté MCP, Composio dirige de nombreuses applications vers une seule interface d’entrée et charge les outils au moment opportun, ce qui atténue l’encombrement lié à la connexion de dizaines de serveurs. Arcade.dev considère l’authentification comme une question fondamentale, en injectant des tokens OAuth lors de l’exécution des outils sans les exposer au modèle, ce qui est essentiel dès qu’il y a plusieurs utilisateurs impliqués. Mem0 relève des deux catégories : c’est un serveur MCP dont la fonction principale est la mémoire sémantique, autrement dit le retrait d’informations.

L’observabilité vient ensuite. Lorsque les deux composants fonctionnent, il est utile de savoir quels appels de retrait ont renvoyé des données inutiles et quels appels d’outils ont échoué, et Langfuse, qui est open source et peut être hébergé soi-même, permet de gérer cela.

On remarque que plusieurs de ces fournisseurs proposent désormais un serveur MCP pour des produits dont l’objectif principal est justement le retrait d’informations. En pratique, ces deux approches convergent plutôt que de se concurrencer.

Questions fréquentes

RAG est-il identique à MCP ? Non. RAG insère le texte récupéré dans une instruction afin que le modèle puisse le lire, tandis que MCP permet à un modèle d’appeler des outils et d’effectuer des actions. L’un rend le modèle mieux informé, l’autre le rend plus capable. Ils fonctionnent à des niveaux différents et apparaissent souvent ensemble au sein d’une même application.

MCP remplace-t-il RAG ? Non, et le considérer ainsi entraîne de réels erreurs de conception. MCP ne fait que standardiser la manière dont les outils sont appelés. Même si 50 000 documents nécessitent une recherche sémantique, des embeddings, une base de données vectorielle et un pipeline de récupération, ces éléments restent nécessaires. MCP modifie simplement le chemin d’accès, de sorte que le pipeline devient un outil derrière une interface standard plutôt qu’une intégration sur mesure.

Quand RAG est-il le meilleur choix ? Lorsque la réponse se trouve dans un volume important de texte relativement stable, tel que de la documentation, des contrats, des politiques, des articles de recherche ou des articles d’aide. Il coûte moins par requête et répond plus rapidement qu’un aller-retour via une API. Passez à MCP dès que la réponse dépend de l’état actuel, ou lorsque l’utilisateur souhaite que quelque chose soit fait plutôt que d’obtenir une explication.

Un serveur MCP est-il différent d’une API ? Généralement, il s’agit d’une couche supplémentaire par rapport à une API. L’API représente la capacité elle-même, tandis que MCP est la méthode standard permettant à un modèle de la découvrir et de l’appeler. Les développeurs consultent les documents d’API lors de la création, tandis que les modèles lisent les descriptions des outils MCP lors de leur exécution.

MCP a-t-il besoin d’une base de données vectorielle ? Non. MCP ne dispose pas de composant de recherche propre. Une base de données vectorielle n’est utilisée que si l’outil que vous exposez effectue une recherche sémantique, auquel cas elle se trouve derrière l’outil et non à ses côtés.

Un serveur MCP peut-il exécuter RAG en interne ? Oui, et c’est un schéma courant en production. Créez un pipeline de recherche normal et exposez-le en tant qu’outil, par exemple search_internal_docs. Le modèle appelle un seul outil, tandis que l’incorporation des données et la recherche vectorielle s’occupent du reste en arrière-plan.

Quel système coûte moins cher ? Une fois indexé, RAG est généralement plus avantageux par requête : une petite opération d’incorporation des données suivie d’une recherche vectorielle. MCP coûte ce que coûte l’API qui le soutient, ce qui peut aller de peu cher pour une cote boursière à cher pour une session de navigateur ou un traitement de document. L’erreur coûteuse consiste à envoyer des questions à MCP que un index statique aurait pu gérer.

En quoi MCP est-il lié à A2A ? Ils résolvent des problèmes distincts. MCP relie un modèle à des outils, tandis qu’A2A (Agent-to-Agent) permet aux agents de communiquer entre eux. Un même agent peut appeler une base de données via MCP et transmettre des tâches à un agent spécialisé via A2A, de sorte qu’ils s’associent plutôt que de concurrencer.

Comment choisir rapidement ? Imaginez de devoir relancer la requête dans une heure. Si la réponse diffère, il s’agit d’un état en temps réel qui nécessite l’utilisation de MCP. Sinon, il s’agit de connaissances stables pour lesquelles RAG est approprié. Ensuite, il faut déterminer si l’utilisateur souhaite que quelque chose se produise, car dans ce cas MCP est indispensable : RAG ne peut pas agir.

Pourquoi la confusion persiste-t-elle

La comparaison persiste car ces deux technologies sont devenues populaires à peu près en même temps, et on les décrit toutes deux à l’aide de l’expression « permet à votre IA d’accéder à vos données ». Cette expression a un poids excessif. Être capable de lire ce qui a été écrit est une chose, être capable d’agir à l’intérieur de vos systèmes en est une autre. Si l’on distingue bien ces deux aspects, l’architecture se dessine en grande partie d’elle-même.