Brancher un MCP sur WordPress pour ne plus jamais l'ouvrir.
Créer, modifier et retirer des pages sans passer par l'administration, en restant dans la charte du site. Voici le principe, ce que ça débloque, et la limite qui ne sera pas franchie.
Le back-office est une impasse
Deux constats, et le second est plus embêtant que le premier.
Le premier, c'est que presque personne ne va dans son back-office. Les clients à qui on a livré un site avec la promesse de l'autonomie éditoriale n'y touchent pas. Les pages qu'on devait ajouter attendent des mois, et le site se fige le jour de la livraison.
Le second, c'est que l'administration WordPress est pensée pour un humain avec une souris. Automatiser à travers elle, c'est simuler des clics ou bricoler dans des écrans qui n'ont pas été conçus pour ça. Tout ce qu'on construit ainsi casse à la première mise à jour.
Un contrat plutôt qu'un contournement
La réponse a été de sortir complètement de l'interface. Un serveur MCP expose ce qu'on veut pouvoir faire au site : créer une page, la modifier, la supprimer. Le contenu, lui, est assemblé par un page builder à partir de blocs qui appartiennent à la charte du site.
Ce détail décide de tout. Le générateur ne dispose que des blocs existants, donc il ne peut pas dénaturer le design. Ce n'est pas une consigne qu'on lui donne et qu'il pourrait mal suivre, c'est une contrainte matérielle : il n'a rien d'autre sous la main.
Une instruction se contourne, une contrainte non. C'est toute la différence entre demander à un modèle de respecter votre charte et lui retirer les moyens d'y déroger.
Ce que ça débloque
À partir du moment où le site s'adresse par un contrat propre, tout ce qui sait parler ce contrat peut l'alimenter. Concrètement, chez nous, un workflow de référencement repère une thématique à traiter, produit la page correspondante dans la charte du client, avec ses métadonnées et un contenu écrit dans son ton, puis la pousse en brouillon.
Le client ne voit jamais WordPress. Il relit un brouillon, il valide ou il refuse.
Et comme c'est un contrat et non un bricolage, la source n'a aucune importance. Un modèle de langage, un workflow d'automatisation, une interface interne, un fil de discussion sur une messagerie : tout ce qui peut appeler le serveur peut produire une page. C'est le signe qu'une architecture est correcte, elle accepte des branchements auxquels on n'avait pas pensé.
La limite : brouillon, jamais publication
Rien ne se publie tout seul, et ce n'est pas une précaution ajoutée après coup.
Un texte généré puis mis en ligne sans relecture se reconnaît. Il ne tranche rien, ne refuse rien, ressemble à tout ce que produisent les concurrents avec les mêmes outils, et ne se classe nulle part. Automatiser la publication reviendrait à industrialiser exactement ce qu'on passe son temps à corriger chez les autres.
La bonne répartition est celle-ci : le traitement fait le travail ingrat, chercher le sujet, respecter la structure, remplir les métadonnées, poser la page au bon format. Le jugement reste humain : est-ce que ce texte dit quelque chose, est-ce qu'il est juste, est-ce qu'on le signe.
Pourquoi ça intéresse une agence
Le problème que ça règle n'est pas technique, il est économique. Pour une agence, ajouter trois pages sur un site client est une tâche à faible marge que personne n'a envie de planifier, et qui finit par être facturée à perte ou repoussée.
Quand la production passe par un contrat programmable et que le design est garanti par construction, cette tâche cesse d'être un chantier. Elle devient une relecture.
C'est ce qui rend l'outil utile en renfort pour une agence : la production avance sans mobiliser un chef de projet.
Questions fréquentes
Qu'est-ce qu'un MCP, dans ce contexte ?
Un serveur qui expose des actions à un programme extérieur selon un contrat défini : ici créer, modifier ou supprimer une page. L'intérêt par rapport à une automatisation qui simulerait des clics dans l'administration, c'est qu'il ne dépend pas de l'interface. Il continue de fonctionner quand celle-ci change, et n'importe quel outil capable d'appeler le serveur peut s'en servir.
Une page générée peut-elle casser le design du site ?
Non, et pas parce qu'on lui demande d'être sage. Le contenu est assemblé à partir des blocs qui composent déjà la charte du site : grille, couleurs, typographie. Le générateur n'a rien d'autre à sa disposition, donc il ne peut pas sortir de la direction artistique. C'est une contrainte matérielle, pas une consigne qu'il pourrait mal interpréter.
Les pages sont-elles publiées automatiquement ?
Non, jamais. Elles arrivent en brouillon et attendent une relecture humaine. Publier sans relire reviendrait à mettre en ligne du contenu qui ne tranche rien et ne se classe nulle part, c'est-à-dire exactement le défaut que ce travail cherche à éviter. Le traitement fait le travail ingrat, le jugement reste humain.
Faut-il un modèle d'IA pour s'en servir ?
Pas nécessairement. Le serveur expose des actions, il ne présuppose rien de ce qui les appelle. Un workflow d'automatisation, une interface interne ou un formulaire feraient l'affaire. Un modèle de langage est simplement le client le plus commode quand il s'agit de rédiger, mais l'architecture ne l'impose pas.
Votre site est figé depuis sa mise en ligne
Si les pages que vous vouliez ajouter attendent depuis des mois, le problème n'est probablement pas votre motivation. En trente minutes, on regarde ce qui bloque.