Sept versions de PHP cohabitent sur ce parc de vingt machines, et trois d’entre elles n’ont plus reçu le moindre correctif de sécurité depuis plus de deux ans. Aucun changement volontaire n’explique cette situation : chaque serveur a simplement été loué, configuré une fois, puis laissé tel quel pendant que l’équipe se concentrait sur la livraison de sites. Le résultat est un empilement silencieux de versions obsolètes de PHP, de MariaDB, de noyaux Linux et d’extensions Apache que personne n’a jamais eu le temps de remettre à plat.
Le réflexe naturel, face à un tel constat, consiste à vouloir tout mettre à niveau en une seule campagne. C’est précisément l’erreur qui bloque ce genre de chantier depuis des mois : la tâche paraît si vaste que rien ne démarre. Ce retour d’expérience détaille l’ordre de priorité retenu pour sortir de l’immobilisme, sans toucher à la question distincte d’une éventuelle migration vers des offres cloud plus élastiques.
Pourquoi l’ancienneté seule ne suffit pas comme critère
La première tentative de tri a classé les vingt serveurs par date de mise en service. Ce critère semblait logique, mais il a vite montré ses limites : la machine la plus ancienne du parc hébergeait un site vitrine à faible trafic, tandis qu’un serveur loué dix-huit mois plus tôt faisait tourner une boutique WooCommerce en pleine croissance, sur une version de PHP déjà signalée comme vulnérable dans plusieurs avis de sécurité publics.
Le critère retenu ensuite a combiné deux axes : l’exposition (le serveur accepte-t-il des paiements, des formulaires, des connexions authentifiées ?) et l’écart réel avec les versions supportées en amont. Un serveur ancien mais isolé, sans formulaire public et sans base de données sensible, est descendu en fin de liste. Un serveur récent mais exposé, avec PHP en fin de vie, est remonté en tête.
La grille de lecture retenue pour classer les vingt machines
Concrètement, chaque serveur a reçu une fiche courte, alimentée par un script d’inventaire lancé en SSH sur l’ensemble du parc :
for host in $(cat inventaire-serveurs.txt); do
echo "=== $host ==="
ssh "$host" 'php -v | head -n1; mysql --version; uname -r'
doneCette boucle simple a permis de constituer, en une matinée, un tableau exhaustif des versions réellement installées, sans avoir à se fier aux notes de configuration prises des années plus tôt et jamais mises à jour.
| Critère | Poids dans la priorisation | Exemple observé |
|---|---|---|
| Version PHP en fin de vie | Élevé | PHP 7.4 sur un serveur de paiement |
| Exposition à des formulaires publics | Élevé | Site de contact sans pare-feu applicatif |
| Trafic mensuel | Moyen | Boutique à forte saisonnalité |
| Ancienneté du serveur | Faible | Machine louée en 2018 mais peu sollicitée |
Un ordre de traitement en quatre paliers
Une fois la grille appliquée, les vingt serveurs se sont répartis en quatre paliers de priorité :
- Serveurs exposés avec PHP en fin de vie : traités en premier, sur un créneau de maintenance annoncé à l’avance.
- Serveurs exposés mais encore dans une version PHP supportée : planifiés sur les six semaines suivantes.
- Serveurs peu exposés mais avec une base de données ancienne : regroupés pour une campagne commune de mise à niveau MariaDB.
- Serveurs peu exposés et peu sollicités : laissés en dernier, avec une date limite fixée pour éviter un report indéfini.
Ce découpage a rendu le chantier soutenable : au lieu d’un unique week-end de bascule générale, source classique d’incidents en cascade, chaque palier a fait l’objet d’une intervention isolée, avec sa propre fenêtre de rollback.
Traiter un serveur à la fois, jamais deux en parallèle sur le premier palier
La tentation de gagner du temps en montant deux serveurs en parallèle sur le palier le plus critique a été écartée volontairement. Une seule personne suivait chaque bascule, du snapshot initial jusqu’à la vérification des journaux d’erreurs PHP-FPM pendant les heures suivantes. Cette discipline a permis d’isoler immédiatement l’unique incident survenu pendant la campagne : une extension de paiement figée sur une fonction dépréciée en PHP 8.0, détectée en quelques minutes grâce à l’absence de bruit provenant d’un second chantier simultané.
Sur un parc hérité, la vitesse de traitement compte moins que la capacité à revenir en arrière sans stress. Un serveur remis à niveau proprement vaut mieux que trois serveurs à moitié traités.
Ce que ce chantier n’a pas résolu
Cet audit n’a pas cherché à uniformiser les systèmes d’exploitation du parc, ni à statuer sur l’intérêt d’un hébergement mutualisé face à des instances cloud plus élastiques : ce sont des décisions distinctes, qui supposent d’abord que chaque serveur tourne sur des versions supportées. Il n’a pas non plus traité l’automatisation des futures mises à jour, laissée à une phase ultérieure une fois le rattrapage terminé.
En résumé
Un parc de vingt serveurs jamais mis à niveau ne se rattrape pas en un seul week-end. Le classement par exposition plutôt que par ancienneté a permis de traiter en premier les machines qui présentaient un risque réel, et le découpage en quatre paliers a rendu chaque intervention réversible. Six mois après le début du chantier, les sept versions de PHP recensées au départ sont retombées à deux, avec une date de fin fixée pour les serveurs restants.
