MCP vs RAG vs Agents : comprendre les architectures de l’IA moderne - DAHU.FR - Création internet

Il faut bien comprendre de quoi on parle : l’IA, c’est sympa… mais ce serait mieux si elle connaissait mes données sans en inventer.Depuis quelque temps, on parle beaucoup des serveurs MCP. Évidemment, je me suis dit :
« et si j’en faisais un, pour voir… »
(Documentation officielle du Model Context Protocol). J’ai donc commencé un test simple : créer un MCP sur mon site QueFaitesVous.com.

Deux outils (“tools”) :

listAVH : renvoie la liste des récits disponibles.
getAVH : renvoie le détail d’un récit en particulier.

Le tout repose sur un site MVC en PHP , donc assez simple.

L’objectif : permettre à mes modèles (AnythingLLM, LMStudio, etc.) d’appeler directement mon MCP.
Autrement dit, si je demande : « Donne-moi la liste des Aventures sur QueFaitesVous.com », il doit répondre la stricte vérité… en interrogeant mes propres services, sans avoir à visiter mes pages et les interpréter : un service propre avec un JSON parfait en réponse.

Je me contente des GET pour ce test, mais tout l’intérêt et de faire des POST, c’est-à-dire de permettre à mon modèle d’avoir une incidence réelle sur mes données, comme par exemple « ouvrir un ticket » .

Pourquoi connecter l’IA au “réel” ?

Un modèle d’IA, même très avancé, ne connaît pas vos données métiers, vos API internes ni vos règles de gestion.
Il ne sait rien de vous, et tout ce qu’il “sait” date forcément un peu.
Il sait raisonner, mais il ne sait pas où aller chercher l’information.
D’où l’apparition de trois grandes familles de solutions :
RAG, Agents et MCP.
Elles visent toutes le même objectif : donner à l’IA un accès propre, à jour et maîtrisé à votre écosystème.

Les trois approches en bref

RAG (Retrieval Augmented Generation)

Le RAG consiste à laisser l’IA rechercher dans une base documentaire (PDF, pages web, base vectorielle, etc.) pour enrichir sa réponse.
C’est parfait pour du question/réponse, de la documentation produit ou du support utilisateur.
Mais un RAG ne fait rien : il ne crée pas de compte, n’envoie pas de QR code, ne met pas à jour de fiche.

Techniquement, les RAG posent souvent le même défi : la qualité du dataset.
Autrement dit, tout dépend de la structure et de la propreté de vos données.
C’est, au fond, “juste” une base de données vectorielle.

Agents

Les agents sont des IA capables de planifier et enchaîner plusieurs actions :
« Je regarde la météo, puis j’envoie un mail, puis je résume ».
Puissant, mais plus complexe à encadrer (coût, contrôle, sécurité).
On les utilise quand on cherche de l’autonomie.

En résumé, on programme une suite d’actions, avec intervention du modèle uniquement à certains moments.

MCP (Model Context Protocol)

Le MCP adopte une autre philosophie : au lieu de dire “l’IA va tout faire toute seule”, on lui donne une
liste d’outils bien décrits qu’elle peut appeler quand elle en a besoin.
Le serveur MCP devient alors la prise normalisée entre l’IA et vos services.

Autrement dit, au lieu de dire à un agent “tu vas faire ceci, puis cela”, on dit directement au modèle “fais cela” et il comprend qu’il doit utiliser les bons outils pour y parvenir.

Ce qu’est vraiment un serveur MCP

Un serveur MCP, c’est un service qui dit à l’IA :
« Voici les outils que je propose, voici les paramètres attendus, voici ce que ça renvoie ».
L’IA peut ensuite les découvrir (via /.well-known/mcp.json)
puis les appeler (via /mcp/call).

Contrairement à une API REST classique, le MCP est conçu pour être auto-décrivable :
l’IA n’a pas besoin de lire votre documentation Postman.
Elle lit la description et le schéma d’entrée/sortie fournis par le serveur.

MCP ≠ REST (mais on peut partir de REST)

Une API REST expose des routes (GET /avh, POST /pro-account) pensées pour des humains ou des frontends.
Le MCP expose des outils (listAVH, getAVH…) pensés pour une IA.
La logique métier reste la même, seule la façon de la décrire change.

La bonne nouvelle : si vous avez déjà une API REST propre, vous pouvez la “habiller” en MCP.
Il suffit de créer :

un document de découverte : /.well-known/mcp.json qui indique où se trouve votre serveur MCP ;
un endpoint /mcp/tools listant les outils disponibles (équivalents de vos routes REST, mais décrits) ;
un endpoint /mcp/call qui exécute l’outil demandé avec les paramètres fournis.

Exemple tiré de mon test avec QueFaitesVous.com :

{
  "tools": [
    {
      "name": "listAVH",
      "description": "Retourne la liste des récits disponibles",
      "inputSchema": {
        "type": "object",
        "properties": {}
      }
    },
    {
      "name": "getAVH",
      "description": "Retourne les détails d’une AVH à partir de son id ou slug",
      "inputSchema": {
        "type": "object",
        "properties": {
          "id": { "type": "integer" },
          "slug": { "type": "string" }
        }
      }
    }
  ]
}

Sous le capot, vous pouvez réutiliser vos contrôleurs REST existants :
le MCP ne vous oblige pas à réécrire votre métier, il demande simplement de le déclarer proprement
et d’envoyer un JSON valide en UTF-8.
En pratique, la majorité des bugs vient de là : mauvaise validation, encodage défaillant ou clés inattendues.

Tableau comparatif rapide

Approche	Finalité	Ce que l’IA voit	Quand l’utiliser
RAG	Donner du contexte documentaire	Des textes retrouvés	FAQ, documentation, support
Agents	Enchaîner plusieurs actions	Des outils + un plan	Automatisation complexe
MCP	Exposer proprement des services métiers	Une liste d’outils décrits	Connecter une IA à votre système

Quand choisir MCP plutôt qu’un RAG ou un agent ?

Quand vous avez déjà des services REST et que vous voulez les rendre compréhensibles par une IA.
Quand vous voulez garder la maîtrise de ce que l’IA peut ou ne peut pas faire.
Quand vous cherchez un format stable et documenté que plusieurs IA peuvent consommer.
Quand vous ne voulez pas gérer un agent complexe mais souhaitez aller plus loin qu’un simple RAG.

Conclusion

Le MCP ne remplace pas le RAG ni les agents : il comble le fossé entre “l’IA sait parler” et “l’IA sait appeler mon service”.
Si votre objectif est d’ouvrir votre écosystème (comptes pro, statistiques, contenus pédagogiques, etc.) aux IA sans tout réécrire,
alors le duo REST existant + couche MCP est une voie pragmatique et puissante.

Mon avis

Les MCP sont encore en construction : il n’existe pas encore de spécification totalement stable.
J’ai passé trois jours complets à faire fonctionner mon serveur avec LMStudio et AnythingLLM.
J’ai dû tordre un peu le principe du MCP : en théorie, le service doit être streamable,
permettant un dialogue en temps réel entre le modèle et le service.
Sur un serveur mutualisé, pas question de monter un NodeJS ni un proxy dédié.
Mon service “fait semblant”… et ça marche !
Exposer ses services REST à un modèle d’IA est une idée incroyablement prometteuse — bien plus qu’un RAG ou un agent —
mais aussi potentiellement risquée : tout dépend de ce que vous exposez.

Donc, vraiment, quand on lit un peu plus la doc, il y a des trucs très puissants à construire, et cela a déjà commencé…

Il vous suffit d’aller sur https://github.com/modelcontextprotocol/servers pour comprendre l’ampleur des possibilités, le nombre de sites « annuaires » qui existent, etc.

Personnellement, je me pose la question des collisions entre services (ex: si j’ai 2 MCP pour connaître la météo)…

Tester le service

Démo proof-of-concept (si ça ne fonctionne pas, envoyez-moi un mail):

Avec LMStudio : ajoutez dans votre configuration :

{
  "mcpServers": {
    "qfv-mcp": {
      "url": "https://www.quefaitesvous.com/mcp"
    }
  }
}

Avec AnythingLLM : ajoutez :

{
  "mcpServers": {
    "qfv-mcp": {
      "type": "streamable",
      "url": "https://www.quefaitesvous.com/mcp"
    }
  }
}

Vous pourrez alors demander :
« Donne-moi la liste des AVH sur QueFaitesVous.com »
ou « Donne-moi des détails sur Mordicus ».
Sympa, non ?

Mot de la fin : les MCP vont profondément transformer la notion même de “service web”.