MCP pour WordPress

Définition

MCP pour WordPress : de quoi parle-t-on ?

MCP pour WordPress, c’est un serveur MCP rattaché au site, qui publie un catalogue d’actions et de données qu’un assistant peut appeler. L’assistant ne pilote pas un navigateur et ne rejoue pas vos clics : il appelle des fonctions déclarées, avec des paramètres typés, et reçoit une réponse structurée.

La différence avec un simple accès administrateur tient au périmètre : vous décidez, fonction par fonction, ce que l’assistant peut faire et sur quoi. Le mécanisme du protocole est traité sur la page serveurs MCP. Cette page porte uniquement sur ce que l’on branche côté WordPress, et sur ce qu’il vaut mieux laisser en dehors.

Les abilities WordPress exposées à une IA

Un serveur MCP WordPress expose en général quatre familles de capacités. Les contenus : articles, pages, types personnalisés, taxonomies. La médiathèque : téléversement, textes alternatifs, remplacement de fichiers. La structure : menus, hiérarchie des pages, permaliens. Enfin les données portées par les extensions : champs SEO, champs personnalisés, catalogue e-commerce.

Chaque capacité se déclare comme un outil doté d’un schéma d’entrée. Le nom et la description pèsent autant que le code : c’est sur eux que le modèle décide s’il doit appeler l’outil, et avec quels arguments. Écrivez-les comme une consigne à un prestataire qui découvre le site : ce que fait l’outil, sur quoi il agit, ce qu’il ne fait pas.

Les resources jouent un autre rôle : elles donnent à l’assistant de quoi se repérer avant d’agir (arborescence des pages, types de contenus, taxonomies disponibles). Sans elles, le modèle devine la structure du site et se trompe.

Ce que l’IA peut lire et ce qu’elle peut écrire sur le site

La lecture peut être large, l’écriture doit être découpée. Ouvrir en lecture les contenus publiés, les métadonnées et la structure fait gagner du temps en analyse pour un risque limité. L’écriture, elle, se fractionne en outils étroits ayant chacun un objet précis.

Un outil « mettre à jour la méta-description d’un contenu » se contrôle et se relit. Un outil « exécuter une requête sur la base » ne se contrôle pas. Deuxième garde-fou dans le même esprit : écrivez toujours par les fonctions natives de WordPress. Révisions, caches et hooks en dépendent, et une écriture en base vous prive de l’historique qui permet de revenir en arrière.

Cadre de sécurité

Sécurité, rôles utilisateur et bonnes pratiques

Créez un compte WordPress dédié à l’assistant, calé sur le rôle le plus faible qui permette la tâche visée. Ce compte n’est pas le vôtre : il doit être identifiable dans les journaux et révocable en une manipulation. Le tableau met en regard les périmètres courants et le niveau de droits correspondant.

Périmètre exposé	Ce que l’assistant peut faire	Niveau de droits adapté	Point de vigilance
Lecture des contenus publiés	Auditer, comparer, cartographier le maillage et les balises	Droits de lecture seule	Un filtre de statut mal posé laisse remonter brouillons et contenus privés
Rédaction de brouillons	Proposer des textes, des balises, des variantes sans les publier	Contributeur	Les brouillons s’accumulent et polluent la liste des contenus si rien ne les purge
Modification de contenus existants	Corriger, enrichir, réorganiser des pages déjà en ligne	Éditeur	Écrasement silencieux d’un contenu retravaillé à la main, à relire avant publication
Médiathèque	Téléverser des fichiers, renseigner les textes alternatifs	Auteur ou éditeur	Formats et poids non contrôlés, fichiers vectoriels à filtrer côté serveur
Réglages, extensions, comptes utilisateurs	Modifier la configuration du site et les droits d’accès	Administrateur, à éviter	Aucun retour arrière automatique, une commande mal interprétée peut rendre le site inaccessible

Trois périmètres restent fermés par défaut. La gestion des comptes et des rôles, où une élévation de privilèges passe inaperçue. L’installation et la mise à jour d’extensions, que l’assistant n’a aucun moyen d’évaluer. L’accès direct aux fichiers et à la base, auquel aucune révision ne s’applique.

Ajoutez une journalisation des appels : horodatage, outil appelé, objet touché. Sans ce registre, vous constaterez une modification sans pouvoir en identifier l’origine. Le réflexe vaut pour toute automatisation WordPress : ce qui écrit sans laisser de trace finit par coûter plus cher que le temps gagné.

Applications

Cas d’usage

• Créer un silo complet de pages avec structure Hn et maillage interne
• Mettre à jour les balises SEO Yoast d’un lot d’articles en une passe
• Auditer les contenus dupliqués, les liens cassés et les pages orphelines
• Générer des fiches produits WooCommerce à partir d’un fichier fournisseur

Vos questions

Questions fréquentes

Faut-il installer une extension pour utiliser MCP sur WordPress ?

Pas obligatoirement, mais du code doit exister quelque part : soit dans le site, sous forme d’extension ou de mu-plugin, soit à l’extérieur, en dialoguant avec WordPress par son API REST.

Le critère de choix est la profondeur d’accès. Du code hébergé par le site voit tout ce que WordPress voit, champs personnalisés compris. Une passerelle externe s’arrête à ce que l’API publie : si votre besoin porte sur des champs métier, elle vous bloquera vite.

MCP remplace-t-il l’API REST de WordPress ?

Non, il s’ajoute par-dessus et s’appuie souvent sur les mêmes fonctions. L’API REST reste la bonne réponse pour une application qui sait déjà quoi appeler. MCP sert à un modèle qui doit découvrir les actions disponibles et choisir laquelle utiliser.

Posez la comparaison avant de construire : exposer une API existante via MCP a un coût et n’a pas toujours d’intérêt. Ce point est développé sur la page MCP et API.

Quel rôle utilisateur attribuer à l’IA ?

Un compte dédié, avec le rôle le plus faible qui permette la tâche : lecture seule pour l’audit, contributeur pour la proposition de contenu, éditeur pour la correction en ligne. Le rôle administrateur ne se justifie que sur un environnement de test.

Le piège classique consiste à monter le rôle d’un cran parce qu’un appel a échoué. Identifiez plutôt la capacité manquante et ouvrez-la seule, dans un rôle sur mesure. Un rôle élargi dans l’urgence ne se resserre jamais.

MCP fonctionne-t-il avec Gutenberg et Elementor ?

Avec Gutenberg, oui : le contenu est stocké en balisage de blocs, donc lisible et modifiable par un outil qui respecte cette syntaxe. Avec Elementor, la mise en page vit dans des métadonnées sérialisées, ce qui impose des outils spécifiques.

Le piège est le même dans les deux cas : un outil qui réécrit le contenu sans en comprendre le format casse la mise en page. Vérifiez que la modification s’affiche correctement dans l’éditeur, pas seulement en base. Les usages plus larges de l’IA sur ce type de site sont détaillés sur IA et WordPress.