MCP WordPress : brancher son site sur Claude, on l’a fait

L'été StartingUp. Nous profitons de la saison pour dresser la carte, sans fard, d'une année qui a bousculé nos méthodes. Après les questions que l'IA a rendues obsolètes, place à une expérience menée en production : connecter notre WordPress à Claude via MCP, et laisser l'IA écrire directement dans notre CMS.

La dernière mise à jour des mentions légales de ce site n'est pas passée par l'administration de WordPress. Elle a été préparée dans une conversation avec Claude, l'assistant d'Anthropic, qui a ensuite écrit lui-même le contenu dans notre CMS, avec les permissions que nous lui avions accordées. Pas de copier-coller, pas d'onglet d'admin ouvert : une instruction, une relecture, et la page en ligne quelques secondes plus tard.

Derrière ce petit moment de science-fiction domestique, il y a un standard ouvert dont vous entendrez de plus en plus parler : MCP, pour Model Context Protocol. Nous avons branché notre WordPress dessus, pour de vrai, en production. Voici ce que ce protocole recouvre, pourquoi il mérite l'attention d'un décideur, comment nous l'avons mis en œuvre, et ce que nous avons appris en chemin.

Brancher WordPress sur Claude via MCP est désormais à la portée de n'importe quel site : l'Abilities API de WordPress 6.9 déclare les capacités du CMS, l'adaptateur officiel mcp-adapter les expose comme outils MCP, et l'assistant s'y connecte avec les droits d'un compte dédié. Trois briques standard, que nous détaillons plus bas.

Avant MCP, chaque connexion entre un assistant IA et un outil métier était un développement sur mesure. Dix outils, trois assistants : trente intégrations à écrire et à maintenir. Fin 2024, Anthropic a publié MCP en open source pour régler exactement ce problème : un protocole unique par lequel n'importe quel assistant peut découvrir et utiliser les capacités de n'importe quel outil qui l'implémente. La documentation officielle emploie une image devenue canonique :

Pensez à MCP comme à un port USB-C pour les applications d'IA.

Documentation officielle du Model Context Protocol (traduction par nos soins)

Ce qui aurait pu rester un format maison est devenu, en dix-huit mois, un standard de fait. OpenAI l'a adopté au printemps 2025, Google a suivi, et fin 2025 Anthropic a confié la gouvernance du protocole à une fondation neutre sous l'égide de la Linux Foundation : MCP n'appartient plus à un éditeur, il appartient à l'écosystème. Celui-ci se compte désormais en milliers de serveurs publiés, des bases de données aux outils de design. La spécification continue d'évoluer (une révision majeure est en préparation à l'heure où nous écrivons), mais le socle est stable et très largement déployé.

Le workflow que tout le monde pratique aujourd'hui ressemble à ceci : on rédige avec l'IA dans un onglet, on copie, on colle dans l'admin du site, on recrée la mise en forme, on corrige les liens perdus en route. La friction est faible à l'unité, considérable au cumul, et chaque manipulation est une occasion d'erreur.

MCP inverse la logique : au lieu d'apporter vos contenus à l'IA, c'est l'IA qui vient travailler dans votre outil. Concrètement, une fois le CMS branché :

• La rédaction assistée atterrit directement en brouillon dans le CMS, mise en forme comprise, sans copier-coller ;
• Les mises à jour en série deviennent une seule instruction : rafraîchir des mentions légales, corriger une coordonnée présente sur plusieurs pages ;
• Le contenu devient interrogeable en langage naturel : quels articles traitent déjà de tel sujet, lesquels n'ont pas bougé depuis deux ans.

Le point décisif pour un décideur tient en une phrase : l'IA lit et écrit vos contenus avec les permissions que vous lui donnez, et uniquement celles-là. Ce n'est pas un robot lâché dans votre back-office, c'est un collaborateur dont vous définissez la fiche de poste.

Notre site est un WordPress headless doublé d'un front Next.js auto-hébergé, dont nous avons déjà raconté la containeurisation sur notre VPS. Le back exposait déjà une API ; lui ajouter une prise MCP était une évolution naturelle, et l'écosystème WordPress a rendu l'exercice étonnamment court.

Le socle existe désormais dans le cœur de WordPress : depuis la version 6.9, l'Abilities API permet de déclarer les « capacités » d'un site de façon standardisée. Chaque capacité réunit quatre choses : un nom, un schéma décrivant les entrées acceptées, une fonction d'exécution et une règle de permission. L'adaptateur officiel mcp-adapter, publié par le projet WordPress, expose ensuite ces capacités comme outils MCP sur une route REST du site. Notre part du travail : un mu-plugin d'environ 160 lignes qui déclare trois capacités éditoriales : créer un contenu, le mettre à jour, lister l'existant. Soit quelques dizaines de lignes par capacité, dont voici la première, à peine simplifiée :

Rien d'exotique : du WordPress standard de bout en bout. La valeur est dans les deux garde-fous : le schéma d'entrée dit à l'IA ce qu'elle peut envoyer, la règle de permission borne ce qu'elle a le droit de faire.

Côté authentification, nous avons retenu les Application Passwords, natifs dans WordPress : un mot de passe dédié, révocable à tout moment, attaché à un compte précis et transmis sur HTTPS. Claude se connecte avec ce compte et hérite exactement de ses droits, ni plus ni moins. Dernier bonus, propre à notre architecture headless : quand Claude modifie un contenu, le mécanisme de revalidation de notre front Next.js se déclenche automatiquement, et la page à jour est servie aux visiteurs quelques secondes plus tard.

Le récit serait suspect sans les échecs. Voici les nôtres, dans l'ordre où ils nous ont fait perdre du temps.

• Le schéma d'entrée n'est pas optionnel. Nos premières capacités n'en déclaraient pas : l'adaptateur rejetait alors tout argument fourni, et plantait avec une erreur PHP peu parlante quand il n'y en avait aucun. Le input_schema est le contrat entre l'IA et votre site ; sans lui, rien ne fonctionne, et c'est finalement une bonne chose.
• Un 404 peut cacher une évidence. L'adaptateur installé mais non activé ne crée tout simplement pas la route : avant de soupçonner sa configuration, vérifier l'activation du plugin nous aurait épargné une soirée.
• Ne jamais exposer sans authentification. Un serveur MCP capable d'écrire est une porte d'entrée sur votre site. Authentification obligatoire, HTTPS, et compte aux droits minimaux : notre capacité de lecture exige la permission read, celles d'écriture edit_posts, et jamais un compte administrateur.
• Le brouillon par défaut. Nos capacités créent les contenus en draft sauf demande explicite : la publication reste une décision humaine, prise après relecture.

Le gain le plus net n'est pas spectaculaire, il est quotidien : des tâches d'édition qui demandaient d'enchaîner les écrans se règlent désormais dans la conversation où le travail se fait déjà. Le brouillon naît là où il sera publié, la correction en série ne dépend plus de la patience de celui qui clique, et l'inventaire du contenu se demande comme on pose une question à un collègue.

L'honnêteté impose le revers. La relecture humaine reste systématique : l'IA écrit bien, elle peut aussi se tromper avec aplomb, et un contenu publié engage votre entreprise. Notre implémentation couvre l'essentiel éditorial, pas tout : ni gestion des médias, ni réglages SEO fins à ce stade. Le protocole évolue vite, ce qui impose de suivre les mises à jour de l'adaptateur et de la spécification. Enfin et surtout : brancher une IA sur son CMS est moins un sujet technique qu'un sujet de gouvernance. Qui a le droit de faire quoi, sur quels contenus, avec quelle validation ? Cette réponse doit précéder le branchement, pas le suivre.

Le coût de l'expérience tient en trois lignes : un adaptateur officiel, environ 160 lignes de PHP, un mot de passe d'application. Ce qui compte n'est pas la prouesse, c'est la position acquise : un CMS branché sur MCP cesse d'être un silo dans lequel on recopie, il devient un outil que vos assistants IA peuvent lire et alimenter, sous votre contrôle et avec vos règles.

Si vous devez emporter une seule question de cette lecture, que ce soit celle-ci : dans vos outils métier, quelles sont les trois actions que vos équipes refont chaque semaine à la main et qui mériteraient une prise standard ? Chez nous, la réponse tenait en trois verbes : créer, mettre à jour, lister. Nous avons commencé par là ; c'est modeste, et c'est déjà un autre métier.