Claude Code sur WordPress : intervenir sans casser le site

Claude Code sur WordPress : la règle qui évite la casse

Claude Code peut travailler sur un site WordPress existant sans le casser, à condition de ne jamais toucher la production. La méthode tient en cinq éléments : une copie de préproduction, un dépôt Git du code maison, une sauvegarde de la base avec WP-CLI, des permissions restreintes et une relecture humaine de chaque modification avant mise en ligne.

Ce tutoriel s’adresse aux dirigeants et aux responsables techniques qui veulent confier des évolutions de thème ou d’extension à un agent IA. Le risque ne vient pas de l’IA elle-même : une seule erreur PHP fatale poussée à chaud suffit à produire une erreur critique, un écran blanc ou une erreur 500. Un humain pressé provoque les mêmes pannes. La méthode ci-dessous les rend récupérables.

Prérequis

• Un site WordPress dont tu contrôles l’hébergement (accès SFTP ou SSH, accès à la base).
• Claude Code installé sur ton poste (voir le guide du premier projet).
• Git installé en local.
• WP-CLI disponible sur le serveur de préproduction et sur la production.
• Une personne qui relit le code : toi, un développeur ou ton agence.

Étape 1 : crée une copie de préproduction

Une préproduction (ou staging) est une copie complète du site, sur une adresse séparée, où l’on teste les changements avant de toucher le site en ligne. Claude Code ne travaille que là.

Plusieurs outils clonent la production en quelques clics. WP STAGING en est un exemple : l’extension permet de cloner la production, de tester et de restaurer une sauvegarde. Ton hébergeur propose peut-être aussi un clonage intégré. Peu importe l’outil, vérifie trois points :

• la préproduction n’est pas indexée par Google (réglage « Demander aux moteurs de recherche de ne pas indexer ce site ») ;
• elle n’envoie pas d’e-mails clients ni de commandes réelles ;
• elle est protégée par un mot de passe.

Active ensuite le mode debug sur cette copie uniquement. WP_DEBUG est une constante PHP qui fait afficher toutes les erreurs, notices et avertissements, alors que PHP n’affiche sinon que les erreurs fatales ou laisse un écran blanc source : WordPress Advanced Administration Handbook, 2026.

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

L’option --raw écrit des booléens sans guillemets. Cela compte : la documentation WordPress précise que 'false' entre apostrophes est interprété comme true. Les erreurs vont dans wp-content/debug.log, que Claude Code lira.

Étape 2 : mets le code maison dans un dépôt Git

Seul le code que tu maintiens va dans Git : ton thème enfant ou sur-mesure et tes extensions maison. Le cœur de WordPress, les extensions du marché, les médias et la base restent dehors.

cd wp-content
git init
printf "uploads/\nplugins/*\n!plugins/mon-extension-maison/\nthemes/*\n!themes/mon-theme/\n" > .gitignore
git add . && git commit -m "État initial du code maison"
git switch -c evolution-formulaire

Chaque demande à Claude Code se fait sur une branche dédiée. Tu obtiens un historique lisible et un retour arrière en une commande. Les règles de conduite de l’agent (conventions de code, dossiers interdits) se déclarent dans un fichier décrit dans CLAUDE.md et AGENTS.md.

Étape 3 : sauvegarde la base avant chaque session

Git protège les fichiers, pas la base de données. Exporte-la avant de commencer, depuis la racine WordPress (là où se trouve wp-config.php) :

wp db export sauvegarde-2026-10-23.sql
ls -lh sauvegarde-2026-10-23.sql

WP-CLI est l’interface en ligne de commande de WordPress : elle lit wp-config.php pour trouver les identifiants de la base et appelle mysqldump pour l’export source : TeamUpdraft, 2026. Vérifie que le fichier existe et que sa taille est plausible. L’option --exclude_tables= permet d’écarter les tables volumineuses de logs.

Cette sauvegarde de la préproduction ne remplace pas celle de la production, que tu feras à l’étape 6. Claude Code n’est pas un système de sauvegarde : il modifie des fichiers, il ne garantit aucune restauration.

Étape 4 : cadre les permissions de Claude Code

Claude Code lit le code, exécute des commandes shell et modifie des fichiers. Ses réglages de permissions définissent ce qu’il peut faire sans te demander.

Depuis la version 2.1.283, le mode Auto est le mode de permission par défaut dans le terminal interactif et dans VS Code source : Anthropic, 2026. Pour un site client, choisis explicitement un mode plus strict : Manual (tu approuves chaque édition et chaque commande) ou plan (exploration sans modification). La documentation de sécurité précise que les règles deny correspondent à la commande telle qu’elle est écrite, et que la garantie réseau passe par l’isolation du sandbox source : Anthropic, 2026.

Dans .claude/settings.json du projet :

{
  "permissions": {
    "deny": [
      "Read(./wp-config.php)",
      "Edit(./wp-config.php)",
      "Read(./.env)",
      "Bash(ssh *)",
      "Bash(scp *)",
      "Bash(rsync *)"
    ]
  }
}

wp-config.php contient les identifiants de la base et les clés de sécurité. Aucun accès SSH ni base de production ne doit exister dans l’environnement de l’agent. Audite régulièrement avec /permissions. Pour aller plus loin sur les droits des outils connectés, lis les serveurs MCP et leurs droits.

Étape 5 : fais travailler l’agent, puis relis tout

Donne une demande précise, avec le fichier concerné et le résultat attendu. Demande-lui de lire la fin de debug.log après chaque test. Puis relis le diff :

git diff --stat
git diff

La documentation officielle recommande de relire toutes les modifications suggérées avant de les approuver. Contrôle trois choses : aucune clé ou mot de passe écrit en dur, aucune requête SQL sans $wpdb->prepare(), aucun fichier modifié hors du périmètre demandé. Une revue de sécurité avec Claude Code peut compléter ta lecture, sans la remplacer.

Étape 6 : déploie le code, jamais la base

Avant toute mise en ligne, sauvegarde la production : fichiers et base. Le principe vient du guide de TeamUpdraft : pousser seulement le code (thèmes et extensions) sans écraser la base de production, sinon on perd les contenus ou les commandes créés entre-temps source : TeamUpdraft, 2026.

1. Fusionne la branche relue dans la branche principale.
2. Déploie uniquement les fichiers du thème ou de l’extension modifiés.
3. Vide les caches.
4. Teste les parcours clés : accueil, connexion à l’administration, formulaire de contact, panier si le site est marchand.
5. Retire les constantes de debug si tu les avais activées en production.

Garde la sauvegarde sous la main pendant les premières heures. Le risque ne tombe jamais à zéro, il devient gérable.

Que faire si une panne survient malgré tout

WordPress envoie aussi un e-mail « Your Site is Experiencing a Technical Issue » avec un lien à usage unique vers le mode de récupération, qui désactive le code défaillant pour la session seulement source : WisdmLabs, 2026.

Questions fréquentes

Pièges courants

• Travailler sur la production « juste pour un petit correctif ». C’est l’origine de la plupart des pannes évoquées plus haut.
• Écraser la base de production avec celle de la préproduction. Tu perdrais les commandes et contenus créés entre-temps.
• Laisser wp-config.php lisible par l’agent. Interdis sa lecture et son édition.
• Écrire 'false' entre guillemets dans la configuration de debug. WordPress l’interprète comme true et affiche les erreurs aux visiteurs.
• Oublier de retirer le debug après les tests.
• Valider un diff sans le lire. Si personne ne relit, l’agent ne fait que produire plus vite des erreurs.

Règle à retenir : la sauvegarde et la relecture sont tes deux garde-fous, et aucun des deux n’est délégable à l’agent.