WordPress MCP vs CMS Headless MCP : Lequel convient aux agents IA ?

WordPress MCP a désormais une route officielle : l'API Abilities, arrivée dans WordPress 6.9, plus l'adaptateur MCP qui transforme les abilities en outils qu'un agent peut appeler. Bien. Les CMS Headless ont atteint ce point plus tôt avec leurs propres serveurs de première partie, tandis que les sites basés sur git évitent une grande partie du même chaos en forçant chaque modification d'agent à passer par une pull request avant qu'elle ne puisse atteindre la production. Aucune de ces piles n'est sûre par défaut. La vraie différence est l'endroit où réside la sécurité : dans la boîte, ou dans le travail que vous faites autour. Cet article compare les piles plutôt que plugin contre plugin, puis vous donne un tableau de bord et une vue prudente sur l'endroit où les sites dirigés par agents pourraient vivre d'ici 2027.

Ce que MCP change : votre site obtient un agent qui peut écrire

MCP en lecture seule est une boîte de recherche mieux élevée. Un agent récupère les articles, les résume et repère les lacunes, et si le travail est mal exécuté, le site n'est pas endommagé. Rien ne casse.

L'accès en écriture est différent. Une fois qu'un serveur expose les outils create, update, publish et delete, l'agent devient un utilisateur actif de votre site, avec tous les droits que son token porte. Il peut réécrire une page tarifaire à 3h du matin. Il peut publier un brouillon que personne n'a approuvé, et il peut être poussé vers l'une ou l'autre erreur par du texte qu'il lit en chemin. Plus d'informations à ce sujet bientôt.

Le choix du CMS cesse donc d'être surtout une question d'éditeurs et de modèles. Cela devient une question de permissions, et quatre sous-questions font la majorité du travail difficile.

1. À quel point pouvez-vous affiner ce que l'agent est autorisé à faire ?
2. Peut-il rester en brouillon, ou chaque écriture devient-elle publique ?
3. Y a-t-il une piste d'audit, et pouvez-vous annuler ?
4. Un humain peut-il voir le résultat avant le public ?

Ce n'est plus une préoccupation de niche maintenant. L'AISI du Royaume-Uni a compté les outils MCP publiquement publiés passant d'environ 5 000 à 177 000 en un an, les téléchargements passant de 80 000 à 14 millions. C'est beaucoup de serveurs auxquels faire confiance, ou refuser de faire confiance. Si vous voulez une routine pour prendre cette décision, j'en ai écrit une dans la vérification des compétences Claude Code, plugins et serveurs MCP, et le tableau plus large de l'exécution de MCP en production est dans le post du stack de production des serveurs MCP.

WordPress, la route officielle : l'API Abilities et l'adaptateur MCP

L'API Abilities a atterri dans WordPress 6.9. Elle donne au cœur, aux thèmes et aux plugins un moyen standard de déclarer ce qu'ils peuvent faire, avec des schémas d'entrée et des callbacks de permission attachés. L'adaptateur MCP se situe au-dessus de cette couche. Il est décrit comme le paquet WordPress officiel pour l'intégration MCP, vit sous l'organisation GitHub WordPress, et appartient à l'initiative Building Blocks for WordPress. Son travail est étroit mais important : exposer les abilities comme outils MCP, ressources et invites.

Ce que le README documente :

• Transports HTTP et STDIO, plus une McpTransportInterface pour les protocoles personnalisés. Les clients se connectent via WP-CLI sur STDIO, ou en pointant un client HTTP vers /wp-json/mcp/mcp-adapter-default-server.
• Une fonctionnalité appelée permissions granulaires : authentification de transport par serveur et vérifications de permission par ability.
• Les capacités sont privées par défaut. Définir meta.public (ou meta.mcp.public) à true en expose une.
• Le serveur par défaut offre trois meta-tools : mcp-adapter/discover-abilities, mcp-adapter/get-ability-info et mcp-adapter/execute-ability.
• Gestion des erreurs enfichable et observabilité via McpErrorHandlerInterface et McpObservabilityHandlerInterface.

Privé par défaut est le bon réflexe. Une capacité qu'aucun utilisateur n'a marquée comme publique ne peut être atteinte par un agent, peu importe la finesse du prompt. Regardez maintenant ce qui manque à cette liste : pas de rôle d'agent brouillon uniquement, pas d'étape d'approbation intégrée, pas de journal d'audit. Les crochets d'observabilité sont un endroit où en construire un. Ce ne sont pas une piste d'audit achevée.

Le contrôle des brouillons vit à l'intérieur des capacités. Quelqu'un doit les écrire. Un plugin tiers, MS WordPress Abilities, montre bien la forme de ce travail. Il enregistre 29 capacités (26 personnalisées, plus trois capacités principales optées pour la visibilité MCP) et offre une mise à jour en deux étapes, preview-post-update puis apply-post-update, tandis que patch-post-content n'a besoin d'aucune mise en scène. Un design sensé. C'est toujours le choix de cet auteur, pas celui de WordPress. Selon le même README, le noyau et le plugin IA officiel ne livrent que quelques capacités d'emblée.

C'est aussi toujours en cours de stabilisation. Un problème ouvert le 18 mars 2026 a souligné que le README de l'adaptateur parlait encore de la nécessité de l'API Abilities après sa fusion avec le noyau (problème 150). Le 24 juin 2026, un contributeur a commenté là-dessus que les nouvelles capacités du noyau et du site appartiennent au plugin IA et à l'API Abilities, pas à l'adaptateur, et que beaucoup de documentation de l'adaptateur enseigne encore le modèle plus ancien d'enregistrement de capacités arbitraires et de définition de mcp.public. Puis, le 5 février 2026, un responsable de WordPress AI a dit qu'il ne connaissait pas de répertoire de plugins implémentant l'API Abilities ou le support MCP (discussion 204). La plomberie est officielle. Le catalogue de capacités sûres et utiles reste mince.

WordPress, la route des plugins : beaucoup de choix, un historique de sécurité mince

L'autre route WordPress est un plugin qui livre son propre serveur MCP. Les noms qui apparaissent sur les pages de comparaison des fournisseurs incluent Easy MCP AI, WPVibe, Novamira, Royal MCP, miniOrange Secure MCP Server et AI Engine. Je les traite comme une catégorie ici. Pas de classement. Je ne répète pas non plus leurs revendications de fonctionnalités comme des faits. Une mise en garde compte : les pages de comparaison populaires sont gérées par les fournisseurs de plugins qui se listent eux-mêmes, alors lisez-les comme du marketing avec un tableau joint.

Ce que la catégorie offre est la rapidité. Installez le plugin, collez un jeton dans votre client IA, et vous obtenez des outils pour les articles, les médias et souvent les utilisateurs et les paramètres. Ce que cela coûte est la confiance. Vous donnez à un auteur tiers un point de terminaison qui peut agir en tant qu'utilisateur WordPress, sur un site PHP avec une zone d'administration complète derrière lui.

Le seul dossier de sécurité public que je cite ici appartient à un plugin, AI Engine :

• CVE-2025-11749. Dans les versions jusqu'à 3.1.3, avec l'option No-Auth URL activée, le jeton porteur MCP s'échappait par les routes REST publiques du site. Les attaquants non authentifiés pouvaient s'authentifier au point de terminaison MCP et créer des comptes administrateur. Corrigé dans la version 3.1.4 et publié sur NVD le 5 novembre 2025 (l'article de SentinelOne, qui place la fuite au point de terminaison /mcp/v1/ et dit qu'aucun code d'exploit public vérifié n'a été confirmé).
• CVE-2026-8719. Publié le 17 mai 2026, évalué élevé (CVSS 8.8). Dans la version 3.4.9, le chemin du jeton porteur OAuth MCP n'a pas vérifié la capacité d'administrateur, donc un utilisateur au niveau abonné avec un jeton valide pouvait accéder aux outils MCP au niveau administrateur et devenir administrateur (avis GitHub).
• Une liste plus longue. WPScan en énumère beaucoup d'autres, notamment une prise de contrôle de compte de l'outil utilisateur MCP sur multisites (corrigée dans la version 3.6.1) et la création de compte administrateur via CSRF (corrigée dans la version 3.6.6).

Soyez juste quant à ce que cela prouve. C'est un plugin. Les plugins populaires attirent l'examen, ce qui est en partie pourquoi celui-ci a un dossier, et un dossier vide ailleurs n'est pas une preuve de sécurité. Néanmoins, le schéma compte. Les deux bugs de titre sont des défaillances d'autorisation à la porte MCP, exactement où un agent reçoit son pouvoir. Rappelez-vous cette partie.

Serveurs MCP Headless CMS : Sanity, Strapi, Contentful et Payload

Les plates-formes Headless ont construit leurs serveurs MCP autour du modèle de données. Pas autour d'un administrateur PHP. Cette différence se voit dans la documentation.

Sanity

Sanity exécute un serveur hébergé à https://mcp.sanity.io sur HTTP Streamable, avec OAuth par défaut et authentification par jeton en option. Les agents peuvent exécuter des requêtes GROQ, gérer les versions et corriger les documents avec une connaissance de votre schéma. La configuration est npx sanity@latest mcp configure. Le ancien package @sanity/mcp-server local est déprécié. C'est la route actuelle.

La documentation décrit l'écriture en priorité aux brouillons : create_documents crée des brouillons à moins que vous transmettiez une releaseId, patch_documents enregistre dans la version brouillon ou version, et le contenu publié n'est jamais modifié directement. La publication est un outil séparé. Les correctifs à chaque document s'appliquent comme une seule transaction. Un jeton personnel partage votre rôle et vous relie aux modifications de l'historique des révisions, tandis qu'un jeton défini dans l'en-tête Authorization agit au sein de son propre rôle et de sa propre portée. Il y a deux inconvénients. Le serveur expose également l'administration du développement et du projet (déploiement de schéma, ensembles de données, origines CORS), donc définissez la portée du jeton avec soin. Et create_release ne planifie rien, ce qui doit se faire dans Studio ou l'API HTTP Actions.

Strapi

Le serveur MCP de Strapi est intégré et s'exécute dans votre propre instance. Il est apparu pour la première fois en v5.47.0 et a atteint la disponibilité générale en v5.49.0 (Blog Strapi, 3 septembre 2026). Par défaut, il est désactivé : server.mcp.enabled est false. Il s'authentifie avec des jetons d'API admin et expose les outils find, create, update, publish et unpublish par type de contenu. Un jeton ne peut jamais dépasser les permissions de son propriétaire, et la désactivation du propriétaire le révoque. Il ne crée pas de types de contenu ni ne télécharge de média ; ceux-ci passent toujours par l'API REST (Strapi).

Contentful et Payload

Contentful publie un serveur MCP open-source officiel (licence MIT, paquet npm @contentful/mcp-server) qui permet aux agents de gérer les entrées et les actifs, de mettre à jour les types de contenu et d'automatiser les tâches comme l'étiquetage et les migrations. Il nécessite un jeton d'accès de gestion et un ID d'espace (Contentful). Un serveur communautaire séparé existe et pointe vers le serveur officiel. Payload ajoute MCP via un plugin officiel plutôt qu'un serveur autonome. C'est aussi loin que j'irai sur Payload ici.

Si vous comparez Sanity et WordPress plus largement, Sanity vs WordPress for enterprise couvre le côté non-MCP. Commencez par là pour cette partie de la décision.

Git-based Jamstack : la pull request comme filet de sécurité

Le troisième modèle n'a aucun serveur CMS. Le contenu vit dans le dépôt sous forme de Markdown, MDX ou JSON typé, et le site est Astro ou Next.js. Un agent de codage édite les fichiers. Il ouvre une pull request, l'hébergeur crée un déploiement d'aperçu, et un humain lit la différence avant de fusionner. Vercel et Netlify offrent tous deux le déploiement basé sur git et les déploiements d'aperçu, ce qui est tout ce dont ce modèle a besoin d'un hébergeur.

Cette boucle de pull-request n'est pas exotique. Next.js documente comment il supporte les agents de codage IA, et un tutoriel Microsoft Azure Static Web Apps montre le câblage standard : un flux de travail GitHub Actions qui se déclenche sur pull request opened, synchronize, reopened et closed, avec une tâche séparée pour détruire l'aperçu. C'est une machinerie de livraison ordinaire. C'est une partie de l'attrait.

Pourquoi cela convient aux agents est simple. Chaque changement est une différence vérifiable. Rien n'atteint la production jusqu'à ce qu'une personne fusionner. Le retour en arrière est un git revert. Le site public est une sortie statique, donc il n'y a pas de connexion d'administration qu'un jeton d'agent volé pourrait atteindre.

Les coûts sont réels, cependant. Les éditeurs non techniques rencontrent des frictions, car git n'est pas leur outil. Rien ici n'est un serveur MCP documenté avec un antécédent de sécurité ; l'agent est un agent de codage avec accès au dépôt, donc votre exposition est la portée de son jeton git et tout ce que son shell peut toucher. L'hygiène de la chaîne d'approvisionnement s'applique toujours. J'ai couvert cela dans Next.js, Astro and Nuxt security in 2026.

Risques MCP sur n'importe quelle pile, et les contrôles qui les contiennent

La NSA a publié une Fiche d'information sur la cybersécurité sur la sécurité MCP en juin 2026, et Microsoft a écrit sur l'état de la sécurité MCP en 2026. Dépouillé du vocabulaire, quatre risques reviennent constamment.

• Permissions héritées. L'agent peut faire tout ce que les identifiants du serveur MCP peuvent faire. Un jeton admin signifie un agent admin.
• Empoisonnement des outils. Les descriptions d'outils sont lues par le modèle, donc un serveur malveillant ou compromis peut cacher des instructions dans celles-ci. C'est pourquoi les serveurs tiers méritent un examen avant installation.
• Injection de prompt. Le contenu que l'agent lit (un commentaire, une page raclée, un ticket d'assistance collé dans un brouillon) peut porter des instructions. L'agent peut les suivre avec son propre accès en écriture.
• Jetons trop privilégiés. La commodité pousse les gens à remettre un jeton large. Ne le faites pas.

Les contrôles sont ennuyeux. Ils fonctionnent. Donnez à l'agent des jetons avec les privilèges minimaux, préférez les scopes en lecture seule ou en brouillon uniquement, et mettez l'approbation humaine avant la publication et la suppression. Conservez les journaux d'audit que vous lirez réellement. Renouvelez les jetons quand quelqu'un s'en va. Rien de cela n'est spécifique à la pile, et c'est le point. La pile décide seulement de la quantité de travail déjà fait pour vous.

La fiche d'évaluation de la préparation des agents

Voici la comparaison en un seul endroit. Les évaluations proviennent de fonctionnalités documentées et du domaine public, avec les sources nommées ci-dessus. Personne n'a exécuté ces piles à travers une suite de tests pour ce tableau. Traitez-le comme une comparaison documentée, non comme un résultat de laboratoire.

Solide signifie que la documentation le couvre par défaut. Partiel signifie documenté mais incomplet, ou appuyé par un seul court historique. Dépend de la configuration signifie que la pile ne décide pas. Votre configuration le fait. Faible signifie des problèmes documentés.

Pourquoi chaque évaluation, brièvement.

WordPress + adaptateur. Les permissions sont solides parce que chaque capacité porte sa propre vérification et les capacités sont privées jusqu'à ce qu'elles soient marquées publiques. Le contrôle du brouillon dépend des capacités que vous installez, comme l'exemple de mise à jour par étapes l'a montré. L'audit est partiel : des interfaces d'observabilité existent, mais un journal d'audit natif ne l'est pas. L'authentification est partielle, avec une authentification de transport par serveur documentée à haut niveau. Le dossier est partiel parce que le paquet est jeune et sa documentation est visiblement en cours de migration.

Plugins WordPress. Rien n'est uniforme dans une catégorie, donc la plupart des cellules dépendent du plugin. Le dossier est faible où documenté : les entrées AI Engine ci-dessus, et seulement celles-ci. Cette distinction compte.

Sanity. Les jetons à portée de rôle, les écritures en brouillon par défaut, les versions et l'historique des révisions méritent les évaluations solides. L'aperçu est partiel parce qu'une version est un concept de staging, mais le serveur MCP ne peut pas planifier ou publier les versions. Le dossier est partiel au sens d'une brève durée. Pas mauvais.

Strapi. Les outils par type de contenu et les jetons liés au propriétaire sont solides pour les permissions et l'authentification. Publier et dépublier sont des outils distincts, et le serveur reste inactif jusqu'à ce que vous l'activiez. L'audit et l'aperçu dépendent de la façon dont vous exécutez votre instance. L'auto-hébergement signifie également que la correction est à votre charge.

Contentful. Le serveur officiel a besoin d'un jeton de gestion et d'un ID d'espace, ce qui se lit comme un large accès, donc j'évalue les permissions et l'authentification partielle. La gestion des brouillons, l'audit et l'aperçu dépendent de la façon dont vous configurez les espaces et les rôles. Le travail important réside dans cette configuration.

Payload. Un plugin officiel existe. Au-delà, je n'ai pas de documentation principale pour noter contre, donc chaque cellule se lit comme dépend de la configuration. C'est une lacune dans ce que je peux vérifier. Ce n'est pas un jugement.

Jamstack basé sur Git. Solide dans quatre colonnes parce que le modèle lui-même les fournit : permissions de dépôt au niveau des branches, une demande de tirage comme portail de publication, historique git et restaurations, aperçus de déploiement. L'authentification dépend de l'agent de codage et de son jeton git. Le dossier est partiel parce qu'il n'y a pas de surface d'administration CMS à attaquer. L'outillage des agents porte toujours les mêmes risques MCP que tout le reste.

Comment choisir aujourd'hui, selon votre situation

Vous avez un parc WordPress existant

Restez en place et soyez strict. Utilisez l'adaptateur officiel, marquez seulement les capacités dont vous avez besoin comme publiques, et écrivez ou choisissez des capacités qui préparent les changements avant de les appliquer. Un large plugin tiers avec un jeton capable d'admin est la configuration la plus risquée de cette comparaison entière. Si vous voulez libérer WordPress par l'avant d'abord, le développement WordPress headless est un chemin intermédiaire.

Vous commencez une nouvelle construction

Si des agents vont l'aider à fonctionner, commencez par headless ou git. Sanity ou Strapi vous donnent des brouillons et des jetons limités dès le départ. Astro ou Next.js dans un dépôt vous donne des diffs et des aperçus. C'est un bon défaut pour les nouveaux travaux.

Votre équipe de contenu est grande, ou non technique

Une équipe d'éditeurs qui vivent dans une interface visuelle n'appréciera pas les pull requests. Headless avec un vrai studio d'édition leur convient mieux, à condition que l'agent soit limité aux brouillons. L'éditeur de WordPress reste vraiment bon ici. C'est un point en sa faveur.

Vous avez des besoins de conformité

Demandez où vit l'historique d'audit et qui le possède. L'historique Git est une bonne réponse. L'historique de révision de Sanity en est une autre. Pour WordPress, vous devrez construire vous-même la journalisation. Les options autohébergées (Strapi, WordPress) gardent les données dans votre infrastructure mais mettent la correction à jour sur vous, tandis qu'un serveur hébergé transfère ce fardeau au fournisseur.

D'ici 2027 : pourquoi Jamstack peut être le meilleur foyer pour les sites gérés par l'IA

Cette section est une opinion, non une conclusion, et je la tiens légèrement.

Pourquoi Jamstack peut prendre de l'avance. Le contenu est structuré et typé. Chaque changement d'agent peut être un diff qu'un humain examine. Les aperçus de déploiement montrent le résultat avant qu'il ne soit en direct. La restauration est une annulation git. Le site public n'a pas de surface d'admin pour qu'un jeton d'agent volé atteigne. Les agents sont bons pour éditer des fichiers et mauvais pour être de confiance, et cette configuration est construite exactement pour cette combinaison.

Pourquoi WordPress peut ne pas perdre. Il a la plus grande base d'installation et le plus grand vivier de talents. L'API Abilities est maintenant en cœur, avec un adaptateur officiel à côté. Les fournisseurs de plugins itèrent vite. L'itération rapide corrige beaucoup, même si elle a créé les CVE ci-dessus.

Ce dont WordPress aurait besoin. MCP en cœur, avec des capacités mappées aux capacités par défaut. Rôles d'agent en brouillon seulement. Un journal d'audit natif. Un meilleur bilan de sécurité pour les plugins MCP. C'est une courte liste, et rien n'en est impossible.

Si cet avis vous pousse à envisager un déménagement, le guide pour quitter WordPress est par où commencer.

Ligne pratique : pour un nouveau site que les agents vont aider à faire fonctionner, commencez par Jamstack ou headless. Pour un parc WordPress existant, utilisez l'adaptateur officiel avec des capacités du moindre privilège plutôt qu'un large plugin tiers. Soyez ennuyeux ici.

FAQ

Puis-je exécuter WordPress MCP en mode lecture seule ?

Oui, en principe. Les capacités sont privées par défaut, exposez donc seulement les capacités qui lisent les données et laissez sans inscription ou non marqué tout ce qui écrit. L'adaptateur n'a pas un seul commutateur en lecture seule. La discipline réside dans les capacités que vous enregistrez.

Quels clients IA peuvent se connecter ?

Pour WordPress, tout ce qui parle MCP via HTTP ou STDIO (via WP-CLI). La documentation de Sanity répertorie Claude Code, Cursor, VS Code, Lovable, Replit et v0 comme clients compatibles, et les sessions OAuth y expirent généralement après 7 jours. Le choix du client n'est pas la partie difficile.

Un serveur MCP hébergé est-il plus sûr qu'un serveur autohébergé ?

Cela échange un risque contre un autre. Un serveur hébergé comme celui de Sanity déplace la correction à jour au fournisseur, mais vous comptez sur leur délimitation et votre hygiène des jetons. Un serveur à l'intérieur de votre instance, comme celui de Strapi, garde tout dans votre infrastructure. Les mises à jour sont votre travail.

Devrais-je construire mon propre serveur MCP à la place ?

Seulement si vous avez besoin d'un ensemble étroit d'outils que les outils officiels ne proposent pas. Un petit serveur construit pour un usage unique avec trois outils est plus facile à raisonner qu'un large. Il y a une procédure pas à pas dans la construction d'un serveur MCP avec Supabase et TypeScript. Gardez la surface petite.

La mise en garde la plus importante est celle qu'on oublie facilement : un agent hérite de tout ce que son jeton peut faire, et le seul registre de sécurité MCP public dans cette comparaison est la liste des CVE d'un plugin WordPress, ce qui suffit amplement à justifier de limiter les jetons avant de choisir une stack. Les évaluations ci-dessus proviennent de la documentation et des avis publics, non de tests. Considérez le choix de la stack comme secondaire par rapport au modèle de permissions.