Configurer un MCP server ne consiste pas seulement à indiquer son adresse ou la commande permettant de le démarrer.
Deux décisions distinctes doivent être prises :
- Quel transport utiliser ?
- Quel scope donner à la configuration ?
Ces deux dimensions sont indépendantes, mais leur combinaison détermine si l’intégration correspond réellement au scénario de déploiement.
Un outil SQLite utilisé uniquement sur le poste d’un développeur, un service de recherche de code partagé par toute une équipe et un serveur de sécurité imposé à toute l’organisation n’ont pas les mêmes besoins.
Le principe à retenir est :
Transport and scope are independent decisions with dependent consequences.
Voyons comment raisonner.
MCP : rappeler le rôle du protocole
MCP — Model Context Protocol — fournit une couche de communication permettant à un MCP client, comme Claude Code, de se connecter à un MCP server.
Le serveur peut notamment exposer :
- des tools ;
- des resources ;
- des prompts.
Le protocole permet au client de découvrir les capacités proposées par le serveur et d’interagir avec elles.
L’un des intérêts de cette architecture est de sortir la définition et la maintenance des tools du code spécifique de chaque application.
On obtient une architecture de ce type :
Claude Code
│
│ MCP client
▼
Model Context Protocol
│
▼
MCP server
│
├── tools
├── resources
└── prompts
Mais pour établir cette communication, il faut déterminer comment le MCP server est exécuté ou rejoint.
C’est le rôle du transport.
Première décision : le MCP transport
Le fichier source distingue principalement deux situations :
- un serveur qui s’exécute sur la machine locale ;
- un serveur hébergé à distance.
Cela conduit à deux grandes approches.
stdio : pour un serveur exécuté localement
stdio est adapté aux MCP servers exécutés directement sur la machine du développeur.
Le schéma conceptuel est :
Claude Code
│
│ stdio
▼
MCP server local
│
▼
ressource locale
Le client démarre ou communique avec un processus local.
C’est particulièrement logique lorsqu’un tool dépend directement des ressources présentes sur la machine.
Par exemple :
Claude Code
↓
MCP server SQLite local
↓
base SQLite locale
Il n’est pas nécessaire de déployer un service HTTP partagé pour une intégration utilisée uniquement sur un poste de développement.
HTTP : pour un MCP server distant
Lorsqu’un MCP server est hébergé sur une infrastructure distante, HTTP devient le choix approprié.
Par exemple :
Développeur A ─┐
│
Développeur B ─┼── HTTP ──► MCP server
│
Développeur C ─┘
Le serveur peut alors être hébergé sur l’infrastructure de l’entreprise.
C’est notamment adapté aux services utilisés par plusieurs développeurs.
Le document résume cette distinction ainsi :
MCP server sur la machine
↓
stdio
MCP server distant / partagé
↓
HTTP
Transport : la question à poser
Pour choisir le transport, la question fondamentale est :
Où s’exécute le MCP server ?
Si le serveur fonctionne localement sur la machine, stdio est généralement cohérent avec ce scénario.
S’il est hébergé à distance ou doit être accessible par plusieurs développeurs, HTTP correspond au modèle présenté dans le module.
Mais cela ne répond pas encore à une deuxième question :
Qui doit disposer de cette configuration ?
C’est là qu’intervient le scope.
Deuxième décision : le scope
Le scope détermine la portée de la configuration MCP.
Le document distingue notamment :
- Local ;
- Project ;
- Enterprise.
Ces scopes correspondent à des besoins de distribution différents.
Local : une configuration personnelle
Le scope Local correspond à une configuration destinée à un développeur particulier.
Elle n’a pas vocation à être distribuée automatiquement avec le repository.
C’est le choix naturel pour :
- un outil personnel ;
- une expérimentation ;
- un serveur spécifique au poste ;
- une intégration qui n’est pas prête à être partagée.
Le modèle est :
Développeur
│
▼
Configuration Local
│
▼
MCP server
Les autres membres de l’équipe ne récupèrent pas automatiquement cette configuration.
Project : partager la configuration avec le repository
Lorsqu’un MCP server doit faire partie du setup d’un projet, la configuration peut être placée au niveau Project, notamment via .mcp.json.
On obtient :
Repository
│
├── code
├── CLAUDE.md
└── .mcp.json
│
▼
configuration MCP
Lorsqu’un autre développeur récupère le projet, il dispose également de la configuration MCP partagée.
C’est utile lorsqu’un serveur fait réellement partie de l’environnement de développement du projet.
Mais attention :
Partager la configuration ne signifie pas partager les credentials.
Comme vu dans l’article précédent, .mcp.json peut contenir une référence à une environment variable, mais ne doit pas embarquer directement la valeur d’une API key.
Par exemple :
{
"type": "http",
"url": "https://warehouse.internal/mcp",
"headers": {
"Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}"
}
}
Le fichier est partageable.
Le secret reste séparé.
Enterprise : une configuration administrée par l’organisation
Le troisième cas concerne les intégrations qui doivent être déployées ou contrôlées au niveau de l’organisation.
Le document associe ce scénario aux enterprise managed settings.
Le principe devient :
Administrateur / IT
│
▼
Enterprise managed settings
│
├── développeur A
├── développeur B
├── développeur C
└── développeur D
Cette approche est particulièrement importante lorsqu’une organisation doit garantir que la même configuration est appliquée à tous les développeurs.
Elle permet également de répondre à une problématique de sécurité :
Un développeur individuel ne doit pas nécessairement pouvoir modifier ou contourner certaines configurations imposées par l’organisation.
C’est particulièrement pertinent dans les environnements réglementés.
Transport et scope : ne pas les confondre
Une erreur fréquente consiste à considérer transport et scope comme une seule décision.
Ce n’est pas le cas.
Le transport répond à :
Comment communique-t-on avec le serveur ?
Le scope répond à :
À qui cette configuration s’applique-t-elle ?
On peut donc raisonner selon deux axes :
| Dimension | Question |
|---|---|
| Transport | Comment le MCP client atteint-il le serveur ? |
| Scope | Qui doit recevoir/utiliser cette configuration ? |
Cette séparation conceptuelle est importante pour analyser les scénarios MCP.
Cas 1 : SQLite local
Prenons le premier scénario du module :
Un outil de requête SQLite local que vous utilisez uniquement sur votre machine de développement.
Deux éléments sont importants.
Où tourne le serveur ?
Localement.
Qui doit l’utiliser ?
Uniquement le développeur concerné.
Le choix correspondant est donc :
Transport : stdio
Scope : Local
Soit :
stdio + Local
C’est la combinaison la plus simple correspondant au besoin.
Cas 2 : service de recherche de code partagé
Deuxième scénario :
Un service de recherche de code hébergé sur l’infrastructure de l’entreprise et auquel toute l’équipe d’ingénierie doit accéder.
Cette fois :
Où tourne le serveur ?
Sur une infrastructure distante.
Donc :
HTTP
Qui doit recevoir la configuration ?
Toute l’équipe travaillant sur le projet.
Une configuration Project peut donc être utilisée via .mcp.json.
Le choix attendu est :
HTTP + Project (.mcp.json)
L’architecture devient :
Repository
│
└── .mcp.json
│
│ HTTP
▼
Code Search MCP server
▲
infrastructure
entreprise
Chaque développeur récupère la configuration avec le projet et rejoint le même service distant.
Cas 3 : serveur expérimental de web scraping
Troisième scénario :
Un serveur expérimental de web scraping testé pendant une semaine sur un repository précis et qui n’est pas encore prêt à être partagé.
Le mot important ici est :
expérimental.
Même si l’expérimentation concerne un repository précis, elle n’est pas prête à devenir une configuration partagée du projet.
Le scope doit donc rester :
Local
Le fichier source propose ici :
stdio or HTTP + Local
Pourquoi les deux transports peuvent-ils être possibles ?
Parce que le scénario définit surtout la portée de la configuration : elle doit rester personnelle.
Le serveur expérimental pourrait être exécuté localement ou être accessible à distance.
Le transport dépend donc de son mode d’hébergement.
Mais son scope reste Local.
C’est un bon exemple montrant que transport et scope sont réellement deux décisions indépendantes.
Cas 4 : serveur de security scanning imposé à toute l’organisation
Dernier scénario :
Un security-scanning server que l’équipe IT doit déployer sur toutes les installations Claude Code des développeurs.
Ici, deux indices sont essentiels :
- le serveur est destiné à toute l’organisation ;
- son déploiement est contrôlé par l’IT.
Le scope Project n’est plus suffisant.
Il faut un contrôle organisationnel.
La combinaison proposée est :
HTTP + Enterprise (managed settings)
On obtient :
IT
│
▼
Enterprise configuration
│
┌───────────┼───────────┐
▼ ▼ ▼
Dev A Dev B Dev C
\ | /
\ | /
└────── HTTP ───────┘
│
▼
Security MCP server
L’organisation contrôle ainsi le déploiement de la configuration.
Tableau récapitulatif
Les quatre scénarios du module donnent une bonne grille de décision :
| Scénario | Transport | Scope |
|---|---|---|
| SQLite personnel | stdio | Local |
| Code search partagé par l’équipe | HTTP | Project |
| Web scraper expérimental | stdio ou HTTP | Local |
| Security scanner imposé par l’IT | HTTP | Enterprise |
Le raisonnement compte davantage que la mémorisation du tableau.
Il faut toujours poser séparément les deux questions :
1. Où tourne le serveur ?
2. Qui doit disposer de la configuration ?
Le piège : stdio dans une configuration partagée
Le document attire particulièrement l’attention sur une combinaison trompeuse.
Un serveur stdio peut être référencé dans une configuration partagée.
Sur le papier, le fichier est bien partagé.
Mais cela ne signifie pas que le serveur lui-même est portable.
Pourquoi ?
Parce que stdio suppose qu’un processus puisse être exécuté sur la machine concernée.
Il faut donc que chaque développeur possède :
- le programme ;
- ses dépendances ;
- les chemins nécessaires ;
- la configuration locale correspondante.
Le module formule le problème ainsi :
A stdio server in
.mcp.jsonis a configuration that looks shareable but is not.
Autrement dit :
Configuration partageable
≠
Serveur réellement portable
C’est un point important pour la conception d’un setup d’équipe.
Le lien avec la portabilité
Cette question rejoint un autre principe du module :
A shareable setup requires portable components.
Prenons un MCP server ou un Skill qui dépend d’un chemin comme :
/Users/priya/scripts/validate-migration.sh
La configuration peut parfaitement être commitée.
Mais elle ne fonctionnera que sur la machine disposant de ce chemin.
Chez un autre développeur :
/Users/priya/...
n’existe pas.
La configuration est donc partagée, mais pas réellement portable.
Éviter les chemins absolus spécifiques à une machine
Les composants destinés à être distribués doivent éviter les hypothèses propres à l’environnement de leur auteur.
Cela concerne notamment :
- les Skills ;
- les hooks ;
- les configurations MCP ;
- les composants de plugins.
Les chemins doivent être conçus de manière portable, notamment relativement au projet lorsque cela correspond au besoin.
De même, les variables d’environnement nécessaires doivent être :
- documentées ;
- ou validées lors de l’installation.
Tester depuis une machine propre
Le document recommande une pratique simple mais importante :
Tester l’installation depuis une machine propre avant de distribuer le setup.
Pourquoi ?
Parce qu’une machine de développement contient souvent des dépendances implicites accumulées au fil du temps.
Par exemple :
Machine auteur
│
├── script installé manuellement
├── variable d'environnement existante
├── package global
└── chemin spécifique
Le développeur peut ne plus se rendre compte que son intégration dépend de ces éléments.
Un test depuis un environnement propre permet de révéler ces dépendances cachées.
Transport, scope et authentification
Une fois le transport et le scope choisis, une autre question apparaît pour les serveurs distants :
Comment le client s’authentifie-t-il ?
Par exemple :
Claude Code
│
│ HTTP
▼
MCP server distant
│
└── authentification requise
Le mécanisme dépend alors du modèle d’identité du service.
Le fichier distingue notamment :
Remote + user identity
↓
OAuth
Remote + service identity
↓
API key via environment variable
Le choix du transport ne détermine donc pas à lui seul le mécanisme d’authentification.
Il faut analyser séparément :
Transport
+
Scope
+
Identity
+
Authentication
Une méthode de raisonnement en quatre questions
Pour un scénario MCP, on peut appliquer la grille suivante.
1. Où s’exécute le MCP server ?
Localement ?
→ envisager stdio.
À distance ?
→ envisager HTTP.
2. Qui doit utiliser cette configuration ?
Une seule personne ?
→ Local.
L’équipe travaillant sur le repository ?
→ Project.
Toute l’organisation avec contrôle administratif ?
→ Enterprise managed settings.
3. Quelle identité accède au service ?
Utilisateur individuel ?
→ modèle d’authentification utilisateur.
Service technique ?
→ service identity.
Ressource locale ?
→ permissions locales adaptées.
4. La configuration est-elle réellement portable ?
Vérifier :
- chemins ;
- dépendances ;
- variables d’environnement ;
- credentials ;
- hypothèses liées à la machine.
Cette quatrième question évite qu’une configuration théoriquement partageable échoue dès son installation chez un autre développeur.
Ce qu’il faut retenir pour la certification
stdio ou HTTP ?
Demandez d’abord :
Où s’exécute le MCP server ?
Local → stdio.
Remote / partagé → HTTP dans les scénarios présentés dans ce module.
Local ou Project ?
Demandez :
Cette configuration doit-elle voyager avec le repository ?
Si non → Local.
Si elle constitue une configuration partagée du projet → Project via .mcp.json.
Quand utiliser Enterprise ?
Lorsque la configuration doit être déployée et contrôlée par l’organisation plutôt que laissée à chaque développeur.
.mcp.json rend-il automatiquement un serveur partageable ?
Non.
Il rend la configuration partageable.
Le serveur et ses dépendances doivent eux aussi être portables.
Peut-on mettre une API key dans .mcp.json parce que le fichier est réservé à l’équipe ?
Non.
Un credential ne doit pas voyager avec la configuration.
Utilisez une référence vers une environment variable ou un mécanisme approprié de gestion des secrets.
Piège d’examen
Imaginez la question suivante :
Une entreprise possède un MCP server de security scanning hébergé sur son infrastructure. L’équipe IT veut que tous les développeurs utilisent cette configuration et qu’ils ne puissent pas modifier individuellement le setup de sécurité. Quelle architecture correspond le mieux au besoin ?
Les éléments importants sont :
serveur distant
↓
HTTP
déploiement organisationnel
↓
Enterprise managed settings
La réponse cohérente avec le module est donc :
HTTP + Enterprise managed settings
Choisir simplement Project parce que plusieurs développeurs doivent utiliser le serveur manquerait l’exigence essentielle :
la configuration doit être administrée et contrôlée au niveau de l’organisation.
Conclusion
Transport et scope répondent à deux problèmes différents.
Le transport répond à :
Comment Claude Code communique-t-il avec le MCP server ?
Le scope répond à :
À qui cette configuration doit-elle être distribuée ?
Le modèle à retenir est :
MCP SERVER
│
┌────────┴────────┐
│ │
local distant
│ │
stdio HTTP
CONFIGURATION
│
┌──────────┼──────────┐
│ │ │
Local Project Enterprise
Il faut ensuite ajouter les autres dimensions :
Transport
+
Scope
+
Authentication
+
Secrets
+
Portability
+
Security controls
C’est l’ensemble de ces décisions qui transforme une connexion MCP fonctionnelle en une intégration réellement adaptée à son environnement de déploiement.
Dans la suite de la série
Authentifier Claude et MCP dans un environnement d’entreprise
Nous verrons comment choisir entre OAuth, service credentials et file-system permissions, pourquoi l’identité utilisée par Claude doit être pensée dès la conception de l’intégration, et comment les exigences changent lorsque l’on passe d’un prototype à un environnement enterprise.
