« quel intérêt de tester une version de PHP qui ne sera stable que dans plusieurs mois ? » — la question mérite d’être posée avant même de lire ce billet. La réponse tient en une phrase : anticiper les ruptures de compatibilité sur un parc de quarante extensions actives prend du temps, et attendre la publication stable de PHP 8.4 pour commencer ce travail reviendrait à découvrir les problèmes au pire moment, celui d’une migration sous pression.
Ce test s’est appuyé sur un instantané de développement de PHP 8.4, compilé directement depuis le dépôt source du projet PHP à un stade de gel des fonctionnalités, plusieurs mois avant la publication de la version stable prévue en fin d’année. Un tel instantané n’a pas vocation à tourner en production : il sert uniquement à explorer par anticipation le comportement du moteur et du JIT sur un parc d’extensions représentatif.
Pourquoi compiler depuis les sources plutôt qu’attendre une bêta packagée
Les dépôts de paquets habituels (Ondřej Surý pour Debian/Ubuntu, par exemple) ne proposent en général une bêta installable qu’à un stade plus avancé du cycle de développement. Compiler depuis les sources permet de tester plus tôt, au prix d’un travail supplémentaire de configuration (./configure avec les mêmes options que la configuration de production : --with-mysqli, --enable-opcache, --with-zip) et d’une prudence de rigueur sur la stabilité du résultat.
Le classement des changements par impact observé
Sur les quarante extensions actives testées, le classement des changements observés, du plus impactant au plus anecdotique :
- Dépréciations de fonctions implicites : deux extensions utilisaient encore des fonctions marquées dépréciées depuis PHP 8.1, dont les messages de dépréciation, jusque-là silencieux en production grâce à un niveau de rapport d’erreur restrictif, sont remontés plus visiblement dans les journaux sur cet instantané.
- Comportement des propriétés non typées : une extension déclarait des propriétés dynamiques sur une classe sans les typer explicitement, un pattern de plus en plus strictement signalé au fil des versions récentes de PHP.
- Gain de performance du JIT : mesuré à environ 5 % de temps de réponse en moins par rapport à PHP 8.3 sur le même jeu de pages de test, un écart cohérent avec les gains progressifs observés version après version plutôt qu’un saut brutal.
- Aucune extension cassée de façon bloquante, mais deux nécessitant une mise à jour mineure de leur propre part pour rester pleinement compatibles.
Le protocole de test
Le même panier de dix URL représentatives que pour les précédents benchmarks PHP a été rejoué via k6, sur un environnement de test isolé, en comparant PHP 8.3 stable (référence de production) à l’instantané de développement de PHP 8.4 :
| Configuration | Temps de réponse moyen | Erreurs PHP levées |
|---|---|---|
| PHP 8.3 stable (production) | 270 ms | 0 |
| PHP 8.4 (instantané de développement) | 256 ms | 2 avertissements de dépréciation |
Ce qu’il reste à vérifier à la sortie stable
Un instantané de développement plusieurs mois avant la sortie peut encore évoluer significativement d’ici la version finale : des fonctionnalités peuvent être ajustées, des messages d’erreur reformulés, des optimisations internes affinées. Ce test ne remplace donc pas une nouvelle campagne de vérification une fois la version stable réellement publiée, il ne fait que réduire le travail restant à cette échéance.
Ce que ce travail anticipé a permis
- Contacter dès à présent les mainteneurs des deux extensions concernées par les dépréciations, avant que la pression d’une migration imminente ne complique la discussion.
- Documenter en interne la liste des points de vigilance à retester lors de la publication stable, plutôt que de repartir d’une feuille blanche.
- Éviter de présenter ces résultats comme définitifs auprès des équipes, en insistant sur le caractère provisoire d’un instantané de développement.
Tester un instantané de développement n’a de valeur que si chacun comprend qu’il documente une tendance, pas un verdict final.
En résumé
Ce travail d’anticipation, mené plusieurs mois avant la sortie stable de PHP 8.4, ne visait pas à obtenir un chiffre de gain définitif mais à cartographier les extensions à surveiller sur ce parc précis de quarante modules actifs. Le gain de performance du JIT, mesuré autour de 5 %, reste cohérent avec la tendance progressive observée sur les versions précédentes de PHP, sans surprise majeure à ce stade du développement.
