SaaS B2B : exposer vos données aux agents IA
Avec un serveur MCP, vos données métier deviennent interrogeables en langage naturel depuis Claude, ChatGPT (Codex) ou Cursor, au lieu d'attendre que vos utilisateurs ouvrent votre dashboard.
Product Engineering • Expertise MCP
Créer un serveur MCP : connectez votre SaaS aux IA et agents
Votre produit devient activable par Claude, ChatGPT (Codex), Cursor et tous les agents IA compatibles. Vos données, vos fonctionnalités, vos workflows, consultables dans une conversation avec une IA.
Le nouveau point d'entrée d'un SaaS
En 2012 il fallait avoir une app mobile, en 2016 une API publique, et en 2026 c'est le serveur MCP.
Un serveur MCP est un canal de distribution pour les IA. Un assistant IA peut répondre aux questions de vos utilisateurs grâce à vos données et les outils de votre SaaS. Sans serveur MCP, l'IA répond avec ses données génériques. Avec, elle interroge votre produit et cite vos données réelles.
L'enjeu est d'être présent dans la conversation des utilisateurs avec leur IA, au lieu d'attendre qu'ils viennent sur votre app.
Qu'est-ce qu'un serveur MCP ?
Le Model Context Protocol (MCP) est un standard ouvert publié par Anthropic en novembre 2024. Un serveur MCP expose des outils (tools), et parfois des resources en lecture, chacun avec un nom, une description et des paramètres, qu'un agent IA lit, choisit et appelle directement dans une conversation.
C'est comme une API REST, mais le consommateur n'est pas un développeur, c'est un LLM. Une API classique attend des appels et paramètres précis. Un serveur MCP, lui, laisse l'IA lire la liste de tools et décider elle-même lequel appeler selon ce que l'utilisateur demande.
Vos données deviennent citées et vos utilisateurs peuvent vous consommer depuis Claude, ChatGPT (Codex), ou Cursor sans jamais ouvrir votre app.
Le vocabulaire essentiel
- Hôte
- L'application IA qui parle à l'utilisateur : Claude, ChatGPT (Codex), Cursor.
- Client
- Le composant qui parle directement au serveur MCP, souvent intégré dans l'app de l’hôte.
- Serveur
- Ce qu'on construit. Il expose les tools de votre produit.
- Tools
- Les capacités exposées au LLM. Chacun a un nom, une description et des paramètres.
- Resources
- Contenus en lecture exposés à l'IA (documentation, catalogue, schémas).
Cas d'usage
Trois profils types et ce qu'un serveur MCP leur débloque.
Outils internes et bases documentaires interrogeables
Specs, comptes-rendus, notes : un agent IA branché via MCP les résume, les recherche et les relie. Votre équipe peut interroger directement l'IA en langage naturel, plus vite qu'en cliquant dans une UI.
Plateformes data et APIs publiques : brancher l'écosystème agentique
Si vous exposez déjà une API publique, le MCP est l'étape suivante : un canal pensé pour les agents IA. Claude, Codex, Cursor, n8n : autant de clients MCP qui peuvent ensuite automatiser des tâches à partir de votre produit sans intégration custom.
Mon approche en 4 étapes
De l'idée au serveur MCP déployé.
1/4
Cadrage
Quels tools exposer (et lesquels ne PAS exposer), à quelle audience IA, pour quelle donnée critique. De la clarté sur les capacités qui comptent.
2/4
Design des tools
Schéma JSON, nommage, descriptions rédigées comme un prompt (bornes et cas limites inclus), erreurs exploitables par le LLM.
3/4
Développement
Stack adaptée au besoin : FastMCP en Python, SDK TypeScript officiel, OAuth 2.1 pour les serveurs distants multi-utilisateurs, avec un mode d'enregistrement client adapté au contexte.
4/4
Déploiement & itération
Mise en production, monitoring des appels réels, ajustement des descriptions selon le comportement observé des agents.
Stack & standards
Les briques techniques que j'utilise, choisies selon le contexte du projet :
Protocoles
- MCP spec
- JSON-RPC 2.0
- OAuth 2.1
Langages
- Python (FastMCP)
- TypeScript (MCP SDK)
Infrastructure
- Cloudflare Workers
- Vercel
- Supabase
- Firebase
Transports
- stdio (local)
- Streamable HTTP (distant)
Le vrai sujet : choisir ce qu'on expose
Un serveur MCP n'est pas une simple copie de l'API interne. Plus vous exposez de tools, plus l'IA se perd, consomme des tokens inutiles, et hallucine des appels hors contexte. La bonne règle, c'est de viser 3 à 5 tools au lancement et augmenter ensuite.
Sur mes deux serveurs MCP en production, j'ai volontairement créé seulement 3 tools :
Begonia.pro
- audit_local_business
- get_business_scan
- search_local_seo_knowledgebase
Fude.md
- list_projects
- search_documents
- get_document
La règle : un tool = une responsabilité claire. Pas de doublon, pas de « au cas où ».
Écrire la description d'un tool, c'est écrire un prompt
La description des tools est lue par un LLM, pas par un humain. C'est un prompt. Si elle est vague, l'IA ne l'appellera jamais, ou pire, l'appellera à tort.
Quatre réflexes à avoir :
- Nom
- Un verbe + un objet (search_documents plutôt que documents).
- Description
- Ce que fait le tool, quand l'utiliser plutôt qu'un autre, ce qu'il retourne. Trois phrases max.
- Paramètres
- Typés, avec un exemple si le format n'est pas évident.
- Erreurs
- Exploitables par le LLM (« Projet introuvable, utilise list_projects » ou « service indisponible, retry possible ») plutôt que des codes HTTP.
Retours d'expérience de deux serveurs MCP en production
J'ai deux serveurs MCP en production sur mes propres SaaS :
Begonia.pro MCP
Un utilisateur demande à Claude « audite la fiche Google de Boulangerie X à Lyon » et récupère un vrai rapport avec les données de Begonia.pro, pas une réponse générique.
Begonia.proFude.md MCP
Le MCP sert à exposer des documents Markdown. L'utilisateur peut demander « rédige un article pour mon blog sur le sujet XXXX en analysant le style d'écriture de mes autres articles ».
Fude.mdFAQ serveur MCP : choisir, concevoir, livrer
Les questions les plus courantes à propos des serveurs MCP.
Prêt à exposer votre produit aux agents IA ?
Que vous ayez un SaaS existant ou une idée à explorer, parlons-en. Je vous aide à identifier les bons tools, à concevoir un serveur MCP utile, et à le déployer proprement.