Les serveurs MCP locaux s’exécutent comme un processus sur votre propre machine, via stdio, tandis que les serveurs MCP distants se trouvent derrière un point d’accès HTTPS que toute personne de votre équipe peut joindre. Cet article compare installation, sécurité, latence, coût et mise à l’échelle pour vous aider à choisir le bon serveur pour votre agent d’IA.
Votre fichier de configuration d’agent IA demande une seule chose avant tout : le choix entre command et url. Cette ligne unique détermine où s’exécutent vos outils, qui peut les atteindre, ce qui se passe quand votre ordinateur portable se met en veille et qui paie la machine qui les fait tourner. Mal choisir, et vous devez surveiller une kyrielle de processus en arrière-plan, ou vous ouvrez à un serveur inconnu un accès à vos fichiers.
Le choix entre un serveur MCP local et un serveur MCP distant paraît technique, mais il porte en réalité sur la confiance, la distance et la propriété. Cet article présente le fonctionnement de chacun, les situations où chacun l’emporte, où chacun pose problème, et se termine par une courte liste de contrôle pour décider en cinq minutes plutôt qu’en cinq réunions.
💡 Réponse rapide : Utilisez un serveur local lorsque l’outil touche aux fichiers, aux shells ou aux données privées de votre machine. Utilisez un serveur distant lorsque plusieurs personnes, appareils ou agents ont besoin du même outil sans rien installer.
Le Model Context Protocol, ou MCP, est un standard ouvert qui permet à une application d’IA d’appeler des outils externes via une interface cohérente. Au lieu d’écrire un plugin spécifique pour chaque modèle et chaque application, un développeur écrit un seul serveur. Tout client compatible peut alors lister ses outils, les appeler et lire les résultats.
Trois rôles entrent en jeu. L’hôte est l’application que vous utilisez, comme un éditeur de code ou un assistant de discussion. À l’intérieur vit un client MCP, qui maintient une connexion un à un avec un serveur. Le serveur expose des outils (actions que le modèle peut demander), des ressources (données que le modèle peut lire) et des prompts (modèles réutilisables). Les messages circulent en JSON-RPC 2.0 : le trafic est donc du texte structuré et simple, quel que soit le chemin entre le point A et le point B.
C’est cette partie « comment il passe de A à B » qui résume tout le débat entre local et distant.
La spécification définit deux transports standard :
Les serveurs locaux utilisent presque toujours stdio. Les serveurs distants utilisent Streamable HTTP, qui a remplacé l’ancien transport HTTP plus SSE. Les outils eux-mêmes peuvent être identiques dans les deux cas. Seule l’infrastructure de communication change, et c’est elle qui détermine votre modèle de sécurité, votre latence et votre facture de maintenance.
Avec stdio, votre client lit un fichier de configuration, lance la commande que vous avez écrite et garde ce processus actif pendant toute la session. Les requêtes entrent par stdin, les réponses sortent par stdout, et les journaux vont sur stderr. Une sortie parasite envoyée sur stdout, par exemple via print, corrompt le flux du protocole, un bug classique du premier jour.
{
"mcpServers": {
"project-files": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/projects"]
}
}
}
Pas de port à ouvrir, pas de règle de pare-feu ni d’écran de connexion. Le processus hérite de vos droits d’utilisateur et de vos variables d’environnement, ce qui explique sa grande commodité et pourquoi il mérite réflexion.
Chaque coéquipier doit installer le runtime, figer la bonne version et copier la configuration. Mettez le serveur à jour et dix ordinateurs portables se désynchronisent. Chaque application cliente lance aussi son propre processus : trois éditeurs signifient trois copies qui tournent côte à côte. Et un serveur local meurt avec votre session, donc rien ne peut l’appeler quand votre ordinateur est fermé.
Le support est le coût caché. Quand un outil tombe en panne sur la machine d’une personne, vous déboguez une version de Node, un problème de PATH ou un paquet Python manquant, au lieu de l’outil lui-même.
Un serveur distant vit à une URL comme https://tools.example.com/mcp. Le client envoie les messages JSON-RPC sous forme de requêtes HTTP POST vers ce point d’accès unique. Le serveur répond soit par une réponse JSON classique, soit en ouvrant un flux Server-Sent Events lorsqu’il a des mises à jour de progression ou plusieurs messages à envoyer. Un en-tête de session permet au serveur de conserver un état entre les appels.
Pour en ajouter un, une seule commande suffit dans la plupart des clients :
claude mcp add --transport http notes https://tools.example.com/mcp
Comme le point d’accès est joignable depuis Internet, l’authentification passe de « qui est connecté sur cet ordinateur portable » à « qui détient un jeton valide ». Le flux d’autorisation de la spécification repose sur OAuth : l’utilisateur se connecte via le navigateur et le client stocke un jeton limité à certains droits et révocable.
Le connecteur de PicassoIA en est un bon exemple concret. C’est un serveur MCP distant qui expose des outils de génération d’images, d’édition d’images et de génération de vidéos. Les tâches sont asynchrones : un appel de génération renvoie aussitôt un identifiant de prédiction, et le client interroge le résultat à intervalles réguliers. Une limite partagée de cinq prédictions simultanées par compte s’applique à toutes les connexions, ce qui n’est possible que parce que l’état vit sur le serveur. Votre ordinateur portable n’a jamais besoin d’un GPU, d’un téléchargement de modèle ni d’un environnement Python.
Vous dépendez désormais de la disponibilité de quelqu’un d’autre et de votre propre connexion. Les allers-retours réseau ajoutent de la latence à chaque appel d’outil, et une poignée de main lente peut donner à un agent une impression de lenteur. Tout ce dont le serveur a besoin sur votre machine, comme un fichier local, n’est tout simplement pas là. L’hébergement implique des certificats TLS, de la supervision, des limites de débit et quelqu’un d’astreint. Et un point d’accès public est une cible : il exige une authentification solide dès le premier jour.
| Critère | Local (stdio) | Distant (Streamable HTTP) |
|---|---|---|
| Lieu d’exécution | Votre machine, sous forme de processus enfant | Un serveur hébergé derrière une URL |
| Installation par utilisateur | Installer un runtime et modifier la configuration | Coller une URL et se connecter |
| Mises à jour | Manuelles sur chaque machine | Déployées une seule fois |
| Réseau nécessaire | Non | Oui |
| Accès aux fichiers locaux | Direct | Aucun, sauf si vous les importez |
| Modèle d’authentification | Utilisateur du système et variables d’environnement | OAuth ou jetons bearer |
| Prise en charge multi-utilisateurs | Faible | Conçu pour cet usage |
| Surcoût de latence | Négligeable | Un aller-retour réseau par appel |
| Coût d’exploitation | Votre propre matériel | Hébergement plus maintenance |
| Panne typique | Le processus plante ou ne démarre pas | Indisponibilité, délai dépassé ou jeton expiré |
Aucune des deux options n’est automatiquement plus sûre. Un serveur local tourne avec vos droits : un paquet malveillant ou bogué peut donc lire vos fichiers et votre configuration SSH, et tout ce qui est tiré via npx ou uvx est du code que vous n’avez probablement pas audité. Un serveur distant garde ce code hors de votre machine, mais vous faites confiance à son exploitant pour tout ce que l’outil reçoit, et chaque requête transite par le réseau.
💡 Règle empirique : Traitez tout serveur MCP comme une extension de navigateur. Vérifiez qui l’a écrit, figez la version et n’accordez que les droits les plus restreints qui lui permettent de fonctionner.
Quelques points précis à mettre en place :
127.0.0.1 et validez l’en-tête Origin, sans quoi une page web ouverte dans votre navigateur peut les atteindre via un DNS rebinding.La couche stdio ne coûte presque rien. Un appel distant ajoute au moins un aller-retour réseau, qui peut représenter quelques millisecondes au sein d’une même région et quelques centaines entre continents, sans compter le TLS et les vérifications d’authentification éventuelles. En pratique, le travail propre de l’outil, comme une requête de base de données, un appel d’API ou un rendu d’image, éclipse le transport. La latence distante ne pose vraiment problème que pour les agents bavards qui enchaînent des dizaines de petits appels.
La fiabilité fonctionne dans l’autre sens. Un processus local échoue bruyamment et visiblement, généralement au démarrage. Un service distant peut échouer discrètement : jeton expiré, limite de débit, panne régionale. Prévoyez des nouvelles tentatives et rédigez des messages d’erreur sur lesquels un modèle peut agir.
Définissez des délais explicites des deux côtés. Un client qui attend indéfiniment un appel distant bloqué fige toute la conversation, tandis qu’un serveur qui abandonne trop tôt coupe les tâches longues légitimes, comme le rendu vidéo. Signalez la progression pour toute opération qui dure plus de quelques secondes.
Le local ne coûte rien en hébergement, mais il coûte du temps en support, et chaque ticket « ça marche sur ma machine » vous revient. Le distant coûte de l’argent et du travail d’exploitation, mais fait gagner du temps de support dès qu’une équipe est concernée. Le seuil de rentabilité se situe au moment où plus d’une poignée de personnes ont besoin du même serveur.
Une façon simple de l’estimer : comptez les personnes, multipliez les minutes que chacune passe chaque mois sur l’installation et le dépannage, puis comparez ce total à un petit forfait d’hébergement. Pour deux personnes, la voie locale l’emporte généralement. Pour vingt, c’est rarement le cas.
Optez pour le local lorsque vos outils touchent à vos propres ressources : un dépôt de code, un dossier de notes, une base de données locale, un navigateur que vous automatisez. Le local est aussi le meilleur terrain pour les prototypes, car vous pouvez modifier le serveur et le relancer en quelques secondes, sans pipeline de déploiement.
Optez pour le distant lorsqu’un outil appartient à l’équipe : systèmes de tickets, bases de connaissances internes, ressources de design partagées, données de facturation. L’authentification centralisée et les journaux d’audit comptent davantage que de grappiller quelques millisecondes. Le distant est aussi le seul choix lorsque le client ne peut pas lancer de processus, ce qui est le cas de la plupart des assistants web et des applications mobiles.
Déployez par étapes. Commencez par un serveur distant en lecture seule pour que chacun puisse l’essayer sans risque, ajoutez les outils d’écriture une fois que le journal d’audit semble sain, et gardez un interrupteur d’arrêt d’urgence qui révoque les jetons en une seule étape. Les équipes qui sautent cet ordre finissent généralement par découvrir leurs erreurs grâce à un message en colère plutôt qu’à un tableau de bord.
Répondez à ces questions dans l’ordre et arrêtez-vous à la première réponse « oui » :
Les projets réels choisissent rarement une seule option. Ces schémas reviennent sans cesse :
C’est dans un café à la connexion instable que l’hybride se révèle utile. Les outils de fichiers continuent de tourner localement pendant que les outils hébergés réessaient en arrière-plan, et rien de sensible ne quitte votre machine, sauf si vous en décidez autrement.
/Users/me/notes n’a aucun sens sur une machine dans le cloud. Si les données se trouvent sur votre ordinateur portable, le serveur doit être sur votre ordinateur portable.Quel que soit le transport choisi, le bénéfice est le même : un assistant d’IA qui fait un vrai travail pour vous au lieu de seulement en parler. Une connexion distante est le moyen le plus rapide de le ressentir, car il n’y a rien à installer et rien à faire tourner en permanence.
Commencez par les images. PicassoIA Image transforme un prompt en langage courant en image finie en quelques secondes, avec sept formats d’image, une seed verrouillable et aucune limite par image. Rédigez un prompt, générez quelques variations, puis modifiez un seul détail, comme l’objectif, la lumière ou l’angle de la caméra, et observez ce qui change. Cette petite boucle de prompt, résultat et ajustement est l’habitude qui rend chaque outil ultérieur, MCP ou non, plus facile à utiliser.
Si vous écrivez ou relisez vous-même du code de serveur, un modèle de code performant est utile. Claude Sonnet 5, GPT 5.6 Sol, Gemini 3.5 Flash et Kimi K2.6 sont tous disponibles sur PicassoIA, ce qui vous permet de comparer la façon dont chacun gère le même schéma d’outil.
Prêt à essayer ? Ouvrez PicassoIA, choisissez un modèle dans la liste complète des modèles et générez votre première image dès aujourd’hui.
Choisissez votre langue
