Mettre à jour WordPress en SSH avec WP-CLI : core, extensions et thèmes

Sur mon serveur, j’ai fait le choix de ne pas installer de serveur FTP.

Pourquoi ? Et bien tout simplement parce que le protocole FTP n’est pas du tout sécurisé : les mots de passe sont envoyés en clair sur le réseau, il n’y a aucun chiffrement appliqué sur la connexion et il existe 1001 manières d’en forcer l’accès.

Mettre WordPress à jour depuis l’administration, c’est pratique. Pourtant, sur un serveur dédié, ce n’est pas toujours la méthode la plus propre.

Si WordPress vous demande des identifiants FTP, ce n’est pas forcément un bug. Le problème vient souvent des permissions fichiers, du propriétaire des répertoires, ou d’une configuration serveur qui empêche WordPress d’écrire correctement dans son propre dossier.

Historiquement, on pouvait contourner le problème avec l’extension PHP SSH2 et quelques constantes dans wp-config.php. Aujourd’hui, sur un serveur sérieux, je préfère une approche plus robuste : SSH + WP-CLI + permissions propres.

Pourquoi éviter FTP pour gérer WordPress ?

FTP n’a plus grand-chose à faire dans une maintenance WordPress moderne. Les identifiants circulent sans chiffrement avec FTP classique, la gestion des droits devient vite sale, et l’on finit souvent par ouvrir trop largement les permissions pour “que ça marche”. Magnifique stratégie, si l’objectif est d’inviter les ennuis à dîner.

Sur un serveur dédié ou un VPS, privilégiez plutôt :

• SSH pour accéder au serveur de manière chiffrée ;
• WP-CLI pour piloter WordPress en ligne de commande ;
• des permissions strictes pour éviter les dossiers modifiables par n’importe qui ;
• des sauvegardes avant mise à jour, parce que même les bons outils n’empêchent pas les extensions mal réveillées.

Le bon modèle : SSH pour se connecter, WP-CLI pour mettre à jour

SSH et WP-CLI ne font pas la même chose.

• SSH vous connecte au serveur.
• WP-CLI exécute les commandes WordPress depuis le terminal.

Une fois connecté en SSH, vous pouvez mettre à jour le cœur WordPress, les extensions, les thèmes, les traductions, vérifier l’état du site, vider le cache objet, exporter la base de données ou lancer des scripts de maintenance.

C’est plus rapide, plus scriptable, plus fiable, et surtout plus clair qu’un formulaire FTP dans l’administration WordPress.

Pré-requis avant de lancer les mises à jour

Avant de commencer, vérifiez ces points :

• vous avez un accès SSH au serveur ;
• WP-CLI est installé ;
• vous connaissez le chemin de l’installation WordPress ;
• le site tourne avec une version PHP compatible avec votre WordPress et vos extensions ;
• les fichiers appartiennent au bon utilisateur système ;
• vous avez une sauvegarde récente de la base et des fichiers.

Pour les permissions, j’ai un guide plus détaillé ici : WordPress : accorder les bonnes permissions aux fichiers et dossiers avec chown et chmod.

Vérifier que WP-CLI fonctionne

Connectez-vous d’abord en SSH :

ssh utilisateur@serveurLangage du code : CSS (css)

Puis allez dans le dossier du site :

cd /var/www/example.com/publicLangage du code : PHP (php)

Adaptez évidemment le chemin. Sur certains serveurs, vous aurez plutôt /home/site/public_html, /home/www/site/public_html ou un chemin propre à votre hébergeur.

Ensuite, vérifiez WP-CLI :

wp cli info

Puis vérifiez que WP-CLI reconnaît bien l’installation WordPress :

wp core version
wp option get home
wp option get siteurlLangage du code : JavaScript (javascript)

Si vous êtes dans le mauvais dossier, WP-CLI vous le dira rapidement. Il a ce tact très terminal : sec, utile, sans câlin.

Sauvegarder avant toute mise à jour

Avant une mise à jour du core, des extensions ou des thèmes, exportez la base de données :

mkdir -p ~/backups

wp db export ~/backups/wordpress-$(date +%F-%H%M%S).sql

Ensuite, sauvegardez les fichiers si votre hébergeur ne le fait pas déjà. Exemple simple avec tar :

tar -czf ~/backups/wp-files-$(date +%F-%H%M%S).tar.gz \
  --exclude='wp-content/cache' \
  --exclude='wp-content/uploads/cache' \
  .Langage du code : JavaScript (javascript)

Pour un site critique, préférez un snapshot serveur, une sauvegarde hébergeur vérifiée, ou une sauvegarde distante. Le fichier SQL dans le home, c’est bien. Une restauration testée, c’est mieux.

Lister les mises à jour disponibles

Commencez par regarder ce qui doit être mis à jour.

Pour le cœur WordPress :

wp core check-update

Pour les extensions :

wp plugin list --update=availableLangage du code : PHP (php)

Pour les thèmes :

wp theme list --update=availableLangage du code : PHP (php)

Vous pouvez aussi obtenir une sortie JSON, très pratique pour des scripts :

wp plugin list --update=available --format=json
wp theme list --update=available --format=jsonLangage du code : PHP (php)

Mettre à jour le cœur WordPress en SSH

Pour mettre à jour WordPress vers la dernière version stable :

wp core update

Ensuite, mettez à jour la base de données si WordPress le demande :

wp core update-db

Puis vérifiez la version installée :

wp core version

Pour ne faire que les mises à jour mineures du core, utilisez :

wp core update --minor

C’est utile si vous voulez appliquer les correctifs de sécurité sans passer immédiatement à une nouvelle branche majeure.

Mettre à jour les extensions WordPress

Avant d’installer quoi que ce soit, prévisualisez les mises à jour disponibles :

wp plugin update --all --dry-run

Ensuite, lancez la mise à jour :

wp plugin update --all

Pour exclure une extension sensible, par exemple WooCommerce sur une boutique active :

wp plugin update --all --exclude=woocommerce

Pour mettre à jour une seule extension :

wp plugin update akismet

Pour limiter les mises à jour aux correctifs :

wp plugin update --all --patch

Ou aux versions mineures :

wp plugin update --all --minor

Sur un site WooCommerce, une marketplace, un LMS ou un site d’adhésion, ne mettez pas tout à jour comme un bourrin. Testez d’abord sur staging lorsque le site encaisse du chiffre.

Mettre à jour les thèmes WordPress

Pour afficher les thèmes avec une mise à jour disponible :

wp theme list --update=availableLangage du code : PHP (php)

Pour tout mettre à jour :

wp theme update --all

Pour mettre à jour un thème précis :

wp theme update generatepress

Si vous utilisez un thème enfant, vérifiez surtout le thème parent. Le thème enfant, lui, contient normalement vos personnalisations et ne doit pas être remplacé par une mise à jour automatique venue de nulle part.

Mettre à jour les traductions

Après les mises à jour du core, des extensions et des thèmes, mettez aussi à jour les traductions :

wp language core update
wp language plugin update --all
wp language theme update --all

Cela évite les interfaces partiellement traduites et certains avertissements agaçants dans l’administration.

Vider les caches après mise à jour

Après une mise à jour, videz au moins le cache objet WordPress :

wp cache flush

Selon votre stack, videz aussi les caches applicatifs : page cache, Redis, OPcache, cache CDN ou cache hébergeur.

Exemple avec PHP-FPM, à adapter selon votre version PHP et votre distribution :

sudo systemctl reload php8.3-fpmLangage du code : CSS (css)

Si votre site utilise Nginx, PHP-FPM et MariaDB sur serveur dédié, vous pouvez aussi relire ce guide : installer Nginx, PHP et MariaDB sur Debian.

Contrôler que le site fonctionne encore

Une mise à jour réussie dans le terminal ne suffit pas. Vérifiez ensuite l’état réel du site.

wp core verify-checksums
wp plugin status
wp theme status

Vous pouvez aussi demander à WordPress de lister les tâches cron :

wp cron event listLangage du code : PHP (php)

Puis testez le front, l’administration, les formulaires, le panier WooCommerce si applicable, et les logs PHP/Nginx/Apache.

Cas multisite : ciblez le bon site

Sur un réseau WordPress multisite, certaines commandes doivent cibler une URL précise.

wp site list

wp plugin list --url=https://example.com
wp option get home --url=https://example.comLangage du code : PHP (php)

Pour mettre à jour le réseau, le cœur, les extensions et les thèmes restent communs. En revanche, les options, les contenus, les transients et certaines opérations de maintenance peuvent dépendre du site ciblé.

Et les constantes SSH dans wp-config.php ?

WordPress prend encore en charge des constantes comme FTP_PUBKEY, FTP_PRIKEY, FTP_USER et FTP_HOST pour renseigner des identifiants FTP ou SSH dans wp-config.php.

Exemple historique :

define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_HOST', 'localhost:22' );Langage du code : JavaScript (javascript)

Mais je ne recommande plus cette approche comme solution principale sur un serveur que vous administrez. Elle dépend de l’API Filesystem de WordPress, d’une extension PHP SSH2, et d’un modèle où WordPress doit gérer les écritures depuis l’interface web.

Pour une maintenance propre, mieux vaut utiliser WP-CLI via SSH, puis garder l’administration WordPress pour l’éditorial. Chacun son métier. Le terminal pour la maintenance, Gutenberg pour les virgules qui bougent toutes seules.

Faut-il définir FS_METHOD à direct ?

Vous verrez souvent ce réglage dans wp-config.php :

define( 'FS_METHOD', 'direct' );Langage du code : JavaScript (javascript)

Il force WordPress à écrire directement dans le système de fichiers. Cela peut résoudre une demande d’identifiants FTP, mais ce n’est pas une baguette magique.

Si les propriétaires et permissions sont mauvais, FS_METHOD masque le symptôme sans corriger l’architecture. Utilisez-le seulement si vous comprenez bien quel utilisateur écrit dans quels dossiers.

En pratique, corrigez d’abord les droits. Ensuite seulement, décidez si FS_METHOD a sa place.

Permissions recommandées pour WordPress

Sur une installation classique, on cherche généralement à éviter les permissions trop larges. Les fichiers ne doivent pas être modifiables par tout le monde.

Une base raisonnable :

find /chemin/vers/wordpress -type d -exec chmod 755 {} \;
find /chemin/vers/wordpress -type f -exec chmod 644 {} \;

Ensuite, adaptez selon votre stack. Par exemple, wp-content/uploads doit pouvoir recevoir les médias. À l’inverse, wp-admin, wp-includes et les fichiers du core n’ont pas vocation à être modifiés par le serveur web hors mise à jour contrôlée.

Évitez absolument les chmod 777 récursifs. C’est rarement la solution. En revanche, c’est souvent le début d’une journée très longue.

Script simple de mise à jour WordPress avec WP-CLI

Voici un script minimaliste pour un site classique. Il sauvegarde la base, met à jour WordPress, les extensions, les thèmes et les traductions, puis vide le cache objet.

#!/usr/bin/env bash

set -euo pipefail

WP_PATH="/var/www/example.com/public"
BACKUP_DIR="$HOME/backups"

mkdir -p "$BACKUP_DIR"

cd "$WP_PATH"

echo "Sauvegarde de la base..."
wp db export "$BACKUP_DIR/wordpress-$(date +%F-%H%M%S).sql"

echo "Vérification du core..."
wp core check-update || true

echo "Mise à jour du core..."
wp core update
wp core update-db

echo "Mise à jour des extensions..."
wp plugin update --all

echo "Mise à jour des thèmes..."
wp theme update --all

echo "Mise à jour des traductions..."
wp language core update
wp language plugin update --all
wp language theme update --all

echo "Vidage du cache objet..."
wp cache flush

echo "Version WordPress installée :"
wp core version

echo "Terminé."Langage du code : PHP (php)

Rendez-le exécutable :

chmod +x update-wordpress.shLangage du code : CSS (css)

Puis lancez-le :

./update-wordpress.sh

Pour un site en production sensible, ajoutez une étape staging, des exclusions d’extensions critiques, une sauvegarde fichiers complète et une notification Slack, email ou monitoring. La sobriété, c’est bien. La traçabilité, c’est mieux.

Erreurs fréquentes avec WP-CLI

“Error: This does not seem to be a WordPress installation”

Vous n’êtes probablement pas dans le bon dossier. Utilisez --path ou placez-vous à la racine WordPress.

wp core version --path=/var/www/example.com/publicLangage du code : PHP (php)

“Permission denied”

L’utilisateur SSH n’a pas les droits nécessaires sur les fichiers. Corrigez le propriétaire et le groupe plutôt que de balancer un chmod -R 777 dans un moment de faiblesse.

“Another update is currently in progress”

Vérifiez qu’aucune mise à jour n’est réellement en cours. Ensuite seulement, vous pouvez supprimer le verrou :

wp option delete core_updater.lockLangage du code : JavaScript (javascript)

Une extension premium ne se met pas à jour

Certaines extensions premium exigent une licence active ou une logique de mise à jour propre. Vérifiez la licence dans l’administration, puis relancez la commande.

Vous pouvez aussi essayer le contexte admin de WP-CLI, utile avec certains plugins qui chargent leurs mécanismes de mise à jour uniquement côté administration :

wp plugin update --all --context=admin

FAQ

WP-CLI remplace-t-il SSH ?

Non. SSH permet de se connecter au serveur. WP-CLI permet ensuite de piloter WordPress depuis le terminal.

Puis-je encore utiliser les mises à jour depuis wp-admin ?

Oui. Mais sur un serveur dédié, WP-CLI offre un workflow plus contrôlable, plus rapide et plus facile à automatiser.

Faut-il installer l’extension PHP SSH2 ?

Pas pour utiliser WP-CLI en SSH. L’extension SSH2 concerne surtout l’API Filesystem de WordPress lorsque WordPress tente d’écrire via SSH/SFTP depuis l’interface web.

Pourquoi WordPress demande-t-il des identifiants FTP ?

Le plus souvent, WordPress ne peut pas écrire correctement dans les fichiers. Corrigez d’abord les propriétaires et permissions du site.

Puis-je automatiser les mises à jour avec cron ?

Oui, mais faites-le prudemment. Automatisez surtout les correctifs mineurs, les traductions et les extensions peu risquées. Pour WooCommerce, les plugins de paiement ou les extensions métier, testez d’abord.

Dois-je désactiver les mises à jour automatiques WordPress ?

Pas forcément. Gardez les correctifs de sécurité automatiques si votre workflow les accepte. En revanche, contrôlez les mises à jour majeures et les extensions critiques.

Conclusion

L’ancienne méthode consistait à ajouter SSH directement dans WordPress pour éviter FTP. Elle avait du sens à une époque où WP-CLI était moins répandu et où les stacks serveur WordPress étaient moins standardisées.

Aujourd’hui, la meilleure approche sur serveur dédié consiste à utiliser SSH pour se connecter, WP-CLI pour maintenir WordPress, et des permissions strictes pour éviter les écritures inutiles.

Vous obtenez un workflow plus propre, plus rapide et plus facile à automatiser. Et surtout, vous évitez de transformer wp-admin en client FTP déguisé. Personne n’a besoin de ce cosplay-là.

Sources

• WP-CLI : commande wp core update
• WP-CLI : commande wp plugin update
• WP-CLI : commande wp theme update
• WordPress Developer Resources : Hardening WordPress
• SkyMinds : bonnes permissions WordPress avec chown et chmod
• SkyMinds : installer Nginx, PHP et MariaDB sur Debian

Report a typo