PHP 8.5 est tentant pour une raison simple : tu vois passer des chiffres, tu te dis « ok, c’est gratuit », et tu commences à planifier l’upgrade. Sauf que dans la vraie vie, le gain peut être de l’ordre de quelques pourcents sur une app web classique, pendant que la friction opérationnelle, elle, peut te coûter une journée complète (ou pire, un incident en prod).
Donc on va faire un truc plus utile qu’un énième “tour des nouveautés”. On va parler perf pragmatique : comment mesurer proprement, où tu peux vraiment gagner, où tu ne gagneras rien, et comment upgrader sans transformer une montée de version en projet.
PHP 8.5 : oui, il y a des gains… mais ils ne paieront pas ton incident
Entre deux versions mineures, il peut y avoir de vraies optimisations internes. PHP 8.5 en apporte, et sur des workloads bien choisis tu peux les voir. Le piège, c’est d’attendre un saut “ressenti” sur une app Symfony/Laravel qui passe son temps à hydrater des objets, faire du templating, et attendre la base.
Ce que je vois le plus souvent sur le terrain, c’est un écart mesurable mais pas spectaculaire quand tu compares 8.4 et 8.5, parfois autour de 3–5% sur des scénarios réalistes. Et ça colle assez bien avec des retours récents sur des apps Symfony en prod. Par contre, beaucoup de gens confondent « upgrade vers 8.5 » avec « upgrade depuis une version plus ancienne vers 8.4+ ». Là oui, le gap peut être nettement plus visible. Mais ce n’est pas la même histoire.
Ce qui m’intéresse, ce n’est pas “est-ce que PHP 8.5 est plus rapide”. C’est “est-ce que PHP 8.5 est plus rapide chez toi, sur tes endpoints, avec ton cache, tes données et tes extensions”. Et ça, personne ne peut te le vendre en tweet.
Sponsorisé par Le Scribouillard
Besoin de contenu optimisé SEO ?
Utilisez la meilleure plateforme française de création de contenu assistée par IA ! Et générez des articles pour moins de 1€ !
Le benchmark qui tient debout : mêmes données, même cache, mêmes endpoints
Si tu benchmarkes une app PHP comme un micro-benchmark de langage, tu vas raconter n’importe quoi. Une app web a du warmup, du cache, des IO, des dépendances, et un comportement complètement différent entre la première requête après deploy et une prod chaude.
Le protocole minimal que je considère “honnête” ressemble à ça : tu prends 2 ou 3 endpoints représentatifs (pas la home statique, pas le “healthcheck”), tu fixes un dataset stable, tu fais un warmup qui ressemble à une vraie montée en charge, et tu mesures des percentiles (au moins p95) plutôt qu’une moyenne qui cache les pics.
Et surtout : tu gardes les variables sous contrôle. Même machine (ou mêmes ressources), même config OPcache, même réglage FPM, mêmes flags, mêmes extensions chargées. Tu serais surpris du nombre de benchmarks “PHP 8.5 vs 8.4” qui comparent aussi deux images Docker différentes, deux kernels, ou un OPcache pas warmé d’un côté.
OPcache et warmup : le détail qui plombe 80% des comparaisons
Une app Symfony/Laravel sans OPcache chaud, c’est une autre application. Si tu compares « requêtes à froid » d’un côté et « requêtes à chaud » de l’autre, tu vas forcément trouver un “gagnant” au hasard. Sur un protocole sérieux, tu assumes que la prod est chaude la plupart du temps, et tu sépares les mesures “cold start” (après deploy) des mesures “steady state”.
Mesure p95/p99, pas juste “req/s”
Le throughput, c’est cool pour se rassurer. Mais ce qui te fait mal en prod, ce sont les latences qui montent, pas le nombre moyen de requêtes par seconde. Une upgrade PHP peut te donner +3% de throughput, et pourtant empirer ton p95 si, par exemple, tu changes une interaction avec une extension, ou si un comportement de GC évolue sur ton workload. Mesure les deux.
# Exemple basique : tu mesures le même endpoint sur deux environnements identiques (8.4 vs 8.5)
# en gardant la même DB, le même cache, et en faisant un warmup.
# Warmup (on ne “mesure” pas ça, on prépare juste le terrain)
wrk -t4 -c32 -d30s https://staging.example.com/api/orders
# Mesure (latence + p95/p99)
wrk -t4 -c32 -d60s --latency https://staging.example.com/api/ordersJe le précise parce que ça arrive tout le temps : si ton staging n’est pas dimensionné comme la prod, ton benchmark n’a pas besoin d’être “faux” pour être inutilisable. Il peut être parfaitement rigoureux… sur un environnement qui ne ressemble pas à ce que tu exploites.
Là où PHP 8.5 peut vraiment accélérer ton app (et là où tu ne verras rien)
PHP 8.5 peut faire mieux sur des chemins CPU-bound, du code qui tourne beaucoup, ou des endpoints qui font relativement peu d’IO. Typiquement, des transformations de données, de la sérialisation/désérialisation, du calcul, ou des bouts de code où le runtime PHP est réellement le facteur limitant.
À l’inverse, si ton endpoint passe 70% de son temps à attendre Postgres/MySQL, Redis, un provider externe, ou le disque, tes “gains PHP” vont se dissoudre dans le bruit. Et c’est normal. Dans ce cas-là, si tu veux de la perf “ressentie”, tu vas la chercher dans les requêtes SQL, les index, la réduction de round-trips, le caching applicatif, le rendu, ou la stratégie HTTP. Upgrader PHP peut rester une bonne idée, mais pas pour la perf.
Sur Symfony/Laravel, il y a un autre point à ne pas rater : une partie de ta latence est du framework overhead (container, events, middleware, validation, normalizers). Les optimisations runtime peuvent le réduire un peu, mais si tu veux un vrai saut, il faut aussi regarder comment ton app utilise le framework. Un endpoint qui fait 15 queries et hydrate 200 modèles ne deviendra pas “rapide” parce que tu as gagné 3% sur l’interpréteur.
Les frictions d’upgrade qui coûtent une journée : OS, images Docker, extensions, CI
Le coût caché d’une montée de version PHP, ce n’est pas “changer le numéro dans la doc”. C’est tout ce qui gravite autour : packaging, extensions, images, pipelines, et parfois des choix historiques qui te rattrapent.
Premier classique : le support OS. Selon ta distro (Ubuntu, Debian, Alpine), la disponibilité de PHP 8.5 et de certaines extensions n’est pas “out of the box”. Tu te retrouves à ajouter un repo, à changer de base image, à attendre un build, ou à compiler une extension en urgence parce que ton stack a une dépendance pas super maintenue. Et quand tu ajoutes ça à une CI qui build des images multi-arch, tu peux perdre un temps fou pour un changement que tu pensais “simple”.
Deuxième classique : les extensions et leurs compatibilités. Xdebug, Imagick, Redis, Swoole, grpc, drivers divers… si tu en as une qui est bloquante et pas encore parfaitement alignée, ton upgrade s’arrête net. Ce n’est pas dramatique, mais il faut le savoir avant de promettre une mise en prod vendredi.
Troisième classique : Composer et la réalité des dépendances. Tu peux avoir du code applicatif compatible, mais une lib qui traîne une contrainte de plateforme trop stricte, ou un framework qui te demande un patchlevel précis. Ce n’est pas “la faute de PHP”, c’est juste la chaîne complète qui doit être prête.
{
"config": {
"platform": {
"php": "8.5.0"
}
}
}Ce snippet ne résout pas l’upgrade, mais il est utile pour arrêter de mentir à Composer. Quand tu testes une montée de version, fixe la plateforme. Sinon tu peux te retrouver avec un lockfile qui “a l’air ok” sur ta machine, et qui explose dans un container ou sur un runner CI un peu différent.
Stratégie d’upgrade sans sueur froide : canary, rollback, métriques
Si tu upgrade PHP “en big bang”, tu prends le risque maximal pour un gain parfois modeste. La bonne stratégie, c’est de rendre l’opération ennuyeuse. Tu introduis PHP 8.5 comme une variante d’exécution, pas comme une nouvelle religion.
En pratique, ça veut dire : un déploiement canary (une fraction du trafic sur des instances 8.5), une capacité de rollback claire (revenir sur 8.4 sans reconstruire la moitié du monde), et des métriques que tu regardes vraiment. Latence p95, taux d’erreur, timeouts, CPU, mémoire, et si possible des métriques applicatives (par endpoint, pas juste « tout va bien »). Le canary te donne un signal dans le réel, là où les benchmarks te donnent un signal en labo.
Le piège, c’est de ne monitorer que le taux d’erreur. Une upgrade PHP peut “fonctionner” et pourtant te coûter cher si elle augmente légèrement la conso mémoire et réduit ta densité par machine, ou si elle dégrade quelques endpoints rares mais business-critical. Ce genre de régression est invisible si tu n’as pas de découpage par route, ou si tu ne regardes pas tes percentiles.
Mon arbitrage en 2026 : quand je pousse 8.5, quand je temporise
Je pousse PHP 8.5 quand j’ai une bonne raison autre que “c’est la dernière version”. Typiquement : support long terme de l’écosystème, homogénéité des environnements, profiter d’améliorations runtime sur des workloads CPU-bound, ou parce que je veux arrêter de traîner une dette technique et que mon process de déploiement est solide.
Je temporise quand l’app est DB-bound et déjà stable, que l’équipe n’a pas le temps de faire un canary propre, ou que je sais que je vais me battre avec une extension ou une image de base. Dans ces cas-là, je préfère investir la même énergie sur ce qui donne des résultats visibles : requêtes SQL, cache, instrumentation, réduction de payload, suppression de N+1, ou un vrai profilage (Blackfire/XHProf, peu importe, mais avec des chiffres).
Le truc à retenir : si tu ne peux pas prouver le gain et si tu ne peux pas rollback vite, la “perf” devient un argument fragile. Et c’est exactement comme ça qu’on se retrouve à perdre une journée pour gagner 3% sur un graphe… qui ne change rien pour les utilisateurs.
Conclusion : vise un upgrade boring, pas un benchmark héroïque
PHP 8.5 vaut probablement le coup à moyen terme, ne serait-ce que pour rester dans une zone de support confortable. Mais si tu l’abordes comme une quête de perf, tu vas souvent être déçu.
La bonne approche, c’est de traiter ça comme une opération d’exploitation : mesurer sur tes endpoints, faire un canary, observer p95 et erreurs, et garder la marche arrière simple. Si tu fais ça, les upgrades PHP deviennent un réflexe sain. Et le jour où une version t’apporte un vrai gain (ou une vraie régression), tu le vois tout de suite, sans débat stérile.
