Comment un assistant conversationnel pourrait-il consulter la liste des templates d’un Site Editor sans qu’un humain n’ouvre l’administration ? C’est la question de départ de ce test, mené sur un site vitrine servant de bac à sable, plusieurs mois avant que l’écosystème WordPress ne commence à discuter sérieusement d’une intégration native du protocole.
Le Model Context Protocol, publié fin 2024, standardise la manière dont un assistant IA découvre et appelle des outils externes. Il ne fait alors l’objet d’aucune intégration officielle dans WordPress : ce test s’appuie sur un petit serveur Node.js indépendant, qui interroge l’API REST de WordPress en coulisses et traduit les résultats au format attendu par le protocole.
Architecture retenue : un serveur intermédiaire, pas un plugin
Plutôt que de développer un plugin PHP exposant directement des points de terminaison compatibles MCP, le choix s’est porté sur un serveur Node.js séparé, utilisant le kit de développement officiel du protocole. Ce serveur agit comme une passerelle : il reçoit les requêtes de l’assistant IA au format MCP, les traduit en appels à l’API REST de WordPress (/wp-json/wp/v2/templates, /wp-json/wp/v2/blocks), puis reformate les réponses.
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
const serveur = new McpServer({ name: 'wp-site-editor-bridge', version: '0.1.0' });
serveur.tool('lister_templates', 'Liste les templates du Site Editor actif', {}, async () => {
const reponse = await fetch('https://site-bac-a-sable.example/wp-json/wp/v2/templates', {
headers: { Authorization: 'Bearer ' + process.env.WP_JETON_APPLICATION },
});
const templates = await reponse.json();
return {
content: [{ type: 'text', text: JSON.stringify(templates.map(t => t.slug)) }],
};
});L’authentification, un point qui a demandé le plus de prudence
Le jeton d’authentification utilisé n’est pas un compte administrateur complet, mais un mot de passe d’application WordPress généré spécifiquement pour ce serveur, associé à un compte disposant uniquement des droits de lecture sur les templates. Cette précaution a semblé indispensable dès le départ : un serveur intermédiaire expérimental, encore instable, ne devait en aucun cas détenir des droits d’écriture sur le site pendant la phase de test.
Ce que le serveur expose, et ce qu’il n’expose pas
Deux outils seulement ont été déclarés pour ce premier essai :
lister_templates, qui retourne la liste des slugs de templates du thème actif.lire_pattern, qui retourne le contenu HTML brut d’un pattern donné, identifié par son nom.
Aucun outil d’écriture n’a été implémenté à ce stade. L’objectif du test était de vérifier la faisabilité de la lecture avant d’envisager toute action de modification, jugée nettement plus risquée tant que le comportement de l’assistant appelant n’est pas parfaitement prévisible.
Premiers résultats, avec un assistant compatible en client
Connecté à un client compatible MCP en local, le serveur a permis à l’assistant de répondre correctement à des questions du type « quels templates existent sur ce site ? » ou « que contient le pattern d’en-tête ? », en s’appuyant sur les données réelles du site plutôt que sur une supposition générique. La latence ajoutée par le relais Node.js reste négligeable, l’essentiel du temps de réponse provenant de l’appel REST vers WordPress lui-même.
Une limite attendue : pas de contexte visuel
L’assistant reçoit le contenu HTML brut des patterns, mais aucune capture d’écran ni rendu visuel. Il peut donc décrire la structure d’un pattern, mais pas juger de son rendu réel sans une étape supplémentaire de génération de capture, non implémentée dans ce premier essai.
Sur ce genre de test, la vraie question n’est pas de savoir si l’assistant peut techniquement lire les données du site, mais de savoir précisément ce qu’on est prêt à lui laisser lire, et avec quels droits.
Ce que cette expérimentation ne couvre pas
Ce test ne s’appuie sur aucune Abilities API native, qui n’existe pas encore à ce stade dans le cœur de WordPress, et ne cherche pas non plus à faire générer du code par l’assistant : il se limite strictement à l’exposition en lecture de données existantes. Ces deux prolongements naturels feront l’objet d’essais séparés une fois l’architecture de base validée.
En résumé
Construire un pont MCP indépendant du cœur WordPress reste, à ce stade, la voie la plus réaliste pour expérimenter sans attendre une intégration officielle. Le principal enseignement de ce premier essai tient dans la prudence nécessaire sur les droits accordés au serveur intermédiaire : mieux vaut un outil limité et sûr qu’un outil complet et risqué. La spécification du protocole reste consultable sur le dépôt GitHub officiel du Model Context Protocol.
