Serveurs MCP pour un projet web : lesquels et quels droits

Quels serveurs MCP sont vraiment utiles sur un projet web ?

Cinq familles de serveurs MCP servent sur un projet de site : le dépôt de code (GitHub), la base de données (Supabase), le paiement (Stripe), l’hébergement et le déploiement (Vercel, Netlify, Cloudflare) et le navigateur de test (Playwright, Chrome DevTools). Leurs droits réels dépendent du jeton fourni : lecture seule par défaut, écriture seulement sur décision explicite.

Le concept de MCP est déjà expliqué dans MCP, Skills, agents : ce que Claude sait vraiment faire. Cet article fait l’inventaire pratique : pour chaque serveur, ce qu’il permet, les droits qu’il réclame et ce qui peut mal tourner. Brancher un serveur MCP revient à donner à une IA un accès à un outil réel, avec les mêmes conséquences qu’un accès donné à un prestataire.

Une précision de méthode : je ne liste que des serveurs publiés par les éditeurs eux-mêmes. Les serveurs communautaires existent par milliers, mais un serveur communautaire n’a pas de garantie de maintenance ni de revue de sécurité. Pour deux familles (hébergement et navigateur), je n’avais pas de page officielle à citer au moment de la rédaction : je le signale plus bas au lieu de décrire des réglages de mémoire.

Comment lire les droits d’un serveur MCP

Un serveur MCP est un programme qui expose à une IA une liste d’outils (lire un fichier, créer une ligne, lancer un déploiement) via un protocole standard. Ce que l’IA peut faire dépend du compte ou du jeton avec lequel le serveur est connecté, pas de la qualité du prompt.

La spécification officielle distingue deux cas. Un serveur local (transport STDIO) récupère ses identifiants dans l’environnement de la machine, tandis qu’un serveur distant (HTTP) suit la procédure d’autorisation OAuth 2.1 source : Spécification MCP, 2025-11-25. L’autorisation est optionnelle dans MCP, donc un serveur peut très bien fonctionner sans aucun contrôle d’accès. Les clients doivent aussi envoyer le paramètre resource (RFC 8707), qui lie le jeton à son destinataire.

Le tutoriel officiel indique quand l’autorisation devient fortement recommandée : accès à des données propres à l’utilisateur (mails, documents, bases de données), besoin de savoir qui a fait quoi, environnement d’entreprise source : tutoriel MCP sur l’autorisation, 2026. Un site avec des clients et des paiements coche les trois cases.

Le risque commun : l’injection de prompt

L’injection de prompt consiste à glisser dans une donnée lue par l’IA (un ticket, une ligne de base, une page web) une instruction que le modèle exécute comme si elle venait de vous. C’est le risque transversal : plus le serveur lit de contenu écrit par des tiers, plus la surface est large.

Le guide officiel de sécurité MCP recense d’autres attaques, dont le « confused deputy » et le détournement de session, et recommande des mesures contre l’exécution non autorisée pour les serveurs lancés en local source : bonnes pratiques de sécurité MCP, 2026. Le brouillon de spécification ajoute qu’un serveur ne doit pas retransmettre tel quel le jeton reçu du client vers une API amont source : considérations de sécurité MCP, brouillon. Ces garde-fous protègent le protocole. Ils ne protègent pas contre un jeton trop puissant que vous avez vous-même fourni.

Tableau récapitulatif des serveurs

Famille	Serveur	Ce qu’il permet	Droits demandés	Risque principal	Réglage prudent
Code	GitHub MCP Server (officiel)	Lire le dépôt, ouvrir des issues, proposer des pull requests	OAuth ou PAT, scopes `repo`, `read:packages`, `read:org`	Écriture sur le code, fuite de dépôts privés	PAT fine-grained, lecture seule, toolsets limités
Base de données	Supabase MCP (officiel)	Requêtes SQL, migrations, logs, fonctions Edge, branches	OAuth (distant) ou PAT (local)	Lecture et modification de données clients, injection de prompt	`read_only=true`, un seul `project_ref`, base de test
Paiement	Stripe MCP (officiel)	Infos de compte, remboursements, recherche, documentation	OAuth ou clé restreinte `rk_`	Opérations sur de l’argent réel	Sandbox d’abord, clé restreinte, lecture seule
Déploiement	Vercel, Netlify, Cloudflare	Voir les projets et les déploiements	Selon l’éditeur : à vérifier	Mise en production, variables d’environnement	Jeton limité à un projet, pas de production
Navigateur	Playwright, Chrome DevTools	Ouvrir des pages, cliquer, lire la console	Pas de jeton, mais l’accès au navigateur	Sessions connectées, contenu non fiable	Profil vierge, environnement de recette

GitHub : le serveur le mieux documenté

Le serveur GitHub permet à l’IA de lire le code, de créer des issues, de commenter et de proposer des modifications. C’est le serveur le plus utile au quotidien, parce que le dépôt est la source de vérité d’un projet web.

Il existe en deux versions. Le serveur local s’authentifie par OAuth ou par jeton d’accès personnel (la variable GITHUB_PERSONAL_ACCESS_TOKEN, prioritaire). Le serveur distant est hébergé à https://api.githubcopilot.com/mcp/, et les groupes d’outils s’y choisissent par URL ou par en-tête source : documentation du serveur distant GitHub, 2026.

Les droits, outil par outil

Le serveur peut appeler de nombreuses API GitHub, et le dépôt officiel conseille de n’activer que les permissions que vous acceptez de donner à l’IA source : dépôt GitHub MCP Server, 2026. Ses bonnes pratiques de jetons tiennent en cinq lignes :

scopes minimaux (repo, read:packages, read:org) ;
un jeton distinct par projet ou par environnement ;
une rotation régulière ;
aucun jeton dans le dépôt Git ;
des permissions restreintes sur le fichier de configuration (chmod 600).

La documentation de configuration va plus loin. Les outils sont regroupés en toolsets (repos, issues, etc.), activables un à un avec --tools ou exclus avec --exclude-tools. Le mode lecture seule (--read-only, en-tête X-MCP-Readonly ou suffixe d’URL /readonly) a priorité : les outils d’écriture restent désactivés même s’ils sont demandés explicitement source : configuration du serveur GitHub MCP, 2026.

Le risque et le réglage

Le risque est double. Un jeton trop large permet à l’IA de pousser du code ou de lire des dépôts sans rapport avec le projet. Et chaque issue ou commentaire public qu’elle lit est un texte que n’importe qui a pu écrire.

GitHub applique cette prudence à son propre agent : pour l’agent Copilot, la documentation recommande fortement de n’autoriser que des outils en lecture seule, car l’agent les utilise de façon autonome sans demander d’approbation. Le serveur intégré à l’agent utilise par défaut un jeton limité à la lecture du dépôt courant, et GitHub conseille un PAT fine-grained limité à des dépôts précis source : GitHub Docs, 2026. Quand l’éditeur lui-même recommande la lecture seule pour son produit, c’est un bon réglage de départ pour le vôtre.

Supabase : utile et le plus délicat

Le serveur Supabase donne à l’IA un accès à votre base Postgres : exécuter du SQL, appliquer des migrations, consulter les logs, gérer des fonctions Edge et des branches. Selon un annuaire tiers, le serveur officiel compte 32 outils répartis en 8 groupes (bases de données, migrations, logs, Edge Functions, branches, documentation) source : MCP Verdict, 2026. Ce chiffre est un comptage tiers, pas une donnée de l’éditeur.

L’endpoint hébergé est https://mcp.supabase.com/mcp. Trois paramètres d’URL limitent le périmètre : project_ref=… pour un seul projet, read_only=true pour la lecture seule, features=database,docs pour ne charger que certains groupes d’outils source : registre mcpservers.org, 2026.

Ce qui protège vraiment

Une analyse tierce fondée sur la documentation et le code source précise un point important : le mode lecture seule exécute les requêtes SQL avec un utilisateur Postgres en lecture seule, donc la restriction s’applique dans la base, pas seulement dans la liste des outils source : Agentic Control Plane, 2026. La même analyse note trois manques : pas d’audit natif, pas de validation humaine intégrée, pas de limitation de débit.

Le serveur n’est pas en lecture seule par défaut, mais il peut l’être (toujours selon MCP Verdict). Les lignes renvoyées par la base peuvent contenir des instructions non fiables, et l’enrobage du prompt n’est pas une barrière de sécurité complète.

Le précédent de 2025

Un billet publié à l’été 2025 décrivait un scénario d’injection de prompt stockée : un message déposé dans une table, lu ensuite par une IA branchée via Cursor, pouvait pousser celle-ci à exposer des données, y compris sur une base protégée par Row Level Security. Supabase a répondu par une approche « defense in depth » : validation des entrées, assainissement des sorties, isolation du contexte et moindre privilège source : blog Supabase, 2025. Ce billet date d’avant le lancement du serveur hébergé, donc ses détails d’architecture sont dépassés, mais le raisonnement sur le risque tient toujours.

Ma règle : l’IA ne se branche jamais sur la base de production. Elle travaille sur une base de développement, en lecture seule, limitée à un projet. Les migrations, elles, passent par un fichier que vous relisez.

Stripe : là où l’erreur coûte de l’argent

Stripe propose un serveur hébergé à https://mcp.stripe.com et un serveur local via le package @stripe/mcp. Les outils couvrent les informations de compte, les remboursements, la recherche et la lecture de ressources, la recherche dans la documentation, plus des outils génériques de lecture et d’écriture sur l’API source : Scalekit, 2026. Les deux sources que j’ai utilisées sur Stripe sont des blogs tiers : avant de configurer quoi que ce soit, vérifiez dans la documentation Stripe consacrée à MCP.

L’authentification se fait par OAuth pour les clients interactifs, ou par clé API restreinte passée en bearer token pour les agents autonomes. L’accès MCP s’active dans le Dashboard, séparément pour le sandbox et pour le mode live. Les clés restreintes (rk_live_) sont recommandées, les clés secrètes (sk_live_) déconseillées (même source).

La différence entre les deux modes compte pour le risque. Le serveur local, open source (stripe/agent-toolkit, licence MIT), expose des actions fines activables une à une, comme créer un client ou un lien de paiement. Le serveur hébergé expose des outils génériques de lecture et d’écriture couvrant environ 150 méthodes d’API source : Growth Method, 2026. Un outil générique d’écriture est plus large qu’une action nommée, donc plus difficile à encadrer.

Cette même source affirme que les Agent Keys deviendraient obligatoires pour le serveur local à partir du 31 octobre 2026. C’est l’affirmation d’un seul blog : ne l’intégrez pas à votre organisation sans l’avoir confirmée chez Stripe.

Pour un site vitrine ou une boutique, mon avis est tranché : on branche Stripe en sandbox pour que l’IA aide à écrire et tester l’intégration, avec une clé restreinte en lecture. Un remboursement ou un paiement ne doit jamais partir sans validation humaine. Si vous vendez de l’alcool en ligne, la conformité du tunnel reste votre responsabilité : voir E-commerce spiritueux : obligations légales 2026.

Hébergement, déploiement et navigateur : ce que je ne détaille pas

Pour ces deux familles, je n’avais pas de page officielle vérifiée dans mes sources. À ma connaissance, Vercel, Netlify et Cloudflare publient chacun un serveur MCP, Microsoft publie Playwright MCP et l’équipe Chrome publie Chrome DevTools MCP. Je ne détaille ni leurs outils ni leurs scopes : décrire des réglages de mémoire serait justement le genre d’erreur que ce guide veut éviter.

Voici ce qu’on peut dire sans risque, parce que c’est vrai de tout outil de déploiement ou de test :

Déploiement : un serveur qui peut lancer un déploiement ou modifier des variables d’environnement touche à la production et à des secrets. Exigez un jeton limité à un projet, et préférez les préversions à la production. Pour comprendre ce qui se passe quand un déploiement échoue, voir Déploiement Vercel qui échoue et Netlify ou Vercel en 2026.
Navigateur : un navigateur piloté par l’IA lit des pages écrites par des tiers, donc c’est un vecteur d’injection de prompt. Utilisez un profil vierge, sans session connectée, sur un environnement de recette. Le test dans Chrome est détaillé dans Faire tester son site par Claude dans Chrome.

Avant de brancher l’un d’eux, ouvrez la page officielle de l’éditeur et cherchez trois choses : la liste des outils, le type d’authentification, l’existence d’un mode lecture seule. S’il manque l’une des trois, passez votre chemin.

Les six règles de configuration que j’applique

Un jeton par serveur et par projet. Un jeton partagé multiplie les dégâts en cas de fuite.
Lecture seule d’abord. On ouvre l’écriture outil par outil, quand un besoin précis le justifie.
Environnement de test avant production. Base de développement, sandbox de paiement, préversion de déploiement.
Pas de secret dans le dépôt. Les jetons vivent dans l’environnement, jamais dans un fichier versionné.
Validation humaine sur les actions irréversibles. Suppression, remboursement, mise en production : un humain clique.
Un serveur de moins vaut mieux qu’un serveur de plus. Chaque serveur branché élargit ce que l’IA peut lire, donc ce qu’une injection peut atteindre.

Chez Peechy, nous travaillons avec Claude et GitHub Copilot, et le détail de cette stack est dans Notre stack IA chez Peechy en 2026. La question des accès se pose de la même façon avec une agence : voir 7 accès à exiger de votre agence web. Une IA branchée à vos outils est un prestataire de plus, et elle mérite le même traitement.

FAQ

Un serveur MCP officiel est-il sans danger ?

Non. « Officiel » signifie publié par l’éditeur, pas sans risque. Les droits dépendent du jeton que vous fournissez, et l’injection de prompt reste possible dès que l’IA lit du contenu écrit par des tiers.

Faut-il choisir un serveur local ou distant ?

Le serveur local lit ses identifiants dans l’environnement de votre machine, le serveur distant passe par OAuth 2.1 selon la spécification MCP. Le distant évite de stocker un jeton longue durée chez soi, le local vous laisse plus de contrôle sur ce qui tourne. Dans les deux cas, limitez les droits.

Peut-on brancher Supabase MCP sur la base de production ?

Je le déconseille. Utilisez une base de développement, le paramètre read_only=true et un seul project_ref. La lecture seule appliquée côté Postgres réduit le risque d’écriture, mais ne supprime pas celui de fuite de données lues.

Stripe MCP peut-il effectuer des remboursements tout seul ?

Les remboursements font partie des outils décrits par les sources tierces, donc oui si la clé le permet. Limitez la clé restreinte à la lecture et gardez un humain pour toute opération sur de l’argent réel.

Le test à faire avant de brancher un serveur

Posez-vous une question avant chaque connexion : si ce jeton fuitait demain, qu’est-ce qu’on perdrait ? Si la réponse est « le site ou l’argent des clients », le jeton est trop large. Commencez par GitHub en lecture seule sur un seul dépôt, constatez ce que l’IA apporte, puis ouvrez le reste un droit à la fois.

Ce problème, Peechy s'en occupe

Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout, hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.

Confier mon site à Peechy