Trente sites clients, chacun avec son propre serveur MCP (Model Context Protocol) : c’est le premier scénario que nous avons envisagé quand un assistant IA interne a commencé à avoir besoin d’interroger l’état de plusieurs sites WordPress du parc — statut des mises à jour, dernières erreurs journalisées, contenu de certaines pages. Trente serveurs à déployer, surveiller et maintenir à jour, pour un protocole apparu en novembre 2024 et encore jeune. L’équation ne tenait pas.
Ce texte décrit l’architecture retenue à la place : une passerelle MCP unique, mutualisée pour l’ensemble du parc, qui route chaque requête vers le bon site sans exposer directement trente points d’entrée différents à l’assistant.
Pourquoi un serveur par site ne passait pas à l’échelle
Un serveur MCP par site présente un avantage réel : l’isolation est totale, un incident sur un serveur ne peut techniquement pas affecter un autre. Mais à l’échelle d’une agence gérant plusieurs dizaines de sites, ce modèle multiplie les points de défaillance à surveiller, les certificats à renouveler, et les versions du serveur à maintenir synchronisées. Une mise à jour du protocole MCP, encore actif dans ses évolutions fin 2025, aurait dû être répercutée trente fois plutôt qu’une.
L’autre argument, plus pragmatique : l’assistant IA que nous voulions outiller n’a besoin de dialoguer qu’avec un seul point d’entrée à la fois. Multiplier les serveurs ne lui apporte rien, cela complique seulement sa configuration côté client.
L’architecture retenue : une passerelle, un routeur, des connecteurs
La passerelle que nous avons construite se compose de trois couches distinctes :
assistant IA
|
v
passerelle MCP (authentification, routage)
|
+--> connecteur site A (WP-CLI via SSH)
+--> connecteur site B (WP-CLI via SSH)
+--> connecteur site C (API REST WordPress)La passerelle expose un unique serveur MCP à l’assistant. À la réception d’une requête, elle identifie le site cible à partir d’un identifiant transmis explicitement dans l’appel, vérifie les permissions associées au jeton d’authentification utilisé, puis délègue l’exécution au connecteur approprié pour ce site — soit une commande WP-CLI exécutée à distance via SSH, soit un appel à l’API REST WordPress du site concerné selon la nature de la ressource demandée.
Isoler les permissions site par site malgré la mutualisation
Le risque principal d’une passerelle unique est qu’une mauvaise configuration expose un site à des requêtes qui ne le concernent pas. Nous avons traité ce risque en attribuant un jeton d’authentification distinct par contexte d’usage, chaque jeton étant associé explicitement à une liste de sites autorisés et à un ensemble de capacités permises :
- Un jeton « lecture seule » limité aux statuts de mise à jour et aux journaux d’erreurs
- Un jeton « support niveau 1 » autorisant en plus la consultation de contenus publiés
- Un jeton « intervention technique » réservé à l’équipe interne, seul à autoriser des actions d’écriture
Cette segmentation reproduit, côté MCP, une logique de permissions déjà familière dans la gestion des accès WordPress classiques, mais appliquée à un protocole conçu pour dialoguer avec des assistants plutôt qu’avec des humains.
Ce que la passerelle ne fait volontairement pas
La passerelle ne conserve aucun historique persistant des requêtes au-delà des journaux techniques nécessaires au débogage, et elle n’exécute jamais directement de commande d’écriture sans confirmation explicite passée dans la requête elle-même. Ce choix limite certains scénarios d’automatisation ambitieux, mais il réduit considérablement la surface d’incident possible sur un parc client sensible.
Les limites rencontrées pendant les six premières semaines
Deux difficultés sont apparues rapidement. La première : certains connecteurs basés sur SSH souffraient de latences importantes sur les sites hébergés à l’étranger, ce qui ralentissait les réponses de l’assistant au-delà d’un délai acceptable pour un usage interactif. La seconde : la gestion des erreurs remontées par WP-CLI n’était pas toujours structurée de façon exploitable automatiquement, ce qui a nécessité une couche de normalisation supplémentaire côté connecteur.
En résumé
Mutualiser un serveur MCP pour l’ensemble d’un parc d’agence évite la multiplication de points d’entrée difficiles à maintenir, à condition de traiter sérieusement l’isolation des permissions par jeton plutôt que de s’appuyer sur la seule séparation physique des serveurs. Un an après le lancement du protocole, cette architecture reste évolutive et devra sans doute être revue quand l’écosystème MCP se stabilisera davantage.
