Le Model Context Protocol (MCP) devient rapidement le « connecteur universel » qui permet aux agents d’IA d’appeler de vrais outils au lieu de simplement générer du texte. Pour l’automatisation de WordPress, cela compte parce que les tâches les plus précieuses , audit de contenu, surveillance des performances, vérification des paramètres et coordination des flux de travail , dépendent d’un accès structuré aux données et aux actions du site.
Aujourd’hui, MCP remodèle la façon dont les sites WordPress peuvent être interrogés et exploités par des assistants IA comme Claude Desktop, les agents basés sur VS Code et Cursor. Avec des acteurs comme WordPress.com et Automattic qui livrent des composants natifs MCP, le chemin qui va de la « demande » à « l’automatisation » devient plus court, plus sûr et plus standardisé.
1) Ce que MCP change pour l’automatisation de WordPress
MCP est un protocole qui standardise la manière dont un agent d’IA découvre des « outils » et les invoque avec des entrées et sorties structurées. Au lieu de plugins ponctuels ou d’un scraping fragile, l’agent peut demander des capacités spécifiques (comme « rechercher des articles » ou « obtenir les statistiques du site ») via une interface cohérente.
C’est particulièrement pertinent pour l’automatisation de WordPress, car les environnements WordPress varient : sites hébergés sur WordPress.com, installations WordPress auto‑hébergées et boutiques WooCommerce exposent souvent des API et des schémas d’authentification différents. MCP vise à réduire cette fragmentation en offrant aux agents un mode de connexion prévisible.
On observe également un mouvement du secteur vers l’interopérabilité. MCP serait en cours d’intégration dans une initiative de normalisation neutre au sein de l’AI and Agent Interoperability Framework (AAIF) de la Linux Foundation, ce qui renforce l’idée que les connexions agent‑outil deviennent une norme partagée plutôt qu’un mécanisme d’enfermement propriétaire.
2) Le serveur MCP intégré de WordPress.com : une voie hébergée vers l’accès à l’IA
WordPress.com inclut désormais un serveur MCP intégré, permettant aux agents d’IA compatibles MCP, notamment Claude Desktop, VS Code et Cursor, d’interroger des sites WordPress.com en langage naturel. La documentation officielle précise : « WordPress.com inclut un serveur MCP (Model Context Protocol) intégré », le positionnant comme une fonctionnalité de premier plan plutôt qu’une intégration additionnelle.
La disponibilité est liée aux offres payantes de WordPress.com. Selon la documentation, MCP « est disponible sur toutes les offres payantes de WordPress.com », ce qui rend chaque site sous abonnement « prêt pour MCP » du point de vue de l’hébergement, une fois activé par l’utilisateur.
Pour connecter un agent d’IA depuis votre environnement local, WordPress.com utilise une approche de proxy local : vous exécutez mcp-wpcom-remote, qui requiert Node.js version 22.0 ou ultérieure. Cette conception conserve pour les développeurs un flux de connexion familier à l’agent tout en s’appuyant, en arrière‑plan, sur le point de terminaison MCP hébergé par WordPress.com.
3) Permissions, confidentialité et sécurité basée sur les rôles sur WordPress.com
L’automatisation fondée sur des outils n’est digne de confiance que dans la mesure où l’est son modèle d’autorisations. WordPress.com décrit un flux d’autorisations explicite où l’agent d’IA demande l’accès avant d’émettre des requêtes MCP, offrant à l’utilisateur un moment clair pour approuver ce que l’agent peut faire.
La confidentialité est également abordée directement dans la documentation MCP de WordPress.com : WordPress.com indique qu’il « n’utilise pas les données des outils MCP pour entraîner des modèles d’IA ». C’est important pour les propriétaires de sites qui souhaitent bénéficier des gains de productivité de l’IA tout en évitant que le contenu et les données analytiques ne soient réutilisés pour l’entraînement de modèles.
En outre, WordPress.com publie une matrice de capacités basée sur les rôles (« accès aux outils MCP ») qui cartographie les outils MCP disponibles selon le rôle de l’utilisateur WordPress.com (Administrateur, Éditeur, Auteur, etc.). En pratique, cela signifie que la portée effective d’un agent d’IA est limitée par le même système de rôles sur lequel les équipes de site s’appuient déjà pour la gouvernance.
4) Lecture seule aujourd’hui : ce que le MCP de WordPress.com peut (et ne peut pas) automatiser
À l’heure actuelle, l’accès MCP de WordPress.com est explicitement en lecture seule. La documentation d’assistance de WordPress.com indique : « L’accès MCP est actuellement en lecture seule. Les assistants IA ne peuvent pas créer, modifier ni supprimer du contenu sur vos sites WordPress.com. »
Il est important d’interpréter correctement cette limitation. La lecture seule permet tout de même des automatisations à fort impact, telles que l’inventaire du contenu, l’assistance à l’audit SEO, le diagnostic des problèmes de configuration, l’examen de l’état des extensions, l’extraction de statistiques et la réponse à des questions opérationnelles comme « Quels articles mentionnent X ? » ou « Qu’est‑ce qui a changé dans les paramètres ? », le tout sans risque de modifications accidentelles.
L’annonce officielle de WordPress.com, « WordPress.com prend désormais en charge MCP » (7 oct. 2025), réaffirme l’accès en lecture seule pour l’instant, avec un accès « en écriture » prévu. La même annonce présente WordPress.com comme « le premier hébergeur WordPress à prendre en charge MCP avec OAuth par défaut », soulignant une posture sécurisée par défaut à mesure que les capacités s’étendent.
5) Le connecteur local : mcp-wpcom-remote et pourquoi c’est important
Automattic maintient mcp-wpcom-remote comme un wrapper de serveur MCP optimisé pour WordPress.com. Son README le décrit comme « un serveur Model Context Protocol (MCP) pour une intégration transparente avec WordPress.com », avec une « authentification sécurisée OAuth 2.0 », et il définit par défaut le point de terminaison de l’API MCP sur https://public-api.wordpress.com/wpcom/v2/mcp/v1.
Sur le plan architectural, cette approche de « wrapper distant » résout un problème pratique : de nombreux clients d’agents IA s’attendent à communiquer avec un serveur MCP localement (via STDIO ou HTTP local). En exécutant un proxy local qui s’authentifie de manière sécurisée auprès de WordPress.com, on obtient le meilleur des deux mondes : une expérience de développement locale avec des services WordPress.com hébergés.
Les outils évoluent également rapidement. Sur npm, @automattic/mcp-wpcom-remote montre une activité de publication récente (par exemple, la version 0.2.3 avec un indicateur de fraîcheur « Publiée il y a 21 jours » au moment de l’inscription), ce qui est utile pour vérifier si le connecteur d’automatisation est activement maintenu.
6) WordPress auto‑hébergé : MCP via adaptateurs, extensions et « abilities » standardisées
Pour le WordPress auto‑hébergé, mcp-wordpress-remote d’Automattic emprunte une autre voie : il connecte les assistants IA à WordPress via OAuth/JWT/Mots de passe d’application et indique qu’il est « conforme à la spécification d’autorisation MCP », avec la prise en charge d’OAuth 2.1 + PKCE (selon son README daté du 18/06/2025).
Ce dépôt signale également une dépendance opérationnelle importante : vous devez installer une extension sur le site WordPress et activer MCP dans les réglages de WordPress (décrit comme l’activation de MCP sous « Réglages > Paramètres MCP »). Cela correspond à la manière dont de nombreuses fonctionnalités WordPress sont généralement livrées : une capacité au niveau du site avec une activation explicite par l’administrateur.
Parallèlement, l’écosystème converge vers une approche plus native à WordPress : le projet WordPress/mcp-adapter « fait le pont entre l’API Abilities de WordPress et la spécification MCP », en traduisant les « abilities » de WordPress en « outils, ressources et invites » MCP. Son README documente un point de terminaison concret pour les intégrations d’automatisation, /wp-json/mcp/mcp-adapter-default-server, et une commande WP‑CLI (wp mcp-adapter serve --server=mcp-adapter-default-server) pour un service via STDIO.
7) Pourquoi l’API Abilities est une couche de sécurité pour l’automatisation par IA
L’API Abilities est pertinente car elle fournit à WordPress un contrat structuré sur ce qu’un agent peut appeler. La documentation développeur met en avant l’utilisation de JSON Schema pour input_schema et output_schema, ce qui aide à valider les requêtes et réponses et réduit l’ambiguïté, un ingrédient essentiel pour une automatisation fiable.
Les abilities peuvent également inclure des callbacks d’autorisation. Cela signifie que les outils exposés à un agent peuvent appliquer des règles d’autorisation contextuelles au‑delà de simples vérifications de rôle, comme restreindre des actions selon le type de contenu, l’environnement (préproduction vs production) ou même des règles propres à l’entreprise.
L’équipe Make WordPress AI présente cela comme un « bloc de construction IA ». Dans l’annonce de la version v0.3.0 de l’adaptateur MCP (24/11/2025), l’adaptateur est positionné comme un traducteur entre les capacités de WordPress et MCP, avec des mentions de serveurs multiples, de transports, de permissions, d’observabilité et de WP‑CLI, indiquant que l’objectif n’est pas seulement la connectivité, mais une automatisation gouvernable et débogable.
8) Le paysage plus large des plugins MCP et de l’automatisation (WooCommerce, Zapier, etc.)
Au‑delà des intégrations cœur/hébergeur, MCP apparaît dans des extensions et des couches d’automatisation tierces. Par exemple, l’extension WordPress.org « StifLi Flex MCP » annonce « exposer 117 outils » pour permettre aux agents d’IA de gérer WordPress + WooCommerce, prend en charge un point de terminaison REST conforme à JSON‑RPC 2.0, propose du streaming SSE (Server‑Sent Events) et recommande les mots de passe d’application WordPress pour l’authentification.
Dans l’annuaire des extensions de WordPress.com, « MCP for WooCommerce » est présenté comme un « serveur Model Context Protocol complet » avec authentification basée sur JWT et des transports « diffusables » à la fois en STDIO et HTTP, mettant l’accent sur la « sécurité en lecture seule ». Cela met en évidence un schéma courant : commencer par un accès en lecture seule pour instaurer la confiance, puis étendre vers des opérations d’écriture contrôlées à mesure que les standards et garde‑fous mûrissent.
Il existe aussi une approche sans « glue code ». L’offre « WordPress MCP » de Zapier décrit la génération d’une URL MCP sécurisée, le choix d’actions WordPress et leur connexion à n’importe quel assistant IA compatible MCP, positionnant MCP comme une surface de contrôle portable pour l’automatisation qui n’exige pas des développeurs qu’ils hébergent leur propre middleware d’intégration.
MCP connecte les agents d’IA à l’automatisation de WordPress en standardisant la manière dont les assistants découvrent des capacités, demandent des autorisations et invoquent des outils avec des schémas structurés. Le serveur MCP intégré de WordPress.com (disponible avec les offres payantes et associé à un proxy local Node.js 22+) montre comment les plateformes hébergées peuvent simplifier l’accès à l’IA tout en maintenant des limites claires en matière de consentement utilisateur et de confidentialité.
Dans le même temps, le WordPress auto‑hébergé évolue vers un modèle plus natif et extensible grâce à l’API Abilities et à l’mcp-adapter, tandis que l’écosystème des extensions et des services comme Zapier élargit le sens d’« automatisation ». Pour les équipes qui bâtissent des workflows aujourd’hui, la conclusion pratique est claire : commencez par l’observation et la supervision en lecture seule, concevez autour d’autorisations granulaires et préparez‑vous à un avenir proche où l’automatisation par agents, compatible avec les standards et capable d’écriture, deviendra la norme.
