WordPress MCP : quel compte et quels droits donner à l'IA

Cet article s'adresse aux agences WordPress et aux PME qui veulent connecter un assistant comme Claude ou ChatGPT à leur site avec WordPress MCP, c'est-à-dire l'extension officielle MCP Adapter. La situation de départ est souvent la même : l'installation prend dix minutes, les tutoriels montrent comment brancher le client, et la question des droits arrive à la fin, si elle arrive. Ici, on part de cette question. À la fin, vous saurez avec quel compte connecter l'IA, ce que l'extension vérifie par défaut, et quoi régler avant d'ouvrir l'accès en production.

L'article est construit en questions-réponses, dans l'ordre où elles se posent quand on met l'outil en place. Chaque réponse s'appuie sur la documentation officielle du projet WordPress/mcp-adapter, dont la version 0.7.0 a été publiée le 2 octobre 2026.

Qu'est-ce que WordPress MCP fait, concrètement, sur votre site ?

MCP (Model Context Protocol) est un protocole qui permet à un assistant IA d'appeler des outils. L'extension MCP Adapter prend les « abilities » enregistrées sur votre site, des actions précises déclarées par WordPress ou par une extension (lire des articles, modifier un réglage…), et les rend appelables par un client MCP. Le client se connecte à une adresse REST de votre site, par exemple /wp-json/mcp/mcp-adapter-default-server, en s'authentifiant comme un utilisateur WordPress.

Ce que dit le guide du serveur par défaut : sur le serveur par défaut, une ability n'est visible que si elle est marquée publique (meta.public ou meta.mcp.public). Depuis la 0.6.0, une ability marquée publique par une autre extension y apparaît d'office (sauf si elle s'en exclut avec meta.mcp.public à false) : c'est pour ça qu'il faut refaire l'inventaire après chaque nouvelle extension. Sur un serveur personnalisé, chaque ability listée dans create_server() devient directement un outil. Ce qui compte ensuite, c'est qui se connecte et ce que ce compte a le droit de faire.

Qui peut se connecter au serveur MCP par défaut ?

C'est le point que les tutoriels survolent. La documentation sur les permissions de transport l'écrit clairement : si le développeur qui crée un serveur MCP ne fournit pas de fonction de contrôle, le serveur utilise is_user_logged_in(). Autrement dit, la seule condition pour passer la porte est d'être connecté. Un abonné, un client WooCommerce ou un compte de test oublié remplissent cette condition.

La même page précise un second comportement : si la fonction de contrôle lève une exception, l'adaptateur retombe sur is_user_logged_in(). Une erreur dans votre contrôle ne bloque donc pas forcément l'accès : elle peut le ramener au niveau « connecté ». C'est un comportement documenté, pas une faille, mais il faut le connaître quand on écrit son propre contrôle.

Ce premier niveau n'est pas le seul. L'extension a deux couches : la permission du serveur (la porte d'entrée) puis la permission de chaque ability, vérifiée au moment de l'appel. Un abonné qui passe la porte ne peut pas lancer une ability qui demande manage_options. Le risque réel vient donc d'une combinaison : une porte large, plus une ability publique dont le contrôle est trop permissif ou absent.

Avec quel compte WordPress connecter l'IA ?

La tentation est de prendre son propre compte administrateur, parce que tout fonctionne du premier coup. C'est compréhensible pour une démo. En production, cela veut dire que l'assistant agit avec tous les droits du site, et que le jeton stocké sur l'ordinateur ou dans l'outil de l'IA vaut un accès administrateur complet.

Ce que je conseille : un utilisateur WordPress dédié, nommé clairement (par exemple « ia-redaction »), avec le rôle le plus bas qui suffit au besoin. Si l'IA doit seulement lire et proposer des brouillons, le rôle Contributeur ou un rôle personnalisé suffit souvent : un Contributeur peut écrire des brouillons, mais ne peut ni publier ni téléverser de médias. Ensuite, un mot de passe d'application propre à ce compte et à cet usage. Il se révoque seul, sans toucher au mot de passe principal ni aux autres intégrations.

Ce compte dédié a un deuxième avantage : dans les journaux et l'historique des révisions, on voit tout de suite ce qui vient de l'IA et ce qui vient d'un humain.

Comment restreindre le serveur MCP à certains rôles ?

Si vous développez ou faites développer un serveur MCP pour votre site, ajoutez la fonction de contrôle que la documentation propose en dernier paramètre de create_server(). L'exemple officiel le plus simple limite la porte aux comptes qui peuvent éditer des contenus :

function(): bool {
    return current_user_can('edit_posts');
}

La documentation recommande de régler cette porte sur la capacité la plus large dont une des abilities du serveur a besoin, puis de laisser chaque ability vérifier le cas précis (par exemple current_user_can('edit_post', $args['post_id']) pour un article donné). Gardez la fonction simple : moins elle a de logique, moins elle risque de lever une exception et de retomber sur le comportement par défaut.

Pour les abilities, faites l'inventaire de celles qui sont marquées publiques. Une ability qui écrit (modifier, supprimer, changer un réglage) mérite d'être exposée une par une, après avoir lu son permission_callback.

Comment vérifier ce que l'IA peut réellement faire ?

Sur le serveur par défaut, tools/list renvoie toujours les trois mêmes méta-outils (mcp-adapter-discover-abilities, mcp-adapter-get-ability-info, mcp-adapter-execute-ability), quel que soit le compte : ce test ne prouve donc rien. Le test utile, avec WP-CLI, consiste à comparer entre deux comptes le résultat de tools/call sur mcp-adapter-discover-abilities :

echo '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"mcp-adapter-discover-abilities","arguments":{}}}' | wp mcp-adapter serve --user=ia-redaction --server=mcp-adapter-default-server

Lancez-le avec le compte dédié, puis avec un compte abonné, et comparez les abilities listées. Tentez ensuite, avec chacun des deux comptes, mcp-adapter-execute-ability sur une ability qui écrit (créer ou modifier un contenu, par exemple). Si l'abonné obtient un résultat au lieu d'un refus, la porte est trop large ou l'ability est trop permissive. Sur un serveur personnalisé, où chaque ability est un outil, la comparaison de tools/list entre deux comptes garde tout son sens, comme le montre la section Testing de la documentation sur les permissions. C'est un test de dix minutes, à refaire après chaque ajout d'extension qui déclare de nouvelles abilities.

Où est stocké le jeton, et que se passe-t-il s'il fuit ?

Le jeton (le mot de passe d'application) vit dans la configuration du client MCP, souvent un fichier sur le poste de la personne qui utilise l'assistant. Ces fichiers sont devenus une cible. Exemple réel, documenté par StepSecurity et l'avis GitHub : le 8 octobre 2026, une version piégée du paquet npm tensorlake (0.5.144) volait, dès l'installation, les jetons et secrets du poste, y compris les fichiers de configuration d'outils IA comme Claude ou Cursor. C'est exactement là que vit un mot de passe d'application MCP. Consigne de l'avis : en cas de fuite, changez les secrets depuis une autre machine.

Vous ne pouvez pas garantir qu'un poste ne sera jamais compromis. Vous pouvez en limiter l'effet : un jeton lié à un compte au rôle minimal donne peu de pouvoir, et un mot de passe d'application dédié se révoque en un clic depuis le profil de l'utilisateur, sans casser le reste.

Quelles sont les limites de ces réglages ?

Ces réglages réduisent le pouvoir du jeton, ils ne rendent pas l'IA infaillible. Un compte Contributeur peut toujours créer des brouillons absurdes ou nombreux ; il faut donc garder une relecture humaine avant publication. Les abilities ajoutées par d'autres extensions dépendent de la qualité de leur code : la vôtre ne suffit pas. Enfin, MCP Adapter évolue vite (plusieurs guides de migration en un an) : ce qui est écrit ici correspond à la version 0.7.0 et à la documentation consultée le 13 octobre 2026.

Ce qu'il faut retenir

• Sur le serveur par défaut, seules les abilities marquées publiques sont visibles, y compris celles des autres extensions : refaites l'inventaire après chaque nouvelle extension.
• Par défaut, la porte du serveur demande seulement d'être connecté : ajoutez un contrôle par rôle.
• Connectez l'IA avec un compte dédié au rôle minimal et un mot de passe d'application à part.
• Sur le serveur par défaut, comparez mcp-adapter-discover-abilities entre ce compte et un abonné, puis tentez une ability qui écrit ; gardez tools/list pour les serveurs personnalisés.

Si vous voulez brancher une IA sur votre WordPress avec des droits clairs dès le départ, c'est le type de mise en place que je fais : voir l'offre IA et MCP. Pour aller plus loin sur le sujet, lisez aussi comment définir le périmètre avant la démo, le cas d'une démo MCP branchée sur des clés live et l'accès REST resté administrateur après un login expiré.