Qu'est-ce qu'un serveur MCP, et votre produit en a-t-il besoin ?

Qu'est-ce qu'un serveur MCP ?

Un serveur MCP est un programme qui permet aux assistants IA d'utiliser un produit : il expose les actions et les données du produit via le Model Context Protocol (MCP), afin qu'un modèle comme Claude ou ChatGPT puisse rechercher des informations et agir au nom de l'utilisateur. Voyez-le comme une API conçue pour des clients IA plutôt que pour des développeurs humains.

Le Model Context Protocol est un standard ouvert qu'Anthropic a introduit en novembre 2024 pour résoudre un problème récurrent : chaque application IA avait besoin de code sur mesure pour se connecter à chaque outil. MCP définit une manière commune pour une application IA (le client, aussi appelé host) de découvrir ce qu'un serveur propose et de l'appeler. Les messages utilisent JSON-RPC 2.0. Dès qu'un produit dispose d'un serveur MCP, tout assistant compatible MCP peut s'y connecter sans intégration spécifique, un peu comme n'importe quel navigateur peut ouvrir n'importe quel site qui parle HTTP.

Qu'expose un serveur MCP ?

Un serveur MCP expose trois types de capacités : les outils, les ressources et les prompts. Les outils sont les plus utilisés ; les ressources et les prompts sont des compléments utiles selon le produit et selon ce que le client prend en charge.

Une bonne description d'outil compte autant que le code qui se trouve derrière. Le modèle choisit l'outil à appeler d'après son nom, sa description et son schéma d'entrée : des descriptions vagues entraînent de mauvais appels. Les résultats des outils doivent être compacts et lisibles : renvoyez les champs dont le modèle a besoin, pas une ligne complète de base de données avec cinquante colonnes.

Le protocole définit aussi des fonctionnalités qui vont dans l'autre sens, du client vers le serveur, comme demander à l'utilisateur une information manquante (elicitation) ou solliciter une complétion du modèle (sampling). Leur prise en charge varie selon les clients, si bien que la plupart des serveurs en production s'appuient d'abord sur les outils.

Comment se connecte un serveur MCP : stdio ou HTTP ?

Les serveurs MCP se connectent via l'un des deux transports standard : stdio pour les serveurs locaux qui tournent sur la machine de l'utilisateur, et HTTP (le transport "Streamable HTTP") pour les serveurs distants hébergés dans le cloud. Un produit SaaS a presque toujours besoin d'un serveur HTTP distant.

Les versions antérieures de la spécification utilisaient un transport distinct HTTP plus Server-Sent Events pour les serveurs distants ; le transport Streamable HTTP l'a remplacé en 2025. Si vous évaluez un serveur ou un SDK plus ancien, vérifiez quel transport il implémente, car les clients récents attendent le transport actuel.

Comment fonctionne l'authentification d'un serveur MCP ?

Les serveurs MCP distants authentifient les utilisateurs via OAuth : l'assistant envoie l'utilisateur vers l'écran de connexion et de consentement de votre produit, reçoit un access token et le présente à chaque requête. Le serveur agit alors avec exactement les permissions de cet utilisateur.

La spécification d'autorisation de MCP s'appuie sur OAuth 2.1 et des standards associés, dont des métadonnées qui indiquent aux clients où se trouve votre serveur d'autorisation. En pratique :

1. L'utilisateur ajoute l'URL de votre serveur dans son assistant.
2. L'assistant découvre votre serveur d'autorisation et lance un flux OAuth.
3. L'utilisateur se connecte à votre produit et approuve l'accès demandé.
4. Chaque appel d'outil porte un token limité à cet utilisateur et à ces permissions.

Deux règles évitent la plupart des problèmes de sécurité. D'abord, le serveur doit vérifier que les tokens ont bien été émis pour lui, et ne doit pas transmettre le token d'un client à d'autres services. Ensuite, les permissions doivent être appliquées côté serveur à chaque appel, comme le fait votre application web. Pour les outils internes et les premiers prototypes, une clé d'API par utilisateur est un raccourci courant, mais un SaaS destiné aux clients doit utiliser un véritable OAuth.

Quand un produit SaaS doit-il livrer un serveur MCP ?

Un produit SaaS doit livrer un serveur MCP lorsque ses clients utilisent déjà des assistants IA au travail et gagneraient à leur demander de lire ou de modifier des données dans le produit. Si vos utilisateurs copient régulièrement des données de votre application vers ChatGPT ou Claude, ou réclament "une intégration avec l'IA", c'est le signal.

De bonnes raisons d'en construire un :

• Votre produit contient des données de travail que les gens veulent résumer, rechercher ou mettre à jour : tâches, tickets, fiches CRM, documents, commandes, analytics.
• Les actions sont répétitives : création d'enregistrements, changements de statut, saisie de temps, rédaction de réponses.
• Vos clients demandent des fonctions IA et vous voulez y répondre sans construire un assistant complet dans votre produit.
• La distribution : les assistants IA listent et recommandent de plus en plus de connecteurs ; y être présent place votre produit là où les utilisateurs travaillent déjà.

Des raisons d'attendre : le produit n'a pas encore d'API stable, les données sont très sensibles et votre modèle de permissions manque de finesse, ou le parcours principal est visuel et ne se traduit pas en actions qu'un modèle peut exécuter. Dans ces cas, corrigez d'abord l'API et les permissions, ou commencez par des outils en lecture seule.

Un serveur MCP ne remplace pas les fonctions IA intégrées au produit. Il les complète : les fonctions intégrées servent les utilisateurs dans votre interface, tandis que MCP sert ceux qui vivent dans leur assistant. Si vous hésitez entre les deux, notre guide pour intégrer ChatGPT et Claude dans votre produit couvre le versant intégré au produit.

Quels sont les risques de sécurité des serveurs MCP ?

Les principaux risques sont l'injection de prompt, des permissions trop larges, des actions destructrices sans confirmation et des fuites de données entre utilisateurs. Un serveur MCP donne à un modèle la capacité d'agir : c'est donc le serveur, et non le modèle, qui doit appliquer les limites.

• Injection de prompt : un texte présent dans un document, un e-mail ou une page web peut ordonner au modèle d'appeler des outils que l'utilisateur n'a jamais voulu appeler. Partez du principe que les entrées des outils peuvent être manipulées et validez-les comme toute entrée non fiable.
• Empoisonnement des descriptions d'outils : les clients ne doivent se connecter qu'à des serveurs de confiance, car des descriptions malveillantes peuvent orienter un modèle. En tant qu'éditeur, gardez des descriptions factuelles et stables.
• Scopes trop larges : donnez aux tokens le minimum de permissions nécessaires. Proposez des scopes en lecture seule aux clients qui veulent seulement rechercher et résumer.
• Actions destructrices : évitez ou signalez clairement les suppressions et les opérations en masse ; préférez les suppressions logiques et les brouillons. Beaucoup de clients demandent à l'utilisateur d'approuver les appels d'outils, mais ne comptez pas uniquement là-dessus.
• Fuites entre clients (tenants) : chaque requête doit être limitée à l'utilisateur et à l'organisation authentifiés, avec des tests qui le prouvent.
• Limites de débit et coûts : un modèle pris dans une boucle peut appeler un outil des centaines de fois. Appliquez des limites de débit par utilisateur.
• Journaux d'audit : enregistrez l'utilisateur, le client et l'outil, avec les entrées et les résultats, afin que les clients puissent voir ce que leur assistant a fait.

Comment développe-t-on un serveur MCP ?

Un serveur MCP se développe généralement avec l'un des SDK officiels (disponibles en TypeScript, Python et plusieurs autres langages), sous forme de fine couche au-dessus d'une API ou d'une couche de services existante. Le travail porte moins sur le protocole que sur le choix des bons outils et l'application des permissions.

Un projet type se déroule en plusieurs étapes :

1. Choisir les tâches : listez les 5 à 20 tâches que les utilisateurs demanderaient à un assistant d'accomplir dans votre produit. Quelques outils bien décrits valent mieux qu'un outil par endpoint.
2. Concevoir les outils : noms clairs, descriptions rédigées pour un modèle, schémas d'entrée typés, sorties compactes et messages d'erreur utiles dont le modèle peut se servir pour se corriger.
3. Autorisation : OAuth pour les serveurs distants, permissions au niveau de l'utilisateur à chaque appel, scopes en lecture seule et en écriture.
4. Sécurité par défaut : brouillons plutôt que publication immédiate, confirmations pour les actions irréversibles, limites sur les opérations en masse.
5. Tests avec de vrais clients : connectez Claude, ChatGPT et un outil de développement, lancez des requêtes réalistes et vérifiez que le modèle choisit les bons outils avec les bons arguments.
6. Observabilité : journalisation, métriques par outil et alertes sur les pics d'erreurs.

Pour un produit doté d'une API propre, un premier serveur distant prend généralement 2 à 6 semaines. Si votre produit a besoin de fonctions IA au-delà de MCP, comme des agents qui exécutent des workflows de façon autonome, consultez notre guide du coût de développement d'un agent IA.

Comment développons-nous des serveurs MCP chez Lytvynov Production ?

Nous développons d'abord des serveurs MCP pour nos propres produits. Notre tableau de projets interne et le CMS de notre site disposent tous deux d'un serveur MCP : notre équipe et nos agents de code IA créent et mettent à jour des tâches, saisissent du temps et modifient le contenu du site depuis Claude et d'autres assistants chaque jour. Cet usage quotidien nous a appris où ces serveurs cassent : descriptions d'outils vagues, validation des champs manquante, outils d'écriture qui publient immédiatement alors qu'un brouillon serait plus sûr, et écarts entre le code du serveur et ce qui est réellement déployé.

Pour nos clients, nous appliquons la même approche aux produits SaaS et aux systèmes internes. Nous avons construit des systèmes de tâches et de tickets, comme une plateforme de gestion des tâches sur mesure pour une équipe de support télécom, ainsi que des fonctions LLM dans notre propre SaaS, AI Resume Master. Notre stack back end est PHP/Symfony avec des front ends React, et nous développons les serveurs MCP dans le langage adapté à votre produit, au-dessus de votre API et de votre modèle de permissions existants.

Prochaine étape

Si vous envisagez un serveur MCP pour votre produit, nous commençons par un court appel de cadrage : nous examinons votre API et vos permissions, choisissons le premier ensemble d'outils, puis vous remettons un devis forfaitaire. Consultez notre service d'intégration IA et notre service de développement d'agents IA, ou contactez-nous pour parler de votre produit.