# Un registre centralisé des versions PHP et WordPress sur 300 sites

> Une feuille de calcul mise à jour à la main ne suit jamais un parc de 300 sites bien longtemps. Voici l'inventaire automatisé qui l'a remplacée.

- Auteur : Clément Hadrot
- Publié le : 2025-12-06
- Mis à jour le : 2025-12-06
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/registre-centralise-versions-php-wordpress-300-sites/

## L’essentiel

- La feuille de calcul manuelle était fausse dans plus d'un cas sur trois
- Un script planifié interroge chaque site via WP-CLI toutes les nuits
- Le registre alimente aussi les alertes de fin de support PHP

« developer.wordpress.org indique que `wp core version` retourne la version exacte du cœur installé » : cette ligne de documentation officielle a servi de point de départ au script qui a remplacé, sur ce parc de 300 sites, une feuille de calcul partagée censée recenser les versions de PHP et de WordPress en production. Un contrôle ponctuel avait révélé que 34 % des lignes de cette feuille étaient obsolètes, certaines depuis plus d'un an, la mise à jour manuelle n'ayant jamais suivi le rythme réel des interventions sur le parc.

Ce texte détaille la construction du registre automatisé qui a pris le relais : comment il interroge chaque site, où il stocke les résultats, et ce qu'il permet de détecter que la feuille de calcul manuelle ne détectait jamais.

## Pourquoi la feuille de calcul ne pouvait pas suivre

La feuille de calcul dépendait d'une discipline humaine : chaque intervention sur un site — montée de version PHP, mise à jour du cœur WordPress — devait, en théorie, être reportée manuellement dans le tableau partagé. En pratique, cette étape était systématiquement la première oubliée en cas d'urgence ou de fin de journée chargée, et aucun mécanisme ne signalait jamais un écart entre la feuille et la réalité du parc.

## Interroger chaque site plutôt que déclarer son état

> L'essentiel à retenir : La feuille de calcul manuelle était fausse dans plus d'un cas sur trois ; Un script planifié interroge chaque site via WP-CLI toutes les nuits ; Le registre alimente aussi les alertes de fin de support PHP

Le registre automatisé repose sur un script exécuté chaque nuit, qui se connecte à chaque site du parc via SSH et exécute deux commandes WP-CLI simples :

```
#!/bin/bash
for site in $(cat inventaire-serveurs.txt); do
  version_wp=$(ssh "$site" "wp core version" 2>/dev/null)
  version_php=$(ssh "$site" "php -v | head -n 1" 2>/dev/null)
  echo "{\"site\":\"$site\",\"wordpress\":\"$version_wp\",\"php\":\"$version_php\"}" >> registre.jsonl
done
```

Chaque ligne du fichier généré représente l'état réel constaté sur un site à un instant précis, sans dépendre d'une déclaration humaine intermédiaire. Ce fichier est ensuite chargé dans une base de données légère, consultable via un tableau de bord interne, avec un historique conservé sur les douze derniers mois pour visualiser l'évolution du parc dans le temps.

## Ce que le registre a permis de détecter immédiatement

Dès la première exécution complète, le registre a révélé des situations que la feuille de calcul n'avait jamais signalées :

- Onze sites encore en PHP 7.4, une version dont le support de sécurité s'est arrêté fin novembre 2022
- Trois sites où la version de WordPress déclarée dans la feuille de calcul ne correspondait à aucune version réellement publiée par le projet
- Un serveur entier, hébergeant sept sites, absent de la feuille de calcul depuis sa mise en service

Ce dernier cas est le plus révélateur : un serveur entier avait échappé à l'inventaire manuel simplement parce que personne n'avait pensé à l'ajouter après son provisionnement, plusieurs mois auparavant.

## Un registre qui alimente désormais les alertes

Au-delà de l'inventaire consultable, ce registre déclenche désormais une alerte automatique dès qu'un site approche de la fin de support d'une version PHP, en s'appuyant sur le calendrier de support officiel publié par le projet PHP. Cette alerte part plusieurs mois avant l'échéance réelle, laissant le temps de planifier la montée de version plutôt que de la découvrir après coup.

> Un inventaire qui dépend d'une saisie manuelle finit toujours par mentir, tôt ou tard.

## Ce que ce registre ne remplace pas

Ce registre décrit l'état technique du parc, pas son état de sécurité applicatif : une version de WordPress à jour ne garantit rien sur la qualité des extensions installées ni sur la configuration serveur environnante. Il reste un outil d'inventaire, pas un outil d'audit de sécurité complet.

## En résumé

Remplacer une feuille de calcul par un registre interrogeant directement chaque site n'a rien de spectaculaire techniquement, mais l'écart constaté dès la première exécution — un serveur entier oublié, onze sites en fin de support PHP — a suffi à justifier l'investissement. Un inventaire fiable commence toujours par interroger la réalité plutôt que par faire confiance à une déclaration.