Les commandes WP-CLI essentielles pour gerer WordPress

Credit : Logo officiel

Les commandes WP-CLI essentielles pour gerer WordPress

Dylan D. — Agent Support Technique Serveur WordPress 1842 mots 10 min de lecture

Les commandes WP-CLI essentielles pour gerer WordPress

Vendredi, 17h42. Un client m'appelle paniqué : son site WordPress affiche une erreur fatale après une mise à jour automatique d'un plugin. Le back-office est inaccessible. En SSH sur le serveur, je tape wp plugin deactivate woocommerce-extra --allow-root et le site revient en ligne en deux secondes. C'est exactement pour ça que WP-CLI est installé sur tous les VPS que je gère. Quand l'interface graphique est cassée, la ligne de commande, elle, fonctionne toujours.

WP-CLI est l'outil officiel pour piloter WordPress depuis un terminal. Sur Debian 12 avec PHP 8.3 et WordPress 6.7, je l'utilise quotidiennement pour automatiser des dizaines de tâches qui prendraient des heures dans wp-admin. Voici les commandes que j'ai vraiment besoin de connaître par cœur.

Installer WP-CLI proprement

L'installation officielle se fait en téléchargeant le .phar directement, pas via apt (le paquet Debian est souvent en retard).

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
mv wp-cli.phar /usr/local/bin/wp
wp --info

La sortie attendue ressemble à ça :

OS:     Linux 6.1.0-13-amd64
PHP binary:    /usr/bin/php8.3
PHP version:    8.3.7
WP-CLI version:    2.10.0

Auto-complétion bash

À ne jamais oublier sur un serveur où vous passerez du temps :

curl -O https://raw.githubusercontent.com/wp-cli/wp-cli/main/utils/wp-completion.bash
mv wp-completion.bash /etc/bash_completion.d/
source /etc/bash_completion.d/wp-completion.bash

Règle d'or sur l'utilisateur

WP-CLI refuse par défaut de s'exécuter en root. Pour de bonnes raisons : si une commande malveillante s'exécute via un fichier compromis, vous lui donnez les clés du serveur. La bonne pratique : créer un utilisateur dédié au site.

adduser --disabled-password --gecos "" deployer
usermod -aG www-data deployer
su - deployer -c "cd /var/www/monsite.fr && wp plugin list"

Le flag --allow-root reste utile pour des scripts ponctuels d'urgence, mais c'est l'exception, pas la règle.

Gérer le core WordPress

Installation complète depuis zéro

Voici comment je provisionne un nouveau site en moins de 30 secondes :

cd /var/www
mkdir monsite.fr && cd monsite.fr
wp core download --locale=fr_FR
wp config create --dbname=wp_monsite --dbuser=wp_user --dbpass='M0t-Solide!' --locale=fr_FR
wp core install --url=monsite.fr \
  --title="Mon Site" \
  --admin_user=admin \
  --admin_password='S3cure-Passw0rd!' \
  --admin_email=admin@monsite.fr

Mises à jour

wp core check-update
wp core update
wp core update-db
wp core version --extra

update-db est crucial après une montée de version majeure : elle met à jour le schéma SQL. Si vous l'oubliez, vous aurez des comportements bizarres en back-office.

Gérer les plugins en masse

Le quotidien d'un admin, c'est jongler avec des dizaines de plugins. WP-CLI rend ça trivial.

wp plugin list --format=table
wp plugin list --update=available --field=name
wp plugin install wordpress-seo wp-super-cache redirection --activate
wp plugin update --all --quiet
wp plugin deactivate akismet hello
wp plugin delete hello

En production, je préfère toujours mettre à jour un plugin à la fois et tester :

for plugin in $(wp plugin list --update=available --field=name); do
  echo "--- Mise a jour de $plugin"
  wp plugin update $plugin
  curl -s -o /dev/null -w "%{http_code}\n" https://monsite.fr
done

Ce boucle met à jour, puis vérifie que la home renvoie toujours 200. Si elle renvoie 500, j'arrête et j'investigue.

Gérer les thèmes

Même logique :

wp theme list
wp theme install astra --activate
wp theme update --all
wp theme delete twentytwentytwo twentytwentythree

Un thème inactif reste une surface d'attaque (les vulnérabilités s'y cachent). Je supprime systématiquement tous les thèmes par défaut sauf un (pour le mode dépannage).

Gérer les utilisateurs

wp user list --format=table --fields=ID,user_login,user_email,roles
wp user create editeur editeur@monsite.fr --role=editor --user_pass='Tmp123!'
wp user update 1 --user_email=nouveau@monsite.fr
wp user delete 5 --reassign=1
wp user reset-password 1 --skip-email

Le --skip-email est précieux quand SMTP n'est pas configuré : la nouvelle valeur s'affiche directement dans la sortie.

Pour créer un super-admin d'urgence quand vous êtes verrouillé hors du back-office :

wp user create urgence urgence@monsite.fr --role=administrator --user_pass='Urg3nce!'

C'est le scénario que je couvre en détail dans Créer un compte admin WordPress en urgence.

Gérer la base de données

Sauvegarde et restauration

wp db export /backups/monsite-$(date +%F).sql
wp db import /backups/monsite-2026-05-01.sql

Optimisation et réparation

wp db optimize
wp db repair
wp db size --tables

La sortie de wp db size --tables :

+-------------------+---------+
| Name              | Size    |
+-------------------+---------+
| wp_options        | 12.5 MB |
| wp_postmeta       | 45.2 MB |
| wp_posts          | 8.1 MB  |
| wp_users          | 0.1 MB  |
+-------------------+---------+

Une wp_options qui dépasse 50 Mo est un signal d'alarme : il y a probablement des transients orphelins ou un plugin qui pollue les options auto-loaded.

Requêtes ad hoc

wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_type='revision';"
wp db query "SELECT option_name, LENGTH(option_value) AS taille FROM wp_options WHERE autoload='yes' ORDER BY taille DESC LIMIT 10;"

Nettoyer les révisions

wp post delete $(wp post list --post_type=revision --format=ids) --force

Sur un site éditorial avec 5 ans d'historique, j'ai déjà récupéré 800 Mo en exécutant cette ligne.

Search-Replace : la commande qui sauve les migrations

Quand vous changez de domaine ou passez en HTTPS, les URL sont sérialisées partout dans la base. Un simple UPDATE MySQL casserait les données. WP-CLI gère la sérialisation correctement.

wp search-replace 'http://ancien-domaine.fr' 'https://nouveau-domaine.fr' --dry-run
wp search-replace 'http://ancien-domaine.fr' 'https://nouveau-domaine.fr' \
  --precise --all-tables --report-changed-only

Le --dry-run est obligatoire en première passe. Le --all-tables capture les tables non préfixées de plugins comme WooCommerce ou WPML.

Pour les migrations complètes, voir Migrer un site WordPress sans coupure.

Gérer le cron WordPress

WP-Cron s'exécute à chaque chargement de page, ce qui est désastreux en termes de performances et de fiabilité (un site sans trafic n'a pas de cron qui tourne).

wp cron event list
wp cron event run --due-now
wp cron schedule list
wp cron test

La bonne pratique : désactiver WP-Cron et le déclencher via crontab système.

Dans wp-config.php :

define('DISABLE_WP_CRON', true);

Dans crontab -e -u www-data :

*/5 * * * * cd /var/www/monsite.fr && /usr/local/bin/wp cron event run --due-now --quiet

Gérer les options et transients

wp option get siteurl
wp option update blogname "Mon Nouveau Titre"
wp option list --search="*_transient_*" --format=count
wp transient delete --all

Vider les transients règle 30% des problèmes de cache mystérieux. C'est mon premier réflexe quand un client me dit "le site bug bizarrement".

Lister les options auto-loaded gourmandes

Les options chargées automatiquement à chaque requête PHP sont la cause numéro 1 de TTFB élevé sur WordPress. Voici la requête que je lance systématiquement lors d'un audit perf :

wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024,2) AS Ko \
  FROM wp_options WHERE autoload='yes' \
  ORDER BY LENGTH(option_value) DESC LIMIT 15;"

Sortie typique d'un site infecté ou mal configuré :

+-------------------------------+--------+
| option_name                   | Ko     |
+-------------------------------+--------+
| _wpcom_query_cache            | 8420.5 |
| widget_text                   | 145.2  |
| rewrite_rules                 | 89.7   |
+-------------------------------+--------+

Une option qui dépasse 500 Ko en autoload doit être basculée en non-autoload ou supprimée.

Gérer les médias et la bibliothèque

WP-CLI sait régénérer les miniatures, importer des images en masse et nettoyer les médias orphelins.

wp media regenerate --yes
wp media import /tmp/photos/*.jpg --post_id=42 --title="Galerie produit"
wp media list --field=ID --format=ids | wc -l

Après un changement de thème qui modifie les tailles d'images, wp media regenerate est obligatoire pour éviter les vignettes étirées.

Erreurs courantes et leur fix

Error: YIKES! It looks like you're running this as root.

Cause : vous avez lancé wp sans --allow-root en étant connecté en root.

Solution : passez sur l'utilisateur du site (su - www-data -s /bin/bash) ou ajoutez --allow-root pour les scripts d'urgence uniquement.

Error: This does not seem to be a WordPress installation.

Cause : vous n'êtes pas dans le répertoire racine de WordPress, ou wp-config.php est manquant/cassé.

Solution : cd /var/www/monsite.fr puis vérifiez que wp-config.php existe et est lisible. Sinon, utilisez --path=/var/www/monsite.fr.

PHP Fatal error: Allowed memory size exhausted

Cause : une commande lourde (export DB, search-replace) dépasse la memory_limit PHP CLI.

Solution : php -d memory_limit=1G /usr/local/bin/wp db export backup.sql ou ajustez /etc/php/8.3/cli/php.ini.

Error: Site checksum verification failed for X files

Cause : wp core verify-checksums détecte des fichiers core modifiés. Souvent un signe d'infection malware.

Solution : forcez un retéléchargement avec wp core download --force. Si ça revient, voir Vérifier l'intégrité des fichiers WordPress.

Warning: Some code is trying to do a URL redirect

Cause : un plugin tente une redirection HTTP pendant l'exécution CLI (typique des plugins de cache mal codés).

Solution : désactivez temporairement le plugin en cause avec wp plugin deactivate nom-plugin --skip-plugins.

Importer et exporter du contenu

WP-CLI gère parfaitement les exports/imports WXR. Pratique pour cloner du contenu d'un site à l'autre :

wp export --dir=/tmp --start_date=2025-01-01 --end_date=2025-12-31
wp import /tmp/monsite.wordpress.2026-01-01.xml --authors=create

Sur un site qui contient 50 000 articles, l'export prend du temps. Lancez-le dans un tmux ou avec nohup pour ne pas être coupé par la déconnexion SSH. Voir Utiliser tmux pour gérer ses sessions terminal.

Travailler avec le multisite

Sur une installation multisite, ajoutez --url= à chaque commande pour cibler un site spécifique :

wp site list
wp plugin update --all --url=blog.monsite.fr
wp post list --url=boutique.monsite.fr --post_type=product

Pour appliquer une commande à tous les sites :

for url in $(wp site list --field=url); do
  wp plugin update --all --url=$url
done

Script de maintenance hebdomadaire

J'utilise ce script en cron sur tous les sites que je maintiens :

#!/bin/bash
set -e
SITE=/var/www/monsite.fr
LOG=/var/log/wp-maintenance.log

cd $SITE
echo "=== Maintenance $(date) ===" >> $LOG
wp core update >> $LOG 2>&1
wp plugin update --all >> $LOG 2>&1
wp theme update --all >> $LOG 2>&1
wp db optimize >> $LOG 2>&1
wp transient delete --expired >> $LOG 2>&1
wp cache flush >> $LOG 2>&1
echo "=== Termine $(date) ===" >> $LOG

Cron hebdomadaire :

0 3 * * 1 /usr/local/bin/wp-maintenance.sh

Pour aller plus loin

Le terminal, votre meilleur allié WordPress

WP-CLI transforme ce qui prend dix clics et deux minutes en une seule ligne. Une fois que vous avez automatisé les dix commandes que j'utilise tous les jours, gérer cinquante sites devient aussi simple que d'en gérer un. Et le jour où le back-office tombe, vous avez toujours une porte de service ouverte. Mes deux conseils pour aller vite : créez des alias bash (alias wpm='wp --allow-root --skip-plugins=wp-rocket,jetpack') pour les commandes que vous tapez tous les jours, et versionnez vos scripts de maintenance dans un repo Git pour les déployer sur tous vos serveurs avec un simple git pull.

# Articles similaires

Sur les memes sujets et plus loin