WP-CLI et alias SSH : administrer un parc de sites multi-serveurs

Sur un parc d’une trentaine de sites répartis sur plusieurs serveurs, lancer une commande WP-CLI identique sur chacun d’eux — vérifier une version de plugin, vider un cache, exporter une liste d’utilisateurs — signifiait, jusqu’à récemment, une connexion SSH par site, un cd vers le bon dossier, puis la commande elle-même. Un exercice fastidieux et propice aux erreurs d’inattention. Les alias WP-CLI éliminent presque entièrement cette friction.

Le principe d’un alias WP-CLI

Un alias associe un nom court à la définition complète d’un site — distant ou local, y compris son chemin d’accès et éventuellement ses identifiants de connexion SSH. Une fois déclaré, on l’utilise en préfixe de n’importe quelle commande WP-CLI habituelle, exactement comme si on était connecté physiquement au bon serveur.

# wp-cli.yml, à la racine du poste ou d'un dépôt de configuration
@production:
  ssh: deploy@serveur-prod.exemple.fr
  path: /var/www/site

@staging:
  ssh: deploy@serveur-staging.exemple.fr
  path: /var/www/site

@toutes:
  - @production
  - @staging

wp @production plugin list
wp @staging cache flush
wp @toutes core version

La dernière ligne est celle qui change vraiment la donne : wp @toutes core version exécute la commande sur chaque site du groupe @toutes, l’un après l’autre, et affiche un résultat consolidé indiquant clairement quel site a répondu quoi.

Un fichier d’alias par parc de sites

Sur nos projets d’agence, on maintient un fichier wp-cli.yml dédié à l’administration du parc, distinct de celui de chaque projet individuel, versionné dans un dépôt privé accessible à l’équipe technique :

@site-a-prod:
  ssh: deploy@srv1.exemple.fr
  path: /var/www/site-a

@site-b-prod:
  ssh: deploy@srv1.exemple.fr
  path: /var/www/site-b

@site-c-prod:
  ssh: deploy@srv2.exemple.fr
  path: /var/www/site-c

@parc-srv1:
  - @site-a-prod
  - @site-b-prod

@parc-complet:
  - @site-a-prod
  - @site-b-prod
  - @site-c-prod

Cette organisation en groupes imbriqués permet de cibler précisément un serveur, un sous-ensemble de sites, ou l’ensemble du parc selon le besoin de l’opération. Vérifier une vulnérabilité sur un plugin précis devient une seule commande :

wp @parc-complet plugin get contact-form-7 --field=version

Un cas d’usage concret : la veille de sécurité

Quand une faille de sécurité est annoncée sur un plugin largement utilisé, la première question est toujours la même : sur combien de sites du parc ce plugin est-il actif, et dans quelle version ? Avec les alias, la réponse tient en une commande, sans ouvrir une seule session SSH manuelle :

wp @parc-complet plugin list --name=nom-du-plugin --format=csv

Sur un incident de sécurité réel qu’on a traité récemment, cette seule commande a permis d’identifier en moins d’une minute les quatre sites concernés sur notre parc, contre une bonne demi-heure de vérifications manuelles avec l’ancienne méthode.

Sécuriser l’accès aux alias

Bonne pratique	Pourquoi
Clé SSH dédiée, avec passphrase	Limite l’impact si le poste d’un développeur est compromis
Fichier wp-cli.yml hors du dépôt de code public	Évite d’exposer la topologie du parc de serveurs
Utilisateur SSH aux droits limités sur chaque serveur	Réduit la portée d’un accès détourné

On évite systématiquement de commiter le fichier d’alias de production dans un dépôt accessible à toute l’équipe : seuls les profils qui interviennent réellement en production y ont accès, via un dépôt de configuration séparé et restreint.

Les alias WP-CLI n’ajoutent aucune capacité que SSH ne permettait déjà. Ce qu’ils changent, c’est le coût cognitif d’une opération répétée sur plusieurs sites — et un coût cognitif plus faible se traduit directement par moins d’oublis et moins d’erreurs.

En résumé

Passer par des alias WP-CLI transforme la gestion d’un parc de sites d’une série d’opérations manuelles répétitives en une poignée de commandes centralisées, versionnables et partageables au sein d’une équipe. C’est un investissement de configuration modeste — un fichier YAML, quelques minutes de rédaction — pour un gain de fiabilité qui se voit surtout le jour où une intervention urgente touche l’ensemble du parc.