La maintenance d’un parc de sites WordPress ressemble souvent à une tournée d’inspection : on se connecte, on regarde si les extensions sont à jour, si l’espace disque tient encore, si la base de données n’a pas grossi anormalement. Fait manuellement sur quinze ou vingt sites, ce rituel prend une matinée entière et reste sujet à l’oubli. wp doctor, paquet officiel de WP-CLI, transforme cette tournée en une seule commande scriptable.
Le principe est simple : un ensemble de « vérifications » (checks) s’exécutent les unes après les autres et rapportent chacune un statut — succès, avertissement ou échec — avec un message explicite. On peut lancer tous les checks d’un coup, un groupe précis, ou écrire les siens pour des vérifications propres à un projet.
Installation et premier lancement
wp package install wp-cli/doctor-command
wp doctor check --all
La sortie liste chaque vérification avec son statut. Sur un site typique, on retrouve par exemple des checks sur la version de PHP, la présence de fichiers volumineux dans wp-content/uploads, l’activation du débogage en production (WP_DEBUG à true sur un site public est une faute classique), ou encore la taille de la table options, souvent gonflée par des « options autoload » oubliées par une extension mal codée.
Lister et cibler des checks précis
Pour ne pas relancer l’intégralité des vérifications à chaque fois, wp doctor list affiche les checks disponibles avec leur nom et leur catégorie, et wp doctor check accepte une liste de noms en argument :
wp doctor list
wp doctor check core-update autoload-options-size --format=table
Écrire une vérification personnalisée
L’intérêt réel de wp doctor apparaît quand on ajoute des checks maison, adaptés aux conventions internes d’une agence. Un check se déclare comme une classe PHP qui étend WP_CLI\Doctor\Checks\Check, enregistrée dans un fichier de démarrage WP-CLI (wp-cli.local.yml ou un fichier chargé via require) :
class Verifier_Compte_Admin_Generique extends \WP_CLI\Doctor\Checks\Check {
public function get_name() {
return 'compte-admin-generique';
}
public function run() {
$utilisateur = get_user_by( 'login', 'admin' );
if ( $utilisateur ) {
return array(
'status' => 'error',
'message' => 'Un compte "admin" existe encore, à renommer ou supprimer.',
);
}
return array(
'status' => 'success',
'message' => 'Aucun compte administrateur générique détecté.',
);
}
}
WP_CLI\Doctor\Checks\Check_Registry::add_check(
'securite',
new Verifier_Compte_Admin_Generique()
);
Ce check illustre un cas fréquent : un compte admin laissé par défaut est une cible évidente pour les attaques par force brute, et c’est le genre de vérification qu’on oublie de refaire manuellement sur chaque site du parc.
Intégrer wp doctor à la routine de maintenance
Sur un parc de sites, l’intérêt de wp doctor se révèle surtout une fois automatisé. On l’appelle depuis un script de maintenance hebdomadaire, avec une sortie au format JSON pour la rendre exploitable par un autre outil :
#!/usr/bin/env bash
for SITE in /var/www/*/; do
cd "$SITE" || continue
RESULTAT=$(wp doctor check --all --format=json 2>/dev/null)
echo "$RESULTAT" | jq -e '.[] | select(.status == "error")' > /dev/null \
&& echo "ALERTE sur $SITE"
done
Ce script parcourt chaque site du serveur, exécute tous les checks, et signale uniquement ceux qui contiennent au moins une erreur. Combiné à un envoi de notification (e-mail, message sur un salon de discussion interne), il transforme la tournée manuelle en surveillance passive.
Ce que wp doctor ne fait pas
- Il ne corrige rien automatiquement : chaque check ne fait que rapporter un statut, à charge pour l’humain ou un autre script d’agir ;
- Il ne remplace pas un scanner de sécurité dédié : ses checks de sécurité restent basiques (comptes génériques, débogage actif) et ne couvrent pas les vulnérabilités connues des extensions ;
- Les checks personnalisés doivent être maintenus dans le temps, comme n’importe quel code : un check qui référence une fonction dépréciée finira par échouer pour de mauvaises raisons.
Notre conseil maison : commencez avec les checks fournis par défaut pendant quelques semaines avant d’écrire les vôtres. On repère ainsi les angles morts réels de son parc plutôt que de deviner à l’avance ce qui mérite un check personnalisé.
Pour aller plus loin
wp doctor gagne encore en intérêt combiné à un outil de supervision plus large (Nagios, Zabbix, ou un simple tableau de bord interne) qui centralise les résultats de plusieurs serveurs. Pris seul, il reste déjà une manière économique de transformer une tournée manuelle en script reproductible, ce qui est souvent le premier pas vers une vraie routine de maintenance de parc.
