Serveur MCP distant : brancher vos agents IA sans clé API
Découvrez comment connecter Claude à votre SaaS via un serveur MCP distant avec OAuth 2.1 et PKCE, sans jamais distribuer de clé API à vos clients.
Imaginez la scène. Un de vos clients ouvre Claude, lui demande de lire ses données dans votre outil, et l'agent s'exécute. Pas de clé API copiée quelque part, pas de fichier de configuration bricolé à minuit, pas de secret qui traîne dans un dépôt Git. Juste une connexion propre, consentie, révocable. C'est exactement ce que permet un serveur MCP distant, et c'est en train de devenir la nouvelle norme pour exposer votre SaaS aux agents IA.
La plupart des tutoriels sur le sujet vous montrent comment lancer un serveur MCP en local, sur la machine du développeur. Ça marche pour du bricolage personnel. Mais dès que vous voulez que vos utilisateurs connectent leurs propres agents à vos données, cette approche s'effondre. Pas d'attribution par utilisateur, pas de consentement, pas de révocation possible, et une clé qui survit longtemps après le départ de l'employé qui l'a créée. Un cauchemar de sécurité.
Pourquoi un serveur MCP distant change la donne
Un serveur MCP distant, c'est un point d'entrée HTTP qui expose les données et les actions de votre application aux agents IA. Il agit comme un serveur de ressources OAuth 2.1. Les agents s'authentifient en tant qu'un de vos utilisateurs existants, demandent un jeton d'accès via un flux de consentement que vous contrôlez, puis appellent vos outils via le Model Context Protocol.
Vous utilisez cette approche quand vous voulez que des agents IA travaillent sur des données clients sans jamais distribuer d'identifiants. C'est la différence entre donner les clés de la maison à tout le monde et installer une serrure connectée qui trace chaque entrée.
Les rôles : qui fait quoi
La confusion la plus fréquente consiste à attendre de Supabase qu'il vous fournisse un serveur MCP. Ce n'est pas le cas. Supabase vous donne la moitié « autorisation », et vous construisez la moitié « ressource ». Concrètement :
- Le serveur d'autorisation, c'est Supabase Auth, via ses endpoints OAuth.
- L'écran de consentement, c'est vous qui le construisez.
- Le serveur de ressources, c'est votre serveur MCP, qui valide les jetons et exécute les outils.
Cette séparation est essentielle. Elle vous permet de garder le contrôle sur ce que chaque agent peut voir et faire, tout en déléguant la partie cryptographique à un service éprouvé.
Le vrai piège : la notion de workspace
Voici le point que la plupart des gens ratent. Le jeton d'accès ne contient aucune notion de l'espace de travail que l'agent est autorisé à toucher. C'est à vous de décider, à chaque appel, quel workspace est légitime. Pas de raccourci possible ici : si vous ne le faites pas, un agent pourrait lire les données d'un autre client.
Dans une implémentation vérifiée sur Next.js 16 et Supabase CLI 2.113.0 en août 2026, sept endroits présentaient d'ailleurs un comportement différent de la documentation officielle. Autant dire que tester en conditions réelles n'est pas optionnel.
Le flux OAuth 2.1 avec PKCE, étape par étape
Le mécanisme repose sur OAuth 2.1 et PKCE, un standard conçu pour les clients publics qui ne peuvent pas garder un secret. Voici comment ça se déroule :
- L'agent découvre les métadonnées de votre serveur MCP et de votre serveur d'autorisation.
- Il initie une demande d'autorisation avec un code challenge PKCE.
- L'utilisateur voit un écran de consentement que vous contrôlez et approuve l'accès.
- L'agent échange le code contre un jeton d'accès en présentant le vérificateur PKCE.
- À chaque appel d'outil, votre serveur valide le jeton et vérifie le scoping par workspace.
Chaque étape est une occasion de reprendre le contrôle. Rien n'est laissé au hasard, et surtout, rien ne dépend d'un secret partagé qui pourrait fuiter.
Valider les jetons et appliquer les règles côté base
La validation du jeton n'est que la première barrière. La seconde, c'est l'application des règles de sécurité au niveau des lignes (RLS) dans votre base de données. Même si un agent présente un jeton valide, la base doit refuser tout accès qui sortirait du périmètre autorisé.
Cette double vérification, au niveau du serveur MCP et au niveau de la base, vous protège contre les erreurs de logique dans votre propre code. C'est le principe de défense en profondeur appliqué aux agents IA.
Pourquoi c'est important
Parce que l'IA agentique arrive dans vos produits, que vous soyez prêt ou non. Si vous exposez vos données aux agents sans cadre d'authentification sérieux, vous créez une faille béante. À l'inverse, un serveur MCP distant bien conçu transforme votre SaaS en plateforme ouverte aux agents, sans sacrifier la sécurité ni la traçabilité. C'est ce qui sépare un produit qu'on peut connecter d'un produit qu'on n'ose pas brancher.
Conclusion
Construire un serveur MCP distant avec OAuth 2.1 et PKCE, ce n'est pas juste une prouesse technique. C'est une décision de conception qui place la confiance au centre de votre relation avec vos utilisateurs. Vous leur donnez le pouvoir de connecter leurs agents IA, tout en gardant la main sur ce qui est accessible, par qui, et pour combien de temps.
Le futur des SaaS passe par là : des produits qui parlent nativement aux agents, sans jamais compromettre la sécurité. Autant prendre de l'avance dès maintenant.
Points clés à retenir
- Un serveur MCP distant expose vos données aux agents IA sans jamais distribuer de clé API.
- Supabase Auth joue le rôle de serveur d'autorisation, mais c'est vous qui construisez le serveur de ressources.
- Le jeton d'accès ne porte pas la notion de workspace : c'est à vous de l'appliquer à chaque appel.
- OAuth 2.1 avec PKCE est le standard adapté aux clients publics comme les agents IA.
- La validation des jetons et les règles RLS forment une défense en profondeur indispensable.