Une semaine. C’est l’âge du Model Context Protocol au moment d’écrire ces lignes, un protocole ouvert publié il y a quelques jours pour standardiser la façon dont un agent conversationnel découvre et appelle des outils externes, qu’il s’agisse d’une base de données, d’un système de fichiers ou d’une API tierce. Rien, à ce stade, ne relie officiellement ce protocole à WordPress, mais la question mérite d’être posée dès maintenant tant l’écosystème des extensions évolue vite dès qu’un standard de ce type émerge.
Cet article ne décrit pas l’implémentation d’un serveur MCP, sujet encore prématuré faute d’exemples matures à observer sur l’écosystème WordPress. Il pose les bases du protocole, ce qu’il change concrètement par rapport aux approches déjà connues, et pourquoi il serait imprudent d’investir dès aujourd’hui du temps de développement dessus sans en comprendre d’abord les fondations.
Le problème que MCP cherche à résoudre
Avant ce protocole, chaque intégration entre un modèle de langage et un outil externe se construisait sur mesure : un développeur définissait ses propres schémas de fonctions, sa propre logique d’authentification, sa propre gestion des erreurs. Cette approche fonctionne, mais elle ne se réutilise pas d’un projet à l’autre : un connecteur écrit pour un assistant donné ne s’adapte pas automatiquement à un autre client conversationnel.
MCP propose un langage commun : un serveur MCP expose une liste d’outils, de ressources et de prompts selon un format standardisé, qu’un client MCP peut découvrir et appeler sans connaître à l’avance les détails de l’implémentation. En théorie, un même serveur MCP pourrait ainsi être branché sur plusieurs clients différents, sans réécriture, du moment que ces clients respectent la même spécification.
Ce que cela pourrait signifier pour WordPress
Un site WordPress héberge une quantité d’informations et d’actions qu’un agent pourrait vouloir consulter ou déclencher : lire le contenu d’un article, créer un brouillon, lister les commentaires en attente de modération, interroger le statut d’une commande WooCommerce. Un serveur MCP dédié à WordPress pourrait, en théorie, exposer ces capacités de façon standardisée, ouvrant la porte à des agents capables d’agir sur un site sans passer par une intégration développée au cas par cas pour chaque assistant.
Ce potentiel reste, à ce jour, entièrement théorique du point de vue de l’écosystème WordPress : aucune extension officielle ni communautaire connue ne propose actuellement d’implémentation de ce protocole pour le CMS. La spécification elle-même vient de sortir et continuera vraisemblablement d’évoluer dans les prochains mois, ce qui rend prématurée toute tentative de construire une intégration WordPress dessus avant d’avoir observé sa stabilisation.
Pourquoi il est trop tôt pour tout miser dessus
- La spécification n’a pas encore fait ses preuves à grande échelle et pourrait évoluer sur des points structurants.
- Aucun retour d’expérience concret n’existe encore sur les questions de sécurité et d’authentification propres à un serveur MCP exposé publiquement.
- L’écosystème des clients compatibles reste restreint, limitant l’intérêt pratique immédiat d’un serveur MCP pour WordPress.
Ce qu’un développeur WordPress peut faire dès maintenant
Sans se précipiter sur une implémentation, comprendre les concepts du protocole permet d’anticiper les choix d’architecture à venir : la notion d’outil exposé avec un schéma de paramètres, proche de ce que propose déjà le function calling de plusieurs fournisseurs de modèles, et la notion de ressource, qui distingue une donnée consultable d’une action déclenchable. Ces deux notions structureront vraisemblablement les futures intégrations, quelle que soit la forme exacte qu’elles prendront sur WordPress.
Suivre l’apparition d’un nouveau standard ne signifie pas se précipiter pour l’adopter avant qu’il n’ait fait ses preuves : cela signifie comprendre son principe assez tôt pour ne pas être pris au dépourvu quand il deviendra pertinent.
Ce que cet article ne traite pas
L’implémentation technique d’un serveur MCP, avec son code, son authentification et son déploiement, sort volontairement du périmètre de ce premier tour d’horizon. Le sujet mérite un article à part entière, une fois que des exemples concrets et éprouvés seront disponibles à observer.
En résumé
MCP propose une idée séduisante : un langage commun entre les agents et les outils qu’ils manipulent. Pour WordPress, cette idée reste à ce stade une direction à surveiller plutôt qu’un chantier à ouvrir immédiatement. La prudence, ici, consiste à comprendre le principe avant de se demander comment l’implémenter.
