Ce que comprend le développement de serveur MCP
Le développement de serveur MCP consiste à rendre votre produit utilisable par un assistant IA : un serveur qui parle le Model Context Protocol et expose les actions de votre produit (outils), ses données consultables (ressources) et des modèles (prompts). Une fois le serveur en ligne, un utilisateur peut connecter votre produit à Claude, à ChatGPT ou à un outil de développement et demander, en langage courant, de retrouver une fiche, de résumer l'activité récente ou de créer un brouillon : l'assistant le fait via votre serveur, avec les permissions de cet utilisateur.
Notre prestation de développement de serveur MCP couvre l'ensemble du travail, pas seulement la couche protocole :
- Conception des outils. Choisir les 5 à 20 tâches que les utilisateurs veulent réellement confier, puis rédiger des noms, des descriptions et des schémas d'entrée que les modèles comprennent.
- Intégration avec votre API. Une fine couche au-dessus de vos endpoints existants ou de votre couche de services, pour ne pas dupliquer les règles métier et les permissions.
- Authentification. OAuth pour les serveurs ouverts à vos clients, tokens à portée limitée, scopes en lecture seule et en écriture.
- Sécurité par défaut. Des brouillons plutôt qu'une publication immédiate, des confirmations pour les actions irréversibles, des limites sur les opérations en masse, la validation des entrées.
- Tests avec de vrais clients. Des requêtes réalistes passées dans plusieurs assistants pour vérifier que les bons outils sont appelés avec les bons arguments.
- Déploiement et observabilité. Déploiement Docker, métriques par outil, journaux d'audit et alertes en cas de pic d'erreurs.
Si vous voulez d'abord comprendre les notions de base, notre guide qu'est-ce qu'un serveur MCP explique les outils, les transports et l'authentification en termes simples. Cette page porte sur le recours à une équipe pour en développer un.
Qui a besoin d'un serveur MCP sur mesure ?
Un serveur MCP sur mesure est pertinent lorsque vos utilisateurs travaillent déjà dans des assistants IA et y copient sans cesse des données issues de votre produit, ou lorsque vos clients demandent "une intégration IA" et que vous voulez leur répondre sans construire un assistant complet dans votre interface.
Les situations que nous rencontrons le plus souvent :
- Les produits SaaS qui contiennent des données de travail : tâches, tickets, fiches CRM, documents, commandes, analytics. Les utilisateurs veulent interroger leur assistant sur ces données et les mettre à jour sans changer d'onglet.
- Les systèmes internes comme un ERP, un CRM ou un back-office, où le personnel et les agents IA internes ont besoin d'un accès contrôlé aux mêmes actions que celles réalisées à la main.
- Les produits qui développent leurs propres agents. Un serveur MCP est une façon propre et réutilisable de donner des outils à vos agents, et le même serveur peut ensuite être ouvert à vos clients.
- Les équipes qui utilisent des agents de codage IA et qui ont besoin d'un accès contrôlé aux services internes, aux données de test ou aux outils de déploiement.
Quand il est trop tôt : le produit n'a pas encore d'API stable, les permissions sont trop grossières, ou le parcours principal est visuel et ne se traduit pas en actions. Dans ces cas, nous commençons généralement par la couche API ou par des outils en lecture seule.
Comment nous développons des serveurs MCP en production
Nous développons et exploitons des serveurs MCP en production pour nos propres systèmes, et notre équipe comme nos agents de codage IA les utilisent tous les jours. C'est de cet usage quotidien que viennent nos règles de conception : des descriptions d'outils floues obligent les modèles à deviner, l'absence de validation laisse entrer de mauvaises données, et les outils d'écriture qui publient immédiatement auraient dû créer des brouillons.
Pour un projet client, le développement suit ces étapes.
| Étape | Ce que nous faisons | Ce que vous obtenez |
|---|---|---|
| 1. Cadrage | Revue de votre API, de votre modèle de données et de vos permissions ; liste des tâches que les utilisateurs confieraient à un assistant | Une liste d'outils priorisée et un devis forfaitaire |
| 2. Conception des outils | Noms, descriptions, schémas typés, sorties compactes, messages d'erreur exploitables | Une spécification des outils que votre équipe peut relire |
| 3. Serveur et authentification | Serveur distant en Streamable HTTP, OAuth, contrôle des permissions de l'utilisateur à chaque appel | Un serveur fonctionnel en environnement de préproduction |
| 4. Sécurité et limites | Brouillons, confirmations, limites de débit, tests d'isolation entre clients, contrôles d'injection de prompt | Une note de sécurité pour votre revue |
| 5. Tests clients | Requêtes réalistes via Claude, ChatGPT et un outil de développement | Un rapport de tests avec les résultats de sélection des outils |
| 6. Lancement | Déploiement, journalisation, métriques, documentation pour vos clients | Un serveur en production et un runbook |
Nous utilisons les SDK officiels et écrivons le serveur dans le langage qui convient à votre produit. Notre stack back-end principale est PHP et Symfony, et nous développons aussi en TypeScript et en Python lorsque c'est plus adapté à votre API ou à votre hébergement.
Serveur MCP local ou distant ?
Un serveur MCP distant, qui tourne dans le cloud en HTTP, est le bon choix pour presque tous les produits SaaS : vos clients le connectent depuis des assistants web et desktop sans rien installer, et vous gardez la main sur l'authentification, les mises à jour et les journaux en un seul endroit. Un serveur local, qui tourne sur la machine de l'utilisateur via stdio, convient aux outils de développement qui ont besoin des fichiers ou de la ligne de commande.
Certains produits ont besoin des deux. Un schéma fréquent associe un serveur distant pour les clients et un petit serveur local pour les agents de codage de votre propre équipe d'ingénierie. Nous tranchons pendant le cadrage, en fonction des utilisateurs et de l'endroit où se trouvent les données.
Sécurité : ce que le serveur doit imposer
Un serveur MCP donne à un modèle la capacité d'agir, c'est donc le serveur qui doit porter les limites. Nous construisons chaque serveur autour de ces règles :
- Des permissions au niveau de l'utilisateur à chaque appel. L'assistant agit en tant qu'utilisateur connecté, jamais avec une clé admin partagée.
- Le moindre privilège. Des scopes en lecture seule pour les clients qui veulent seulement rechercher et résumer ; des scopes en écriture uniquement là où c'est nécessaire.
- Des entrées non fiables. Le texte issu d'e-mails, de documents et de pages web peut contenir une injection de prompt : les entrées des outils sont donc validées comme toute entrée externe.
- Des écritures sûres. Brouillons, suppressions réversibles et confirmations pour les actions irréversibles ; opérations en masse plafonnées.
- Des tests d'isolation entre clients. Des tests automatisés prouvent qu'une organisation ne peut pas accéder aux données d'une autre.
- Des limites de débit et des journaux d'audit. Un modèle pris dans une boucle peut appeler un outil des centaines de fois. Des limites par utilisateur l'en empêchent, et les journaux montrent à vos clients exactement ce que leur assistant a fait.
La même rigueur protège les produits que nous exploitons nous-mêmes. Dans le projet AI Grief Companion, par exemple, chaque message est chiffré dès l'ingestion en AES-256-GCM, message par message, sous une clé d'enveloppe KMS, car les données sont profondément personnelles.
Serveur MCP, agent IA ou fonctionnalité IA dans le produit ?
Ces trois options répondent à des problèmes différents, et beaucoup de produits finissent par en combiner plusieurs.
| Option | Qui l'utilise | Idéal lorsque |
|---|---|---|
| Serveur MCP | Vos utilisateurs, dans l'assistant qu'ils utilisent déjà | Les utilisateurs veulent accéder à votre produit depuis Claude, ChatGPT ou leurs outils |
| Fonctionnalité IA dans le produit | Vos utilisateurs, dans votre interface | La capacité IA fait partie de l'expérience de votre produit |
| Agent IA | Votre équipe ou votre système, qui exécute un processus | Une tâche en plusieurs étapes doit tourner avec peu d'intervention humaine |
Un serveur MCP est souvent la première étape la moins chère, car il réutilise votre API et laisse les utilisateurs venir avec leur propre assistant. Si vous avez besoin du modèle dans votre propre interface, consultez notre offre d'intégration IA. Si vous avez besoin d'un logiciel qui exécute tout un processus, consultez notre page développement d'agents IA ; nos agents accèdent d'ailleurs généralement à vos systèmes via des serveurs MCP.
Combien de temps prend le développement d'un serveur MCP, et combien coûte-t-il ?
Pour un produit doté d'une API propre, un premier serveur MCP distant avec un ensemble d'outils ciblé, OAuth et journalisation prend généralement de 2 à 6 semaines. L'essentiel de ce temps va au choix des outils, à la rédaction de descriptions que les modèles comprennent, aux autorisations et aux tests avec de vrais assistants, pas au protocole lui-même.
Les principaux facteurs de coût sont le nombre d'outils, l'état de votre API, la complexité de votre modèle de permissions, l'obligation ou non de faire tourner le serveur sur votre infrastructure, et le nombre de clients IA que vous voulez prendre en charge et tester.
Un premier serveur ciblé tient généralement dans un AI Sprint : 10 000 USD pour 4 semaines, prix fixe, avec le code source dans votre dépôt. Les serveurs plus importants, ou ceux qui exigent d'abord la construction d'une couche API, sont chiffrés après un court appel de cadrage. Notre taille minimale de projet est de 10 000 USD.
Pourquoi les équipes nous confient leurs serveurs MCP
- Nous exploitons les nôtres. Nous développons et exploitons des serveurs MCP en production pour nos propres systèmes, nous avons donc déjà rencontré les défaillances qui n'apparaissent qu'après des semaines d'usage réel.
- Nous développons aussi les clients. Nous intégrons l'API Claude et l'API OpenAI dans des produits et construisons des agents par-dessus : nous concevons donc les outils du point de vue du modèle autant que de celui de l'API.
- Nous livrons de l'IA à de vrais utilisateurs. Notre propre AI Resume Master, un SaaS IA construit sur l'API OpenAI, a été développé en trois mois environ et a atteint 50 000 utilisateurs actifs mensuels.
- Des ingénieurs seniors avec des agents de codage IA. Les ingénieurs seniors sont responsables de l'architecture, de la sécurité et des revues ; les agents de codage IA accélèrent le travail répétitif sous leur supervision.
Lytvynov Production a été fondée en 2020 à Dnipro, en Ukraine, et affiche une note de 5,0 sur Upwork avec 100 % de Job Success.
Prochaine étape
Envoyez-nous un lien vers la documentation de votre API et quelques exemples de ce que vos utilisateurs demanderaient à un assistant. En 30 minutes d'appel, nous vous proposerons un premier ensemble d'outils, signalerons les questions de permissions et de sécurité, et vous dirons si cela tient dans un seul sprint. Contactez-nous pour réserver l'appel.