WordPress MCP Adapter 0.7.0 : tester un agent IA sans risque

Le 2 octobre 2026, WordPress a publié la version 0.7.0 de MCP Adapter, son extension officielle qui permet à un agent IA compatible MCP (Model Context Protocol) de piloter un site : lire du contenu, en créer, en modifier, et selon les droits accordés, le publier.

C'est la première version distribuée sur le répertoire officiel de plugins WordPress.org. Autrement dit : ce qui relevait de l'expérimentation GitHub devient accessible à n'importe quel site, en quelques clics.

La question n'est donc plus "est-ce que c'est possible ?", mais "comment l'essayer sans casser mon site ?".

Ce que fait MCP Adapter, concrètement

MCP est un protocole ouvert qui standardise la façon dont un assistant IA parle à un outil externe. L'adapter WordPress joue le rôle de traducteur : il expose les abilities du site (les actions que WordPress déclare via son Abilities API) sous forme d'outils que l'agent peut appeler.

Résultat : au lieu de copier-coller un texte généré dans l'éditeur, tu demandes à ton agent "rédige un brouillon sur tel sujet et enregistre-le", et il agit directement sur le site.

Le point clé à retenir : l'agent agit avec les droits d'un vrai compte utilisateur. Si ce compte est administrateur, l'agent peut potentiellement tout faire. C'est là que se joue toute la sécurité.

Ce qui change dans la 0.7.0

Support de la révision 2026-07-28 du protocole MCP, tout en restant compatible avec les clients plus anciens
Première publication sur WordPress.org
Les abilities par défaut s'enregistrent même si un autre plugin initialise l'Abilities API en premier
L'usage de l'adapter comme bibliothèque Composer embarquée est déprécié : il faut installer le plugin

Attention aux breaking changes si tu étends l'adapter : classes DTO et validateurs supprimés, filtre mcp_adapter_validation_enabled retiré, transports personnalisés à déléguer à HttpRequestHandler ou McpWireOrchestrator. Lis le guide de migration avant de mettre à jour.

Prérequis et réserves

D'après les premiers retours, il faut WordPress 6.9 minimum et PHP 7.4+ (à vérifier sur la page du plugin au moment de l'installation).

Et surtout : on est en 0.x. Le projet est jeune, l'API peut encore bouger, et rien ne garantit la stabilité d'une version à l'autre. Ce n'est pas un plugin à poser directement sur le site d'un client en production.

Le protocole de test sans risque

Voici la démarche que j'appliquerais, dans l'ordre.

1. Travailler sur une copie, pas sur la prod

Clone le site (staging, instance Docker locale, ou copie sur un sous-domaine protégé). L'idée : si l'agent écrase vingt articles, tu supprimes la copie et tu recommences.

# Exemple : export de la base puis import en local
wp db export prod.sql
wp --path=/chemin/staging db import prod.sql
wp --path=/chemin/staging search-replace 'https://monsite.fr' 'http://staging.local'

2. Créer un compte dédié aux droits limités

Ne branche jamais l'agent sur ton compte administrateur. Crée un utilisateur spécifique, par exemple agent-ia, avec le rôle Contributeur ou Auteur :

Contributeur : peut écrire des brouillons mais pas publier. Idéal pour un premier test, tu gardes la validation humaine.
Auteur : peut publier ses propres articles. À réserver à un environnement où l'erreur est acceptable.

Pour l'authentification, WordPress propose les mots de passe d'application (Application Passwords) : un identifiant révocable par compte, sans exposer le vrai mot de passe. Si l'agent part en vrille, tu le révoques en un clic.

3. Commencer en lecture, puis en brouillon

Progression conseillée :

L'agent liste les articles existants (lecture seule)
L'agent crée un brouillon
Tu relis, tu corriges, tu publies toi-même
Seulement ensuite, tu envisages de lui donner le droit de publier

4. Garder une trace et pouvoir revenir en arrière

Active les révisions d'articles, fais une sauvegarde avant chaque session de test, et consulte les journaux d'activité. Si quelque chose tourne mal, tu dois pouvoir répondre à "qui a modifié quoi, et quand ?".

5. Se méfier de l'injection de prompt

Un agent qui lit du contenu externe (commentaires, formulaires, pages web) peut recevoir des instructions cachées dans ce contenu. Avec un accès en écriture, c'est un vrai risque. Raison de plus pour limiter les droits du compte et ne pas laisser l'agent traiter du contenu non fiable sans supervision.

Ce que ça annonce pour les devs

Quelques tendances se dessinent derrière cette sortie :

Les CMS deviennent des "outils" pour agents. Après le code, l'IA obtient des accès en écriture sur les outils du quotidien : CMS, CRM, calendriers, bases de données.
Le modèle de permissions devient la compétence clé. Savoir découper des rôles, limiter des scopes et auditer des actions pèse désormais autant que savoir écrire une requête.
Les freelances WordPress ont une carte à jouer. Configurer un agent proprement, avec un compte cloisonné, une validation éditoriale et un plan de retour arrière, est un service que les clients voudront sans savoir le formuler.

Et il y a un enjeu de qualité. Un agent qui publie vite, ce n'est pas un agent qui publie bien : relecture humaine, cohérence éditoriale et SEO restent des responsabilités à garder.

Faut-il l'adopter maintenant ?

Ma lecture : oui pour expérimenter, non pour la production.

Teste sur une copie, avec un compte Contributeur, pour comprendre le fonctionnement et mesurer le gain de temps réel
Surveille les prochaines versions avant de l'envisager chez un client
Garde toujours un humain sur le bouton "Publier"

MCP Adapter 0.7.0 n'est pas la fin de la rédaction humaine. C'est le moment où la question "qui a le droit de faire quoi sur mon site ?" cesse d'être théorique.

WordPress MCP Adapter 0.7.0 : tes articles bientôt publiés par une IA à ta place ?