Qu'est-ce qu'un serveur MCP ?

Un programme qui expose un logiciel ou une source de données sous forme d'actions nommées, utilisables par n'importe quel outil IA compatible avec le protocole Model Context Protocol. Le modèle n'accède ni aux tables, ni aux écrans, ni aux identifiants : il appelle une action décrite à l'avance, et le serveur l'exécute en appliquant vos règles.

À quoi sert un serveur MCP dans une entreprise ?

À exposer un logiciel métier une seule fois au lieu de le réintégrer dans chaque outil IA. Sans lui, trois outils et quatre logiciels demandent douze intégrations à écrire et à maintenir ; avec lui, quatre serveurs suffisent et chaque nouvel outil se branche sans développement supplémentaire. Il protège aussi vos agents d'un changement de logiciel : seul le serveur est réécrit lors d'une migration.

Qui développe des serveurs MCP sur mesure en France ?

Le sujet est encore peu couvert en français et le marché se partage entre développeurs indépendants spécialisés en intégration IA et quelques studios techniques. Le critère de sélection utile est l'expérience de l'intégration de logiciels métier, pas la connaissance du protocole en lui-même : celui-ci s'apprend en une journée, la difficulté est ailleurs. J'en développe et j'en ai livré.

Combien coûte le développement d'un serveur MCP ?

De 3 à 6 jours pour un périmètre simple sur un logiciel qui expose déjà une API. De 8 à 15 jours quand il faut gérer des règles métier, des droits par utilisateur et des actions qui modifient des données. Multipliez par le TJM de votre prestataire. Ce n'est pas un projet autonome, c'est une couche à l'intérieur d'un projet d'automatisation.

Faut-il un serveur MCP pour connecter un agent IA à un logiciel ?

Non, une intégration directe suffit pour un agent unique sur un besoin figé. Le serveur MCP devient rentable à partir de deux outils IA et deux logiciels, ou quand vous prévoyez d'ajouter d'autres agents ensuite, ou quand le logiciel sous-jacent doit être remplacé à moyen terme.

Comment sécuriser un serveur MCP en entreprise ?

Quatre règles posées avant la première action : séparer lecture et écriture en commençant par un serveur en lecture seule, appliquer les droits de l'utilisateur pour le compte duquel l'agent agit plutôt que ceux du serveur, journaliser chaque appel avec son auteur et ses paramètres, et exiger une validation humaine sur les actions irréversibles.

Peut-on connecter un serveur MCP à un logiciel qui n'a pas d'API ?

Oui. Le serveur se construit au-dessus de la voie d'accès disponible, qu'il s'agisse d'une lecture directe en base de données, d'un import-export de fichiers ou d'une automatisation d'interface. C'est même l'un de ses intérêts : la voie d'accès reste un détail d'implémentation, invisible pour les agents qui l'utilisent.

Quelle différence entre un serveur MCP et une API classique ?

Une API est conçue pour des développeurs qui lisent une documentation. Un serveur MCP est conçu pour un modèle : chaque action porte une description en langage naturel de ce qu'elle fait et de quand l'utiliser, et le jeu d'actions est volontairement restreint aux intentions métier utiles. Un serveur MCP s'appuie souvent sur une API existante, en la traduisant.

Serveur MCP sur mesure : à quoi ça sert dans une entreprise

En résumé. Un serveur MCP expose votre logiciel métier sous forme d’actions nommées, que n’importe quel outil IA compatible peut ensuite utiliser. L’intérêt est arithmétique : sans lui, brancher 4 logiciels sur 3 outils IA demande 12 intégrations ; avec lui, 4 serveurs et zéro intégration supplémentaire à chaque nouvel outil. Comptez 3 à 6 jours de construction pour un périmètre simple sur un logiciel qui a une API, 8 à 15 jours avec des règles métier et une gestion fine des droits. C’est une couche d’infrastructure, pas un projet à elle seule.

Ce que c’est, concrètement

Prenez votre ERP. Il sait faire une centaine de choses, mais un agent IA n’a besoin que de six d’entre elles : consulter le stock d’une référence, vérifier l’encours d’un client, créer une commande, retrouver une facture, lister les commandes en retard, éditer un bon de livraison.

Un serveur MCP est le programme qui expose ces six actions, avec pour chacune un nom, une description, les paramètres attendus et les règles à respecter. Le modèle n’a jamais accès aux tables, aux écrans ou aux identifiants ; il demande « stock de la référence TUB-INX-040 », le serveur exécute et renvoie la réponse.

Le protocole qui décrit ce dialogue s’appelle Model Context Protocol. Il est ouvert, et l’essentiel des outils IA sérieux savent s’y connecter aujourd’hui.

L’intérêt réel : construire une fois

Voici le calcul qui décide, et il n’a rien à voir avec la technique.

Sans MCP, chaque outil IA doit être intégré à chaque logiciel séparément. Trois outils, quatre logiciels : douze intégrations à écrire et à maintenir. Le jour où vous ajoutez un quatrième outil, quatre intégrations de plus.

Avec MCP, vous écrivez quatre serveurs, un par logiciel. Chaque nouvel outil IA se branche dessus sans une ligne de code supplémentaire.

	Intégrations à écrire	Ajouter un outil IA
Sans MCP	outils × logiciels	autant que de logiciels
Avec MCP	un serveur par logiciel	rien

L’écart devient réel à partir de deux outils et deux logiciels. En dessous, la couche ne se rentabilise pas et une intégration directe suffit.

Ce qu’un serveur peut exposer

Trois choses, et la distinction compte au moment de la conception.

Des actions. Ce que le modèle peut faire : lire une donnée, créer un enregistrement, lancer un traitement. Chacune est décrite avec ses paramètres et leurs contraintes. Une action bien nommée et bien décrite est utilisée correctement ; une action vague est utilisée n’importe comment.

Des ressources. Des données que le modèle peut consulter sans les demander explicitement : la grille tarifaire du jour, la liste des dépôts, le référentiel articles.

Des modèles d’instruction. Des façons préparées de formuler une demande courante, réutilisables par tous les utilisateurs.

La plupart des serveurs d’entreprise n’exposent que des actions, et c’est très bien ainsi. Commencez par cinq ou six, ajoutez ensuite selon l’usage réel.

Trois usages qui reviennent

Ouvrir un logiciel métier à plusieurs agents. Le cas le plus fréquent. Votre ERP est interrogé par l’agent de traitement des commandes, par l’assistant du service client et par un tableau de bord. Trois usages, une seule porte d’entrée à écrire et à sécuriser.

Donner à vos équipes un accès conversationnel à un logiciel qu’elles utilisent mal. Beaucoup d’ERP contiennent des informations que personne ne va chercher, parce que le parcours à l’écran est pénible. Exposer dix actions en lecture change l’usage sans toucher au logiciel.

Préparer une migration. Si le logiciel doit être remplacé dans deux ans, les agents construits au-dessus du serveur MCP survivent au changement : seul le serveur est réécrit, les agents ne bougent pas. C’est l’argument le plus solide et le moins avancé lors des projets.

Les trois cas où c’est une couche en trop

Le serveur MCP n’est pas toujours la bonne réponse, et un prestataire qui le propose systématiquement vend son savoir-faire plutôt que votre besoin.

Un seul agent et un seul logiciel, sur un besoin figé. L’intégration directe est plus courte à écrire et plus simple à déboguer.

Un logiciel qui expose déjà une API propre, moderne et documentée, utilisée par un seul outil. Le serveur MCP n’ajouterait qu’une traduction.

Un besoin exploratoire dont le périmètre n’est pas stabilisé. Concevoir les bonnes actions demande de savoir ce que les agents feront ; construire cette couche trop tôt fige de mauvaises décisions.

Comment ça se construit

Quatre étapes, dont une seule est technique.

Choisir les actions. Étape la plus importante et la plus rapide à bâcler. Une action doit correspondre à une intention métier complète, pas à une opération technique. « Créer une commande avec ses lignes et vérifier l’encours » vaut mieux que trois actions séparées que le modèle devra enchaîner correctement.

Décrire précisément. La description de chaque action est ce qui détermine si le modèle l’utilise au bon moment. Écrire quand l’appeler, pas seulement ce qu’elle fait, change nettement le comportement.

Implémenter au-dessus de la voie d’accès existante, qu’il s’agisse d’une API, d’une base en lecture ou d’un import de fichiers.

Poser les limites. Quelles actions sont en lecture seule, lesquelles demandent une validation humaine, ce qui est journalisé.

Comptez 3 à 6 jours pour un périmètre simple sur un logiciel doté d’une API, 8 à 15 jours quand il faut gérer des règles métier, des droits par utilisateur et des actions qui écrivent.

Sécurité : ce qu’il faut poser d’emblée

Un serveur MCP est une porte d’entrée sur votre système d’information. Quatre décisions à prendre avant d’écrire la première action.

Séparer lecture et écriture. Commencez par un serveur en lecture seule, ajoutez les actions d’écriture ensuite, une par une.

Appliquer les droits de l’utilisateur, pas ceux du serveur. Si l’agent agit pour le compte d’un commercial, il ne doit pas voir plus que ce commercial.

Journaliser chaque appel avec son auteur, ses paramètres et son résultat. C’est ce qui vous permettra de comprendre un incident, et c’est trivial à faire au moment de la construction.

Poser une validation humaine sur les actions irréversibles. Envoyer un mail à un client, valider un paiement, supprimer un enregistrement. Ces quatre décisions se prennent avant la première ligne de code et s’écrivent sur le devis, comme le reste de ce qu’un agent a le droit de faire dans une mission d’automatisation.

Les durées de construction sont des ordres de grandeur pour un périmètre de cinq à dix actions, hors reprise de données et hors règles métier exceptionnelles.