Serveur MCP

• Facebook
• Instagram
• Twitter

---

Serveur MCP : Tout Ce Que Vous Devez Savoir en 2025

Si vous êtes comme moi, vous avez passé ces dernières années la tête dans le guidon, à essayer d’intégrer des LLM dans à peu près tout. Et, pour être honnête, ça a souvent été un mélange d’émerveillement et de frustration pure.

On passe des heures à peaufiner des prompts, à injecter des tonnes de contexte dans des requêtes API qui finissent par coûter un bras, pour un résultat qui reste… statique. Le LLM connaît ce qu’on lui a dit au début de la conversation, et c’est tout.

J’ai récemment travaillé sur un agent de support client pour une plateforme e-commerce, et on se battait constamment avec ce problème. On injectait l’historique de commande de l’utilisateur dans le system prompt, mais si une nouvelle commande était passée pendant la conversation ? Le modèle n’en savait rien. C’est en cherchant une solution à ce problème précis que je suis tombé sur le concept de serveur MCP, ou Model Context Protocol. Et ça a complètement changé ma vision de l’intégration IA.

Comprendre les Serveurs MCP

Alors, c’est quoi, un serveur MCP ? Oublions le jargon une minute.

Imaginez que vous engagez un assistant ultra-brillant mais qui a une mémoire de poisson rouge et qui est enfermé dans une pièce sans accès au monde extérieur. C’est un peu ça, un LLM comme Claude.

Pour qu’il soit utile, vous devez lui apporter tous les documents dont il a besoin avant qu’il commence à travailler. C’est le prompt engineering classique. Maintenant, imaginez que vous donniez à cet assistant un téléphone spécial. Avec ce téléphone, il peut vous appeler à tout moment pendant sa tâche et vous demander une information précise : « J’ai besoin du statut de la commande XYZ-123 » ou « Donne-moi le contact de l’ingénieur de garde cette semaine ». Vous, de l’autre côté, vous avez accès à toutes les bases de données et à tous les outils de l’entreprise. Vous trouvez l’info, vous lui donnez une réponse claire et concise, et il l’intègre immédiatement dans son travail.

Ce téléphone, c’est votre serveur MCP.

La première fois que j’ai lu ça, je me suis dit : « Ok, c’est juste une API REST que le modèle peut appeler ». Mais c’est plus subtil que ça. Une API REST est passive ; c’est votre code qui doit décider de l’appeler. Un serveur MCP, lui, répond à une sollicitation initiée par le LLM lui-même au milieu de sa propre génération de texte. C’est comme un webhook, mais à l’envers et synchrone.

Le modèle met sa propre réponse en pause, vous interroge via un protocole défini, attend votre réponse, et l’utilise pour continuer à écrire sa phrase. Mon « eurêka », ça a été de comprendre que le LLM n’est plus un simple exécutant, il devient un orchestrateur qui sait quand il a besoin d’aide.

Les Coulisses Techniques du Protocol MCP

Maintenant qu’on a l’idée générale, mettons un peu les mains dans le cambouis. Comment ça marche, concrètement ? D’après ce que j’ai pu décortiquer en lisant la documentation (notamment celle d’Anthropic qui est assez pointue sur le sujet) et en débuggant mes propres implémentations, l’architecture est assez élégante. Quand vous faites un appel à un modèle compatible, comme Claude, vous lui fournissez dans votre requête initiale une liste des « outils » que votre serveur MCP supporte.

C’est une sorte de manifeste. Pour chaque outil, vous donnez un nom (get_order_status) et une description très claire de ce qu’il fait et des paramètres qu’il attend.

Lorsque le LLM, en générant sa réponse, détermine qu’il a besoin d’une de ces informations, il ne vous renvoie pas du texte. À la place, il envoie une requête HTTP POST spéciale à l’URL de votre serveur MCP que vous avez préalablement déclarée. Ce qui est intéressant, c’est que cette requête contient un payload JSON très structuré, du genre : { "tool_id": "get_order_status", "params": { "order_id": "XYZ-123" } }.

Votre serveur doit alors traiter cette demande, aller chercher l’info dans votre base de données, et renvoyer une réponse JSON tout aussi structurée, par exemple : { "status": "success", "content": "Votre commande a été expédiée le 25/10/2025." }.

J’aurais aimé savoir dès le début à quel point la latence est critique ici. Le LLM attend votre réponse en bloquant sa propre génération. Si votre serveur met 3 secondes à répondre, l’utilisateur final attendra 3 secondes de plus pour voir la suite de la phrase apparaître.

Un des premiers pièges dans lequel je suis tombé, c’est de faire des appels BDD complexes directement dans le handler de la requête MCP. Grosse erreur. Maintenant, dans mon équipe, on a une règle : les serveurs MCP doivent être ultra-rapides, quitte à utiliser massivement du cache (Redis est notre meilleur ami pour ça) ou des vues matérialisées. Pensez-y comme à des microservices optimisés pour une réponse en moins de 100ms.

Créer Votre Premier Serveur MCP

Alors, comment on se lance ? Pour être franc, mon premier essai était un peu chaotique. J’ai voulu faire ça en Python avec Flask et j’ai créé une seule grosse fonction handle_mcp_request avec une chaîne de if/elif/else pour chaque tool_id.

Ça a marché pour deux outils, puis c’est devenu un cauchemar à maintenir. Ne faites pas ça.

La bonne approche, que nous utilisons maintenant, est beaucoup plus modulaire. Que vous choisissiez Python avec FastAPI (mon favori pour sa rapidité et sa validation de données avec Pydantic) ou TypeScript avec Express, la structure est la même.

On a un répertoire tools/ où chaque fichier correspond à un outil. Chaque fichier expose une fonction execute qui prend les paramètres en entrée et retourne le résultat. Ensuite, on a un « registre d’outils » qui, au démarrage du serveur, scanne ce répertoire et charge dynamiquement toutes les fonctions execute dans un dictionnaire. L’endpoint principal du serveur MCP ne fait alors qu’une chose : il récupère le tool_id de la requête, trouve la fonction correspondante dans le registre et l’exécute avec les bons paramètres.

C’est propre, testable, et ça permet à n’importe qui dans l’équipe d’ajouter un nouvel outil sans toucher au cœur du serveur.

Le moment où tout a cliqué pour moi, c’est quand j’ai lancé mon serveur en local avec ngrok pour l’exposer sur internet.

J’ai posé une question à mon chatbot de test : « Où est ma dernière commande ? ».

Dans mon terminal, j’ai vu la requête MCP arriver de la part des serveurs d’Anthropic. Mon code Python s’est exécuté, a interrogé ma base de données locale, a renvoyé le JSON… et quelques millisecondes plus tard, dans le chatbot, Claude a répondu : « Votre dernière commande, la XYZ-789, est actuellement en cours de préparation pour l’expédition. » Voir cette information dynamique, qui n’existait nulle part dans le prompt initial, apparaître comme par magie, c’était un vrai déclic sur le potentiel de cette technologie pour l’automatisation.

Cas d’Usage Réels et Retours d’Expérience

Au-delà de la théorie, où est-ce que ça brille vraiment ? Dans mon équipe, on a déployé des serveurs MCP sur trois projets concrets avec des résultats assez mesurables. Le premier, c’était cet agent de support client.

En lui donnant des outils pour vérifier les statuts de commande, initier des retours ou vérifier la disponibilité d’un produit, on a réduit le temps moyen de traitement des demandes simples de près de 40%. Surtout, on a libéré nos agents humains pour qu’ils se concentrent sur les cas complexes qui nécessitent de l’empathie. C’est une vraie victoire pour l’expérience client et pour le moral de l’équipe de support.

Un autre cas d’usage, c’est un outil interne qu’on a surnommé « DevHelper ». C’est un bot Slack connecté à un LLM. Son serveur MCP a des outils pour interroger notre instance Jira (get_ticket_details), notre Confluence (search_docs) et même notre cluster Kubernetes (get_pod_status).

Un nouveau développeur peut maintenant demander en langage naturel « Quels sont les derniers logs du pod de l’API de paiement en production ? » et obtenir une réponse instantanée sans avoir à connaître kubectl. C’est devenu un outil de développement indispensable.

Mais ce n’est pas une solution miracle. On a aussi essayé de créer un serveur MCP pour un assistant d’écriture créative. L’idée était de lui donner des outils pour aller chercher des synonymes, des rimes ou des informations encyclopédiques à la volée.

Et pour être honnête, ça n’a pas bien marché. Chaque appel MCP introduisait une petite latence qui cassait le rythme de la génération. Le texte produit semblait haché, artificiel. On a appris une leçon importante : le Model Context Protocol est parfait pour des tâches factuelles et des workflows d’automatisation, mais il peut être contre-productif pour des tâches qui exigent un flux créatif ininterrompu. C’est un outil de plus dans notre boîte, pas un marteau pour tous les clous.

Réflexions et Perspectives

Quand je prends un peu de recul, je vois les serveurs MCP non pas comme une simple évolution technique, mais comme un changement de paradigme. On passe d’un modèle où l’on « pousse » de l’information vers le LLM à un modèle où le LLM « tire » l’information dont il a besoin, quand il en a besoin.

C’est une inversion fondamentale du contrôle qui rend les intégrations IA beaucoup plus dynamiques et puissantes. Ce qui me surprend le plus, c’est la rapidité avec laquelle cette approche se standardise.

On voit émerger des spécifications et des bibliothèques qui facilitent la création de ces outils.

Pour mes prochains projets, je réfléchis déjà à comment pousser le concept plus loin.

Par exemple, un serveur MCP pour notre pipeline de CI/CD. Imaginez un agent IA qui, face à un build qui échoue, pourrait utiliser des outils pour lire les logs, inspecter le commit qui a tout cassé, et suggérer une correction directement dans une pull request. Ça semble être de la science-fiction, mais techniquement, toutes les briques sont là. C’est juste une question de créer les bons outils et de les exposer via ce protocole.

Finalement, le développement de ces serveurs nous force à penser nos propres systèmes d’une manière différente : non plus comme des boîtes noires, mais comme des ensembles de capacités atomiques, descriptibles et actionnables par une intelligence artificielle. Et vous, avez-vous déjà expérimenté avec ce genre d’approche ? Je suis curieux de lire vos retours et vos cas d’usage dans les commentaires.