Un agent IA devient utile quand il peut lire les bonnes données et accomplir les bonnes actions dans les systèmes de l'entreprise. Le Model Context Protocol (MCP) est le standard ouvert qui définit comment un agent découvre et utilise des outils et des ressources. shardana.ai développe des serveurs MCP sur mesure qui n'exposent aux clients compatibles que ce qui doit l'être, avec autorisations, validations et journaux.
Le serveur MCP est souvent la partie la moins visible d'un projet d'IA, mais c'est elle qui décide du degré de fiabilité et de sécurité de l'agent.
Qu'est-ce qu'un serveur MCP ?
Un serveur MCP est un composant logiciel qui expose à un agent IA des outils et des ressources selon le Model Context Protocol. Les outils, appelés tools, sont des actions que l'agent peut demander, comme chercher une commande ou créer un ticket. Les ressources sont des contenus qu'il peut lire, comme des documents ou des fiches clients. Le protocole décrit de façon uniforme ce qui existe, quels paramètres sont nécessaires et ce qui est renvoyé, de sorte que le même serveur peut être utilisé par des clients différents sans intégrations répétées. Le serveur reste sous votre contrôle : il décide quels outils publier, qui peut les appeler et comment enregistrer l'usage. En pratique, c'est la couche frontière entre le modèle de langage et les systèmes réels, et c'est pourquoi sa conception compte autant que celle de l'agent. Un serveur bien fait est petit, documenté, testable et conçu pour arrêter l'agent quand il le faut.
Quand faut-il un serveur MCP et quand une API suffit-elle ?
Un serveur MCP est nécessaire quand un agent IA doit travailler avec des systèmes réels et que vous voulez un point unique où définir autorisations, validations et journaux, réutilisable par plusieurs agents et clients. Si vous avez un seul assistant et une seule intégration, un appel direct aux API du système peut suffire et coûte moins cher. MCP est pertinent quand les outils sont nombreux, quand les agents peuvent changer avec le temps ou quand vous voulez que ce soit celui qui gouverne le système, et non celui qui écrit le prompt, qui décide de ce que l'agent peut faire. Par rapport à un plugin lié à un seul produit, un serveur MCP n'enferme pas chez un fournisseur. Par rapport à une API brute, il ajoute des descriptions lisibles par le modèle et une surface volontairement restreinte. Le tableau résume les différences, et lors du premier échange nous vérifions quelle voie a du sens pour votre cas.
| Critère | API directe | Plugin de produit | Serveur MCP |
|---|---|---|---|
| Qui l'utilise | Votre code | Un seul assistant ou produit | Tout client compatible MCP |
| Description pour le modèle | À écrire dans le prompt | Définie par le fournisseur | Incluse dans le serveur, pour chaque outil |
| Autorisations et journaux | À construire au cas par cas | Dépendent du fournisseur | Centralisés dans le serveur |
| Réutilisation avec plusieurs agents | Faible | Nulle | Élevée |
| Quand il convient | Une intégration, un agent | Produit déjà adopté | Plusieurs outils, plusieurs agents, gouvernance |
Comment fonctionne un serveur MCP entre l'agent et les systèmes de l'entreprise ?
Le serveur MCP se place entre l'agent et les systèmes de l'entreprise et traduit les demandes du modèle en opérations contrôlées. Quand l'agent se connecte, le serveur lui présente la liste des outils disponibles, avec nom, description et paramètres. Si l'agent décide d'en utiliser un, il envoie la demande au serveur, qui vérifie l'identité et les autorisations, contrôle que les paramètres respectent le schéma, exécute l'opération sur le système cible et renvoie le résultat. Chaque étape peut être enregistrée. L'agent ne connaît ni les identifiants, ni les adresses internes, ni les structures de bases de données : il ne voit que ce que le serveur décide d'exposer. C'est pourquoi il vaut mieux concevoir des outils petits et à la tâche précise, plutôt qu'un outil unique qui fait tout. Si un outil est erroné ou trop large, on le corrige dans le serveur sans toucher à l'agent, et le schéma montre où se place cette couche.
À quoi ressemble concrètement un outil MCP ?
Un outil MCP est une fonction dotée d'un nom, d'une description et d'un schéma d'entrées, que le serveur exécute après avoir vérifié les autorisations. L'exemple montre un serveur TypeScript avec un seul outil en lecture seule qui renvoie le statut d'une commande. Le paramètre est validé avant de toucher le système de gestion : un numéro de commande au mauvais format n'atteint jamais le système. L'outil contrôle le scope de l'utilisateur, interroge le système de gestion et écrit un enregistrement d'audit avec l'outil appelé, le paramètre et le client. Si les autorisations manquent, il répond par une erreur claire au lieu d'essayer. C'est du code illustratif, pas le projet d'un client, mais il reflète la façon dont nous configurons chaque outil : entrées strictes, actions minimales, résultat prévisible et trace de ce qui s'est passé. Les actions en écriture suivent le même schéma et, quand c'est utile, ajoutent une étape de validation humaine.
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";
const server = new McpServer({ name: "gestion-commandes", version: "1.0.0" });
// Exemple illustratif : un seul outil, en lecture seule, avec une entrée validée.
server.tool(
"statut_commande",
"Renvoie le statut et la date de livraison prévue d'une commande",
{ numeroCommande: z.string().regex(/^CMD-\d{6}$/) },
async ({ numeroCommande }, { authInfo }) => {
if (!authInfo?.scopes.includes("commandes:read")) {
return { isError: true, content: [{ type: "text", text: "Autorisation refusée" }] };
}
const commande = await gestion.trouverCommande(numeroCommande);
audit.log({ tool: "statut_commande", numeroCommande, utilisateur: authInfo.clientId });
return { content: [{ type: "text", text: JSON.stringify(commande) }] };
},
);Exemple illustratif d'un serveur MCP avec un outil en lecture seule, autorisations et audit.
Comment sécurisons-nous un serveur MCP ?
La sécurité d'un serveur MCP se construit sur quelques principes appliqués avec rigueur. Le premier est le moindre privilège : chaque outil reçoit uniquement les autorisations nécessaires, et les outils en lecture sont séparés de ceux en écriture. Le deuxième est la validation : chaque paramètre est contrôlé en type, en format et en plage avant d'atteindre un système. Le troisième est l'identité : les appels sont associés à un utilisateur ou à un client, avec des identifiants gérés par le serveur et jamais exposés au modèle. Viennent ensuite les limites de fréquence, le suivi de chaque requête et les seuils au-delà desquels une action exige la validation d'une personne, par exemple paiements, suppressions ou envois aux clients. Il faut aussi tenir compte du fait que le contenu lu par l'agent peut contenir des instructions hostiles : c'est pourquoi données et actions restent séparées et les actions sensibles ne dépendent jamais du seul texte reçu. Aucune mesure ne suffit à elle seule, nous les appliquons donc ensemble.
Combien coûte un serveur MCP et combien de temps faut-il ?
Le coût et la durée dépendent du nombre de systèmes que vous voulez connecter et des actions que l'agent doit pouvoir accomplir. Un serveur avec quelques outils en lecture seule sur une API déjà documentée demande bien moins de travail qu'un serveur qui écrit dans un système de gestion sans API, avec validations et exigences de confidentialité. Pèsent aussi la qualité de la documentation des systèmes, le modèle d'authentification et le nombre de clients à prendre en charge. Après le développement subsistent des coûts récurrents modérés, comme l'hébergement, la supervision et la mise à jour des outils quand les systèmes connectés changent. C'est pourquoi nous ne publions pas de grille unique : après le premier échange, vous recevez une proposition écrite avec phases, livrables et coûts. Commencer par un premier serveur avec deux ou trois outils est souvent le moyen le plus rapide de mesurer la valeur avant d'étendre le périmètre. Les durées du tableau sont indicatives et confirmées après l'analyse.
| Phase | Ce qui se passe | Durée indicative |
|---|---|---|
| Premier échange | Systèmes, données et actions que l'agent doit pouvoir utiliser | Une rencontre |
| Analyse et périmètre | Liste des outils, autorisations, risques, critères de réussite | Environ une semaine |
| Premier serveur | Deux ou trois outils sur un cas réel, avec tests et journaux | 1 à 3 semaines |
| Extension et intégration | Plus d'outils, authentification, validations, documentation | 2 à 4 semaines |
| Mise en production et maintenance | Production, supervision, mise à jour des outils | Continu |
Avec quelle expérience développons-nous des serveurs MCP ?
Le fondateur, Maurizio Brioschi, a plus de 25 ans d'expérience en ingénierie logicielle, en développement backend et en architecture de systèmes. Dans le travail sur les serveurs MCP, cette base compte, car un serveur est avant tout une API bien conçue : contrats clairs, authentification, gestion des erreurs, tests et observabilité. La stack de référence comprend PHP, Laravel, MySQL, Node.js et TypeScript, avec des intégrations fondées sur les API. Côté IA, le studio travaille sur les modèles de langage, le RAG, les workflows agentiques et les serveurs MCP. Nous ne publions pas de cas clients que nous ne pouvons pas documenter : lors du premier échange, nous entrons dans le détail des choix techniques pour vos systèmes, en partant des API disponibles, des points où des autorisations plus strictes sont nécessaires et des actions qu'il vaut mieux laisser à la validation d'une personne, et quand un projet aura l'accord du client, nous le raconterons avec des délais, une stack et des métriques vérifiables.
Questions fréquentes
- Qu'est-ce qu'un serveur MCP ?
- C'est un composant qui expose des outils et des ressources à des clients ou à des agents IA compatibles avec le Model Context Protocol, en leur permettant de lire du contexte ou d'accomplir des actions contrôlées.
- Quand est-il pertinent de développer un serveur MCP ?
- Quand un agent IA doit travailler avec des systèmes réels, des API, des données ou des procédures d'entreprise et qu'il faut une couche ordonnée d'autorisations, de journaux et de maintenance, réutilisable par plusieurs agents.
- Un serveur MCP fonctionne-t-il uniquement avec un modèle précis ?
- Non. MCP est un protocole ouvert : le même serveur peut être utilisé par n'importe quel client compatible, quel que soit le modèle de langage qui se trouve derrière.
- L'agent peut-il modifier les données de mes systèmes ?
- Seulement si le serveur expose des outils d'écriture. Les actions sont limitées par rôle et, quand elles touchent à des données sensibles, peuvent exiger la validation d'une personne.
- Est-ce aussi utile pour des entreprises non techniques ?
- Oui, si l'entreprise utilise des logiciels et des données qui doivent être reliés à un assistant IA. La complexité reste dans le serveur, tandis que l'expérience de ceux qui l'utilisent peut rester simple.
- Combien coûte un serveur MCP ?
- Cela dépend des systèmes à connecter, des actions autorisées et des exigences de sécurité. Après le premier échange, vous recevez une proposition écrite avec phases, livrables et coûts.
Services associés
- Développement d'intelligence artificielle pour les entreprises : la page pilier avec toutes les solutions d'IA.
- Chatbots d'entreprise : assistance client et assistants internes fondés sur vos contenus.
- Automatisations IA pour les entreprises : processus entre CRM, systèmes de gestion, e-mails et documents.
Parlez-nous des systèmes à connecter
Décrivez les outils que vous utilisez, les données auxquelles l'agent devrait accéder et les actions qu'il pourrait accomplir. Nous vous répondons avec une première évaluation et, si cela a du sens, avec une proposition pour un premier serveur sur un cas concret.