Reprendre un WordPress en main : du live au local en SSH

Le site d’une thérapeute. WordPress, Elementor, bilingue français-anglais, hébergé chez Combell. Ma mission : une refonte. Mais avant de toucher au moindre pixel, il faut une copie de travail fidèle sur ma machine. Voici le workflow complet, exécuté en une heure environ, presque entièrement piloté par Claude Code.

Le point de départ

Un WordPress 6.9 construit avec Elementor, traduit en anglais via TranslatePress, en production sur un mutualisé Combell. Pas de documentation, pas de Git, pas d’historique : juste un accès au panneau de l’hébergeur. Et 1,3 Go annoncés côté serveur, dont je ne sais pas encore que plus de la moitié n’est que du lest.

Ma règle sur toute reprise : la production reste intouchée. On observe, on copie, on travaille sur le clone. La seule chose que j’installe côté serveur, c’est une clé.

La clé SSH : tout se joue là

La question qui a lancé la session : si je crée une clé SSH, ai-je encore besoin du mot de passe ? Réponse : non. Et cette réponse change tout le workflow.

Une clé SSH, c’est une paire de fichiers. La clé privée reste sur ma machine et n’en sort jamais. La clé publique, elle, est faite pour être diffusée : on la dépose chez l’hébergeur, et le serveur sait désormais reconnaître ma machine. Pas de secret partagé, rien à retenir, rien à taper.

# Générer une paire de clés (si vous n'en avez pas déjà une)
ssh-keygen -t ed25519

# Afficher la clé publique à copier
cat ~/.ssh/id_ed25519.pub

Le format ed25519 tient en 68 caractères là où une clé RSA en fait environ 400, pour une sécurité équivalente à du RSA-3072. Chez Combell, l’installation est un simple copier-coller dans le formulaire « SSH keys » du panneau. C’est moi qui l’ai fait, dans le navigateur : le mot de passe du compte n’a jamais transité nulle part. Ni dans un terminal, ni dans une commande, ni par l’IA.

Premier test de connexion, avec un flag que je recommande :

ssh -o PasswordAuthentication=no moncompte@ssh0xx.webhosting.be 'echo CONNECTED'

PasswordAuthentication=no force un échec franc si la clé ne fonctionne pas, au lieu de retomber silencieusement sur une demande de mot de passe. Piège au passage : l’alias ssh.mondomaine.be annoncé par Combell ne résolvait pas encore ; le nom réel du serveur, lui, fonctionne toujours.

• Plus de mot de passe - ni à retenir, ni à taper, ni à stocker en clair dans un script.
• Rien ne transite par l’IA - la clé publique n’est pas un secret, et la clé privée ne quitte pas la machine.
• Un seul tunnel pour tout - ssh, scp, rsync, et plus tard le déploiement vers le staging.
• L’automatisation devient possible - l’IA enchaîne des dizaines de commandes distantes sans intervention.

L’environnement local d’abord

Avant de rapatrier quoi que ce soit, la machine doit être prête à servir le site : vhost Apache en HTTP et HTTPS, certificat local signé par mkcert (le domaine en .test a rejoint un certificat multi-domaines qui en compte désormais 104), base MySQL en utf8mb4, entrée dans /etc/hosts. Vingt minutes de mécanique, scriptées à partir d’un template réutilisé de projet en projet.

Un garde-fou que je maintiens partout : l’IA ne redémarre jamais mes services. Elle prépare la configuration, la valide avec httpd -t, puis me tend la commande. C’est moi qui tape le sudo.

Inventaire à distance, puis rapatriement

La clé en place, l’inventaire se fait à distance, en lecture seule. Et il paye immédiatement : WP-CLI est disponible côté serveur, et sur les 1,3 Go annoncés, 724 Mo ne sont que d’anciens backups de plugins qui n’ont rien à faire dans un clone.

La base d’abord : un dump WP-CLI directement sur le serveur, compressé avant transfert :

ssh moncompte@ssh0xx.webhosting.be 'cd www && wp db export /tmp/dump.sql && gzip -f /tmp/dump.sql'
scp moncompte@ssh0xx.webhosting.be:/tmp/dump.sql.gz ./_import/

145 Mo de SQL deviennent 16 Mo de transfert. Sur un site Elementor, le dump est dominé par du JSON qui se compresse à merveille : neuf fois moins d’octets qui voyagent.

Les fichiers ensuite, avec rsync et une liste d’exclusions : backups, caches, logs. Résultat final : 23 952 fichiers et 438 Mo au lieu de 1,3 Go. Mais pas du premier coup, et les échecs méritent d’être racontés :

• macOS n’a plus le vrai rsync - le système fournit openrsync, qui rejette des options modernes comme --info=progress2. Échec immédiat.
• Un pipe maquille l’échec - rsync ... | tail renvoie le code de sortie de tail, jamais celui de rsync. Le transfert a été déclaré « réussi » alors que zéro fichier n’avait été copié. Depuis : set -o pipefail et un log dans un fichier.
• Chemin absolu obligatoire en tâche de fond - un ./ relatif lancé du mauvais répertoire copie le site... ailleurs. Arrêt d’urgence, vérification, relance propre.

Adapter le clone sans rien casser

Un clone WordPress ne démarre pas tout seul. La liste des adaptations est courte, mais chacune est non négociable :

• wp-config.php regénéré de zéro - celui de la production contient les identifiants MySQL du serveur live. Il est archivé hors du site servi, jamais réutilisé.
• Salts neufs - réutiliser les clés de sécurité de la prod permettrait de forger, depuis le clone, un cookie de session valide sur le site en ligne. Regénérés via l’API de wordpress.org.
• Search-replace du domaine - 19 420 remplacements de l’URL de production vers l’URL locale, dont 2 459 dans du PHP sérialisé. wp search-replace recalcule les longueurs de chaînes ; un sed brut aurait détruit toutes les mises en page Elementor.
• Plugins de prod neutralisés - le cache LiteSpeed (pages blanches sans le module serveur), Wordfence (timeouts en local), et surtout la double authentification : ses codes TOTP sont liés aux appareils enregistrés en prod. Sans désactivation, l’admin du clone est inaccessible à jamais.

Une frayeur pour finir : trois fichiers aux noms louches à la racine, comme laissés par un intrus. Analyse ligne par ligne, à la recherche des marqueurs classiques de backdoor : rien. Deux copies manuelles de fichiers WordPress légitimes et un renommage défensif opéré par Wordfence. Un nom étrange n’est pas une compromission : on vérifie avant de conclure.

Vérifier avant de crier victoire

Premier chargement : 1 162 octets servis, et le contenu d’un autre projet local. Deux pannes empilées. Apache tournait en mémoire avec une configuration antérieure au nouveau vhost : redémarrage, et la requête arrive enfin au bon endroit. Puis un index.html de maintenance oublié depuis 2023 masquait silencieusement tout WordPress : en production, le .htaccess le contournait ; en local, non. Déplacé, affaire classée.

Ensuite seulement, la batterie de contrôles : homepage en 200 et 183 Ko, login, page contact et version anglaise en 200, certificat accepté sans avertissement, zéro occurrence résiduelle du domaine de production dans le HTML. Dernier contrôle, visuel : une capture d’écran pilotée via le protocole DevTools de Chrome. Logo, menu, slider, sélecteur de langue : le clone est fidèle.

Brancher l’IA sur WordPress : deux plugins MCP

Le clone tourne. Reste à donner à l’IA un accès propre à l’intérieur de WordPress, pas seulement au serveur. C’est le rôle de deux plugins, activés uniquement en local :

• MCP Adapter - le pont officiel de l’initiative « AI Building Blocks » de WordPress.org : il expose l’Abilities API de WordPress selon le protocole MCP, celui que parlent Claude et les autres agents.
• EMCP Tools - la surcouche Elementor : plus d’une centaine d’outils pour lire et manipuler widgets, templates, popups, réglages globaux et médias, avec les écritures sensibles désactivées par défaut.

Les deux canaux sont complémentaires : la clé SSH parle au serveur (fichiers, base, WP-CLI), les plugins MCP parlent à WordPress lui-même (contenus, design Elementor). L’authentification passe par un Application Password dédié, pas par le mot de passe de connexion. Et ces plugins restent sur le clone : rien de tout cela ne part en production.

Les chiffres

Et le serveur de développement ?

C’est la suite du même workflow, et la clé SSH resservira telle quelle. La mécanique, je l’ai déjà éprouvée sur un autre WordPress déployé vers un staging mutualisé : export de la base avec wp search-replace --export (sérialisation gérée d’office), archive tar.gz du site en excluant wp-config.php et les deux plugins MCP, transfert rsync, puis import en forçant --default-character-set=utf8mb4. Sans ce dernier flag, les caractères accentués doublent d’encodage au passage et les « N° » deviennent des hiéroglyphes. Enfin : blog_public=0 pour interdire l’indexation du staging, et purge des CSS générés par Elementor.

Le principe reste le même dans les deux sens : le live n’est jamais un environnement de travail. Local pour construire, staging pour montrer, production pour publier.

Les limites

• Un clone contient de vraies données - formulaires, comptes, entrées historiques. Ce dump ne se partage pas, ne se versionne pas, ne s’envoie à personne. Le RGPD ne s’arrête pas à la production.
• Le clone n’est pas un staging - il prouve que le site fonctionne sur ma machine, pas qu’une mise à jour majeure passera en production. La migration Elementor 3 vers 4, par exemple, attendra un vrai staging.
• L’IA exécute, elle ne décide pas - chaque action sensible est restée derrière une validation humaine : le sudo, le redémarrage des services, le choix de ce qu’on rapatrie.

Le bilan

• La clé SSH est le premier geste, pas un détail - dix minutes d’installation, et tout le reste du workflow devient scriptable.
• WP-CLI côté serveur change l’échelle - dump, search-replace, gestion des plugins : tout se fait en commandes, sans interface web.
• Les échecs sont des données - openrsync, le pipe menteur, l’index.html fantôme : chaque piège documenté fait gagner une heure sur le prochain projet.
• Rien de magique là-dedans - une clé, un tunnel, des outils standard vieux de vingt ans. La nouveauté, c’est qu’une IA les enchaîne sans fatigue et documente tout au passage.