Connecter Claude à WordPress : exécuter WP-CLI et vérifier chaque changement avec Relvato

Deux moitiés : modifier le site, et le vérifier

WP-CLI est la ligne de commande de WordPress. Il liste les extensions, les met à jour, exporte la base de données, compare les fichiers du cœur avec WordPress.org, et plus encore. C'est ainsi qu'un assistant modifie un site. Ce qu'il ne peut pas vous montrer, c'est le site tel qu'un visiteur le voit : si le paiement passe toujours, si le formulaire de connexion s'envoie toujours, si une page est toujours rapide.

C'est la faille derrière la plupart des histoires du type « une mise à jour a cassé mon site » : la mise à jour elle-même annonce un succès, et la panne est ailleurs, dans un formulaire, un script ou un gabarit. Relvato vérifie précisément cela, dans un vrai navigateur, depuis l'extérieur. Via son connecteur, un assistant peut demander l'état d'un site (site_overview), lancer des contrôles tout de suite (trigger_scan), lire une exécution en détail (get_run) et obtenir le brief derrière un échec (get_fix_prompt).

Ensemble, ils forment une boucle : modifier quelque chose avec WP-CLI, le vérifier avec Relvato et lire le résultat avant de continuer, dans la même conversation.

Quel Claude peut faire quoi

Claude Code, dans le terminal ou dans l'application de bureau de Claude, peut exécuter des commandes shell. Il peut lancer WP-CLI sur un site local ou, via SSH, sur un site distant. C'est la façon la plus directe de connecter Claude à WordPress.

Claude sur le web, sur mobile et dans le chat de bureau ne peut pas exécuter de shell. Pour modifier un site depuis là, utilisez le MCP Adapter de WordPress en HTTPS ou, pour les sites hébergés sur WordPress.com, son propre connecteur. Le connecteur Relvato fonctionne partout dans Claude.

Étape 1 : ajouter le connecteur Relvato

Dans Claude, ouvrez Settings → Connectors, cherchez Relvato (ou ouvrez sa page dans l'annuaire), cliquez sur Connect et identifiez-vous sur Relvato. Sur l'écran de consentement, vous autorisez l'assistant à lire vos sites et résultats et à faire des changements : ajouter des sites et des contrôles, modifier les plannings et lancer des scans. Si vous appartenez à une organisation, vous choisissez lequel de ses espaces de travail il peut utiliser.

Dans Claude Code, ajoutez le serveur en une commande, puis identifiez-vous quand on vous le demande. Les clients qui ne peuvent pas s'identifier peuvent utiliser une clé d'API Relvato. La page développeurs présente les deux options.

# Claude Code : ajoutez Relvato, puis lancez /mcp dans Claude Code et choisissez Authenticate
claude mcp add --transport http relvato https://app.relvato.com/api/mcp

Étape 2 : lui donner WP-CLI, via SSH

WP-CLI peut exécuter des commandes sur un serveur distant via SSH. Placez des alias pour vos sites dans un wp-cli.yml, dans le dossier où vous lancez Claude Code : chaque commande désigne alors le site visé. WP-CLI doit être installé sur le serveur et accessible sous le nom wp pour l'utilisateur SSH, et votre clé SSH doit fonctionner sans demande de mot de passe.

Commencez par une copie de staging. Vérifiez d'abord la connexion avec une commande sans risque : wp @staging core version doit afficher votre version de WordPress.

# wp-cli.yml
@staging:
  ssh: deploy@staging.example.com/var/www/html
@prod:
  ssh: deploy@example.com/var/www/html

# vérifier la connexion
wp @staging core version

Étape 3 : décider de ce qu'il peut lancer sans demander

Par défaut, Claude Code demande avant chaque nouvelle commande. Dans .claude/settings.json, vous pouvez pré-autoriser les commandes en lecture seule, garder les changements derrière une confirmation et interdire purement et simplement les commandes destructrices. Les règles deny l'emportent toujours sur les règles allow.

Deux précautions. Les règles correspondent à la commande telle qu'elle est écrite : wp @staging plugin list et wp @prod plugin list sont donc des règles différentes. Et la documentation de Claude Code elle-même qualifie de fragiles les règles qui cherchent à figer les arguments d'une commande. Voyez-les comme une ceinture de sécurité, pas comme un verrou : la vraie limite, c'est ce que l'utilisateur SSH peut faire sur le serveur.

{
  "permissions": {
    "allow": [
      "Bash(wp @staging core version)",
      "Bash(wp @staging plugin list *)",
      "Bash(wp @staging plugin update * --dry-run)"
    ],
    "ask": [
      "Bash(wp @staging plugin update *)",
      "Bash(wp @staging db export *)"
    ],
    "deny": [
      "Bash(wp * db drop *)",
      "Bash(wp * db reset *)",
      "Bash(wp * eval *)",
      "Bash(wp * search-replace *)"
    ]
  }
}

Un cas concret : mettre à jour les extensions sans casser le paiement

Voici la boucle en pratique, d'abord en staging. Demandez à Claude quelles extensions sont obsolètes. Il lance wp @staging plugin list --update=available. Demandez ensuite à Relvato l'état du site avant de toucher à quoi que ce soit (site_overview), pour avoir une référence à comparer.

Faites une sauvegarde (wp @staging db export) et prévisualisez la mise à jour (--dry-run). Mettez à jour une extension, puis demandez à Relvato de lancer tout de suite les contrôles du site (trigger_scan) et lisez les résultats (get_run). Si le paiement, la connexion ou un formulaire échoue, get_fix_prompt renvoie le même brief que celui de l'IA de Relvato : la pile technique du site, ce qui a changé juste avant et l'erreur exacte. Claude peut raisonner sur la cause et, si besoin, revenir à la version précédente de l'extension avec WP-CLI.

Ce n'est que lorsque le staging est propre que vous recommencez en production. Si l'extension Relvato est connectée, Relvato relance aussi des contrôles de lui-même après les mises à jour d'extensions. Demander dans la conversation vous donne simplement la réponse pendant que vous y êtes encore.

Terminez par des contrôles d'intégrité que WP-CLI sait faire seul : wp core verify-checksums compare les fichiers du cœur avec WordPress.org, et wp plugin verify-checksums --all fait de même pour les extensions de WordPress.org. Les extensions premium ne peuvent pas être vérifiées ainsi.

wp @staging plugin list --update=available
wp @staging db export
wp @staging plugin update woocommerce --dry-run
wp @staging plugin update woocommerce
#  → Relvato : trigger_scan, puis get_run
#  → en cas d'échec : get_fix_prompt, puis retour en arrière :
wp @staging plugin install woocommerce --version=<version précédente> --force
wp @staging core verify-checksums
wp @staging plugin verify-checksums --all

Sans terminal : le WordPress MCP Adapter

WordPress 6.9 a introduit l'Abilities API, une manière standard pour les extensions de décrire ce qu'elles savent faire. Le MCP Adapter, une extension officielle distincte du cœur et encore avant sa version 1.0, expose ces capacités aux assistants IA sous forme de serveur MCP. L'ancienne extension d'Automattic, wordpress-mcp, est archivée à son profit.

L'adaptateur dialogue avec les clients locaux via WP-CLI (wp mcp-adapter serve) et avec les clients distants en HTTPS sur /wp-json/mcp/mcp-adapter-default-server, authentifiés par un mot de passe d'application WordPress. Seules les capacités qu'une extension déclare publiques sont exposées : ce que l'assistant peut faire dépend donc de ce que publient vos extensions. WooCommerce propose un aperçu pour développeurs construit dessus, pour les produits et les commandes.

Donnez-lui un utilisateur WordPress dédié avec le moins de droits possible, pas votre compte administrateur, et révoquez le mot de passe d'application une fois terminé. Les sites sur WordPress.com peuvent utiliser à la place le connecteur MCP de WordPress.com, sur les forfaits payants.

wp plugin install https://github.com/WordPress/mcp-adapter/releases/latest/download/mcp-adapter.zip --activate

# Claude Code, relié à un site local via WP-CLI
claude mcp add wordpress -- wp --path=/var/www/html mcp-adapter serve --server=mcp-adapter-default-server --user=ai-editor

Des garde-fous qui comptent plus que le prompt

Un assistant est exactement aussi sûr que le compte avec lequel il agit. Commencez par une copie de staging, faites une sauvegarde avant chaque changement, et utilisez un utilisateur SSH et WordPress qui n'a que les droits nécessaires à la tâche. Gardez les changements derrière une confirmation, et n'utilisez pas Claude Code avec les confirmations désactivées sur un site en production : sa documentation le réserve aux conteneurs et machines virtuelles isolés.

Vérifiez après chaque changement, pas seulement avant. WP-CLI peut vous dire qu'une mise à jour est terminée. Seul un contrôle depuis l'extérieur vous dit que le site fonctionne toujours pour ceux qui l'utilisent. C'est pour cela que le connecteur Relvato est conçu pour cette boucle, et pourquoi il ne peut délibérément ni supprimer de données, ni valider des changements visuels, ni appliquer de correctifs, ni toucher aux clés d'API : cela reste dans le tableau de bord Relvato, sous vos yeux.