Développement de Serveurs MCP Sur Mesure : Notre Méthodologie pour Connecter les Entreprises aux Agents IA

En 2026, le Model Context Protocol est devenu le standard de facto pour connecter les systèmes d'entreprise aux agents IA. Avec 13 000 serveurs publiés et une gouvernance Linux Foundation, la question n'est plus "faut-il adopter MCP ?" mais "comment bien le faire ?"

Parce qu'un serveur MCP, ça se conçoit. Entre le serveur "hello world" d'un tutoriel et un serveur production qui connecte le CRM, l'ERP et le catalogue d'une ETI à l'écosystème IA, il y a un fossé — de conception, de sécurité et d'architecture.

Chez KODY, nous développons des serveurs MCP pour des entreprises B2B. Cet article partage notre méthodologie : comment on aborde un projet, ce qu'on a appris, et ce qui fait la différence entre un serveur MCP qui fonctionne et un qui transforme vraiment l'accès aux données de l'entreprise.

Phase 1 : Audit et cartographie

Avant d'écrire une ligne de code, on passe une semaine sur le terrain. Pas pour coder — pour comprendre.

Ce qu'on audite

• Les systèmes existants : CRM, ERP, catalogue, base de connaissances, API tierces. On liste chaque système, son état (legacy, managé, cloud), ses API exposées, et la qualité de sa documentation.
• Les cas d'usage réels : on interroge les équipes métier. Qu'est-ce qu'un assistant IA pourrait faire qui leur ferait gagner du temps ? Chercher un produit ? Vérifier un stock ? Générer un devis ? Suivre une commande ? Les réponses sont souvent surprenantes — et rarement celles qu'on imagine depuis une spec technique.
• Les contraintes de sécurité : qui a accès à quoi ? Quelles données peuvent être exposées à un LLM ? Quelles actions peuvent être automatisées sans validation humaine ?

Ce qui en sort

Un document de conception qui liste :

• Les systèmes à connecter (avec leur état et leur API)
• Les outils à exposer (nom, description, paramètres, retour)
• Les règles de sécurité (authentification, périmètre de chaque outil, logging)
• Les contraintes techniques (transport, hébergement, stack)

Ce document est notre vérité partagée avec le client. On ne commence pas le développement tant qu'il n'est pas validé.

Phase 2 : Conception des outils

C'est l'étape la plus importante — et la plus sous-estimée.

Le piège : trop d'outils

Un serveur MCP qui expose 20 outils aura un problème : les définitions des outils consomment de la fenêtre de contexte du modèle. Plus il y en a, moins il reste de place pour les données utiles. Cloudflare a documenté ce problème : une spécification OpenAPI complète représente 2 millions de tokens. Dans la pratique, un agent qui doit choisir parmi 20+ outils passe plus de temps à décider qu'à exécuter.

Notre règle : entre 3 et 8 outils par serveur. Si un cas d'usage en nécessite plus, on conçoit plusieurs serveurs spécialisés plutôt qu'un monolithe.

Les bonnes pratiques de conception

Noms d'outils explicites. Le LLM choisit un outil principalement sur son nom. search_products est plus efficace que query_catalog. create_quote_with_validation est plus parlant que process_request. On privilégie des noms qui décrivent l'action et le résultat.

Descriptions optimisées pour le function calling. La description de chaque outil doit répondre à trois questions : quand utiliser cet outil ? Quels paramètres sont obligatoires ? Que retourne-t-il ? Les modèles les plus récents (Claude 4, GPT-5) lisent ces descriptions pour décider si l'outil est pertinent.

Paramètres stricts et bien typés. On utilise Zod (en TypeScript) ou Pydantic (en Python) pour valider les entrées. Chaque paramètre a un type strict, une valeur par défaut si possible, et une description qui aide le modèle à fournir la bonne valeur.

Exemple concret

// Un outil bien conçu pour un serveur MCP B2B
server.tool(
  "search_available_products",
  "Recherche des produits disponibles dans le catalogue. " +
  "À utiliser quand un client cherche un produit par nom, catégorie ou référence. " +
  "Retourne jusqu'à 20 résultats avec prix, disponibilité et délai de livraison.",
  {
    query: z.string().describe("Terme de recherche (nom, référence, ou mot-clé)"),
    category: z.string().optional().describe("Filtrer par catégorie"),
    max_price: z.number().optional().describe("Prix maximum en euros"),
    in_stock: z.boolean().optional().describe("Ne retourner que les produits en stock"),
  },
  async ({ query, category, max_price, in_stock }) => {
    const results = await catalogApi.search({ query, category, max_price, in_stock });
    return {
      content: [{
        type: "text",
        text: JSON.stringify({
          count: results.length,
          products: results.map(p => ({
            id: p.id,
            name: p.name,
            price: p.price,
            available: p.stock > 0,
            delivery_delay: p.deliveryDelay,
          })),
        }),
      }],
    };
  }
);

La validation multi-modèles

Avant de déployer, chaque outil est testé avec au moins trois modèles différents (Claude, GPT-4, Gemini). On vérifie que :

• Le modèle comprend quand utiliser l'outil
• Il fournit les bons paramètres
• Il interprète correctement le retour

Une différence subtile entre deux modèles — par exemple, l'un qui envoie in_stock: true et l'autre qui envoie inStock: "yes" — peut casser l'intégration. On adapte les définitions d'outils pour être tolérants ou on normalise côté serveur.

Phase 3 : Implémentation et stack technique

Choix de la stack

On utilise systématiquement le SDK officiel MCP, soit en TypeScript soit en Python :

Architecture type

src/
├── server.ts          // Point d'entrée : configuration du serveur MCP
├── tools/             // Un fichier par outil ou groupe d'outils
│   ├── search.ts
│   ├── availability.ts
│   └── booking.ts
├── clients/           // Clients API pour chaque système externe
│   ├── crm.ts
│   ├── erp.ts
│   └── catalog.ts
├── middleware/        // Logging, auth, rate limiting
│   ├── auth.ts
│   └── logger.ts
├── config.ts          // Variables d'environnement, secrets
└── types.ts           // Types partagés entre outils

Transport : Streamable HTTP

Pour les serveurs B2B déployés en production, on utilise presque toujours le transport Streamable HTTP (requêtes POST + SSE pour les réponses asynchrones). Il permet :

• Le déploiement derrière un load balancer (scale horizontal)
• L'authentification au niveau HTTP (API keys, JWT)
• Le monitoring standard (logs HTTP, métriques, tracing)
• L'intégration dans une infrastructure existante (Kubernetes, Docker, serverless)

Le transport stdio reste pertinent pour les serveurs locaux (IDE, outils internes) mais n'est pas adapté à un déploiement enterprise.

Sécurité : couche non-négociable

La spécification MCP de base ne définit pas d'authentification. En production, on ajoute systématiquement :

1. Authentification par API key ou JWT au niveau du transport HTTP
2. Stockage des tokens sensibles dans un vault (AWS Secrets Manager, HashiCorp Vault, ou équivalent)
3. Principe du moindre privilège : chaque outil ne peut faire que ce pour quoi il est conçu
4. Logging de toutes les invocations : qui a appelé quel outil, quand, avec quels paramètres, quel résultat
5. Rate limiting par client pour éviter les abus

Notre recommandation : si votre entreprise opère dans un secteur régulé (finance, santé, données personnelles), MCP peut être utilisé, mais avec une couche gateway dédiée qui gère l'authentification SSO et les guardrails. Des solutions comme Agentgateway (Linux Foundation) commencent à répondre à ce besoin.

Phase 4 : Déploiement et monitoring

Où déployer un serveur MCP

Les options sont les mêmes que pour une API classique :

• Docker + AWS ECS / Fargate : notre option par défaut. Scalable, managé, facile à intégrer dans une infrastructure existante.
• Cloudflare Workers : idéal pour des serveurs légers avec peu de dépendances. Latence minimale.
• Kubernetes : pour les entreprises qui ont déjà un cluster et veulent standardiser le déploiement.
• Serverless (AWS Lambda) : possible mais attention au cold start. Le transport Streamable HTTP avec SSE peut poser problème sur certaines configurations serverless.

Monitoring

Un serveur MCP en production doit être surveillé comme n'importe quelle API. On met en place :

• Logs structurés : chaque invocation d'outil est loggée avec timestamp, client, outil, paramètres, durée et statut.
• Métriques : nombre d'invocations par outil, taux d'erreur, latence moyenne et P99.
• Alertes : seuil d'erreur dépassé, latence anormale, tentative d'accès non autorisée.
• Dashboards : vue d'ensemble de l'activité du serveur, avec filtrage par client et par outil.

Tests

Chaque serveur MCP passe par une batterie de tests avant déploiement :

Tests unitaires (vitest / pytest)
  → Chaque outil testé isolément avec des mocks

Tests d'intégration
  → Chaque outil testé contre un serveur MCP réel
  → Validation du format JSON-RPC

Tests multi-modèles
  → Chaque outil invoqué via Claude, GPT-4 et Gemini
  → Vérification que les définitions sont comprises correctement

Tests de charge
  → Simulation de 100, 500, 1000 invocations simultanées
  → Vérification des temps de réponse et du taux d'erreur

Pourquoi faire appel à une agence plutôt que développer en interne ?

C'est une question légitime. MCP n'est pas une technologie extraterrestre — un développeur TypeScript ou Python peut produire un serveur fonctionnel en une journée.

Le problème, c'est la conception.

Un serveur MCP n'est pas une API de plus. C'est une interface qui va être consommée par des modèles d'IA — des systèmes qui ne lisent pas la documentation, qui interprètent les descriptions d'outils de manière non déterministe, et qui changent de comportement à chaque mise à jour.

Ce qui fait la différence :

1. L'expérience de conception d'outils pour LLM. Savoir comment un modèle comme Claude 4 ou GPT-5 interprète les descriptions d'outils, comment il priorise entre plusieurs outils similaires, comment il gère les erreurs de paramètres — ça s'apprend par la pratique, pas dans la spec.

2. La connaissance des pièges. Les problèmes documentés — surcharge de contexte, injection via descriptions d'outils, authentification fragile — sont réels. Un serveur conçu sans les connaître produira des résultats imprévisibles en production.

3. La validation multi-modèles. Tous les modèles ne se comportent pas pareil. Un outil parfaitement conçu pour Claude peut produire des résultats médiocres avec Gemini. Une agence qui a testé sur les trois saura ce qui fonctionne partout.

4. L'infrastructure et le monitoring. Un serveur MCP en production a besoin de déploiement, de scaling, de logging et d'alertes — exactement comme n'importe quelle API. Mais les métriques pertinentes sont différentes.

Quand faire en interne : vous avez déjà une équipe qui maîtrise l'écosystème IA, qui a déployé des agents en production, et qui peut consacrer 2 à 4 semaines à un projet MCP.

Quand faire appel à nous : vous voulez un serveur MCP en production en 3 à 6 semaines, avec une conception validée multi-modèles, une sécurité enterprise, et un accompagnement sur la stratégie d'exposition de vos données aux agents IA.

Ce qu'il faut retenir

Développer un serveur MCP pour une entreprise B2B, c'est 80 % de conception et 20 % de code. Le vrai travail n'est pas technique — il est dans la compréhension des cas d'usage, la conception des outils, et l'anticipation de la façon dont les modèles d'IA vont interagir avec le serveur.

Notre méthodologie en quatre phases (audit, conception, implémentation, déploiement) nous permet de livrer des serveurs MCP qui :

• Exposent les bonnes capacités (ni trop, ni trop peu)
• Sont compris par tous les modèles du marché
• Respectent les contraintes de sécurité de l'entreprise
• Sont surveillés et maintenus en production

Les entreprises qui investissent dans MCP aujourd'hui ne le font pas pour suivre une mode. Elles le font parce qu'elles ont compris que la prochaine vague de distribution digitale passe par les agents IA — et qu'elles veulent être présentes quand ces agents chercheront leurs données et services.

Vous avez un projet MCP ?

Nous accompagnons les entreprises B2B dans la conception, le développement et le déploiement de leurs serveurs MCP. De l'audit initial à la mise en production, en passant par la validation multi-modèles et la sécurité.

Contactez KODY pour discuter de votre projet.

Ressources

• Spécification officielle MCP — documentation de référence
• MCP en Entreprise : pourquoi adopter le protocole — l'article compagnon sur la stratégie business
• GitHub modelcontextprotocol/servers — catalogue des serveurs officiels et communautaires
• Agentic AI Foundation — gouvernance et membres