Jusqu’ici, la plupart de nos articles sur MCP décrivaient WordPress comme fournisseur : un serveur exposant des outils que des agents externes viennent consulter. Un projet client récent nous a confrontés à l’architecture inverse, moins documentée : WordPress devient client MCP, capable depuis son administration d’appeler des outils exposés par des serveurs tiers, un service de traduction, un outil de vérification de stock fournisseur, ou un assistant de veille concurrentielle. Cet article ne traite pas de l’exposition de WordPress en serveur MCP, déjà couverte séparément : ici, le sens du flux s’inverse entièrement.
Le schéma général de cette architecture
Administration WordPress
|
|-- Interface d'administration (écran dédié « Outils IA »)
|
|-- Client MCP intégré (bibliothèque cliente, pas serveur)
| |
| |-- Connexion 1 : serveur MCP de traduction (tiers)
| |-- Connexion 2 : serveur MCP de suivi de stock fournisseur (tiers)
| +-- Connexion 3 : serveur MCP de veille concurrentielle (tiers)
|
+-- Annuaire local des serveurs autorisés
(URL, jeton, périmètre, statut d'activation)
Dans ce schéma, l’administrateur du site active ou désactive chaque connexion externe depuis un écran dédié, WordPress jouant le rôle de client qui découvre les outils disponibles sur chaque serveur connecté, puis les propose comme actions possibles depuis l’interface d’administration, par exemple un bouton « Traduire cette page » qui appelle en coulisses l’outil exposé par le serveur MCP de traduction tiers.
Les cas d’usage qui justifient cette inversion
Le cas le plus parlant sur notre projet concerne la vérification de stock en temps réel auprès d’un fournisseur qui expose désormais ses données via un serveur MCP plutôt qu’une API REST classique documentée séparément. Plutôt que d’écrire une intégration REST maison à maintenir, WordPress se connecte directement au serveur MCP du fournisseur, découvre automatiquement les outils disponibles, et les expose à l’équipe commerciale sous forme de bouton dans l’administration des produits WooCommerce.
La sécurité, sujet central de cette architecture
Chaque serveur MCP externe connecté à l’administration élargit la surface de confiance du site : un serveur tiers compromis ou mal intentionné pourrait renvoyer des données malveillantes ou des instructions déguisées dans ses réponses, un risque connu sous le nom d’injection indirecte lorsqu’un agent traite sans discernement le contenu renvoyé par un outil externe comme s’il s’agissait d’instructions légitimes. Nous n’autorisons jamais qu’une réponse issue d’un serveur MCP tiers déclenche une action sensible sans validation humaine explicite, quelle que soit la confiance accordée au fournisseur du serveur.
L’annuaire de serveurs autorisés
Concrètement, l’administration ne permet pas à un utilisateur de connecter n’importe quelle URL de serveur MCP à la volée : une liste blanche de serveurs autorisés, gérée par un rôle d’administrateur technique, définit précisément quels serveurs peuvent être ajoutés, avec quel périmètre de droits. Cette liste blanche s’est révélée indispensable après qu’un test en environnement de recette a montré qu’un utilisateur avec des droits d’édition simples pouvait, sans cette restriction, connecter n’importe quel serveur externe de son choix.
Les limites actuelles de cette approche
Le principal frein reste la maturité inégale des serveurs MCP tiers disponibls dans certains secteurs, beaucoup de fournisseurs continuant à privilégier une API REST classique plus établie, MCP restant un ajout récent dans leur offre. Nous recommandons cette architecture uniquement quand le fournisseur maintient réellement son serveur MCP à jour, avec une documentation claire de ses outils, plutôt que par simple attrait pour la nouveauté du protocole.
- Un annuaire de serveurs autorisés géré par un rôle technique restreint, jamais une connexion libre
- Aucune action sensible déclenchée automatiquement à partir d’une réponse d’un serveur tiers
- Une vérification régulière que les serveurs tiers connectés restent réellement maintenus
- Une préférence pour cette architecture uniquement quand elle simplifie réellement une intégration existante
Faire de WordPress un client plutôt qu’un serveur ne réduit pas les enjeux de sécurité, cela les déplace vers la confiance accordée à chaque service externe connecté.
En résumé
L’architecture cliente reste une option récente et encore peu répandue dans l’écosystème WordPress, mais elle répond à un besoin réel quand des partenaires ou fournisseurs exposent eux-mêmes leurs outils via MCP. La vigilance doit alors se déplacer du contrôle des outils exposés vers le contrôle des serveurs externes autorisés à se connecter, un exercice de confiance qui mérite autant de rigueur que la sécurisation d’un serveur MCP WordPress classique.
