Votre SaaS sans serveur MCP : un produit à moitié intégré

Le débat sur MCP tourne en boucle depuis six mois : protocole révolution, USB-C de l'IA, standard de facto. On a compris. Ce qu'on lit beaucoup moins, c'est la question qui concerne directement les gens qui construisent des SaaS — pas ceux qui les achètent.

Est-ce que le produit que vous livrez aujourd'hui doit exposer son propre serveur MCP ?

La réponse courte : si vos clients ont des agents IA dans leur stack (et en 2026, ils en ont), oui. La réponse longue, c'est cet article.

---

De protocole expérimental à critère d'achat SaaS

MCP a été lancé par Anthropic en novembre 2024. Dix-huit mois plus tard, les chiffres résument assez bien le chemin parcouru : 97 millions de téléchargements mensuels des SDK, plus de 10 000 serveurs actifs, près de 2 000 entrées dans le MCP Registry¹. OpenAI, Google DeepMind, Microsoft ont tous intégré le protocole. Cursor, VS Code, JetBrains, Windsurf l'ont suivi. Salesforce, HubSpot, Atlassian, Stripe, GitHub ont leurs serveurs officiels.

En décembre 2025, Anthropic a confié la gouvernance de MCP à l'Agentic AI Foundation, filiale de la Linux Foundation¹. Ce n'est plus un projet Anthropic — c'est un standard ouvert avec une gouvernance formelle.

Ce déplacement a une conséquence concrète sur les décisions d'achat. Les DSI qui déploient des agents IA commencent à filtrer leurs outils sur un nouveau critère : est-ce que ce SaaS expose un serveur MCP officiel ? Un outil qui ne le fait pas devient un frein dans l'orchestration, un cas particulier à traiter manuellement². La question n'est plus "est-ce que ce logiciel a une API" — c'est "est-ce que cette API parle MCP".

Datadog vient de passer son serveur MCP en disponibilité générale. Ce n'est pas anodin : c'est une plateforme d'observabilité qui expose ses logs, métriques et traces directement aux agents de codage — Claude Code, Cursor, Codex — sans que le développeur quitte son environnement de travail³. L'agent diagnostique l'incident, récupère les traces en production, propose un correctif. Zéro friction entre l'outillage de développement et les données de production.

Si Datadog, qui cible des équipes d'ingénierie avancées, juge que c'est prioritaire, c'est que ses clients l'exigent.

---

Ce que "exposer un serveur MCP" veut dire concrètement

MCP définit trois types de capacités qu'un serveur peut exposer à un modèle IA⁴ :

Tools — des actions exécutables. Créer une facture, mettre à jour un statut, lancer un export, déclencher un webhook. C'est ce qui transforme un agent de lecteur en acteur dans votre logiciel.

Resources — des données en lecture. Lister les commandes du mois, récupérer le profil d'un client, lire l'état d'un projet. Les resources ne déclenchent pas d'action — elles alimentent le raisonnement du modèle.

Prompts — des templates préconfigurés pour des tâches récurrentes. "Génère le rapport mensuel à partir des ventes de ce client" devient une instruction réutilisable, directement découvrable par l'agent.

Cette séparation n'est pas anodine. Elle force à penser ce qu'on expose, à qui, et avec quelles permissions. Un serveur MCP bien conçu n'est pas un miroir de votre API REST — c'est une interface pensée pour être comprise et actionnée par un modèle de langage.

La règle de base : exposez des méthodes de requête paramétrées, jamais du SQL brut. Gérez l'authentification et la limitation de débit côté serveur MCP, pas côté client⁴. L'agent n'a pas besoin de savoir comment votre base est structurée — il a besoin de savoir ce qu'il peut faire.

---

Remote vs local : un choix architectural qui n'est pas trivial

Les serveurs MCP peuvent tourner en local (stdio, même machine que le client) ou à distance (HTTP/SSE ou Streamable HTTP). Le mode remote a connu une croissance de plus de 400 % depuis mai 2025⁵. C'est logique : les SaaS sont des produits distribués, pas des binaires qu'on installe chez le client.

Pour un SaaS B2B, le serveur MCP remote est presque toujours la bonne option. Vos clients ne devraient pas avoir à faire tourner quoi que ce soit localement pour que leurs agents accèdent à votre produit.

Ce choix a des implications sur le scaling. Streamable HTTP, le transport qui permet les déploiements remote à grande échelle, est aujourd'hui au cœur de la roadmap officielle MCP⁶ : les sessions stateful se battent avec les load balancers, le scaling horizontal demande des contournements, et la découverte des capacités sans connexion active n'est pas encore standardisée. Ce sont des problèmes réels à anticiper si vous dimensionnez pour de gros volumes.

La roadmap prévoit aussi un format de métadonnées standard via .well-known, qui permettra à des registres ou des agents de découvrir les capacités d'un serveur sans avoir à s'y connecter d'abord⁶. Utile à planifier dès maintenant dans votre architecture.

---

Les pièges réels : sécurité, surface d'attaque, gouvernance

MCP n'est pas un protocole magique qui sécurise vos données par définition. C'est une interface d'exposition — et comme toute interface d'exposition, elle élargit votre surface d'attaque.

Quelques règles qui émergent des déploiements en production⁷ :

Moindre privilège sur les tools. Exposez le minimum nécessaire. Chaque tool supplémentaire est une action que l'agent peut déclencher — y compris par erreur ou par prompt injection. La discipline s'impose : les serveurs qui apparaissent les plus stables en production sont ceux qui ont refusé d'exposer des capacités "pour plus tard".

Les secrets restent côté serveur. Les tokens d'API, les clés d'accès, les connexions aux bases — tout ça se lit depuis les variables d'environnement ou un secret store côté serveur MCP. Jamais transmis au client, jamais dans le contexte du modèle⁷.

Timeouts et idempotence. Les appels d'agents peuvent durer, peuvent être réessayés, peuvent être interrompus. Un tool qui crée deux fois la même ressource parce qu'un timeout a masqué le succès de la première requête, c'est un bug de production. Concevez vos tools comme des endpoints d'API sérieux : idempotents quand c'est possible, avec des identifiants de résultats récupérables si l'opération est longue.

Logs d'audit. Quel agent a appelé quel tool avec quels paramètres, à quelle heure, avec quel résultat. Pas optionnel. Les organisations qui traitent MCP comme un projet IT ordinaire, sans cadre de gouvernance, prendront des risques à mesure que les agents déploient plus d'autonomie².

La bonne nouvelle : les SDK officiels (TypeScript et Python) gèrent une grande partie de la plomberie de sécurité. Le travail côté builder consiste surtout à définir le scope de façon rigoureuse — ce qui est une question de conception produit autant que de technique.

---

Ce que ça change pour les SaaS qu'on livre

À NXL Forge, on construit des SaaS B2B sur mesure. La question du serveur MCP devient concrète à chaque nouveau projet : est-ce que ce produit sera utilisé dans un contexte où le client a des agents dans son workflow ?

En 2026, la réponse est presque toujours oui — ou le sera dans six mois.

Ce qu'on observe sur nos projets en cours : les clients qui demandent une API REST "classique" demandent en réalité la capacité d'automatiser des actions dans leur logiciel. Ce qu'ils voulaient appeler depuis Zapier hier, ils veulent maintenant l'appeler depuis leur agent. MCP standardise cette couche — et rend le code plus maintenable, pas moins.

L'approche que Lonestone décrit comme "MCP-first" — exposer vos briques métier en services MCP, plugger des outils tiers pour le reste, garder la liberté de changer de modèle sans tout réécrire⁸ — correspond à ce qu'on applique avec notre méthode : code structuré, interfaces explicites, propriété transférable. Un serveur MCP bien construit est du code auditable. Ça rentre dans le cadre.

La question du coût de développement mérite d'être posée directement. Un serveur MCP de base, avec cinq à dix tools couvrant les actions principales d'un SaaS, représente quelques jours de travail avec le SDK TypeScript. Ce n'est pas un chantier. C'est une décision d'architecture à prendre tôt, pas une fonctionnalité à ajouter en v3.

Si vous lancez un SaaS et que vous voulez estimer ce que ça représente dans votre budget total, l'estimateur de coût peut vous donner un ordre de grandeur selon votre scope.

---

Ce qui reste à régler

MCP en 2026, c'est un standard en production — pas un standard fini. Les gaps techniques que la communauté est en train de combler⁶ :

• Le scaling horizontal des serveurs stateful reste un sujet ouvert. Les entreprises qui tournent avec des centaines d'agents simultanés gèrent des workarounds.
• La gouvernance enterprise (SSO, audit trails, configuration portability) n'est pas encore dans le core spec — elle se construit en extensions.
• La découverte de serveurs sans connexion active est en cours de standardisation.

Aucun de ces points n'est bloquant pour démarrer. Ils définissent juste où investir du temps de robustesse dans les mois qui viennent.

Ce qui est acquis : MCP est le protocole sur lequel les agents vont appeler vos logiciels. Le "si" est derrière nous. La vraie question pour les builders, c'est le "quand" et le "comment" — et sur un SaaS neuf, le bon moment c'est maintenant.

---

Sources

Footnotes

1. IT-Room — MCP : le protocole open source qui connecte l'IA à vos outils — Chiffres d'adoption : 97M téléchargements SDK mensuels, 10 000 serveurs actifs, gouvernance confiée à l'Agentic AI Foundation (Linux Foundation) en décembre 2025. Lire l'article ↩ ↩²

2. 2LKATIME — MCP : ce que chaque DSI doit savoir en 2026 — Analyse du changement dans les critères d'achat SaaS : un outil sans serveur MCP devient un frein à l'intégration IA. Exemples de déploiements en production. Lire l'article ↩ ↩²

3. IT Social — Datadog lance son serveur MCP — Disponibilité générale du serveur MCP Datadog, compatible Claude Code, Cursor et Codex. Accès direct aux logs, métriques et traces depuis l'IDE. Lire l'article ↩

4. Bridgeapp — Guide complet MCP : architecture, intégration et bonnes pratiques — Détail des trois capacités exposées (Tools, Resources, Prompts), gestion d'état, sécurité et principe de moindre privilège. Lire l'article ↩ ↩²

5. Digitalkin — Architecture MCP : du SaaS monolithique au mesh agentique — Croissance de plus de 400 % des déploiements remote depuis mai 2025, analyse des défis de scalabilité et sécurité. Lire l'article ↩

6. MCP Official Blog — The 2026 MCP Roadmap — Feuille de route officielle du protocole : transport Streamable HTTP, scaling horizontal, metadata format via .well-known, gouvernance enterprise. Lire l'article ↩ ↩² ↩³

7. Apify — MCP Standard and Ecosystem in 2026 — Bonnes pratiques de production : moindre privilège, secrets hors prompts, timeouts, idempotence, logs d'audit, versioning. Lire l'article ↩ ↩²

8. Lonestone — Créer un SaaS IA en 2026 : MCP-first — Approche "MCP-first" pour les nouveaux SaaS IA : exposer les briques métier en services MCP, maintenir l'interopérabilité entre fournisseurs de modèles. Lire l'article ↩