10 juin 2023 : Debian 12 Bookworm sort officiellement, avec PHP 8.2 comme version système par défaut, quand Debian 11 Bullseye ne fournissait encore que PHP 7.4 dans ses dépôts standards. Pour une agence qui gère plusieurs dizaines de serveurs clients sous Debian, cette sortie ne se traduit pas par une simple mise à jour de distribution : elle implique de facto un saut de version PHP majeur sur chaque machine migrée, avec tous les risques de régression que cela comporte sur des sites parfois vieux de plusieurs années.
Ce qui change concrètement
Le paquet php de Debian 12 pointe vers PHP 8.2, ce qui signifie qu’une mise à niveau de distribution (apt full-upgrade après changement des sources) bascule automatiquement PHP-FPM et le CLI vers cette version, sans étape intermédiaire par PHP 8.0 ou 8.1 au niveau des paquets système.
Certaines extensions PHP historiquement utilisées par des plugins WordPress anciens changent de nom de paquet ou sont retirées : php-mysql n’existe plus depuis longtemps au profit de php-mysqli et php-pdo-mysql, mais Bookworm accentue ce mouvement en retirant certaines extensions considérées obsolètes des dépôts principaux.
Les fonctions dépréciées à surveiller
PHP 8.2 transforme en erreur fatale l’utilisation de propriétés dynamiques non déclarées sur des classes qui n’implémentent pas __get/__set, un changement qui touche particulièrement les extensions et thèmes anciens écrits avant l’ère orientée objet stricte de WordPress.
Planifier la bascule sur un parc
Une bascule non planifiée, serveur par serveur sans méthode, expose à des régressions différentes sur chaque site du parc. Une méthode reproductible limite ce risque :
- Lister l’ensemble des serveurs du parc encore sous Debian 11, avec la version PHP actuellement active sur chacun
- Cloner un serveur représentatif (le plus ancien, ou celui avec le plus d’extensions tierces) dans un environnement de test
- Activer
WP_DEBUGet surveiller le journal PHP pendant une navigation complète du site après bascule vers PHP 8.2 - Corriger les avertissements de dépréciation avant de reproduire la migration sur les serveurs suivants
- Planifier chaque bascule en dehors des heures de forte affluence, avec un instantané du serveur pris juste avant
Pièges rencontrés sur ce type de migration
- Des extensions WordPress abandonnées depuis plusieurs années qui appellent des fonctions PHP retirées, sans message d’erreur clair avant la bascule
- Des thèmes maison développés en interne, jamais audités pour la compatibilité PHP 8.2, qui cassent silencieusement l’affichage de certains gabarits
- Des scripts cron externes au site, écrits en PHP CLI, qui pointaient vers un chemin d’interpréteur désormais absent après la bascule
- Des dépendances système tierces (extensions ImageMagick, bibliothèques de conversion PDF) recompilées différemment sous Bookworm, provoquant des erreurs de génération de miniatures
php --version
# PHP 8.2.7 (cli) (built: Jun 13 2023 17:51:32)
Vérifier avant plutôt que constater après
Un outil comme phpcompatinfo ou une simple analyse statique via PHP_CodeSniffer avec la règle PHPCompatibility permet de repérer, avant la bascule, les usages de fonctions dépréciées dans le code d’un thème ou d’une extension maison, plutôt que d’attendre qu’un visiteur signale une page cassée en production.
vendor/bin/phpcs --standard=PHPCompatibility --runtime-set testVersion 8.2 wp-content/themes/theme-maison/
Sur un parc de plus de dix serveurs, il vaut toujours mieux migrer le site le plus fragile en premier plutôt qu’en dernier : les problèmes qu’il révèle profitent à tous les suivants.
Le cas des serveurs restés en Debian 11 par choix
Rien n’oblige à migrer immédiatement l’ensemble du parc dès la sortie de Bookworm : Debian 11 Bullseye reste supportée en sécurité plusieurs années après la sortie de sa remplaçante, ce qui laisse une fenêtre pour planifier la bascule sereinement plutôt que dans l’urgence. Une agence peut ainsi choisir de migrer d’abord les serveurs les moins critiques, puis d’affiner sa méthode avant de toucher aux sites les plus sensibles du parc.
En résumé
La sortie de Debian 12 Bookworm impose un saut PHP direct vers la version 8.2, sans étape intermédiaire, pour tout serveur qui suit la distribution système. Une agence qui gère un parc de sites doit traiter cette migration comme un projet à part entière, avec test préalable systématique, plutôt que comme une simple mise à jour de sécurité de routine, en profitant du support prolongé de Debian 11 pour étaler la bascule dans le temps.
