wp plugin list --format=csv --fields=name,version,update lancée sur l’environnement de recette, puis la même commande sur la production : quand une ligne diffère entre les deux sorties, l’explication d’un bug qui « ne se reproduit que chez le client » saute souvent aux yeux en moins d’une minute.
Deux environnements qui partent identiques au premier déploiement dérivent presque toujours avec le temps. Une extension mise à jour manuellement sur l’un, un correctif de sécurité appliqué en urgence sur l’autre, une désactivation temporaire jamais réactivée : chaque petite intervention creuse un écart. Le problème n’est pas l’écart lui-même, mais le fait qu’il reste invisible jusqu’au jour où il casse quelque chose en production.
Pourquoi les extensions dérivent entre deux environnements
La recette sert de terrain d’essai : on y installe une extension pour tester une fonctionnalité, on la désactive après usage, mais la désinstallation complète est oubliée. À l’inverse, la production reçoit parfois une mise à jour de sécurité poussée en urgence par l’hébergeur ou par un correctif manuel, sans que la recette suive. Au bout de quelques mois, les deux environnements racontent deux histoires différentes alors qu’ils sont censés être le même projet à deux stades différents du cycle de vie.
Ce décalage devient un problème concret au moment de valider une mise en ligne : un test réussi en recette ne garantit rien si la production tourne avec une version différente d’une extension qui touche au panier, au formulaire de contact ou à la mise en cache. La confiance accordée à la phase de recette suppose une hypothèse implicite — que les deux environnements sont comparables — qui n’est presque jamais vérifiée explicitement.
Extraire un inventaire fiable avec WP-CLI
La commande wp plugin list accepte un paramètre --format qui accepte entre autres table, csv et json. Pour une comparaison automatisée, le format JSON est le plus pratique parce qu’il se prête bien à un traitement scripté :
wp plugin list --fields=name,version,status --format=json > recette.json
wp plugin list --fields=name,version,status --format=json > production.jsonChaque commande doit bien sûr être exécutée sur l’environnement correspondant, via un alias WP-CLI (wp @recette plugin list ...) ou par connexion SSH distincte. L’essentiel est de figer un instantané exploitable des deux côtés, sans dépendre d’un tableau de bord ou d’une capture d’écran qui vieillira mal.
Comparer les deux inventaires en une commande
Une fois les deux fichiers JSON obtenus, la commande diff, disponible sur toute machine Unix, suffit largement pour un premier contrôle :
diff <(jq -S . recette.json) <(jq -S . production.json)Le passage par jq -S trie les clés de chaque objet JSON avant la comparaison, ce qui évite les faux positifs liés uniquement à un ordre différent. Les lignes affichées par diff correspondent exactement aux extensions dont la version, le statut d’activation ou le nom diffèrent entre les deux environnements. Sur un projet avec une trentaine d’extensions actives, ce contrôle prend quelques secondes et remplace avantageusement une relecture manuelle de deux tableaux.
Automatiser le contrôle avant chaque mise en ligne
Intégré dans un pipeline de déploiement, ce contrôle peut bloquer ou simplement avertir avant que le déploiement continue. Un script minimal :
- Récupérer les deux inventaires via les alias WP-CLI configurés pour chaque environnement
- Comparer avec
diffet capturer le code de sortie - Afficher les écarts dans les journaux du pipeline si le code de sortie est différent de zéro
Un code de sortie non nul ne doit pas nécessairement interrompre le déploiement : un écart peut être volontaire, par exemple une extension de démonstration activée uniquement en recette. L’objectif est de rendre l’écart visible et de forcer une décision consciente plutôt que de laisser la dérive s’accumuler sans que personne ne la remarque.
Ce que cette comparaison ne couvre pas
Ce contrôle porte uniquement sur l’inventaire des extensions actives et leurs versions. Il ne dit rien du contenu des bases de données, qui peuvent elles aussi diverger de façon significative entre recette et production — options stockées en base par une extension, réglages modifiés uniquement via une interface d’administration, tables personnalisées créées par un plugin. Cette question relève d’une méthode de synchronisation à part entière et mérite un traitement dédié plutôt qu’un ajout hâtif à ce script.
Il ne couvre pas non plus les thèmes, qui suivent la même logique et méritent le même traitement s’ils sont amenés à évoluer indépendamment sur les deux environnements.
En résumé
Comparer deux inventaires d’extensions ne demande ni outil supplémentaire ni service tiers : wp plugin list, jq et diff suffisent pour transformer une intuition — « ça devrait être pareil » — en vérification factuelle. Le gain le plus net se voit au moment du support : quand un client signale un comportement étrange qui ne se reproduit pas en recette, la première question à se poser devient enfin vérifiable en deux minutes plutôt que de rester une hypothèse parmi d’autres.
