🐘 PHP en 2026, factuellement

Vous avez entendu pas mal de blagues sur PHP. Mais vous l’avez aussi vu dans de nombreuses offres d’emploi, dans la stack technique d’une entreprise respectable, dans le CMS d’un site qui n’est jamais en panne et qui répond vite… Et vous vous demandez quel sens donner à tout ça. Qui croire ? Les PHP haters, ou les fanboys de PHP ?

Ce livre est là pour donner du factuel, et vous permettre de vous faire une opinion sur PHP tel qu’il est, pour savoir s’il est adapté à votre projet, votre entreprise, vos envies.

Vous verrez beaucoup de chiffres et de graphiques. Chaque élément chiffré est sourcé et daté en annexe. Les comparaisons sont factuelles ; aucune n’est écartée parce qu’elle mettrait PHP dans une situation inconfortable.

Comptez entre quatre-vingt-dix minutes et deux heures, et l’opinion que vous emporterez sera la vôtre.

Comment lire ce livre

On vous demande de prendre PHP au sérieux, et vous vous en passeriez bien. Le langage a trente ans, on l’associe au pire code qu’on vous ait jamais mis sous les yeux, et personne n’en parle dans les conférences que vous suivez. Il revient pourtant sans cesse : dans la pile technique d’une entreprise que vous respectez, dans les offres d’emploi, derrière un site qui encaisse plus de trafic que le vôtre. J’ai écrit ce livre pour régler cette contradiction avec des preuves plutôt qu’avec de l’enthousiasme.

Chaque chiffre de ce livre a une source et une date, et l’annexe les recense pour que vous puissiez vérifier chacun d’eux. Un nombre dans le texte est suivi de sa provenance et de sa date, entre parenthèses. Un chiffre de fournisseur, une étude de cas auto-déclarée ou un benchmark synthétique sont signalés comme tels dans la phrase même où ils apparaissent, et quand je ne sais pas, je le dis. Vous ne devriez jamais avoir à vous demander si une phrase énonce un fait ou un souhait.

Pourquoi le doute est raisonnable

La réputation a été méritée. Pendant sa première décennie, PHP a été permissif jusqu’à la faute : les variables surgissaient de nulle part, "abc" == 0 valait vrai, les erreurs s’imprimaient dans la page et l’exécution continuait, les requêtes vers la base de données se bricolaient par concaténation de chaînes, et la bibliothèque standard grossissait une fonction à la fois, sous le nom que son auteur préférait cette semaine-là. Une génération a appris à programmer sur ce PHP-là et en a écrit énormément, et une bonne partie de ce code tourne encore. L’essentiel de ce qu’on vous a montré sous l’étiquette « PHP » date de cette période.

Le langage que vous évalueriez aujourd’hui est un autre objet. PHP 7 (2015) a reconstruit le moteur et ajouté les déclarations de types scalaires. PHP 8 (2020) a apporté les types union, match, les arguments nommés, les attributs, les énumérations, les propriétés readonly, les callables de première classe et un compilateur JIT, et il a appris à l’interpréteur à lever une exception là où il devinait. Une version est sortie chaque année depuis, fin novembre ou début décembre. La PHP Foundation salarie des développeurs du cœur depuis 2021, le gestionnaire de paquets est universel, et deux analyseurs statiques vous donnent l’essentiel de ce qu’un compilateur vous donnerait. La syntaxe actuelle est dans Le langage en 2026, et les gens qui la publient sont dans Gouvernance et pérennité.

Une partie de la réputation reste méritée. Les chaînes sont des suites d’octets, la bibliothèque standard garde ses noms historiques, il n’y a ni génériques ni threads en espace utilisateur, et le runtime est synchrone par défaut. Une grande part du PHP qui tourne sur le web public est vieille, parce que l’hébergement qui la fait tourner est vieux. Chacune de ces limites se trouve dans le chapitre où vous iriez la chercher, à côté de la pratique qui l’entoure aujourd’hui, et Là où PHP est le mauvais choix rassemble les cas où le conseil honnête est de choisir autre chose.

Les questions, dans l’ordre

Chaque chapitre répond à une question que vous poseriez, dans l’ordre d’une revue de due diligence, de l’extérieur vers l’intérieur.

Empreinte demande qui tourne sur PHP et à quelle échelle, et répond par les parts de marché du web, par les plateformes bâties dessus et par les organisations qui décrivent leur production PHP avec leurs propres mots. Le runtime explique le modèle d’exécution, parce que l’essentiel de ce que PHP fait bien et de ce qu’il ne sait pas faire en découle. Débit et latence et Concurrence donnent les chiffres de performance, avec le round du benchmark, le matériel et le test nommés, et avec, sur le même graphique, les langages qui battent PHP sur le même test.

Le langage en 2026 est le tour de la syntaxe le plus court possible, pour ceux qui jugent un langage en le lisant. L’écosystème compte les paquets, les frameworks et les outils. Gouvernance et pérennité couvre le processus des RFC, le calendrier des versions, le processus de sécurité et l’argent, et Coût de possession regarde le recrutement, l’hébergement et les mises à niveau.

Là où PHP est le mauvais choix est le chapitre qui rend les autres crédibles. Une évaluation en une semaine est un protocole, quoi installer, quoi mesurer, quoi lire, pour que la décision que vous prendrez repose sur vos chiffres et non sur les miens.

Les règles que je me suis fixées

Les comparaisons sont symétriques. Quand un graphique montre PHP devant un langage sur une mesure, le texte nomme une mesure où ce langage est devant, quand elle existe. Les options courantes que vous vous attendez à voir, Node.js, Python, Java, C#, Go, Ruby, ne sont jamais écartées d’un graphique parce qu’elles y feraient bonne figure.

Les noms viennent avec des preuves. Une entreprise n’apparaît ici que si ses propres ingénieurs, dans un billet de blog, une conférence, un dépôt ou un rapport, disent qu’elle fait tourner PHP en production, et l’annexe renvoie à ce document avec sa date. Les entreprises qui font tourner Hack sur HHVM, un langage issu d’un fork de PHP, ne sont pas présentées comme des utilisatrices de PHP, si tentant que fût le logo.

Les frameworks et les outils sont listés, pas recommandés. Ils apparaissent par ordre alphabétique. La PHP Foundation, sous l’égide de laquelle ce livre paraît, promeut le langage et ses standards plutôt qu’un fournisseur, et je fais de même.

Comment le vérifier

Chaque chapitre se termine par quelque chose que vous pouvez vérifier en un après-midi : un tableau de bord public à ouvrir, un benchmark à relancer sur votre matériel, une commande à taper. Prenez-les au sérieux. Un chiffre que j’ai mal relevé, ou qui a vieilli depuis que je l’ai écrit, est exactement ce que vous devriez trouver, et Sources vous donne l’URL pour le trouver.

Votre première question est sans doute celle par laquelle j’ai commencé moi aussi : qui tourne vraiment là-dessus ?

Empreinte

Votre première question est de savoir qui tourne vraiment là-dessus, à quelle échelle, et si la réponse tient dans une liste de logos ou dans une liste de documents. PHP est le langage côté serveur d’environ sept sites web sur dix parmi ceux dont le langage peut être détecté, et cette part baisse depuis dix ans. Les deux moitiés de cette phrase comptent, et aucune ne vaut grand-chose tant que vous ne savez pas ce que l’enquête compte.

Ce que mesure la part du web

W3Techs, la société d’études derrière ce chiffre, inspecte chaque jour un échantillon de plus de vingt millions de sites web et détecte le langage côté serveur à partir des en-têtes de réponse, des cookies, des extensions de fichiers et d’autres traces du même genre. Le pourcentage est calculé sur les sites dont le langage a pu être détecté, si bien qu’un site derrière un framework qui ne laisse aucune trace n’est pas compté. Chaque site compte pour un, et l’ensemble de wordpress.com ou de wix.com pèse autant qu’un blog personnel. Un site peut aussi utiliser plusieurs langages, ce qui explique que les colonnes ne totalisent pas cent.

À la même date, JavaScript côté serveur est à 7,5 %, Ruby à 7,1, Java à 5,4, Scala à 5,0, ASP.NET à 4,2 et Python à 1,1. Dans ses limites, l’enquête est stable dans ce qu’elle dit : le gros du web adressable tourne sur PHP, surtout à travers WordPress, et les langages dont on parle davantage sont petits sur cette mesure. Scala devant ASP.NET rappelle que l’enquête compte ce que sa détection voit, et que quelques plateformes laissent une signature sans rapport avec leur usage.

La part de PHP sur cette mesure était de 80,6 % au 1er janvier 2015, de 75,2 au 1er janvier 2025 et de 72,4 au 1er janvier 2026, puis de 69,9 en septembre 2026. La tendance est à la baisse, et c’est la première chose à regarder. Le déclin s’est accéléré en 2025 et 2026, et la part qui a quitté PHP est allée pour l’essentiel vers JavaScript côté serveur, dont W3Techs a noté en juillet 2026 qu’il avait dépassé Ruby à la deuxième place. Deux faits se tiennent côte à côte : une base installée sur le web public que rien d’autre n’égale, et une courbe qui ne va pas dans le sens de PHP.

Les plateformes

L’essentiel de cette base installée, ce sont des produits, pas du code sur mesure. WordPress à lui seul fait tourner 40,2 % de tous les sites web, soit 58,8 % des sites qui utilisent un système de gestion de contenu détectable, et les systèmes PHP suivants, Joomla, Drupal, PrestaShop et TYPO3, sont chacun sous les deux pour cent. WooCommerce, l’extension de commerce de WordPress, équipe 8,0 % de tous les sites web et représente 47,7 % des systèmes de commerce en ligne détectés.

Les plateformes publient aussi leurs propres décomptes, chacun avec son biais. Moodle, la plateforme d’apprentissage, déclare 146 634 sites enregistrés et 531 millions d’utilisateurs, en ne comptant que les sites qui ont choisi de s’enregistrer. Nextcloud annonce plus de 500 000 serveurs. Drupal compte 470 795 sites qui remontent leur version par son module de mise à jour, ce qui oublie ceux qui l’ont désactivé. PrestaShop revendique près de 250 000 sites et plus de 22 milliards d’euros de ventes passées par eux en 2024, un chiffre auto-déclaré. Shopware cite une étude EHI qui le place sur 115 des 1 000 plus grandes boutiques B2C allemandes en 2025, et Matomo, la plateforme d’analyse d’audience, annonce plus de 1,4 million de sites web. Adobe ne publie aucun décompte de marchands pour Adobe Commerce, donc je n’en donne aucun.

Aucun chiffre de cette liste ne compte autant que sa forme. La gestion de contenu, le commerce, l’apprentissage, le partage de fichiers et l’analyse d’audience sont les catégories où l’on installe un produit sur un serveur et où on le laisse tourner des années, et ce sont celles que les logiciels PHP dominent. C’est de là que vient la part de la section précédente.

Les organisations qui le disent elles-mêmes

Une entreprise n’apparaît ici que si ses propres ingénieurs ou ses propres documents disent qu’elle fait tourner PHP, et la date de ce document fait partie de la preuve.

Wikimedia Foundation. Wikipédia et ses projets frères tournent sur MediaWiki, une application PHP servie par PHP-FPM. Les états financiers audités de la fondation font état de plus de 19,4 milliards de pages vues par mois sur l’ensemble de ses projets. Sa production est passée de PHP 8.1 à PHP 8.3 le 25 novembre 2025, et au moment où j’écris, la migration vers PHP 8.5 est prévue pour la fin 2026. La même infrastructure a tourné sur HHVM jusqu’en 2019, année où la fondation a achevé son retour à l’interpréteur PHP. La fondation rapporte aussi des pics de 800 000 requêtes par seconde sur ses sept centres de données, un chiffre compté en bordure, où la couche de cache sert la plupart des requêtes sans qu’elles atteignent jamais PHP ; ne le lisez donc pas comme un débit PHP.

Automattic. WordPress.com et Tumblr, selon Automattic, « tournent principalement sur PHP ». WordPress VIP, la branche d’hébergement pour grands comptes du groupe, publie 2 400 milliards de requêtes servies par an et 22 milliards de requêtes la nuit de l’élection américaine de 2024, des chiffres qui incluent son CDN.

Etsy. La page carrières de l’ingénierie de la place de marché indique que ses ingénieurs « codent principalement en PHP et en JavaScript », aux côtés de Java, Go et Swift. Etsy a fait passer sa production à PHP 7 en 2016 et a documenté le passage à l’époque, graphiques de production à l’appui.

Mailchimp. Le blog développeurs de l’entreprise décrit son exécuteur de tâches et son monolithe applicatif en PHP, et ses offres d’emploi en ingénierie de 2025 et 2026 demandent PHP aux côtés de React et de Go. Aucun chiffre d’échelle n’est publié.

Bumble (Badoo). Le blog d’ingénierie décrivait, en 2017, plus de trois millions de lignes de PHP et des centaines de serveurs applicatifs passés à PHP 7, avec une économie annoncée d’un million de dollars en matériel. Ce chiffre a neuf ans et vous devez le peser comme tel ; les offres d’emploi actuelles de l’entreprise listent toujours PHP à côté de Go.

Secteur public. Les sites web de la Commission européenne tournent sur Drupal, ce que leurs pages déclarent dans leurs métadonnées. Des agents de la Commission ont présenté la plateforme à Drupal4Gov EU en janvier 2026, avec 770 sites en ligne, un chiffre rapporté par des participants et que je n’ai pas pu confirmer dans une publication de la Commission. Le site de la Maison-Blanche tourne sur WordPress, hébergé chez WordPress VIP sous une autorisation FedRAMP Moderate. Le Government Site Builder fédéral allemand, le CMS standard des administrations fédérales, est bâti sur TYPO3 et sert plus de 80 administrations et 250 sites web. La plateforme australienne GovCMS déclare plus de 370 sites gouvernementaux sur Drupal, et 77 collectivités locales du Royaume-Uni partagent la distribution LocalGov Drupal.

Qui est parti, et qui n’y a jamais été

La liste des entreprises qui ont abandonné PHP est aussi instructive que celle qui précède, et elle est plus courte que la réputation ne le laisse croire.

Meta et Slack sont les deux noms qu’on cite le plus souvent pour PHP à grande échelle, et ni l’un ni l’autre ne fait tourner PHP. Les deux font tourner Hack, un langage que Facebook a annoncé en 2014, sur HHVM, une machine virtuelle qu’il développait pour PHP depuis 2011 et qui a abandonné la compatibilité avec PHP en 2019. Slack a retiré son dernier code PHP lors du passage à HHVM 4 et maintient aujourd’hui environ cinq millions de lignes de Hack. Les deux entreprises montrent qu’une base de code commencée en PHP peut devenir très grande, et aucune des deux ne dit quoi que ce soit sur l’interpréteur PHP, donc je ne les compte jamais.

Zalando a réécrit sa boutique Magento en Java en 2010, d’après le témoignage d’un ancien ingénieur. Trivago a remplacé une grande base de code PHP par une application TypeScript entre 2020 et 2021. Dailymotion, qui servait son site avec PHP et Symfony depuis 2005, indique dans une offre d’emploi de 2026 qu’elle « réduit progressivement PHP » et que les nouveaux développements se font en Go, Java et Python. BlaBlaCar, une maison Symfony en 2015, décrit dans ses offres une migration « d’une pile PHP/Symfony vers une pile dominée par Java et JS ». Voilà les cas que j’ai trouvés avec une source primaire, et ils ont un motif commun : une entreprise dont le produit avait dépassé le cadre d’un monolithe web a déplacé ses services vers un langage compilé ou vers la JVM, comme le font au même stade les entreprises qui quittent Ruby ou Python.

La population de développeurs

La part du web mesure des serveurs. Les enquêtes mesurent des personnes, et elles placent PHP plus bas.

Chacune de ces mesures porte sur autre chose, et chacune a un biais connu : l’échantillon de Stack Overflow est auto-sélectionné parmi ses utilisateurs, celui de JetBrains est pondéré vers ses clients, GitHub compte l’activité open source et TIOBE compte des résultats de recherche. Lues ensemble, elles disent qu’entre un développeur sur six et un sur cinq a écrit du PHP dans l’année, que PHP est un premier langage pour moins de gens qu’il n’est un second, et que son activité sur les dépôts publics ne bouge pas. JetBrains décrit PHP comme en « déclin de long terme » aux côtés de Ruby et d’Objective-C, tandis que l’enquête consacrée à PHP du même rapport a trouvé que 58 % des développeurs PHP ne prévoient pas de migrer vers un autre langage. Ce que cela veut dire pour le recrutement est une question pour Coût de possession.

La limite : l’empreinte est large et vieille. Sa largeur vient des produits plus que des applications sur mesure, son âge se lit dans la part de la base installée encore sur des versions non maintenues, et la part du langage parmi les développeurs est plus petite que sa part des serveurs en service. Si vous choisissez un langage pour un nouveau service, donnez au second fait plus de poids qu’au premier.

Ce que vous pouvez vérifier vous-même

Ouvrez les pages W3Techs des langages côté serveur et des systèmes de gestion de contenu ; elles sont mises à jour chaque jour et la vue historique est publique. Pour Wikimedia, les tâches Phabricator que je cite se lisent sans compte et montrent le travail de migration tel qu’il s’est déroulé, dates comprises. Pour toute entreprise nommée ici, allez fouiller vous-même son blog d’ingénierie et ses offres d’emploi, et traitez l’absence de PHP dans les offres récentes comme le signal qu’elle est.

L’échelle du déploiement ne dit rien de la façon dont une requête est servie. C’est là que le runtime entre en scène.

Le runtime

L’essentiel de ce que PHP fait bien, et l’essentiel de ce qu’il ne sait pas faire, découle de la façon dont il sert une requête. Une requête PHP démarre sans rien, exécute votre code de haut en bas, envoie sa réponse et est jetée ; la concurrence vient d’un pool de processus, chacun traitant une requête à la fois. Rien ne survit d’une requête à la suivante à l’intérieur du processus, et c’est pour cela qu’on appelle ce modèle shared-nothing : aucun objet application ne reste en vie, pas de boucle d’événements, pas de thread.

Une requête, un processus

Le déploiement standard, c’est PHP-FPM, le gestionnaire de processus FastCGI, derrière un serveur web comme nginx, Apache ou Caddy. Le gestionnaire entretient un pool de processus worker, confie chaque requête entrante à un worker libre, et le worker exécute le script, écrit la réponse et revient dans le pool la mémoire vidée. La taille du pool tient en une ligne de configuration. Une machine avec plus de cœurs fait tourner plus de workers, et plus de machines derrière un répartiteur de charge font tourner plus de pools, sans la moindre coordination entre eux.

Une équipe plateforme remarque d’abord le bon côté de ce modèle. Une requête qui plante, qui fuit ou qui dépasse son temps emporte un worker avec elle et rien d’autre ; le gestionnaire remplace le worker et les autres requêtes n’en voient rien. Une fuite mémoire ne peut pas s’accumuler au-delà d’une requête, si bien qu’une application PHP qui tourne longtemps ne se dégrade pas au fil des jours comme peut le faire un processus qui vit longtemps. Déployer, c’est copier des fichiers puis vider un cache, parce qu’il n’y a aucun processus à redémarrer proprement et aucun état en mémoire à drainer.

Le même modèle a ses coûts, et c’est un ingénieur performance qui les voit en premier. Chaque requête paie l’amorçage de l’application : lire la configuration, câbler les dépendances, enregistrer les routes. Il n’y a pas de cache en processus d’une requête à l’autre, si bien qu’une table calculée une fois par processus dans un autre langage l’est ici une fois par requête, à moins de la ranger en mémoire partagée via l’extension APCu ou dans un cache externe. Les connexions à la base de données s’ouvrent et se ferment à chaque requête, sauf à les configurer comme persistantes, si bien qu’un pool de connexions, quand il en faut un, vit hors de PHP. Une charge qui doit garder un état entre les requêtes, un serveur WebSocket ou un salon de jeu, n’entre pas du tout dans ce modèle, et Concurrence explique ce qui y entre à la place.

OPcache, le préchargement et le JIT

L’objection évidente à un amorçage à chaque requête, c’est le coût d’analyser et de compiler le source à chaque fois, et PHP l’a levée en 2013. OPcache garde la forme compilée de chaque fichier en mémoire partagée, si bien qu’un fichier est compilé une fois par déploiement et non une fois par requête. Il fait partie de la distribution standard depuis PHP 5.5 et il est activé dans le modèle php.ini-production livré avec elle ; un benchmark lancé sans lui ne mesure rien de PHP.

Le préchargement, arrivé avec PHP 7.4, va un cran plus loin. Une liste de fichiers est compilée et liée au démarrage du gestionnaire puis gardée en mémoire, si bien que les classes existent avant la première requête et qu’aucun autoloading n’a lieu. La RFC qui l’a introduit a mesuré un gain de 30 % sur la page hello-world d’un framework et de 50 % sur celle d’un autre, et précise dans le même paragraphe que les gains en conditions réelles « seront probablement plus faibles » et dépendent du rapport entre l’amorçage et le travail effectif.

Le compilateur JIT, ajouté dans PHP 8.0 à l’intérieur d’OPcache, compile les chemins de code chauds en code machine, et ses propres notes de version sont plus sobres que les gros titres. php.net indique que le JIT traçant « montre des performances environ 3 fois meilleures sur des benchmarks synthétiques et une amélioration de 1,5 à 2 fois sur certaines applications spécifiques de longue durée », et que « les performances d’une application typique sont au niveau de PHP 7.4 ». La mesure de la RFC elle-même sur WordPress donnait 326 requêtes par seconde avec le JIT contre 315 sans. Le JIT n’a jamais été activé par défaut : avant PHP 8.4, la taille de son tampon était zéro, et depuis 8.4 un tampon de 64 mégaoctets est réservé mais opcache.jit vaut disable, si bien qu’il faut l’activer explicitement. Une application web en tire peu, un script limité par le CPU peut en tirer beaucoup.

Les runtimes worker

Le seul coût qu’OPcache ne supprime pas est l’amorçage de l’application, et une seconde famille de runtimes le supprime en gardant l’application en mémoire. En mode worker, un processus amorce l’application une fois, puis traite les requêtes en boucle, une à la fois, pendant des milliers de requêtes avant d’être recyclé. Par ordre alphabétique : FrankenPHP, un serveur d’application écrit en Go au-dessus du serveur web Caddy, qui propose aussi bien le mode classique d’une requête par processus qu’un mode worker ; RoadRunner, un serveur d’application lui aussi écrit en Go, qui garde en vie un pool de workers PHP et leur transmet les requêtes par un protocole ; et Swoole, ou son fork OpenSwoole, une extension en C qui donne à PHP sa propre boucle d’événements et son propre serveur HTTP. FrankenPHP est hébergé sous l’organisation php sur GitHub depuis le 8 juin 2025, avec une gouvernance inchangée.

Ce que le changement rapporte dépend entièrement du prix de l’amorçage, et la façon honnête de le montrer est de prendre le même code avec le runtime pour seule variable. Sur un script hello-world nu, où il n’y a aucun amorçage à éviter, Tideways, un éditeur de profileur PHP et membre fondateur de la PHP Foundation sans intérêt dans l’un ou l’autre runtime, a trouvé FrankenPHP en mode classique et PHP-FPM à moins d’un demi pour cent l’un de l’autre, autour de 18 400 requêtes par seconde sur une machine virtuelle à huit cœurs. Sur un framework complet, la suite de benchmarks que Débit et latence lit en détail montre l’entrée Symfony passer de 26 000 requêtes par seconde sous PHP-FPM à 74 000 sous FrankenPHP et 111 000 sous Swoole sur son test Fortunes, sans une ligne changée dans le framework. Les éditeurs et les auteurs de frameworks publient des rapports plus élevés sur leurs propres pages. Je m’en tiens à ces deux chiffres parce que vous pouvez reproduire l’un et l’autre à partir de documents publiés.

Le prix, c’est la perte de la garantie shared-nothing. Un worker qui garde l’application amorcée garde aussi tout ce qu’elle a laissé fuir, si bien que propriétés statiques, caches et ressources ouvertes persistent désormais d’une requête à l’autre, et qu’une classe de bugs que PHP-FPM rendait impossible redevient possible. La documentation de FrankenPHP le dit sans détour : PHP « n’a pas été conçu à l’origine pour des processus de longue durée », et le mode worker est livré avec un compteur de requêtes maximum qui recycle les processus par précaution. Une équipe qui choisit le mode worker endosse la discipline que les équipes Node.js ou Java ont déjà.

Ce que coûte un processus

Vous voudrez un point de référence avant d’ajouter le moindre framework. Sur la machine où j’ai écrit ce livre, un processus PHP 8.3 en ligne de commande, sans script, alloue 2 mégaoctets pour son propre tas, atteint 33 mégaoctets de mémoire résidente en comptant l’interpréteur et ses extensions chargées, et démarre puis se termine en 20 millisecondes, mesuré avec memory_get_usage(true) et /usr/bin/time. Reproduisez ces mesures sur votre matériel, et souvenez-vous qu’un worker PHP-FPM partage avec ses frères les pages en lecture seule de l’interpréteur, si bien qu’un worker de plus coûte moins que le chiffre ne le suggère. La configuration de production de Wikimedia, publiée dans son gestionnaire de tâches, fait tourner huit workers PHP-FPM par conteneur MediaWiki, avec un OPcache de 500 mégaoctets et un cache APCu de 768 mégaoctets, dans un à deux gigaoctets de mémoire par conteneur.

La limite : le modèle shared-nothing n’a ni threads, ni état partagé en processus, ni travail en arrière-plan à l’intérieur d’une requête. Tout ce qui doit survivre à une requête, un pool de connexions, un cache chaud, une tâche planifiée, vit dans un autre processus ou un autre système, et l’architecture autour d’une application PHP en porte la marque. C’est une vraie contrainte, et c’est aussi ce qui rend l’exploitation simple.

Ce que vous pouvez vérifier vous-même

Installez PHP-FPM et un serveur web sur une petite machine virtuelle, activez la page de statut de FPM, et regardez le pool sous un générateur de charge comme wrk ou ab : le nombre de processus, la mémoire par worker et le temps de requête sont là, sous vos yeux. Lancez ensuite le même hello-world sous FrankenPHP en mode worker et comparez. Un après-midi de ce régime vous apprend plus sur le runtime que je ne viens de le faire, et les chiffres seront les vôtres.

Un chiffre de débit ne veut dire quelque chose qu’une fois que vous savez lequel de ces runtimes l’a produit.

Débit et latence

À quelle vitesse va-t-il, sur quelle mesure, et face à qui ? C’est votre deuxième question, et c’est celle où la hype fait le plus de dégâts. Sur le plus grand benchmark public qui compare des frameworks web de tous langages, les entrées PHP s’étalent sur deux ordres de grandeur selon le runtime qui les fait tourner, des quarante premières places au dernier dixième. Le langage seul ne prédit rien ; le déploiement prédit presque tout. Un écart pareil ne vous sert que si chaque chiffre vient avec son round, son matériel et son test, et ceux de ce chapitre les ont tous les trois.

L’histoire du moteur

Sur du code qui occupe le processeur, l’interpréteur a fait un grand pas une fois, puis des petits pas depuis. Le grand pas, c’est PHP 7.0, en décembre 2015, qui a remplacé les structures de données internes du moteur. Son éditeur affirmait alors que le temps d’exécution était « souvent divisé par deux » par rapport à PHP 5.6, dans un livre blanc sans méthodologie publiée. Une mesure indépendante, faite sur une seule machine avec toutes les versions de l’interpréteur de 5.6 à une build de développement de PHP 8.0, retrouve la même forme. Le score PHPBench, une suite synthétique de micro-benchmarks de l’interpréteur, passe de 288 000 sur PHP 5.6 à 620 000 sur PHP 7.0, puis monte par petites marches, entre rien et treize pour cent par version, jusqu’à 876 000 sur la build 8.0.

Depuis PHP 8.0, la vitesse de l’interpréteur sur une application web ne bouge plus, et ceux qui la mesurent le disent eux-mêmes. Un hébergeur qui publie des benchmarks chaque année a mesuré WordPress à 146 requêtes par seconde sur PHP 8.2 et à 148 sur PHP 8.5, sur la même machine, et il écrit que « les versions incrémentales produisent rarement de grands sauts de vitesse à elles seules ». C’est sa propre mesure, lancée à quinze requêtes simultanées sur une machine de trente cœurs ; elle dit donc le temps de réponse, pas la capacité. Retenez ceci : une version actuelle de PHP est à peu près deux fois plus rapide que PHP 5 sur le travail propre de l’interpréteur, et une montée de version mineure ne vous apportera rien d’autre que des corrections et des fonctionnalités.

Le benchmark multi-langages

Le Framework Benchmarks de TechEmpower est une suite publique qui a fait passer des centaines de frameworks web, dans des dizaines de langages, par les six mêmes tests sur le même matériel, chaque implémentation étant contribuée et entretenue par des volontaires dans un dépôt public. Son dernier round achevé est le Round 23, daté du 24 février 2025, exécuté sur un serveur à processeur Xeon Gold 6330, 28 cœurs et 56 threads, avec un réseau à 40 gigabits. Le dépôt du projet a été archivé le 24 mars 2026 : le Round 23 est donc le dernier, et ses chiffres sont les derniers de leur espèce. Rien d’autre ne compare autant de frameworks sous un même protocole, c’est pourquoi je les garde. Et comme les tests ne mesurent pas la même chose, chaque chiffre nomme le sien.

Le test Fortunes est celui qui ressemble le plus à une page web : une requête en base qui renvoie une douzaine de lignes, un gabarit HTML rendu avec échappement. Sur ce test, 510 entrées ont terminé le Round 23. Le graphique en retient seize, les leaders toutes catégories, le framework grand public de chaque langage majeur et les entrées PHP de chaque type de runtime. Le tableau brut avec toutes les entrées est rangé à côté des données de graphiques du livre, pour que vous puissiez faire votre propre sélection.

Lisez les barres PHP de haut en bas. Les entrées PHP les plus rapides, sur les runtimes workerman et Swoole, en SQL brut et sans framework, occupent les rangs 31 à 38 sur 510, au-dessus de 730 000 requêtes par seconde, devant l’entrée ASP.NET Core de base, les entrées Go et Spring. Un framework PHP complet avec un ORM complet sur un runtime worker, l’entrée Ubiquity, atteint 428 000 au rang 92. PHP nu sous PHP-FPM et nginx, le déploiement standard, atteint 146 000 au rang 248, environ un tiers devant Gin et FastAPI. Les deux frameworks PHP les plus utilisés, sous PHP-FPM, sont près du bas : Symfony à 26 000 et Laravel à 16 000, derrière Rails à 43 000 et Django à 32 000. Un même benchmark soutient donc à la fois que PHP peut compter parmi les runtimes web les plus rapides et qu’une application PHP typique compte parmi les plus lentes. Quand on ne vous dit que l’un des deux, on vous vend quelque chose.

Une partie de l’écart tient au runtime. Une entrée qui garde l’application chargée entre deux requêtes supprime le coût de démarrage, et c’est lui qui domine le temps de requête d’un framework.

Le même code Symfony passe de 26 000 requêtes par seconde sous PHP-FPM à 74 000 sous FrankenPHP et 111 000 sous Swoole, et le même code Laravel de 16 000 à 50 000 sous workerman. Le reste de l’écart tient à l’entrée elle-même. Chez TechEmpower, une entrée est entretenue par qui veut bien s’en occuper, et une entrée lente peut refléter une configuration datée autant que le framework. L’entrée Laravel sous RoadRunner, à 8 000, est plus lente que sous PHP-FPM ; je n’ai pas d’explication et je la rapporte telle qu’elle a été mesurée.

Les autres tests déplacent les rangs, pas l’histoire. Sur le test de sérialisation JSON, qui n’a pas de base de données, l’entrée Swoole atteint 2,5 millions de requêtes par seconde au rang 73, PHP-FPM nu 428 000 et Laravel sous PHP-FPM 27 000, tandis qu’ASP.NET Core est à 1,4 million, Node.js à 1,1 million, Spring à 328 000 et Django à 167 000. Sur le test à vingt requêtes SQL, que le pilote de base de données bride, les leaders de tous les langages se rejoignent sous 90 000, et les entrées PHP les plus rapides sont à 56 000, devant FastAPI à 37 000 et Spring à 32 000.

La latence

Le débit dit combien de requêtes une machine peut absorber. La latence dit combien de temps un utilisateur attend, et ce qui la domine, c’est ce que la requête attend, pas l’interpréteur. Tideways, un éditeur de profileur et membre fondateur de la PHP Foundation, a mesuré un hello-world PHP-FPM derrière nginx sur une machine virtuelle à huit cœurs, et relevé un 99e centile de 0,9 milliseconde à 18 000 requêtes par seconde. C’est le plancher : l’interpréteur et le gestionnaire de processus coûtent ensemble moins d’une milliseconde quand il n’y a rien d’autre à faire, et tout ce qui vient au-dessus, c’est l’application et ses dépendances.

Les chiffres de latence publics les plus utiles viennent d’une organisation qui publie ses propres objectifs et ses propres tableaux de bord. Les règles d’ingénierie de Wikimedia exigent qu’une requête GET s’achève en 50 millisecondes à la médiane et en 200 millisecondes au 99e centile du temps passé dans PHP, et en 500 millisecondes au 99e centile pour un POST. Son instance Grafana est publique et montre la distribution mesurée pour les requêtes qui atteignent les serveurs applicatifs, c’est-à-dire les défauts de cache et les utilisateurs connectés, autrement dit les requêtes chères. Le jour où j’ai vérifié, la médiane était d’environ 170 millisecondes et la queue de distribution bien au-dessus de l’objectif, pour des pages qui incluent le rendu du wikitexte depuis un cache d’analyse froid. Je vous donne le tableau de bord plutôt que l’instantané, parce qu’une semaine vous en dira plus qu’une heure.

Là où PHP perd

Sur du calcul pur, sans entrées-sorties, PHP est un interpréteur avec un JIT en option, et il est un ordre de grandeur plus lent qu’un runtime compilé à la volée comme V8. Le Computer Language Benchmarks Game, qui compare des programmes contribués sur les mêmes petites tâches, place le programme n-body mono-thread le plus rapide à 2,2 secondes en Rust, 3,1 en C#, 6,0 en Java, 6,4 en Go, 8,6 en Node.js, 167 en Ruby avec YJIT, 204 en PHP 8.4 et 360 en Python 3.13.

Le graphique a ses réserves. Les programmes PHP tournent avec un tampon JIT configuré mais opcache.jit laissé à sa valeur par défaut de PHP 8.4, c’est-à-dire désactivé : ils mesurent donc l’interpréteur seul. La RFC du JIT rapporte un gain de quatre fois sur Mandelbrot une fois le JIT activé, ce qui resserrerait l’écart sans le combler. Les programmes sont aussi contribués, donc ils mesurent le meilleur programme que quelqu’un a pris la peine d’écrire. Avec ces deux réserves, l’ordre tient. Pour du calcul numérique, de la simulation, l’analyse de gros fichiers en boucle ou tout ce qui occupe un cœur, PHP est dans la classe de Python et de Ruby, pas dans celle de Node.js, et trente à cent fois derrière Go, Java, C# et Rust sur ce programme. Là où PHP est le mauvais choix en tire la conséquence.

La limite : les bons chiffres de débit de PHP viennent des runtimes worker et de l’accès brut à la base, ce qu’une équipe ordinaire ne fait pas tourner dès le premier jour. Ses chiffres typiques, un framework complet sous PHP-FPM, sont ceux de Rails et de Django, quelques dizaines de milliers de requêtes par seconde sur une grosse machine, ce qui reste plus que ce que la plupart des applications recevront jamais. Et sur du calcul pur, l’interpréteur est un ordre de grandeur derrière V8.

Ce que vous pouvez vérifier vous-même

L’outillage TechEmpower tourne encore depuis son dépôt archivé, avec Docker, et les tableaux bruts du Round 23 pour six tests sont rangés en CSV dans le dossier charts/raw/ du livre : vous pouvez vérifier ma sélection et en faire une autre. Plus près de chez vous, prenez l’application que vous construiriez, ou un équivalent open source, faites-la tourner sous PHP-FPM puis sous un runtime worker sur la même machine, et mesurez avec wrk à la concurrence que vous attendez en production. Le rapport que vous obtiendrez est le seul qui compte. Pour la latence, ouvrez le tableau de bord public « Backend Pageview Timing » de Wikimedia et lisez-en une semaine.

Le débit suppose des requêtes indépendantes. Que se passe-t-il quand elles ne le sont pas ? C’est la question suivante.

Concurrence

Dix mille connexions qui dorment, cent appels sortants à lancer d’un coup, un calcul qui devrait occuper tous les cœurs : un jour ou l’autre, vos requêtes cessent d’être indépendantes les unes des autres, et c’est là que commence votre troisième question. PHP n’a ni threads dans sa version standard, ni boucle d’événements intégrée. La concurrence lui vient des processus, de bibliothèques bâties sur les coroutines que le langage a ajoutées en 8.1, et de runtimes qui apportent leur propre boucle d’événements. Chacune de ces trois réponses convient à certaines charges et échoue sur d’autres, et c’est cette différence qu’il faut connaître avant de lui confier un service.

Beaucoup de requêtes

Un worker qui attend 40 millisecondes une réponse de la base occupe un processus pendant 40 millisecondes, et aucune autre requête ne s’en aperçoit. Tout le modèle tient là, pour le cas ordinaire des requêtes HTTP indépendantes : le pool de processus du chapitre Le runtime, où chaque worker bloque sur sa requête SQL, sa lecture de cache ou son appel HTTP sortant pendant que le système d’exploitation fait tourner les autres. Un runtime à boucle d’événements comme Node.js a besoin de code asynchrone pour qu’un appel lent ne gèle pas toutes les connexions. PHP a préféré donner un processus à chaque connexion, et le code reste synchrone.

Cette simplicité se paie en mémoire, connexion par connexion. Un worker qui garde un WebSocket ouvert, qui attend la fin d’un long poll ou qui diffuse une réponse pendant une minute immobilise un processus entier tout ce temps, et un pool de quelques centaines de processus ne tiendra jamais dix mille connexions inactives. Pour cette charge-là, le modèle par défaut de PHP est le mauvais.

Beaucoup de connexions

Pour les charges qui exigent de nombreuses connexions simultanées dans un seul processus, PHP dispose de runtimes asynchrones, et ce sont des bibliothèques ou des extensions, pas des fonctionnalités du langage. Par ordre alphabétique : AMPHP, un ensemble de bibliothèques non bloquantes construites sur une boucle d’événements et sur les fibers du langage ; ReactPHP, un ensemble de bibliothèques bas niveau pilotées par les événements, avec sa propre boucle, son serveur HTTP et ses composants de flux ; Swoole enfin, ou son fork OpenSwoole, une extension en C qui donne à PHP une boucle d’événements, des coroutines et un serveur HTTP et WebSocket intégré, avec des appels d’entrées-sorties qui rendent la main au lieu de bloquer. FrankenPHP et RoadRunner, les runtimes worker du chapitre Le runtime, ne figurent pas dans cette liste parce qu’ils répondent à un autre besoin : ils gardent l’application chargée entre deux requêtes, toujours une requête à la fois par worker, et ne rendent pas le code concurrent.

Sous les deux premiers se trouve la Fiber, arrivée en PHP 8.1 : une fonction capable de se suspendre elle-même, et que celui qui la tient peut reprendre plus tard. La RFC qui l’a introduite dit très précisément ce qu’elle n’est pas : « toutes les fibers vivent dans un seul thread, une seule fiber s’exécute à la fois », et « le code bloquant, comme file_get_contents(), continuera de bloquer le processus entier, même si d’autres fibers existent ». Le langage ne fournit aucun ordonnanceur. C’est une bibliothèque qui l’apporte, et chaque appel d’entrée-sortie du programme doit passer par elle pour rendre la main. Une application PHP asynchrone s’écrit donc contre le client HTTP, le client de base de données et les fonctions de fichiers d’AMPHP ou de ReactPHP, et non contre les fonctions standard. Une seule bibliothèque synchrone glissée par mégarde dans les dépendances bloque toute la boucle.

Jusqu’où une boucle d’événements porte PHP, le test plaintext du benchmark multi-langages le montre : il ne fait aucun travail applicatif et mesure seulement combien de connexions en pipeline une couche HTTP sait servir.

L’entrée Swoole sert 3,5 millions de requêtes par seconde, devant Micronaut, Gin, Node.js et Spring, quand PHP nu sous PHP-FPM en sert 450 000 et Laravel sous PHP-FPM 27 000. Le plafond est ailleurs : ASP.NET Core à 11,5 millions, et tout en haut un serveur Python adossé à du C et un serveur Rust, autour de 28 millions. Avec une boucle d’événements, PHP joue dans le deuxième groupe, pas dans le premier. Sans, il joue dans le quatrième.

Beaucoup de cœurs

Le programme spectral-norm le plus rapide en PHP dans le Benchmarks Game termine en 18 secondes de temps réel pour 72 secondes de CPU réparties sur plusieurs cœurs, contre 90 secondes pour le meilleur programme Python et 1,6 seconde pour Node.js. Cet écart entre temps CPU et temps réel, c’est à cela que ressemble le calcul parallèle en PHP, et une fois de plus il vient des processus. L’interpréteur en ligne de commande forke avec pcntl_fork(), lance des sous-processus avec proc_open() ou fait tourner plusieurs scripts sous un superviseur, et les résultats reviennent par des tubes, des fichiers, une base ou une file d’attente. L’extension parallel propose bien des threads, mais sur la version thread-safe de l’interpréteur, que peu de distributions livrent. Le parallélisme par fork fonctionne, et il fonctionne dans la classe de vitesse de l’interpréteur décrite dans Débit et latence.

L’ordonnanceur entrera-t-il un jour dans le moteur ? La question est ouverte sur la liste internals. Une RFC intitulée « Concurrency Support in the PHP Engine », qui ajouterait un ordonnanceur et de la concurrence structurée au langage lui-même, y était en discussion au moment où j’écris, sans vote, après qu’une première proposition sur le même sujet a été abandonnée en juillet 2026. En septembre 2026, le langage a des fibers, et l’ordonnanceur est une bibliothèque.

Ce qui ne doit pas faire attendre l’utilisateur

La concurrence dont vous aurez besoin le plus souvent n’a rien de spectaculaire : c’est le travail que l’utilisateur ne devrait pas avoir à attendre. Une requête a une durée limite et une réponse à rendre, donc tout ce qui prend plus de temps doit en sortir. L’idiome, c’est une file d’attente et un processus worker. La requête dépose un travail dans une table ou un courtier de messages, puis répond. De son côté, un script PHP en ligne de commande, maintenu en vie par un superviseur, dépile la file et exécute les travaux un par un. Ce script n’a ni limite de temps ni limite de mémoire tant que vous ne lui en donnez pas, alors un worker de production fixe les deux et s’arrête proprement après quelques milliers de travaux, pour que le superviseur relance un processus neuf. La plupart des frameworks full-stack livrent ce schéma avec un pilote pour les courtiers habituels, et cron couvre les tâches planifiées.

La limite : la concurrence de PHP est à gros grain. Des processus pour les requêtes, des processus pour les cœurs, une file d’attente pour le travail en arrière-plan, et un runtime à part, avec ses propres bibliothèques d’entrées-sorties, pour le cas des connexions nombreuses. Si votre produit est un service temps réel avec des dizaines de milliers de connexions ouvertes, vous passerez votre premier mois à choisir puis à apprendre l’un des runtimes asynchrones, et vous découvrirez que la plupart des bibliothèques de l’écosystème n’ont pas été écrites pour lui. Si votre produit est fait de requêtes et de réponses, vous ne rencontrerez jamais la question.

Ce que vous pouvez vérifier vous-même

Prenez le scénario à connexions nombreuses que vous avez vraiment, si vous en avez un, et écrivez-le deux fois dans l’après-midi : une fois avec AMPHP ou ReactPHP, une fois avec Swoole ou OpenSwoole. Comptez ensuite combien des bibliothèques dont vous dépendriez offrent un client non bloquant. Si c’est la plupart, la voie asynchrone vous est ouverte. Si elles sont rares, la conclusion honnête est que PHP est le mauvais outil pour ce service-là, et le reste de votre système est une décision à part.

Reste à savoir si le langage lui-même est de ceux que vous auriez envie d’écrire, et cette question-là, vous y répondez en le lisant.

Le langage en 2026

Est-ce un langage que vous auriez envie d’écrire pendant quelques années ? Aucun benchmark ne répond à cela ; vous y répondez en lisant du code. PHP est aujourd’hui un langage orienté objet, avec ramasse-miettes, aux types déclarés et appliqués à l’exécution aux frontières des fonctions et des propriétés, doté d’énumérations, d’immutabilité, de closures, d’attributs et d’un gestionnaire de paquets. Un exemple suffit pour le juger, et chaque construction plus jeune que 2022 porte la version qui l’a introduite, pour que vous sachiez ce qu’un projet donné peut utiliser.

Un exemple complet

<?php
declare(strict_types=1);

enum Status: string
{
    case Draft = 'draft';
    case Published = 'published';
    case Archived = 'archived';

    public function isVisible(): bool
    {
        return $this === self::Published;
    }
}

final readonly class Article
{
    public function __construct(
        public string $title,
        public Status $status,
        public ?\DateTimeImmutable $publishedAt = null,
    ) {
    }

    public function publish(\DateTimeImmutable $at): static
    {
        return new static($this->title, Status::Published, $at);
    }
}

function summary(Article ...$articles): string
{
    $visible = array_filter($articles, fn (Article $a): bool => $a->status->isVisible());
    $titles = array_map(fn (Article $a): string => $a->title, $visible);

    return match (count($titles)) {
        0 => 'nothing published',
        1 => $titles[array_key_first($titles)],
        default => implode(', ', $titles),
    };
}

$draft = new Article(title: 'Benchmarks', status: Status::Draft);
$live = $draft->publish(new \DateTimeImmutable('2026-09-01'));

echo summary($draft, $live), PHP_EOL;   // Benchmarks
echo $draft->status->value, PHP_EOL;    // draft

Lisez-le comme vous liriez une pull request. declare(strict_types=1) passe le fichier en typage strict : une chaîne passée là où un int est déclaré lève une TypeError au lieu d’être convertie. L’interrupteur agit fichier par fichier, et un projet l’active dans chacun. L’enum est une vraie énumération, un ensemble fermé d’objets singletons qui peuvent porter des méthodes et une valeur sous-jacente. La classe readonly (PHP 8.2) rend chaque propriété immuable après construction, et son constructeur déclare et affecte ces propriétés en un seul endroit.

Le reste de la syntaxe, vous le connaissez déjà par d’autres langages : les arguments nommés à l’appel, ? pour les types nullables, static comme type de retour, fn pour les closures d’une ligne, et un match qui compare strictement, ne tombe jamais dans la branche suivante et lève une exception quand aucune branche ne correspond.

Ce que l’exemple ne montre pas compte tout autant. Chaque frontière y est typée, alors que le langage ne l’exige pas ; la lecture d’une variable non définie est un avertissement en PHP 8, et les analyseurs statiques en font une erreur. Le signe $ sur les variables et la flèche -> pour l’accès aux membres sont les deux morceaux de syntaxe qui paraissent étrangers à tout le monde, et au bout d’une heure on ne les voit plus.

Les ajouts récents

Les deux dernières versions ont changé la façon d’écrire le code, et un projet sur PHP 8.4 ou plus récent utilisera ce qu’elles ont apporté.

// PHP 8.4
final class Money
{
    public function __construct(
        public private(set) int $cents,
        public string $currency,
    ) {
    }

    public string $formatted {
        get => number_format($this->cents / 100, 2) . ' ' . $this->currency;
    }
}

$price = new Money(1999, 'EUR');
echo $price->formatted, PHP_EOL;     // 19.99 EUR
$price->cents = 5;                   // Error: Cannot modify private(set) property Money::$cents

public private(set) est la visibilité asymétrique (PHP 8.4) : la propriété se lit de partout et ne s’écrit que depuis l’intérieur de la classe, ce qui supprime la plupart des getters qu’un développeur Java ou C# s’attend à écrire. Le bloc get sous $formatted est un hook de propriété (PHP 8.4), une logique attachée à une propriété sans changer ses sites d’appel, et cela supprime la plupart des autres. L’opérateur pipe (PHP 8.5) enchaîne les fonctions de gauche à droite :

// PHP 8.5
$slug = '  Hello, World  '
    |> trim(...)
    |> strtolower(...)
    |> (fn (string $s): string => preg_replace('/[^a-z0-9]+/', '-', $s))
    |> (fn (string $s): string => trim($s, '-'));

echo $slug, PHP_EOL;   // hello-world

La forme trim(...) est un callable de première classe (PHP 8.1), une référence à une fonction sous forme de valeur, avec l’arité vérifiée par le moteur. Ajoutez les attributs, des métadonnées structurées lues par réflexion et utilisées par tous les frameworks pour le routage, la validation et le mapping, et vous avez les constructions que vous croiserez le plus dans une base de code démarrée après 2024.

Ce que le système de types fait et ne fait pas

Les types sont déclarés sur les paramètres, les valeurs de retour, les propriétés et les constantes de classe, et le moteur les applique à l’exécution. Les types union (int|string), les types intersection (Countable&Traversable), les types nullables, never, mixed et les énumérations font tous partie du langage. Une erreur de type est une exception, pas un avertissement, et en mode strict il n’y a aucune coercition implicite entre scalaires, à l’exception de l’élargissement d’un int en float.

Ce qui manque, autant l’entendre de moi maintenant que le découvrir la troisième semaine. Il n’y a pas de génériques dans le langage. Un list<Order> ne peut pas s’exprimer dans une signature ; le paramètre est array. L’écosystème répond par une syntaxe de docblock que les deux analyseurs statiques, PHPStan et Psalm, comprennent et appliquent. @param list<Order> $orders est vérifié au moment de l’analyse, dans l’éditeur et en intégration continue, avec les types template, les types conditionnels et les types de forme, plus riches que tout ce que le langage lui-même sait exprimer ; un projet PHP typé exécute donc un analyseur à son niveau le plus strict à chaque build et traite sa sortie comme des erreurs de compilation. Que ce soit un substitut acceptable à des génériques dans le langage, c’est à vous d’en juger, selon vos propres habitudes. C’est un substitut, et vous devriez le peser comme tel.

L’autre absence vient du runtime plutôt que du langage : pas de threads en userland ni de boucle d’événements intégrée. Concurrence décrit ce qui existe à la place.

La bibliothèque standard

strpos voisine avec str_replace, array_key_exists avec in_array, et certaines fonctions prennent l’aiguille en premier quand d’autres prennent la botte de foin. Cette incohérence est historique, elle est réelle, et elle ne disparaîtra pas. Depuis PHP 8.0, les nouvelles fonctions suivent un seul schéma de nommage (str_contains, array_is_list, array_find), les fonctions internes lèvent TypeError et ValueError sur une entrée invalide au lieu de retourner false, et tout éditeur doté d’un serveur de langage PHP complète les noms ; c’est ainsi qu’une équipe vit avec le reste. La seconde verrue, ce sont les chaînes, qui sont des suites d’octets : strlen('é') vaut 2, et le traitement du texte passe par la famille mb_. Voilà les deux que vous rencontrerez en premier.

La limite : le système de types de PHP est appliqué à l’exécution et aux frontières des fonctions et des propriétés, pas à l’intérieur des expressions ni à travers les conteneurs génériques. Une équipe qui veut des garanties à la compilation sur ses collections les obtient d’un analyseur statique, pas du langage.

Ce que vous pouvez vérifier vous-même

Installez PHP 8.5 (votre gestionnaire de paquets, ou l’image Docker officielle php:8.5-cli), collez le premier exemple dans un fichier et lancez-le avec php file.php. Puis cassez-le : passez une chaîne là où l’énumération Status est attendue, retirez strict_types, écrivez un match sur l’énumération en oubliant un cas, puis appelez-le avec ce cas. Les messages d’erreur sont la partie d’un langage avec laquelle on vit, et cinq minutes suffisent pour les juger. Pour le système de types, lancez PHPStan ou Psalm à son niveau le plus strict sur n’importe quel projet PHP open source d’une taille qui vous parle, et lisez les vingt premiers résultats ; ils vous montrent ce que l’analyseur attrape et que le moteur laisse passer.

L’écosystème

Personne n’adopte un langage seul ; on adopte avec lui ses bibliothèques, ses outils et ses conventions, et votre question est de savoir si ceux de PHP tiennent la comparaison avec ce que npm, pip ou Maven vous donnent ailleurs. PHP a un gestionnaire de paquets, un registre public, un organisme d’interopérabilité qui publie des standards plutôt que des produits, et au moins deux options mûres dans chaque catégorie d’outillage, dont aucune n’est cautionnée par le langage lui-même. La taille et l’activité se mesurent, et les chiffres sont ici ; la qualité, je ne peux que vous la désigner du doigt.

Composer et Packagist

Composer est le gestionnaire de dépendances, et il n’y en a pas de second. Il lit un composer.json, résout les versions selon des contraintes de versionnage sémantique, écrit un composer.lock qui fige chaque dépendance transitive, et génère l’autoloader qui fait correspondre les noms de classes aux fichiers selon le standard PSR-4. Packagist, son registre par défaut, listait 468 099 paquets et 5,8 millions de versions de paquets le 17 septembre 2026, et avait enregistré 199,6 milliards d’installations de paquets depuis avril 2012.

Les installations via Composer sont passées de 2,0 milliards en 2016 à 36,0 milliards en 2025, et le seul mois d’août 2026 en a enregistré 4,9 milliards, 91 % de plus qu’en août 2025. C’est le signal d’activité, et sa définition appelle une réserve : une installation est un paquet installé par Composer et signalé au registre, si bien que les pipelines d’intégration continue et les builds d’images de conteneurs en représentent une part large et inconnue. La courbe dit que les projets PHP sont construits, testés et déployés en nombre croissant. Elle ne compte pas les projets, et vous ne pouvez pas non plus mettre le nombre de paquets d’un registre en face de celui d’un autre, parce que ce qu’on appelle un « paquet » diffère d’un écosystème à l’autre.

Depuis Composer 2.4, sorti en août 2022, composer audit confronte chaque paquet installé aux avis de sécurité que Packagist sert par son API, et fait échouer le build quand il trouve une vulnérabilité connue, un paquet abandonné ou un paquet signalé comme malveillant. Les avis viennent de la base partagée de l’écosystème, qui en contenait 1 649 en septembre 2026. Les extensions écrites en C, que Composer n’a jamais gérées, ont reçu leur propre installeur en 2025 et 2026 : PIE, le PHP Installer for Extensions, financé par une subvention publique et hébergé sous l’organisation php.

Frameworks et plateformes

Les frameworks full-stack en développement actif sont CakePHP, Laminas, Laravel, Symfony et Yii ; les micro-frameworks, Mezzio et Slim ; les plateformes de contenu, Drupal, Joomla, TYPO3 et WordPress ; les plateformes de commerce, Adobe Commerce avec son édition Magento Open Source, PrestaShop, Shopware, Sylius et WooCommerce. L’ordre est alphabétique d’un bout à l’autre, et je n’en recommande aucun.

Ce qu’ils sont les uns pour les autres, en revanche, se dit avec une source. Symfony publie la liste des projets construits sur ses composants, et elle compte Drupal, Joomla, TYPO3, Magento, PrestaShop, Shopware et Sylius, ainsi que Composer lui-même. Ces composants, et ceux de Laravel, sont ce que vous trouverez sous la plupart des plateformes du chapitre Empreinte, WordPress excepté, et c’est pour cela que l’écosystème est moins fragmenté qu’une liste de noms ne le laisse croire. Les chiffres d’usage viennent d’une enquête : parmi les développeurs qui citent PHP comme langage principal, 64 % déclarent utiliser Laravel, 25 % WordPress et 23 % Symfony, plusieurs réponses étant permises. L’échantillon penche vers les clients de l’éditeur, alors lisez cela comme des réponses d’enquête, pas comme un classement que je cautionne.

Outillage

Chaque catégorie a au moins deux options maintenues, et un après-midi avec chacune est la bonne façon de choisir. Pour les tests, Pest et PHPUnit. Pour l’analyse statique, PHPStan et Psalm, qui lisent tous deux une syntaxe de types en docblock plus riche que le langage et appliquent les génériques, les formes et les types conditionnels que le moteur ne connaît pas. Pour le style de code, PHP-CS-Fixer et PHP_CodeSniffer, tous deux capables d’appliquer le standard PER Coding Style. Pour l’édition, PhpStorm et VS Code avec une extension PHP, chacun avec un serveur de langage ; pour servir, FrankenPHP, PHP-FPM derrière un serveur web et RoadRunner. Deux outils sont seuls dans leur catégorie : Xdebug, le débogueur, qui profile aussi, et Rector, qui réécrit le code vers une syntaxe plus récente et qui est le moyen de faire passer une grande base de code d’une version de PHP à l’autre.

Quelle part de cet outillage est réellement utilisée est une autre affaire, et le chiffre d’enquête sur ce point est le moins flatteur de ce chapitre.

La moitié des développeurs PHP de l’échantillon JetBrains utilisent PHPUnit, un tiers utilisent PHPStan, et un tiers n’écrivent aucun test ; 42 % n’utilisent régulièrement aucun outil de qualité de code. Est-ce pire que dans d’autres écosystèmes, l’enquête ne le dit pas, et je ne le devinerai pas. L’outillage existe ; qu’il soit utilisé est une propriété de l’équipe, pas du langage.

Standards

Une bibliothèque qui type son logger en Psr\Log\LoggerInterface fonctionne sous n’importe quel framework, et c’est à cela que sert le PHP Framework Interoperability Group, PHP-FIG. Il publie les standards qui permettent aux bibliothèques d’auteurs différents de s’emboîter : 14 PHP Standards Recommendations acceptées en septembre 2026, couvrant l’autoloading (PSR-4), la journalisation (PSR-3), les messages et gestionnaires HTTP (PSR-7, 15, 17), le cache (PSR-6, 16), les conteneurs (PSR-11), les événements (PSR-14) et les horloges (PSR-20), plus le PER Coding Style, en version 3.1, qui a remplacé PSR-12 comme standard de codage.

La distribution du langage lui-même est la dernière pièce. php.net publie des archives sources signées par les release managers depuis 2012, avec leurs sommes de contrôle ; les images Docker officielles php:8.5-cli et php:8.5-fpm suivent chaque version ; et les distributions Linux grand public empaquettent une version qu’elles corrigent elles-mêmes, qui n’est pas toujours une version que php.net maintient encore.

La limite : l’écosystème est un écosystème web. Sa profondeur en HTTP, gabarits, ORM, files d’attente, paiement et contenu n’a pas d’équivalent en calcul numérique, apprentissage automatique, pipelines de données ou applications de bureau et mobiles, où les paquets sont rares et la communauté petite. Si votre produit en a besoin, vous utiliserez un autre langage pour cette partie, et Là où PHP est le mauvais choix le dit en détail.

Ce que vous pouvez vérifier vous-même

Lancez composer create-project avec le squelette du framework de votre choix, puis composer audit, et lisez le fichier lock produit ; toute la chaîne d’approvisionnement est devant vous en dix minutes. Cherchez ensuite sur Packagist les trois bibliothèques dont votre projet ne peut pas se passer, et regardez la date de leur dernière version et le nombre de leurs tickets ouverts. Cette vérification vous en apprend plus que le nombre de paquets.

Sous tout cela tourne un interpréteur, et qui l’entretient est une question à part entière.

Gouvernance et pérennité

Avant de miser une base de code sur quoi que ce soit, vous voulez savoir qui décide de ce qui y entre, qui est payé pour l’entretenir, et combien de temps une version reste maintenue. PHP évolue par un processus de RFC public avec un vote aux deux tiers, livre une version mineure chaque année et maintient chacune pendant quatre ans, et dispose depuis 2021 d’une fondation qui contractualise treize ingénieurs et a signé 42 % des commits de l’interpréteur en 2025. L’argent derrière cette fondation est inférieur à un million de dollars par an, et ce chiffre fait autant partie de la réponse que le reste.

Comment un changement entre

Chaque changement du langage passe par une Request for Comments sur wiki.php.net. La proposition est écrite, discutée pendant au moins deux semaines sur la liste de diffusion internals, puis soumise à un vote ouvert pendant au moins deux semaines, et elle ne passe qu’avec les deux tiers des voix exprimées ; les votants sont les contributeurs qui disposent d’un compte php.net et un petit nombre de représentants de la communauté, et la règle des deux tiers est stricte depuis février 2019. Chaque étape est publique, jusqu’aux votes exprimés nominativement.

Les types intersection nullables ont été rejetés 12 à 26 en 2021. Les closures multi-instructions à capture automatique ont obtenu une majorité de 27 à 16 en 2022 et ont été refusées quand même, faute d’atteindre la barre des deux tiers. La visibilité asymétrique a été refusée 14 à 12 en janvier 2023, révisée, acceptée 24 à 7 en août 2024 et livrée dans PHP 8.4, et les classes imbriquées ont été refusées 2 à 20 en mai 2025. Cette liste de refus est la preuve que le processus est réel.

Le rythme se lit dans un index secondaire : 31 RFC pour PHP 8.4, 19 pour PHP 8.5, et déjà 29 listées pour PHP 8.6 en septembre 2026. Si vous venez d’un langage piloté par un seul éditeur ou par un dictateur bienveillant, pesez ce que cela signifie : rien n’entre dans PHP parce que quelqu’un d’important le veut, et des fonctionnalités qu’une majorité voulait ont été refusées. Le processus est lent, et il est public.

Le calendrier des versions

Depuis décembre 2015, PHP livre une version mineure chaque année, onze d’affilée, chacune entre le 20 novembre et le 8 décembre. Chaque branche reçoit ensuite deux ans de support actif, avec des corrections de bugs et de sécurité dans des versions correctives mensuelles, puis deux ans de corrections de sécurité seulement. Depuis une RFC votée en avril 2024, les deux fenêtres se terminent le 31 décembre de leur dernière année, ce qui vous permet de planifier vos mises à niveau par année civile.

En septembre 2026, quatre branches sont maintenues : PHP 8.2 en support de sécurité jusqu’au 31 décembre 2026, 8.3 jusqu’à la fin 2027, 8.4 en support actif jusqu’à la fin 2026, et 8.5 en support actif jusqu’à la fin 2027. PHP 8.6 est prévu en disponibilité générale le 19 novembre 2026, avec son gel des fonctionnalités en août, des release candidates à partir du 24 septembre et trois release managers nommés. Aucune date n’existe pour un PHP 9.0, et je n’en donne aucune. Les versions de PHP, 2015 à 2026 liste chaque version avec ses dates.

Derrière le calendrier, le dépôt montre l’activité. Dans les douze mois jusqu’au 17 septembre 2026, la branche principale de php-src a reçu 5 316 commits de 171 auteurs distincts, et le dépôt compte 1 644 contributeurs sur un historique GitHub qui commence en 2011.

Qui est payé

Jusqu’en 2021, l’interpréteur était entretenu par des bénévoles et par une poignée d’ingénieurs employés par des entreprises ayant un intérêt dans PHP. En novembre 2021, quand l’un des développeurs du cœur les plus actifs a annoncé qu’il s’éloignait de ce travail, dix entreprises ont créé The PHP Foundation pour financer directement le développement du cœur : Acquia, Automattic, Craft CMS, JetBrains, Laravel, PrestaShop, Private Packagist, Symfony, Tideways et Zend by Perforce. La fondation est hébergée fiscalement par Open Source Collective, liste chaque transaction sur sa page Open Collective et publie un rapport de transparence chaque année.

Les contributions ont été de 712 000 dollars en 2022, 419 000 en 2023, 684 000 en 2024 et 731 000 en 2025. Les dépenses en ingénieurs sont passées de 275 000 dollars en 2023 à 635 000 en 2024 et 784 000 en 2025, une année que la fondation a close sur un déficit qu’elle décrit comme délibéré. Voilà l’échelle, et ce sont les rapports eux-mêmes qui la donnent.

Ce que cet argent achète, en septembre 2026, c’est treize ingénieurs à temps plein ou partiel sous contrat, un directeur exécutif et un conseil de dix membres non rémunérés ; ces ingénieurs ont signé 42 % des commits de php-src et 32 % des pull requests fusionnées en 2025. Deux subventions publiques s’ajoutent à l’argent des sponsors. La Sovereign Tech Agency allemande a financé 205 000 euros de travaux en 2023 et 2024 et 223 680 euros en 2025 et 2026, et une subvention d’Alpha-Omega, un projet de la Linux Foundation, finance une équipe de sécurité de l’écosystème depuis mai 2026.

La dépendance est dans les mêmes rapports. Deux sponsors, Automattic et JetBrains, représentent respectivement 762 500 et 476 670 dollars des 3,37 millions de dollars enregistrés sur la page Open Collective de la fondation depuis novembre 2021, soit environ 37 % à eux deux ; ce total cumulé et les rapports annuels n’ont pas le même périmètre, et je ne les ai pas réconciliés. Le nombre d’organisations et de particuliers sponsors est tombé de 658 en 2024 à 536 en 2025, ce que la fondation elle-même qualifie de « nettement moins ». Un budget inférieur à un million de dollars est petit pour un langage de l’empreinte décrite dans Empreinte : il paie une douzaine d’ingénieurs, pas un groupe de recherche. Chacun de ces chiffres, c’est la fondation qui le publie.

Sécurité

Une vulnérabilité arrive au projet par le flux d’avis privés de GitHub sur le dépôt php-src ou par e-mail à l’équipe de sécurité. Une politique publiée la classe en sévérité haute, moyenne ou basse, et les deux classes supérieures sont corrigées dans un dépôt privé avant une publication coordonnée. Les tags de version sont signés par les release managers depuis avril 2012, et chaque archive est livrée avec une signature détachée et une somme de contrôle publiée. Je n’ai trouvé ni nomenclature logicielle ni attestation de build pour les archives de version, et je le rapporte comme « non trouvé » plutôt que comme « n’existe pas ».

L’interpréteur a eu 8 vulnérabilités publiées en 2022, 7 en 2023, 18 en 2024, 13 en 2025 et 14 en 2026 jusqu’au 17 septembre. La hausse de 2024 coïncide avec un audit externe de l’interpréteur, commandé avec des fonds publics, qui a trouvé 27 problèmes dont 17 avaient des implications de sécurité, trois d’entre eux de sévérité haute, et qui a produit plusieurs des CVE de cette année-là. Le graphique se lit mal si l’on n’y prend garde. La politique de PHP n’attribue pas de CVE à la plupart des problèmes de sévérité basse, donc le décompte reflète la politique autant que le code. Un décompte de vulnérabilités ne se compare pas non plus d’un langage à l’autre : ce qui compte comme « le langage », un runtime, une bibliothèque standard, un registre de paquets, diffère dans chacun, et la politique de divulgation aussi.

La limite : le langage est gouverné par ses contributeurs, financé par une fondation au budget inférieur à un million de dollars par an avec deux sponsors dominants, et sécurisé par une petite équipe et une politique qui attribue moins de CVE que d’autres ne le feraient. Ce sont les faits d’un projet communautaire, et ils sont publiés par le projet lui-même ; si vous les comparez avec un langage adossé à la masse salariale d’un grand éditeur, comparez les risques des deux côtés, y compris la liberté de l’éditeur de changer de cap.

Ce que vous pouvez vérifier vous-même

Ouvrez wiki.php.net/rfc et lisez une RFC actuellement en vote, puis le fil de la liste internals qui l’accompagne ; une heure passée là vous montre comment les décisions se prennent, mieux que n’importe quelle description. Ouvrez la page Open Collective de la fondation, où chaque contribution et chaque dépense est listée par date. Ouvrez les avis de sécurité de php-src sur GitHub et lisez les trois plus récents, en notant le délai entre le signalement et le correctif.

Ce que tout cela vous coûte, en salaires, en hébergement et en mises à niveau, est la question suivante.

Coût de possession

Un langage vous coûte trois choses : les gens qui l’écrivent, les machines qui l’exécutent et le calendrier que vous consacrez à le tenir à jour. PHP a un chiffre pour chacune, et chaque chiffre se lit de deux façons. Les développeurs PHP sont nombreux et, d’après les médianes des enquêtes elles-mêmes, moins payés que ceux de la plupart des autres langages ; le runtime est celui qui compte le moins de pièces mobiles à héberger, des fichiers servis par un pool de processus ; et la cadence annuelle des versions impose un budget de mise à niveau annuel qu’une large part du parc installé n’a pas payé. La lecture bon marché et la lecture chère sortent des mêmes sources, et vous aurez besoin des deux.

Les personnes

Un développeur professionnel sur cinq a écrit du PHP dans l’année. Cela le place douzième parmi les langages de la plus grande enquête auprès des développeurs, à quelques points de Go et de C.

Une autre enquête confirme l’ordre de grandeur : 17 % des répondants de l’enquête JetBrains de 2025 ont utilisé PHP, et 9 % l’ont cité comme langage principal. Le marché du travail, lui, reste peu documenté publiquement. Un agrégateur d’offres d’emploi britanniques a compté 613 postes permanents citant PHP sur les six mois précédant septembre 2026, contre 404 un an plus tôt, pour un salaire médian annoncé de 48 676 livres, en hausse de 14,5 %. Je n’ai trouvé aucune série publique comparable pour d’autres pays, je n’en rapporte donc aucune.

Le chiffre de salaire qui existe est la médiane d’enquête, et elle est basse.

Dans la dernière édition de l’enquête Stack Overflow à publier des salaires par langage, les développeurs utilisant PHP ont déclaré une médiane de 49 586 dollars par an, la deuxième plus basse de cinquante langages, contre 63 694 pour JavaScript, 67 723 pour Python et 90 221 pour Ruby. Le chiffre est mondial et auto-déclaré, et les répondants PHP vivent plus souvent qu’à leur tour dans des pays à bas salaires, si bien qu’il en dit moins sur votre ville qu’il n’y paraît. Lisez-le comme un coût, et recruter en PHP revient peu cher dans l’ensemble. Lisez-le comme un signal, et le marché valorise le poste PHP médian sous le poste médian des autres langages. Si vous montez une équipe, il vous faut les deux lectures.

Le sentiment se chiffre moins bien que le salaire. Parmi les développeurs ayant utilisé un langage dans l’année, 38,9 % de ceux qui ont utilisé PHP veulent continuer, le taux le plus bas des langages grand public et loin derrière Rust à 72,4, TypeScript à 58,0 ou Python à 56,4. La même année, 58 % des développeurs dont le langage principal est PHP disaient ne pas prévoir de migrer vers un autre. Les deux chiffres décrivent des populations différentes, l’utilisateur occasionnel et le spécialiste, et mis côte à côte ils dessinent un langage auquel on est plus souvent affecté qu’attiré. Pour le recrutement, cela veut dire un vivier large et une question de rétention, et c’est à vous de les pondérer.

Les machines

Une application PHP en production, ce sont des fichiers sur un disque, servis par un pool de processus. Pas de processus applicatif de longue durée à surveiller, redémarrer ou vider, pas de préchauffage, pas de tas mémoire à dimensionner : c’est le modèle shared-nothing décrit dans Le runtime, et c’est lui qui donne à PHP le moins de pièces mobiles à héberger. Voilà pourquoi tous les hébergeurs mutualisés du monde le proposent, et pourquoi les plateformes du chapitre Empreinte peuvent être installées par des gens qui ne sont pas ingénieurs. Pour la plupart des applications, une image de conteneur du build officiel php:8.5-fpm, un serveur web devant et un répartiteur de charge forment toute l’architecture de production, et ajouter de la capacité, c’est ajouter une copie.

Cette simplicité se paie en efficacité par machine. Dans le benchmark de Débit et latence, un framework sous PHP-FPM sert quelques dizaines de milliers de requêtes par seconde sur un gros serveur ; un runtime en mode worker multiplie ce chiffre par trois à quatre, et apporte avec lui la discipline opérationnelle d’un processus de longue durée. Les progrès du moteur lui-même s’inscrivent dans le même registre. Badoo a rapporté en 2017 que le passage de ses centaines de serveurs applicatifs de PHP 5 à PHP 7 lui avait économisé environ un million de dollars de matériel, chiffre auto-déclaré sur le blog d’ingénierie de l’entreprise. Je ne dispose d’aucune mesure indépendante du coût d’hébergement par requête d’un langage à l’autre, et je n’affirme rien à ce sujet.

Le calendrier

L’historique des mises à niveau de Wikimedia est public : la production est passée de PHP 7.4 à 8.1 en mars 2025, à 8.3 en novembre 2025, et prévoyait 8.5 pour fin 2026. Une version mineure sort chaque année fin novembre ou début décembre et reste maintenue quatre ans, si bien que vous devez prévoir une mise à niveau par an pour rester en support actif, ou une tous les deux à trois ans pour rester en support de sécurité. Le travail d’une mise à niveau est borné : le langage déprécie dans une version mineure et supprime à la majeure suivante, les analyseurs signalent les dépréciations, et Rector applique les réécritures mécaniques. Sur une base de code bien testée, une montée de version se compte en jours ; sur une base non testée, en semaines.

Le parc installé montre ce qui arrive quand ce budget n’est pas payé.

Parmi les paquets installés via Composer, 94 % des installations d’août 2026 tournaient sur PHP 8 et 0,2 % sur PHP 5. Les sites WordPress qui se déclarent à wordpress.org en étaient à 77 % de PHP 8, 21 % de PHP 7 et 2 % de PHP 5. Le web tel que W3Techs le détecte tournait à 64 % sur PHP 8, 28 % sur PHP 7 et 8 % sur PHP 5, et ces deux dernières sont des versions qui n’ont reçu aucun correctif de sécurité depuis novembre 2022 et décembre 2018 respectivement. Ce sont trois populations : les développeurs qui construisent, les sites qui se mettent à jour eux-mêmes, et le web tel qu’il est. L’écart entre la première et la troisième, c’est la dette technique de l’écosystème, et si vous héritez d’une base de code PHP, demandez à quelle population elle appartient avant d’annoncer un prix.

La limite : le recrutement PHP est bon marché selon les médianes et son hébergement a le moins de pièces mobiles, et chacun de ces faits traîne son ombre, une question de rétention et un parc installé dont plus d’un tiers tourne sur des versions non maintenues. Budgétez la mise à niveau annuelle et recrutez le spécialiste plutôt que l’utilisateur occasionnel, et vous obtenez le bon côté de chaque fait ; sautez l’un ou l’autre, et vous obtenez l’autre côté.

Ce que vous pouvez vérifier vous-même

Cherchez le langage sur les sites d’offres d’emploi de votre ville, puis les frameworks que vous utiliseriez, et comparez le nombre d’annonces et la fourchette affichée avec les langages que vous envisagez : cela vaut mieux que n’importe quelle médiane mondiale. Demandez à votre hébergeur ou à votre équipe plateforme quelle version de PHP ils font tourner aujourd’hui, et comment ils la mettraient à niveau. Prenez ensuite un projet PHP open source de la taille de votre base de code, en retard de deux versions, et passez-y le jeu de règles de mise à niveau de Rector : le diff qu’il produit, c’est le coût d’une version, sous vos yeux.

Les cas où cette arithmétique cesse de s’appliquer, parce que PHP est le mauvais outil et non un outil cher, sont rassemblés dans Là où PHP est le mauvais choix.

Là où PHP est le mauvais choix

Une évaluation incapable de nommer les cas où son sujet perd n’est pas une évaluation, et PHP perd dans plusieurs. PHP est le mauvais choix pour le calcul limité par le CPU, pour les services dont le métier est de maintenir de nombreuses connexions de longue durée, pour tout ce qui s’exécute hors d’un serveur, et pour les équipes dont les compétences, la plateforme et l’échelle les ont déjà menées ailleurs. Dans chacun de ces cas, le conseil honnête est rarement « tout réécrire » et bien plus souvent « pas cette partie », avec un autre outil pour la partie en question.

Le calcul

Le programme n-body prend 204 secondes en PHP avec le JIT désactivé, contre 8,6 pour Node.js, et le JIT resserre cet écart sans le combler, comme Débit et latence l’a montré. Sur du code qui occupe un cœur, l’interpréteur joue dans la catégorie de Python et de Ruby, un ordre de grandeur derrière V8, la JVM, .NET, Go et Rust. Autour de lui, aucune pile numérique digne de ce nom : pas de bibliothèque de tableaux de la portée de NumPy, pas de bibliothèque de dataframes de la portée de pandas, pas de framework d’apprentissage automatique qu’une équipe de recherche reconnaîtrait. Les paquets qui existent sont rares et maintenus par de petits groupes, et je n’ai trouvé aucun chiffre d’échelle à citer pour aucun d’entre eux.

Si votre produit est un modèle, une simulation, un pipeline de traitement du signal ou un gros calcul par lots, prenez Python pour l’écosystème ou un langage compilé pour la vitesse. Si ce produit a aussi une façade web, c’est là que PHP peut encore trouver sa place.

Les connexions de longue durée

Dix mille connexions inactives coûtent dix mille processus dans le modèle par défaut de PHP, et un processus coûte trop cher pour le dépenser sur une socket qui dort. Les runtimes asynchrones de Concurrence existent et tiennent la charge, l’entrée Swoole servant 3,5 millions de requêtes pipelinées par seconde sur le test plaintext. Mais ce sont des bibliothèques avec leurs propres clients d’entrées-sorties, pas une propriété du langage, et la plupart des paquets de l’écosystème ont été écrits pour le modèle bloquant. Un backend de chat, un serveur de jeu multijoueur, une passerelle de trading, un pipeline de streaming ou un service de notifications push, c’est le cas ordinaire pour Node.js, Go, Elixir et Erlang, Java ou C#, et ces écosystèmes ont les bibliothèques qui vont avec.

Les budgets de latence sous la milliseconde tombent du même côté. Le plancher d’une requête PHP-FPM est sous la milliseconde sur une machine au repos, et rien de ce qui se construit dessus n’y reste sous charge, donc un système avec ce budget s’écrit dans un langage compilé.

Hors du serveur

PHP est un langage pour serveurs. Il a un interpréteur en ligne de commande, et une bonne partie de l’outillage est écrite avec, mais pour les applications de bureau, les applications mobiles, les navigateurs, les appareils embarqués ou la distribution d’un binaire autonome aux utilisateurs finaux, il n’a rien sur quoi une équipe devrait bâtir. Si vos utilisateurs n’exécutent pas d’interpréteur PHP, écrivez l’outil que vous leur donnez dans autre chose.

Les garanties au niveau du langage

Un match auquel il manque une branche lève une exception à l’exécution. Ce seul fait décrit le système de types du chapitre Le langage en 2026 : il est appliqué à l’exécution, aux frontières des fonctions et des propriétés, sans génériques dans le langage, sans étape de compilation, sans modèle de propriété ni de durée de vie, et sans vérification d’exhaustivité. La réponse de l’écosystème est un analyseur statique lancé à son niveau le plus strict à chaque build, ce qui donne à un projet typé l’essentiel de ce qu’un compilateur donnerait, et beaucoup de grandes bases de code PHP vivent avec cette réponse. Si « le compilateur le garantit » est pour vous une exigence et non une préférence, à cause du domaine, du régulateur ou de la taille de la base de code, TypeScript, Java, C#, Kotlin, Go ou Rust vous serviront mieux, et je ne plaiderai pas le contraire.

Les équipes et l’échelle

Un développeur professionnel sur cinq a écrit du PHP l’an dernier, un sur onze le cite comme langage principal, et sa part du web est passée de 80 à 70 % en dix ans. La part des développeurs est plus petite que la part des serveurs en production. Empreinte documente aussi les entreprises qui ont quitté PHP, et elles sont parties vers Java, Go ou TypeScript quand un monolithe web s’était mué en un ensemble de services : Zalando en 2010, Trivago en 2021, Dailymotion et BlaBlaCar en 2025 et 2026. Leurs documents publics donnent l’architecture pour raison, pas le coût du runtime.

Si vos ingénieurs travaillent déjà dans un autre langage, sur une plateforme construite pour lui, ajouter PHP pour un nouveau service vous rapporte peu. Les avantages du runtime, décrits tout au long de ce livre, sont des avantages de simplicité, et une seconde pile les efface. Et si votre entreprise a atteint l’échelle où elle réécrit son monolithe en services compilés et typés, vous suivez un schéma dans lequel PHP est ce que l’on quitte, comme Ruby et Python le sont ailleurs au même stade.

Là où le doute ne s’applique pas

Les mêmes preuves soutiennent le verdict inverse, et sans adjectifs. Les applications web en requête-réponse, à toute échelle que vous avez des chances d’atteindre : contenu, commerce, back-offices, API, les plateformes du chapitre Empreinte et les applications sur mesure bâties à côté. Les équipes qui tiennent à un runtime sans processus à materner et à un déploiement qui se résume à une copie de fichiers. Les organisations qui doivent faire tourner un logiciel pendant dix ans sur un hébergement qu’elles ne contrôlent pas, où le parc installé et la fenêtre de support de quatre ans pèsent plus que le débit. Et les produits dont la partie difficile est le domaine et non la machine, c’est-à-dire la plupart des produits.

La limite de ce chapitre : il nomme les cas que les preuves couvrent. Un domaine que je n’ai pas mesuré, je ne l’ai pas jugé, et si le vôtre en fait partie, déroulez la semaine qui suit avant de croire la réputation, ou moi.

Ce que vous pouvez vérifier vous-même

Écrivez la charge de travail de votre produit qui vous inquiète le plus, et cherchez-la ci-dessus. Si elle y est, le conseil tient, sauf si votre propre mesure le contredit. Si elle n’y est pas, Une évaluation en une semaine existe pour elle.

Une évaluation en une semaine

Rien de ce que j’ai écrit ne devrait décider à votre place. La raison de votre décision devrait être une mesure faite sur votre propre charge de travail, et il ne faut pas longtemps pour en faire une. Cinq jours ouvrés suffisent pour installer le langage, le lire, l’exécuter sous charge, construire une tranche de votre produit, et vérifier par vous-même l’écosystème et la gouvernance. Il vous faut un ordinateur portable, une petite machine virtuelle et personne d’autre, et ce que vous tenez à la fin, c’est une page de chiffres que personne ne vous a tendue.

Jour un : le langage

Installez PHP 8.5 depuis votre gestionnaire de paquets ou lancez l’image officielle, php:8.5-cli. Collez le premier exemple du chapitre Le langage en 2026 dans un fichier, exécutez-le, puis cassez-le comme ce chapitre le suggère et lisez chaque message d’erreur. Clonez un projet PHP open source d’une taille qui vous parle et lancez sa suite de tests. Passez ensuite un analyseur statique, PHPStan ou Psalm, à son niveau le plus strict, et lisez les vingt premiers résultats :

composer require --dev phpstan/phpstan
vendor/bin/phpstan analyse --level=max src

composer require --dev vimeo/psalm
vendor/bin/psalm --init src 1 && vendor/bin/psalm

Ce que l’analyseur attrape et que le moteur laisse passer, c’est la réponse pratique à la question des génériques. Notez le temps qu’il vous a fallu pour lire la base de code, et si les résultats étaient des choses que vous auriez voulu voir attrapées.

Jour deux : le runtime

Sur la machine virtuelle, installez PHP-FPM avec nginx, activez OPcache et servez un script hello-world. Servez ensuite le même script sous FrankenPHP en mode worker, et chargez les deux avec le même outil, à la même concurrence :

wrk -t4 -c64 -d30s --latency http://127.0.0.1/

Notez pour chaque exécution les requêtes par seconde, la latence médiane, le 99e centile et la mémoire par worker, lue sur la page de statut de FPM ou dans ps. Remplacez ensuite le hello-world par le squelette d’un framework full-stack, n’importe lequel parmi CakePHP, Laminas, Laravel, Symfony ou Yii, et recommencez. Le rapport entre les quatre exécutions est le coût du runtime pour votre future application sur votre matériel, le chiffre que Débit et latence ne pouvait vous donner que pour le matériel de quelqu’un d’autre.

Jour trois : une tranche du produit

Choisissez la fonctionnalité de votre produit qui le représente le mieux : un endpoint authentifié qui lit et écrit une base de données, rend ou sérialise quelque chose, et envoie un message dans une file. Construisez-la dans le framework choisi le deuxième jour, avec des tests, en n’utilisant que ce que le framework et Packagist fournissent, et n’optimisez pas. Notez le temps que cela a pris, la part que vous avez écrite et la part que vous avez configurée, le nombre de paquets tirés, et ce que composer audit en a dit.

Jour quatre : la tranche sous charge

Chargez la tranche du troisième jour comme vous avez chargé le hello-world, à la concurrence que vous attendez en production, puis à dix fois cette valeur. Profilez une requête lente avec le profileur de Xdebug ou avec hrtime() autour des appels suspects, et regardez où passe le temps ; sur la plupart des tranches, il passe dans la base de données, et le langage n’est qu’une mince part à chaque bout. Notez le débit et le 99e centile aux deux concurrences, et la part d’une requête passée hors de PHP.

Faites ensuite la seule chose que les benchmarks ne font jamais. Tuez un worker en pleine requête, saturez la limite de mémoire, levez une exception non attrapée dans un job de file d’attente, et notez ce que l’utilisateur a vu, ce que les journaux ont dit, et ce qui s’est rétabli tout seul.

Jour cinq : l’écosystème et la gouvernance

Cherchez sur Packagist les trois bibliothèques dont votre produit ne peut se passer, et notez pour chacune la date de sa dernière version et son nombre de tickets ouverts. Ouvrez wiki.php.net/rfc et lisez la RFC en cours de vote, puis le fil internals qui la porte. Ouvrez la page des versions maintenues de php.net et notez la date à laquelle la version que vous avez choisie cesse de recevoir des correctifs de sécurité. Ouvrez la page Open Collective de la fondation et lisez le dernier mois de transactions, puis les trois avis de sécurité les plus récents de php-src, avec leur délai entre signalement et correctif. Tout cela tient dans un après-midi, et c’est la matière première que Gouvernance et pérennité a résumée pour vous.

La décision

La semaine a produit des chiffres, et une décision demande des pondérations que vous seul pouvez fixer. Chaque question ci-dessous a ses preuves publiques dans un chapitre et votre propre réponse dans un jour de la semaine.

Certaines issues reviennent souvent. Quand la charge de travail est en requête-réponse, que le débit du deuxième jour a dépassé votre besoin avec de la marge et que les bibliothèques du cinquième jour étaient vivantes, mes preuves et les vôtres concordent, et la décision porte sur votre équipe plus que sur le langage. Quand le quatrième jour a révélé un cœur limité par le CPU ou par les connexions, la conclusion honnête est un autre langage pour ce cœur, avec éventuellement PHP autour. Et quand la semaine a été agréable mais que les sites d’offres d’emploi de votre ville étaient vides, ou que les chiffres de rétention de Coût de possession vous inquiètent plus que le runtime, c’est une raison légitime de décliner. Je ne la contesterai pas, même sous l’égide de la fondation du langage.

La limite : une semaine mesure une tranche, pas un produit, et l’équipe qui fait tourner la tranche n’est pas celle qui fera tourner le produit pendant dix ans. La semaine retire la réputation de la décision, et laisse le jugement.

Ce que vous pouvez vérifier vous-même

Tout ce qui précède. Si un chiffre de ces pages se révèle faux quand vous le vérifiez, l’annexe des sources donne l’URL où vit le bon, et le dépôt derrière ce livre accepte les corrections. C’est l’arrangement que vous devez attendre de tout document qui réclame votre temps.

Annexes

Trois sections de référence ferment ce livre, et chacune existe pour que vous puissiez vérifier plutôt que croire.

A - Sources liste chaque chiffre utilisé dans le livre, chapitre par chapitre, avec l’éditeur, l’URL, la date à laquelle la donnée se rapporte et la date de sa dernière vérification. Elle se termine par les chiffres que j’ai refusés, et pourquoi.

B - Les versions de PHP, 2015 à 2026 donne la date de sortie, la fenêtre de support et les changements marquants de chaque version, de PHP 7.0 à PHP 8.5, pour qu’un chiffre sur « PHP 8 » puisse être situé dans le temps.

C - Glossaire définit les termes que j’emploie et que vous pouvez ne pas connaître si vous venez d’un autre écosystème.

A - Sources

Chaque chiffre utilisé dans le livre, chapitre par chapitre, avec son éditeur, la date à laquelle la donnée se rapporte, et l’URL. « Vérifié » est la date à laquelle la page a été lue pour la dernière fois pour cette édition. Quand une source est un fournisseur, une auto-déclaration ou un benchmark synthétique, l’entrée le dit, comme le chapitre l’a fait. Quand un chapitre cite un document que le livre n’a pas pu lire directement, l’entrée le dit aussi.

Les graphiques sont générés à partir des fichiers de données de charts/data/, dont chacun répète sa source, et les tables brutes TechEmpower utilisées par les chapitres 3 et 4 sont stockées en CSV dans charts/raw/.

Comment lire ce livre

• Historique des versions de PHP et fonctionnalités citées : pages de versions et changelogs de php.net, vérifiés le 17 septembre 2026. https://www.php.net/releases/
• La PHP Foundation salariant des développeurs du cœur depuis 2021 : annonce JetBrains, 22 novembre 2021. https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/

Empreinte

• Part des sites web par langage côté serveur (PHP 69,9 %, JavaScript 7,5, Ruby 7,1, Java 5,4, Scala 5,0, ASP.NET 4,2, Python 1,1) : W3Techs, données du 17 septembre 2026. https://w3techs.com/technologies/overview/programming_language
• Part historique par année, valeurs au 1er janvier (PHP 80,6 % en 2015, 75,2 en 2025, 72,4 en 2026) : tendances historiques W3Techs, vérifiées le 17 septembre 2026. https://w3techs.com/technologies/history_overview/programming_language/ms/y
• JavaScript dépassant Ruby comme deuxième langage côté serveur : W3Techs « technology fact of the day », 27 juillet 2026. https://w3techs.com/
• Méthodologie W3Techs (échantillon de plus de 20 millions de sites, un site par domaine, domaines redirigés exclus, mises à jour quotidiennes) : vérifiée le 17 septembre 2026. https://w3techs.com/technologies
• WordPress 40,2 % de tous les sites web et 58,8 % du marché des CMS ; Joomla 1,1, Drupal 0,6, PrestaShop 0,5, TYPO3 0,3 ; 31,5 % des sites sans CMS détecté : W3Techs, 17 septembre 2026. https://w3techs.com/technologies/overview/content_management
• WooCommerce 8,0 % de tous les sites web, 47,7 % des systèmes d’e-commerce : W3Techs, 17 septembre 2026. https://w3techs.com/technologies/details/cm-woocommerce
• Moodle 146 634 sites enregistrés et 531 millions d’utilisateurs (sites auto-enregistrés seulement) : stats.moodle.org, vérifié le 17 septembre 2026. https://stats.moodle.org/
• Nextcloud « 500K+ servers » : Nextcloud, bilan 2025, 11 décembre 2025. https://nextcloud.com/blog/nextcloud-2025-wrap-up/
• Drupal 470 795 sites déclarant leur version : statistiques d’usage de drupal.org, semaine du 6 septembre 2026. https://www.drupal.org/project/usage/drupal
• PrestaShop près de 250 000 sites et plus de 22 milliards d’euros de ventes en 2024 (auto-déclaré) : prestashop.com, vérifié le 17 septembre 2026. https://prestashop.com/about-us/
• Shopware sur 115 des 1 000 plus grandes boutiques B2C allemandes (étude EHI 2025) : Shopware, 10 janvier 2025. https://www.shopware.com/en/news/shopware-is-the-market-leader-among-ecommerce-platforms-in-germany/
• Matomo « more than 1.4 million websites » : Matomo, 1er septembre 2026. https://matomo.org/blog/2026/09/matomo-launches-reseller-partner-programme/
• Wikimedia 19,4 milliards de pages vues par mois : états financiers audités de la Wikimedia Foundation, exercice 2023 à 2024. https://upload.wikimedia.org/wikipedia/foundation/f/f6/Wikimedia_Foundation_2024_Audited_Financial_Statements.pdf
• Production Wikimedia sur PHP 8.3 depuis le 25 novembre 2025 : Phabricator T360995, résolu le 18 décembre 2025. https://phabricator.wikimedia.org/T360995
• Migration Wikimedia vers PHP 8.5 prévue pour fin 2026 : Phabricator T413223, créé le 19 décembre 2025. https://phabricator.wikimedia.org/T413223
• Fin de HHVM en production chez Wikimedia : Phabricator T176370, résolu le 23 novembre 2019. https://phabricator.wikimedia.org/T176370
• Wikimedia 800 000 requêtes par seconde en bordure et sept centres de données : Wikimedia Foundation, 26 novembre 2025. https://wikimediafoundation.org/news/2025/11/26/how-does-the-wikimedia-foundation-use-donations-to-wikipedia/
• Automattic : Tumblr et WordPress « run on PHP primarily » : automattic.com, vérifié le 17 septembre 2026. https://automattic.com/work-with-us/tumblr-migration/
• WordPress VIP 2 400 milliards de requêtes par an et 22 milliards la nuit de l’élection de 2024 (page marketing, CDN inclus) : wpvip.com, vérifié le 17 septembre 2026. https://wpvip.com/capabilities/performance/
• Les ingénieurs d’Etsy « primarily code in PHP and JavaScript » : careers.etsy.com, vérifié le 17 septembre 2026. https://careers.etsy.com/engineering
• Etsy sur PHP 7 en 2016 : conférence « Deploying PHP 7 », PHP Conference Philippines, 13 octobre 2016. https://talks.php.net/ph16
• Exécuteur de jobs et monolithe PHP de Mailchimp : blog développeurs de Mailchimp, « Computers are the easy part », non daté, vérifié le 17 septembre 2026. https://mailchimp.com/developer/blog/computers-are-the-easy-part/ Les offres d’emploi sur jobs.intuit.com demandant PHP, 2025 à 2026, ont été lues mais expirent et n’ont pas pu être archivées ; le chapitre s’appuie sur le billet de blog.
• Badoo trois millions de lignes de PHP, des centaines de serveurs, un million de dollars économisés : Bumble Tech, 7 février 2017. https://medium.com/bumble-tech/how-badoo-saved-one-million-dollars-switching-to-php7-fcbda94ad3ae
• Sites web de la Commission européenne sur Drupal : les métadonnées generator de commission.europa.eu déclarent Drupal 11, vérifié le 17 septembre 2026. Le chiffre de 770 sites en ligne vient d’une présentation du personnel de la Commission à Drupal4Gov EU, 29 janvier 2026, telle que rapportée par des participants ; les diapositives n’ont pas été trouvées en ligne et le chiffre n’est pas confirmé par une publication de la Commission. https://drunomics.com/en/blog/drupal4gov-eu-2026-how-drupal-powers-european-governments-247
• Maison-Blanche sur WordPress VIP avec autorisation FedRAMP Moderate : wpvip.com, mars 2025. https://wpvip.com/blog/fedramp-moderate/
• Le Government Site Builder allemand sur TYPO3, plus de 80 administrations et 250 sites : ITZBund et typo3.com, vérifiés le 17 septembre 2026. https://www.itzbund.de/DE/itloesungen/standardloesungen/gsb/gsb.html
• GovCMS plus de 370 sites pour 115 agences : govcms.gov.au, 2025, tel que cité par The PHP Foundation, 2 septembre 2026. https://thephp.foundation/blog/2026/09/02/digital-sovereignty-is-written-in-php/
• LocalGov Drupal 77 sites de collectivités : localgovdrupal.org, vérifié le 17 septembre 2026. https://localgovdrupal.org/
• HHVM mettant fin à la prise en charge de PHP : hhvm.com, 12 septembre 2018 et 11 février 2019. https://hhvm.com/blog/2018/09/12/end-of-php-support-future-of-hack.html et https://hhvm.com/blog/2019/02/11/hhvm-4.0.0.html
• Slack sur Hack, environ cinq millions de lignes : Slack Engineering, 14 avril 2020 et 8 février 2023. https://slack.engineering/hacklang-at-slack-a-better-php/ et https://slack.engineering/hakana-taking-hack-seriously/
• Réécriture de Zalando en Java en 2010 : témoignage d’un ancien ingénieur de Zalando, 3 mars 2020. https://srcco.de/posts/one-decade-in-zalando-tech.html
• Passage de Trivago de PHP à TypeScript : blog technique de trivago, 16 mai 2022. https://tech.trivago.com/post/2022-05-16-warp-a-web-application-rewrite-project
• Dailymotion « gradually reducing PHP », nouveaux développements en Go, Java et Python : offre d’emploi « Senior Backend Software Engineer, Video Platform », lue le 17 septembre 2026 (les offres expirent). https://jobs.smartrecruiters.com/Dailymotion/744000136260231-senior-backend-software-engineer-video-platform-full-remote-from-france- Usage historique : blog Symfony, 18 février 2011.
• Migration de BlaBlaCar « from a PHP/Symfony stack towards a Java/JS-dominated one » : offre d’emploi « Software Engineer, Backend », lue le 17 septembre 2026 (les offres expirent). https://jobs.smartrecruiters.com/BlaBlaCar/743999670001836-software-engineer-backend Usage historique : SymfonyCon Paris, 4 décembre 2015.
• Chiffres de l’enquête développeurs (PHP 19,1 % des développeurs professionnels, 12e) : Stack Overflow Developer Survey 2025, menée de mai à juin 2025, 49 009 réponses. https://survey.stackoverflow.co/2025/technology
• JetBrains 17 % d’utilisateurs (13e langage), 9 % en langage principal (9e), « long-term decline » : JetBrains State of Developer Ecosystem 2025, 24 534 répondants, menée d’avril à juin 2025. https://devecosystem-2025.jetbrains.com/
• 58 % des développeurs PHP ne prévoyant pas de migrer : JetBrains, The State of PHP 2025, octobre 2025, 1 720 répondants. https://blog.jetbrains.com/phpstorm/2025/10/state-of-php-2025/
• PHP sixième langage par contributeurs mensuels : GitHub Octoverse 2025, 28 octobre 2025. https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/
• PHP quatrième, à égalité avec C# : classement des langages RedMonk, janvier 2026, publié le 14 avril 2026. https://redmonk.com/sogrady/2026/04/14/language-rankings-1-26/
• PHP 14e à 1,04 % : index TIOBE, septembre 2026. https://www.tiobe.com/tiobe-index/

Le runtime

• Modèle de processus et configuration de PHP-FPM : manuel php.net, vérifié le 17 septembre 2026. https://www.php.net/manual/en/install.fpm.php
• OPcache : manuel php.net, vérifié le 17 septembre 2026. https://www.php.net/manual/en/book.opcache.php
• Chiffres du préchargement (30 % et 50 % sur deux pages hello-world de frameworks, « will likely be lower ») : RFC Preloading, wiki.php.net, 2018, acceptée 48 voix contre 0. https://wiki.php.net/rfc/preload
• JIT : « about 3 times better performance on synthetic benchmarks », « typical application performance is on par with PHP 7.4 » : php.net, annonce de la version PHP 8.0. https://www.php.net/releases/8.0/en.php
• JIT sur WordPress, 326 contre 315 requêtes par seconde : RFC JIT, wiki.php.net, 2019. https://wiki.php.net/rfc/jit
• JIT désactivé par défaut depuis PHP 8.4 : php.net, configuration d’OPcache, opcache.jit. https://www.php.net/manual/en/opcache.configuration.php
• FrankenPHP sous l’organisation php depuis le 8 juin 2025 : The PHP Foundation, 15 mai et 8 juin 2025. https://thephp.foundation/blog/2025/05/15/frankenphp/ et https://thephp.foundation/blog/2025/06/08/php-30/
• Mode worker de FrankenPHP, « not originally designed for long-running processes », réglage du nombre maximal de requêtes : documentation frankenphp.dev, vérifiée le 17 septembre 2026. https://frankenphp.dev/docs/worker/
• RoadRunner : roadrunner.dev, vérifié le 17 septembre 2026. https://roadrunner.dev/
• Swoole et OpenSwoole : openswoole.com et github.com/swoole/swoole-src, vérifiés le 17 septembre 2026.
• FrankenPHP en mode classique contre PHP-FPM, 18 403 contre 18 478 requêtes par seconde, p99 0,9 ms, machine virtuelle à huit vCPU : Tideways, 23 septembre 2025 (indépendant des deux projets). https://tideways.com/profiler/blog/testing-if-franken-php-classic-mode-is-faster-and-more-scalable-than-php-fpm
• Symfony sous PHP-FPM, FrankenPHP et Swoole sur le test Fortunes : TechEmpower Round 23, voir la section suivante.
• Coût d’un processus nu (2 Mo de tas, 33 Mo résidents, 20 ms) : mesuré par l’auteur sur PHP 8.3.33 sous Linux, le 17 septembre 2026, avec memory_get_usage(true) et /usr/bin/time -v. Reproductible avec php -r ''.
• Configuration des conteneurs Wikimedia (8 workers, 500 Mo d’OPcache, 768 Mo d’APCu, 1 à 2 Go par conteneur) : Phabricator T280497, 2021. https://phabricator.wikimedia.org/T280497

Débit et latence

• « Execution time is often halved » : Zend (Rogue Wave), livre blanc « Maximize performance and mitigate risks with PHP 7 », 9 novembre 2017 ; un document de fournisseur sans méthodologie publiée. https://www.zend.com/sites/default/files/pdfs/rw-maximize-performance-mitigate-risks-wp-fnl-20171109.pdf
• Scores PHPBench de PHP 5.6.40 à 8.0-dev (288 326 à 876 420) : OpenBenchmarking.org, résultat 2002269-VE-PHPBENCHM24 par Michael Larabel, février 2020, Core i9-9900KS, Ubuntu 20.04. https://openbenchmarking.org/result/2002269-VE-PHPBENCHM24
• WordPress 146,09 requêtes par seconde sur PHP 8.2 et 148,30 sur PHP 8.5, « incremental releases rarely produce large speed jumps » : Kinsta, 13 décembre 2025 ; le benchmark d’un hébergeur, ApacheBench à 15 requêtes concurrentes sur une machine à 30 vCPU, JIT désactivé. https://kinsta.com/blog/php-benchmarks/
• TechEmpower Round 23 : résultats datés du 24 février 2025, matériel décrit par TechEmpower comme « ProLiant DL360 Gen10 Plus, Intel Xeon Gold 6330 (56 cores), 64 GB, 40 Gbps Ethernet » ; le Xeon Gold 6330 a 28 cœurs et 56 threads. Page de résultats (rendue en JavaScript), lue avec un navigateur headless le 17 septembre 2026, et stockée en CSV dans charts/raw/. https://www.techempower.com/benchmarks/#hw=ph&test=fortune&section=data-r23 Annonce du round : https://www.techempower.com/blog/2025/03/17/framework-benchmarks-round-23/
• Dépôt TechEmpower archivé : github.com/TechEmpower/FrameworkBenchmarks, archivé, dernier push le 24 mars 2026, lu via l’API GitHub le 17 septembre 2026.
• Objectifs de latence de Wikimedia (50 ms en médiane, 200 ms en p99 pour GET, 500 ms en p99 pour POST) : Wikimedia, « Backend performance practices », dernière modification le 27 juin 2026. https://wikitech.wikimedia.org/wiki/MediaWiki_Engineering/Guides/Backend_performance_practices
• Tableau de bord public de latence de Wikimedia : Grafana, « Backend Pageview Timing » ; la médiane d’environ 170 millisecondes citée dans le chapitre y a été lue le 17 septembre 2026 vers 10 h 25 UTC, sur une heure, pour les requêtes atteignant les serveurs d’application. https://grafana.wikimedia.org/d/QLtC93rMz/backend-pageview-timing
• Temps écoulés sur n-body, entrée mono-thread la plus rapide par langage (Rust 2,19 s, C# 3,13 s avec AOT natif, Java 6,02 s avec native image, Go 6,39 s, Node.js 8,55 s, Ruby 166,67 s, PHP 204,10 s, Python 360 s), spectral-norm (PHP 18,29 s écoulées pour 72,34 s de CPU ; Python 90,37 s ; Ruby 56,52 s ; Node.js 1,60 s) : The Computer Language Benchmarks Game, vérifié le 17 septembre 2026. https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/nbody.html et https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/spectralnorm.html
• Ligne de commande PHP utilisée par le Benchmarks Game (PHP 8.4.1, opcache.jit_buffer_size=64M, aucun réglage opcache.jit) : page du programme n-body PHP #3. https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/nbody-php-3.html
• Gain d’un facteur quatre du JIT sur Mandelbrot : RFC JIT, wiki.php.net, 2019. https://wiki.php.net/rfc/jit

Concurrence

• Fibers : « all fibers exist within a single thread », « blocking code … will continue to block the entire process » : RFC Fibers, wiki.php.net, acceptée 50 voix contre 14, mars 2021. https://wiki.php.net/rfc/fibers
• AMPHP, ReactPHP : amphp.org et reactphp.org, vérifiés le 17 septembre 2026.
• Chiffres du test plaintext de TechEmpower Round 23 : voir la section précédente ; table brute dans charts/raw/techempower-r23-plaintext.csv.
• RFC « Concurrency Support in the PHP Engine » en discussion : index des RFC de wiki.php.net, vérifié le 17 septembre 2026. https://wiki.php.net/rfc La RFC antérieure « PHP True Async » affiche le statut Canceled, dernière modification le 22 juillet 2026. https://wiki.php.net/rfc/true_async

Le langage en 2026

• Chaque fonctionnalité et sa version : pages de versions de php.net et la fiche de faits du guide d’écriture du livre polyglotte, tous deux vérifiés contre php.net. Les exemples ont été exécutés sous PHP 8.5 avec l’image Docker officielle le 17 septembre 2026.

L’écosystème

• Packagist 468 099 paquets, 5,8 millions de versions, 199,6 milliards d’installations depuis 2012 ; série mensuelle d’installations (2,0 milliards en 2016 à 36,0 milliards en 2025 ; 2,58 milliards en août 2025 et 4,93 milliards en août 2026) : packagist.org/statistics, lu le 17 septembre 2026. https://packagist.org/statistics
• composer audit introduit dans Composer 2.4.0, 16 août 2022 : changelog de getcomposer.org. https://getcomposer.org/changelog/2.4.0 Documentation : https://getcomposer.org/doc/03-cli.md#audit
• 1 649 avis dans la base partagée : github.com/FriendsOfPHP/security-advisories, comptés le 17 septembre 2026.
• PIE 1.5, financé par la Sovereign Tech Agency : The PHP Foundation, rapport trimestriel T2 2026, 21 juillet 2026. https://thephp.foundation/blog/2026/07/21/quarterly-report-q2-2026/
• Projets construits sur les composants Symfony (auto-déclarés) : symfony.com/projects, vérifié le 17 septembre 2026. https://symfony.com/projects
• Laravel 64 %, WordPress 25 %, Symfony 23 % parmi les développeurs PHP ; PHPUnit 50, PHPStan 36, PHP-CS-Fixer 30, Pest 17, 32 % n’écrivant aucun test, 42 % n’utilisant aucun outil de qualité : JetBrains, The State of PHP 2025, octobre 2025. https://blog.jetbrains.com/phpstorm/2025/10/state-of-php-2025/
• 14 PSR acceptées, PER Coding Style 3.1 : php-fig.org, vérifié le 17 septembre 2026. https://www.php-fig.org/psr/ et https://www.php-fig.org/per/coding-style/
• Tags de version signés depuis avril 2012 : page des clés GPG de php.net. https://www.php.net/gpg-keys.php

Gouvernance et pérennité

• Processus RFC et vote (majorité des deux tiers, deux semaines de discussion, deux semaines de vote, qui vote) : wiki.php.net, « How to create an RFC » et « Voting ». https://wiki.php.net/rfc/howto et https://wiki.php.net/rfc/voting
• RFC refusées : Nullable Intersection Types (12 contre 26, août 2021) https://wiki.php.net/rfc/nullable_intersection_types ; Short Closures 2.0 (27 contre 16, refusée, juillet 2022) https://wiki.php.net/rfc/auto-capture-closure ; Asymmetric Visibility v1 (14 contre 12, janvier 2023) https://wiki.php.net/rfc/asymmetric-visibility et v2 (24 contre 7, août 2024) https://wiki.php.net/rfc/asymmetric-visibility-v2 ; Nested Classes (2 contre 20, mai 2025) https://wiki.php.net/rfc/short-and-inner-classes
• Nombre de RFC par version (31 pour 8.4, 19 pour 8.5, 29 pour 8.6 en septembre 2026) : index des RFC de php.watch, une source secondaire. https://php.watch/rfcs
• Dates de sortie de chaque version : archive des versions et changelogs de php.net, vérifiés le 17 septembre 2026. https://www.php.net/releases/ et https://www.php.net/ChangeLog-8.php
• Politique de support et fenêtres en cours : php.net, pages des versions maintenues et de fin de vie, vérifiées le 17 septembre 2026. https://www.php.net/supported-versions.php et https://www.php.net/eol.php
• Mise à jour du cycle de publication (support de sécurité prolongé, fenêtres alignées sur le 31 décembre ; votes 31 contre 0 et 33 contre 0) : RFC, wiki.php.net, acceptée en avril 2024. https://wiki.php.net/rfc/release_cycle_update
• Calendrier de PHP 8.6 (GA le 19 novembre 2026, gel des fonctionnalités le 22 septembre 2026) : wiki.php.net, calendrier de publication de PHP 8.6. https://wiki.php.net/todo/php86
• Activité de php-src (5 316 commits et 171 auteurs sur master dans les douze mois précédant le 17 septembre 2026 ; 1 644 contributeurs) : mesurée sur un clone de github.com/php/php-src avec git log, et l’API des contributeurs de GitHub, 17 septembre 2026.
• Fondation de The PHP Foundation (22 novembre 2021, dix membres fondateurs, le départ qui l’a déclenchée) : JetBrains, 22 novembre 2021, et thephp.foundation. https://blog.jetbrains.com/phpstorm/2021/11/the-php-foundation/ et https://thephp.foundation/
• Rapports de transparence : 2022 (22 novembre 2022) https://thephp.foundation/blog/2022/11/22/transparency-and-impact-report-2022/ ; 2023 (26 février 2024) https://thephp.foundation/blog/2024/02/26/transparency-and-impact-report-2023/ ; 2024 (31 mars 2025) https://thephp.foundation/blog/2025/03/31/transparency-and-impact-report-2024/ ; 2025 (27 mai 2026) https://thephp.foundation/blog/2026/05/27/impact-and-transparency-report-2025/
• Structure (treize ingénieurs, directeur exécutif, conseil de dix membres) : thephp.foundation/structure, vérifié le 17 septembre 2026. https://thephp.foundation/structure/
• Contributions cumulées par sponsor (Automattic 762 500 dollars, JetBrains 476 670, total 3 368 941) : opencollective.com/phpfoundation, lu le 17 septembre 2026. https://opencollective.com/phpfoundation
• Subventions de la Sovereign Tech Agency (205 000 euros en 2023 ; 223 680 euros en 2025) : sovereign.tech. https://www.sovereign.tech/tech/php et https://www.sovereign.tech/tech/php-2025
• Subvention Alpha-Omega et Ecosystem Security Team : The PHP Foundation, 18 mai 2026. https://thephp.foundation/blog/2026/05/18/announcing-ecosystem-security-team/
• Politique de sécurité et classification : politique de sécurité de github.com/php/php-src et github.com/php/policies. https://github.com/php/php-src/security/policy et https://github.com/php/policies/blob/main/security-classification.rst
• Résultats de l’audit externe (27 problèmes, 17 avec des implications de sécurité, 3 de gravité haute) : The PHP Foundation, 10 avril 2025. https://thephp.foundation/blog/2025/04/10/php-core-security-audit-results/
• Nombre de CVE par année de publication (8, 7, 18, 13, 14) : API NVD, produit cpe:2.3:a:php:php, interrogée le 17 septembre 2026. https://nvd.nist.gov/ Avis GitHub pour php-src : https://github.com/php/php-src/security/advisories

Coût de possession

• Usage Stack Overflow 2025 (JavaScript 68,8 %, Python 54,8, TypeScript 48,8, C# 29,9, Java 29,6, PHP 19,1, Go 17,4, Rust 14,5, Ruby 6,9 parmi les développeurs professionnels) et chiffres « admired » (Rust 72,4, TypeScript 58,0, Go 56,5, Python 56,4, C# 55,8, JavaScript 46,8, Ruby 44,3, Java 41,8, PHP 38,9) : Stack Overflow Developer Survey 2025. https://survey.stackoverflow.co/2025/technology
• Salaire médian par langage (PHP 49 586 dollars, deuxième plus bas sur cinquante) : Stack Overflow Developer Survey 2024, « Top paying technologies ». https://survey.stackoverflow.co/2024/technology#top-paying-technologies
• 613 offres d’emploi permanentes au Royaume-Uni citant PHP sur les six mois précédant le 17 septembre 2026, 404 un an plus tôt, médiane 48 676 livres : IT Jobs Watch, un agrégateur britannique, secondaire. https://www.itjobswatch.co.uk/jobs/uk/php.do
• Badoo un million de dollars économisés : Bumble Tech, 7 février 2017, comme dans Empreinte.
• Cadence de mise à niveau de Wikimedia : passage de PHP 7.4 à 8.1 annoncé sur wikitech-l le 17 mars 2025 et achevé le même mois ; 8.1 à 8.3 achevé le 25 novembre 2025 (Phabricator T360995) ; 8.5 prévu pour fin 2026 (Phabricator T413223).
• Versions de PHP par population : Packagist php-statistics, août 2026 https://packagist.org/php-statistics ; API de statistiques de wordpress.org, lue le 17 septembre 2026 https://api.wordpress.org/stats/php/1.0/ ; versions de PHP selon W3Techs, 17 septembre 2026 https://w3techs.com/technologies/details/pl-php
• Fin du support de sécurité de PHP 7.4 (28 novembre 2022) et de PHP 5.6 (31 décembre 2018) : page de fin de vie de php.net. https://www.php.net/eol.php

Là où PHP est le mauvais choix

• Tous les chiffres sont repris des chapitres ci-dessus et portent les mêmes sources.

Non utilisés, et pourquoi

Chiffres qui circulent sur PHP et que le livre a laissés de côté parce qu’aucune source primaire n’a pu être trouvée, ou parce que la source primaire les contredit :

• « Spotify sert 600 000 requêtes par seconde avec Symfony » : un chiffre de trafic global repris par des blogs d’agences ; la seule source primaire est une conférence de 2015 sur le site spotify.com.
• « Etsy est repassé de HHVM à PHP 7 en 2019 ou 2020 » : Etsy était sur PHP 7 en 2016 ; HHVM n’a jamais été utilisé que sur son cluster d’API.
• « Laravel est utilisé par OpenAI, Apple, Nike, la NASA » : une affirmation sur laravel.com sans source par entreprise.
• « Adobe Commerce a traité 6,2 milliards de dollars lors du Black Friday 2024 » : trouvé seulement sur des agrégateurs tiers ; les propres communiqués d’Adobe donnent des chiffres pour l’ensemble de l’e-commerce américain mesuré par Adobe Analytics.
• « Mercedes-Benz sponsorise The PHP Foundation » : absent de la liste des sponsors de la fondation.
• « PHP 8 est trois fois plus rapide que PHP 7 » : le chiffre concerne des benchmarks synthétiques et vient de la RFC JIT ; la même page dit que les applications typiques sont au niveau de PHP 7.4.
• Le « million de lignes de PHP » de Vimeo (décembre 2020) : l’article n’est plus en ligne ; l’origine de Psalm chez Vimeo est la seule affirmation que le livre conserve.
• Tout chiffre sur le nombre de développeurs PHP dans le monde : le dernier chiffre primaire trouvé est 7,3 millions au troisième trimestre 2021 (SlashData), et rien de plus récent n’a pu être rattaché à une page primaire.

B - Les versions de PHP, 2015 à 2026

Chaque version a sa section ci-dessous, avec sa date de sortie, sa fenêtre de support et ses changements marquants. Les dates viennent de php.net (pages des versions maintenues, des fins de vie et des changelogs, vérifiées le 17 septembre 2026). Le support actif couvre les corrections de bugs et les correctifs de sécurité, le support de sécurité les correctifs de sécurité seulement. Depuis la mise à jour du cycle de publication votée en 2024, les deux fenêtres se terminent le 31 décembre de leur dernière année.

Ce qu’il faut retenir du tableau, ce sont onze versions annuelles consécutives, chacune sortie entre le 20 novembre et le 8 décembre. Le calendrier de la suivante paraît sur wiki.php.net des mois à l’avance, avec ses dates de gel des fonctionnalités et de release candidate.

PHP 7.0, décembre 2015

• Nouveau moteur, avec une forte réduction de l’usage mémoire et, sur le travail propre de l’interpréteur, à peu près deux fois la vitesse de PHP 5.6 ; voir Débit et latence pour l’affirmation de l’éditeur et la mesure synthétique indépendante, avec leurs réserves.
• Déclarations de types scalaires (int, float, string, bool) pour les paramètres, et déclarations de types de retour.
• declare(strict_types=1).
• Opérateur de fusion null ??, opérateur spaceship <=>.
• Classes anonymes.
• Les erreurs du moteur deviennent des exceptions (hiérarchie Error), si bien qu’une erreur fatale peut être attrapée.
• Suppression des fonctions mysql_*, des fonctions ereg_* et des constructeurs à la PHP 4.

PHP 7.1 à 7.4, 2016 à 2019

• 7.1 : types nullables (?int), type de retour void, iterable, visibilité des constantes de classe.
• 7.2 : type object, hachage de mots de passe Argon2, Libsodium dans le cœur.
• 7.3 : syntaxe heredoc assouplie, is_countable(), erreurs JSON sous forme d’exceptions.
• 7.4 : propriétés typées, fonctions fléchées (fn), préchargement OPcache, interface de fonctions étrangères (FFI), opérateur ??=, retours covariants et paramètres contravariants.

PHP 8.0, novembre 2020

• Arguments nommés : str_pad(string: 'a', length: 3).
• Attributs : #[Route('/home')], des métadonnées structurées lues par réflexion.
• Promotion de propriétés dans le constructeur : public function __construct(private int $x) {}.
• Types union : int|string $id.
• Expression match : comparaison stricte, pas de fallthrough, exhaustive.
• Opérateur nullsafe : $user?->address?->city.
• mixed et static comme types.
• throw comme expression.
• str_contains(), str_starts_with(), str_ends_with().
• Interface Stringable, WeakMap.
• Compilateur JIT, à l’intérieur d’OPcache.
• Comparaisons chaîne-nombre assainies : 0 == 'foo' vaut false.
• Les fonctions internes lèvent TypeError et ValueError au lieu d’émettre un avertissement et de renvoyer null ou false.

PHP 8.1, novembre 2021

• Énumérations, pures et adossées.
• Propriétés readonly.
• Syntaxe de callable de première classe : strlen(...).
• Fibers : des coroutines à pile, la brique de base des bibliothèques asynchrones.
• new dans les initialiseurs.
• Types intersection purs : Countable&Traversable.
• Type de retour never, constantes de classe final, array_is_list(), notation octale explicite.

PHP 8.2, décembre 2022

• Classes readonly.
• Types en forme normale disjonctive : (A&B)|null.
• Types true, false et null autonomes.
• Propriétés dynamiques dépréciées ; #[\AllowDynamicProperties] réautorise une classe.
• #[\SensitiveParameter] pour masquer un argument dans les traces d’appel.
• Constantes dans les traits, Random\Randomizer.

PHP 8.3, novembre 2023

• Constantes de classe typées.
• Attribut #[\Override] : le moteur vérifie qu’une méthode parente existe.
• json_validate().
• Accès dynamique aux constantes de classe : Foo::{$name}.
• Les propriétés readonly peuvent être réinitialisées dans __clone().

PHP 8.4, novembre 2024

• Hooks de propriété : la logique get et set déclarée sur la propriété elle-même.
• Visibilité asymétrique : public private(set) int $x.
• new Foo()->bar() sans parenthèses englobantes.
• Objets paresseux via la réflexion (newLazyGhost(), newLazyProxy()).
• Attribut #[\Deprecated].
• array_find(), array_find_key(), array_any(), array_all().
• mb_trim() et consorts, mb_ucfirst(), mb_lcfirst().
• Nouvelle extension DOM avec un analyseur HTML5 (Dom\HTMLDocument).
• API objet pour BCMath (BcMath\Number), sous-classes PDO par pilote (Pdo\Sqlite, Pdo\Mysql, Pdo\Pgsql).
• Types de paramètres implicitement nullables dépréciés.

PHP 8.5, novembre 2025

• Opérateur pipe : $value |> trim(...) |> strtoupper(...).
• clone avec mise à jour de propriétés : clone($obj, ['prop' => $value]).
• Attribut #[\NoDiscard], avec le cast (void) pour le faire taire volontairement.
• array_first(), array_last().
• Closures et callables de première classe dans les expressions constantes (arguments d’attributs, valeurs par défaut, constantes).
• Attributs sur les constantes.
• Nouvelle extension uri (Uri\Rfc3986\Uri, Uri\WhatWg\Url).
• Les erreurs fatales incluent une trace d’appel.
• get_error_handler(), get_exception_handler().
• L’opérateur d’exécution shell entre accents graves est déprécié.

C - Glossaire

Les termes que j’emploie et que vous pouvez ne pas connaître si vous venez d’un autre écosystème, dans l’ordre alphabétique des termes anglais.

Active support (support actif). Les deux premières années d’une branche de PHP, pendant lesquelles les bugs et les failles de sécurité sont corrigés dans des versions de correction mensuelles. Suivent deux années de support de sécurité, avec des correctifs de sécurité seulement. Voir Gouvernance et pérennité.

Composer. Le gestionnaire de dépendances de l’écosystème PHP, comparable à npm, pip ou Maven. Il lit composer.json, résout les versions, écrit composer.lock et génère l’autoloader qui fait correspondre les noms de classes aux fichiers.

Fiber. Une coroutine à pile, ajoutée dans PHP 8.1 : une fonction qui peut se suspendre elle-même et être reprise plus tard par qui la détient. Le langage fournit le mécanisme, rien de plus, et l’ordonnancement revient aux bibliothèques. Voir Concurrence.

FrankenPHP. Un serveur d’application pour PHP, écrit en Go au-dessus du serveur web Caddy. Il exécute PHP soit dans le mode classique d’un processus par requête, soit dans un mode worker qui garde l’application démarrée entre les requêtes. Voir Le runtime.

Hack et HHVM. Hack est un langage qui a divergé de PHP chez Facebook en 2014, et HHVM est sa machine virtuelle. HHVM a abandonné la prise en charge de PHP lui-même en 2019. Les organisations qui font tourner Hack ne font pas tourner PHP, et je ne les compte pas comme utilisatrices de PHP.

JIT. Le compilateur à la volée livré à l’intérieur d’OPcache depuis PHP 8.0, qui compile les chemins de code chauds en code machine. Il profite bien plus au code limité par le CPU qu’aux requêtes web ordinaires, et je le rappelle partout où un chiffre JIT apparaît.

NTS et ZTS. Les builds non-thread-safe et Zend-thread-safe de l’interpréteur. Le build standard est NTS, parce que le modèle par processus n’a jamais eu besoin de threads. Les builds ZTS existent pour l’usage embarqué et pour l’extension parallel.

OPcache. L’extension qui garde la forme compilée de chaque fichier PHP en mémoire partagée, si bien qu’un fichier est analysé et compilé une fois plutôt qu’à chaque requête. Elle est standard en production depuis PHP 5.5.

p50, p95, p99. Les centiles d’une distribution de latence : le temps de réponse sous lequel 50, 95 ou 99 % des requêtes se terminent. Un benchmark qui ne rapporte que la moyenne cache la queue de distribution, et c’est pourquoi je préfère les sources qui publient des centiles.

Packagist. Le registre public de paquets que Composer utilise par défaut, comparable à npmjs.com ou PyPI.

PER Coding Style. Le standard de style de code maintenu par le PHP-FIG, successeur de PSR-12. Des outils tels que PHP-CS-Fixer et PHP_CodeSniffer le font respecter.

PHP-FIG. Le PHP Framework Interoperability Group, qui publie les standards PSR pour que les bibliothèques d’auteurs différents s’emboîtent.

PHP-FPM. Le FastCGI Process Manager, la façon standard d’exécuter PHP derrière un serveur web. Il entretient un pool de processus worker, chacun traitant une requête à la fois.

Preloading (préchargement). Une fonctionnalité d’OPcache (PHP 7.4) qui compile une liste de fichiers une fois au démarrage et les garde liés en mémoire, si bien qu’aucune classe n’a besoin d’autoloading pendant une requête.

PSR. PHP Standards Recommendation, un standard d’interopérabilité numéroté publié par le PHP-FIG : PSR-4 pour l’autoloading, PSR-3 pour la journalisation, PSR-7 pour les messages HTTP, et ainsi de suite.

Rector. Un outil qui réécrit le code PHP automatiquement : il fait monter la syntaxe d’une version à la suivante, applique des refactorings et supprime les appels dépréciés. Les équipes s’en servent pour les montées de version à grande échelle.

RFC. Request for Comments, le document par lequel tout changement du langage est proposé, discuté sur la liste de diffusion internals et soumis au vote. Un changement du langage requiert une majorité des deux tiers. Voir Gouvernance et pérennité.

RoadRunner. Un serveur d’application pour PHP écrit en Go. Il garde des processus worker en vie et leur transmet les requêtes par un protocole, si bien que l’application est démarrée une fois plutôt qu’à chaque requête.

Shared-nothing. Le modèle d’exécution dans lequel chaque requête démarre avec une mémoire vierge, s’exécute, répond et est jetée, sans rien partager avec la requête précédente ni la suivante. La plupart des propriétés opérationnelles de PHP en découlent. Voir Le runtime.

Static analysis (analyse statique). Lire le code sans l’exécuter, pour y trouver les erreurs de type et d’autres défauts. PHPStan et Psalm sont les deux analyseurs de l’écosystème PHP, et tous deux comprennent une syntaxe de types en docblock plus riche que celle du langage lui-même.

Swoole et OpenSwoole. Une extension en C et son fork. Chacune donne à PHP une boucle d’événements, des coroutines et un serveur HTTP intégré, pour les charges de travail qui ont besoin de nombreuses connexions concurrentes dans un seul processus.

TechEmpower Framework Benchmarks. Une suite de benchmarks publique, exécutée en continu, qui compare des centaines de frameworks web de tous langages sur un jeu de tests fixe (sérialisation JSON, requêtes de base de données simples et multiples, rendu HTML « fortunes », plaintext). Je la cite avec son numéro de round, son matériel et le test, et je dis ce que chaque test mesure.

W3Techs. Une société d’enquêtes sur le web qui publie l’usage des technologies côté serveur sur un échantillon de plus de vingt millions de sites. Ses chiffres ne comptent que les sites dont le langage peut être détecté, ce qui les biaise d’une manière que je précise quand je les utilise.

Worker mode (mode worker). Une façon d’exécuter PHP dans laquelle l’application est démarrée une fois et gardée en mémoire, chaque processus worker traitant de nombreuses requêtes à la suite. FrankenPHP et RoadRunner le proposent, entre autres. Il supprime le coût de démarrage par requête, au prix de la garantie shared-nothing.