# PHP 8.4 en production : notre plan de bascule sur soixante sites d’agence

> Faire monter soixante sites WordPress vers PHP 8.4 sans casser les plus anciens demande une méthode. Détail de notre plan de bascule et des régressions rencontrées.

- Auteur : Clément Hadrot
- Publié le : 2025-10-22
- Mis à jour le : 2025-10-22
- Catégorie : Hébergement & serveurs
- URL : https://wpmoderne.dev.wordpress-developpement.fr/hebergement/php-84-production-plan-bascule-soixante-sites/

## L’essentiel

- La bascule s'est faite par vagues de dix sites, jamais en une seule fois
- Deux régressions liées à des plugins obsolètes ont bloqué des sites en pleine vague
- Un environnement de test miroir a évité que ces régressions n'atteignent la production

Faire passer un site WordPress isolé vers une nouvelle version de PHP est un exercice devenu presque banal. Le faire sur un parc de soixante sites d'agence, dont certains n'ont pas été touchés depuis plusieurs années, est un exercice d'une tout autre nature : chaque site porte son propre historique de plugins, de thèmes parfois abandonnés par leurs auteurs, et de code sur mesure écrit à des époques où PHP 8 n'existait même pas.

Cet article ne revient pas sur la fin de vie de PHP 7.4, déjà couverte de notre côté en 2022. Il détaille la méthode concrète que nous avons suivie pour faire monter ce parc vers PHP 8.4, sortie en novembre 2024, et les régressions réellement rencontrées en cours de route.

## Pourquoi une bascule en une seule fois était exclue

La tentation de basculer tous les sites en un week-end, pool PHP-FPM par pool PHP-FPM, existait au début de la réflexion. Elle a été écartée dès la phase de préparation : sur un parc aussi hétérogène, il était certain qu'une partie des sites rencontrerait des incompatibilités, et gérer ces incompatibilités en urgence sur soixante sites en parallèle représentait un risque opérationnel jugé inacceptable, notamment pour les sites e-commerce du portefeuille dont l'indisponibilité a un coût direct et immédiat.

Le plan retenu a découpé le parc en six vagues de dix sites, classées par ordre de risque croissant : la première vague regroupait les sites les plus récents, avec le moins de plugins et une couverture de tests automatisés existante ; la dernière vague regroupait les sites les plus anciens et les moins documentés.

> L'essentiel à retenir : La bascule s'est faite par vagues de dix sites, jamais en une seule fois ; Deux régressions liées à des plugins obsolètes ont bloqué des sites en pleine vague ; Un environnement de test miroir a évité que ces régressions n'atteignent la production

## L'environnement miroir, condition de la méthode

Chaque site a d'abord été cloné vers un environnement de test disposant d'un pool PHP-FPM configuré en 8.4, avant toute bascule en production. Le clonage utilisait `wp db export` suivi d'une synchronisation de fichiers, avec les URLs remplacées via `wp search-replace` pour pointer vers le sous-domaine de test.

Sur cet environnement miroir, l'affichage du mode débogage complet (`WP_DEBUG` et `WP_DEBUG_LOG` activés) permettait de faire remonter dans les journaux la moindre notice de dépréciation, bien plus verbeuse en PHP 8.4 qu'en versions antérieures sur certaines constructions de code désormais explicitement signalées comme obsolètes.

## Régression n°1 : un plugin de galerie utilisant une syntaxe abandonnée

Le premier incident bloquant est survenu dès la deuxième vague, sur un plugin de galerie photo tiers non maintenu depuis plusieurs années. Ce plugin utilisait des accolades pour l'accès aux chaînes de caractères (`$chaine{0}`), une syntaxe déjà dépréciée depuis PHP 7.4 et définitivement supprimée en PHP 8.0 — le site fonctionnait donc déjà en sursis depuis quatre versions majeures, la supervision n'ayant simplement jamais remonté d'erreur bloquante jusqu'ici.

Le correctif a consisté à remplacer le plugin par une alternative maintenue, le code du plugin original n'étant pas modifiable sans fork complet, solution jugée disproportionnée pour une fonctionnalité secondaire du site.

## Régression n°2 : une fonction interne renommée sans dépréciation visible

Le second incident, plus subtil, concernait un thème sur mesure ancien qui appelait une fonction interne PHP dont le comportement autour du typage des arguments avait changé entre PHP 8.1 et 8.4 concernant la coercition implicite de types nuls sur les paramètres non nullable, rendue plus stricte par les évolutions successives du langage. Le site s'affichait sans erreur visible mais générait des avertissements `Deprecated` massifs dans les journaux, un signal qui aurait pu passer inaperçu sans le passage préalable par l'environnement miroir en mode débogage complet.

1. Identification de la fonction concernée dans les journaux de l'environnement de test.
2. Correction du typage des arguments passés dans le thème sur mesure.
3. Nouveau test complet du parcours utilisateur critique du site (formulaire de contact, panier).
4. Validation avant bascule en production.

## Régression n°3 : un site resté volontairement en dehors du plan

Le troisième cas n'était pas une régression au sens strict, mais un renoncement assumé : un site utilisant un plugin de paiement propriétaire, dont l'éditeur avait cessé toute activité, s'est révélé incompatible avec PHP 8.4 sans solution de correctif raisonnable. Ce site a été maintenu sur PHP 8.2, encore supportée à la date de la bascule, en attendant une refonte plus large planifiée avec le client.

> Un parc de sites d'agence n'est jamais homogène, et une méthode de montée de version qui ne prévoit pas d'exception pour les cas irrécupérables finit toujours par forcer une casse évitable.

## Notre verdict

Sur soixante sites, trois ont nécessité une intervention manuelle avant de pouvoir migrer, et un est resté délibérément sur une version antérieure. Le découpage en vagues et le passage systématique par un environnement miroir en mode débogage complet restent, à notre avis, les deux décisions qui ont le plus contribué à éviter un incident en production. Le guide officiel des changements rétrocompatibles de chaque version PHP reste la première ressource à consulter avant toute campagne de ce type : [php.net/manual/fr/migration84](https://www.php.net/manual/fr/migration84.php).