Quarante sites, quarante thèmes différents — certains sur mesure, d’autres basés sur des thèmes premium plus ou moins entretenus par leur éditeur — et une échéance imposée par l’hébergeur mutualisé qui annonçait la fin du support de PHP 8.0 dans les semaines suivantes. Ce contexte a forcé cette agence à repenser complètement sa méthode de montée de version, plutôt que de traiter les quarante sites un par un dans l’ordre alphabétique du client.
Ce retour d’expérience détaille la méthode de priorisation, de test et de calendrier retenue ; il ne couvre ni la migration des extensions tierces installées sur ces sites, ni la question de l’hébergement mutualisé lui-même, traités par ailleurs.
Étape 1 : classer les quarante sites par niveau de risque
Avant de toucher un seul thème, l’équipe a établi une grille de risque simple, avec trois critères notés de 1 à 3 pour chaque site : l’ancienneté du thème (date de dernière modification connue), la présence de code personnalisé maison dans functions.php, et le volume de trafic mensuel. Un site combinant un thème vieux de plus de quatre ans, du code sur mesure non documenté, et un trafic significatif obtenait le score de risque le plus élevé.
| Catégorie de risque | Nombre de sites | Approche retenue |
|---|---|---|
| Risque faible (thème premium à jour, peu de code maison) | 28 | Montée directe, test automatisé, validation rapide |
| Risque moyen (code maison limité et documenté) | 8 | Montée avec revue de code ciblée avant activation |
| Risque élevé (thème ancien, code maison non documenté, fort trafic) | 4 | Audit complet préalable, environnement de recette dédié |
Étape 2 : un test automatisé minimal, pas exhaustif
Plutôt que de viser une couverture de test complète — irréaliste dans le calendrier imposé — l’équipe a écrit un script de vérification minimal, exécuté sur une copie de chaque site en environnement de recette, qui active PHP 8.2 et parcourt automatiquement les pages critiques (accueil, une page de contenu, la page de contact, et pour les boutiques, panier et paiement) à la recherche d’erreurs fatales ou de notices de dépréciation :
#!/bin/bash
# Script de vérification minimale post-montée PHP 8.2
PAGES=("/" "/a-propos/" "/contact/" "/panier/")
DOMAINE=$1
ERREURS=0
for page in "${PAGES[@]}"; do
REPONSE=$(curl -s -o /dev/null -w "%{http_code}" "https://${DOMAINE}${page}")
if [ "$REPONSE" != "200" ]; then
echo "ERREUR sur ${page} : code ${REPONSE}"
ERREURS=$((ERREURS+1))
fi
done
wp --path=/var/www/${DOMAINE} eval 'error_reporting(E_ALL); ob_start(); wp_head(); $out = ob_get_clean(); echo strpos($out, "Deprecated") !== false ? "DEPRECIE_TROUVE\n" : "OK\n";'
exit $ERREURSCe script, volontairement simple, a suffi à écarter sans intervention manuelle les vingt-huit sites classés à risque faible : aucune erreur remontée, montée en production directement planifiée. Seuls les douze sites restants ont nécessité une revue humaine plus poussée.
Étape 3 : le calendrier étalé sur six semaines
Le calendrier initial, calqué sur un traitement site par site au même rythme, estimait douze semaines pour l’ensemble du parc. En s’appuyant sur la grille de risque, l’agence a réparti le travail différemment :
- Semaine 1 : mise en place du script de test automatisé, validation sur trois sites pilotes de risque faible
- Semaines 2 à 3 : montée des vingt-huit sites à risque faible, en lots de sept par jour, avec fenêtre de surveillance de 24 heures avant de passer au lot suivant
- Semaine 4 : revue de code et montée des huit sites à risque moyen
- Semaines 5 à 6 : audit complet et montée des quatre sites à risque élevé, un par un, avec environnement de recette dédié pour chacun
Cette répartition a permis de traiter en priorité le volume le plus important (70 % du parc) avec le moins d’effort par site, réservant le temps d’expertise le plus coûteux aux quatre sites qui en avaient réellement besoin.
Ce qui a mal tourné malgré tout
Sur l’un des quatre sites à risque élevé, l’audit préalable n’a pas repéré un appel à une fonction utilisant la syntaxe d’accolades pour l’accès aux chaînes de caractères ($chaine{0}), syntaxe supprimée depuis PHP 8.0 mais qui traînait dans un fichier de compatibilité ancien non touché depuis des années. L’erreur n’est apparue qu’en environnement de recette, heureusement avant la mise en production, ce qui confirme l’intérêt d’avoir gardé cette étape de recette dédiée pour les sites les plus anciens plutôt que de faire confiance uniquement au script automatisé.
Un script de test automatisé minimal élimine le gros du travail répétitif ; il ne dispense jamais d’un vrai passage humain sur les sites les plus anciens et les moins documentés.
Bilan chiffré et enseignements
Le parc complet a été monté en six semaines au lieu des douze initialement estimées, sans incident en production sur les vingt-huit sites à risque faible, et un seul incident détecté et corrigé en amont sur les sites à risque élevé. La grille de risque à trois critères, volontairement simple, s’est révélée suffisante pour orienter correctement l’effort : elle sera reconduite telle quelle pour la prochaine montée de version PHP du parc.
En résumé
Traiter quarante sites de façon uniforme aurait doublé le temps nécessaire sans réduire le risque réel. Classer par niveau de risque, automatiser un test minimal pour la majorité, et réserver l’expertise humaine aux cas réellement complexes a permis de tenir un calendrier serré tout en gardant une marge de sécurité sur les sites les plus fragiles du parc.
