Le PHP fête ses 31 ans et Vonage suit de près l'univers PHP

C'est incroyable de penser que PHP a fêté ses 31 ans en juin. De ses débuts en tant que langage de script basique destiné à aider un seul développeur à son statut actuel de géant open source du Web, le parcours a été pour le moins remarquable. Si vous êtes curieux de savoir où en est PHP aujourd’hui et quelle direction il prend, la lecture de ce résumé vous donnera un bon aperçu de la situation.

Dans mon travail quotidien, je reste avant tout un développeur PHP. Tout ce que je crée, des démos aux contributions open source, s’articule autour du le SDK PHP de Vonage. C’est un élément central de notre activité; les langages de programmation et leurs communautés respectives sont il est important d’y être connecté.

Dans la foulée de mon entretien avec le directeur exécutif de la Fondation PHP, JetBrains a annoncé une nouvelle édition annuelle de PHPVerse, une conférence d’une journée exclusivement en ligne destinée aux développeurs PHP. Cette année, comme l’année dernière, l’événement a réuni un panel exceptionnel de figures emblématiques de l’open source venues s’exprimer sur divers sujets liés à la communauté. Dans cet article, je vais passer en revue la moitié de ces interventions en y ajoutant quelques commentaires, afin de vous permettre de rafraîchir vos connaissances en PHP ou, si vous n’êtes pas développeur PHP, de mieux comprendre pourquoi ce langage reste si populaire. La deuxième partie suivra prochainement.

Elizabeth Barron : À la découverte de la Fondation PHP

J'ai commencé par évoquer l'intervention de Vonage auprès d'Elizabeth ; il semble donc logique de commencer par cette intervention. Depuis sa création, il est très rafraîchissant de disposer d’une infrastructure de gouvernance open source pour PHP. La Fondation a été intégrée à la Linux Foundation, a bénéficié d’un apport financier considérable de la part du gouvernement allemand et dispose désormais d’une équipe de développeurs internes, entièrement rémunérés, répartis dans le monde entier.

Cette intervention a porté principalement sur la direction qu’elle a donnée à la Fondation depuis sa création, sur les projets en cours, ainsi que sur ses réflexions quant à l’avenir. Je vais donc les présenter en trois points.

Premièrement : Conclusions

Au début, Elizabeth a décidé d’écouter. Cela a nécessité de très nombreux appels (environ 60, dont celui de l’auteur de ces lignes) afin de recueillir l’avis des développeurs PHP sur l’état actuel du langage. Il en est ressorti quatre domaines d’action à privilégier :

·      Transparence

·      La perception du PHP en dehors de notre communauté

·      Manque de nouveaux développeurs pour assurer la croissance

·      Fonctionnement interne et processus de vote

Deux : Actions

À la suite de ces conclusions, les initiatives suivantes ont été lancées sous l'appellation générique de « groupes d'intérêt spéciaux » (SIG) :

·      Groupe d'intérêt spécial (SIG) sur la sécurité des écosystèmes

·      Groupe d'intérêt spécial (SIG) du programme des ambassadeurs PHP

·      Groupe d'intérêt spécial sur l'intégration

·      Groupe d'intérêt spécial sur la cryptographie

·      Groupe d'intérêt spécial sur les événements communautaires

·      Groupe d'intérêt spécial sur l'accessibilité

Les personnes souhaitant rejoindre ces groupes peuvent découvrir comment faire sur le blog de la Fondation PHP.

Trois : L'avenir

Le plus gros problème auquel PHP est confronté est une problème de , et non d’ordre technique. Elle a conclu que le langage était stable, que la communauté était nombreuse et active, et qu’il y avait donc de quoi se réjouir.

Nils Adermann : compositeur et spécialiste de la sécurité de la chaîne d'approvisionnement dans le secteur de l'emballage en 2026

Dans la foulée de l'annonce, cette année, de la création d'une équipe chargée de la sécurité de l'écosystème au sein de la Fondation PHP, il semblait tout à fait opportun que Nils vienne nous parler de la sécurité de la chaîne d'approvisionnement. Nous avons assisté à plusieurs cas très médiatisés au cours des cinq dernières années, comme la compromission de XZ Utils, où un responsable de maintenance malveillant a réussi à introduire une porte dérobée dans les archives de publication de XZ Utils : un outil utilisé dans de nombreuses distributions Linux majeures. On a également constaté une augmentation des attaques visant les machines locales, ce qui n’est pas surprenant étant donné que les outils d’IA ainsi que les IDE tels que VSCode et PHPStorm effectuent désormais de nombreux appels externes pour écrire du code. Ces outils disposent également de boutiques de plugins open source, ce qui fait de l’accès aux dépôts GitHub l’une des cibles d’attaque les plus courantes parmi la plupart des principaux gestionnaires de paquets.

Les risques liés à la profession de compositeur : l'édition

Le modèle de publication de Composer a toujours présenté un avantage structurel : lorsque vous ajoutez une balise à une version sur GitHub, Packagist enregistre une URL pointant vers l'API GitHub, qui génère dynamiquement un fichier zip directement à partir du code source.

L'inconvénient, c'est que ces fichiers ZIP générés dynamiquement ne sont pas stables. Ils évoluent au fil du temps, ce qui signifie qu'il est impossible de les signer de manière sécurisée. Bien que le fichier de verrouillage de Composer permette de figer un commit pour une balise donnée, cela implique que, dans le cadre d'un audit de sécurité, les développeurs doivent examiner minutieusement les fichiers de verrouillage. Je ne sais pas si vous avez déjà travaillé sur un projet de grande envergure, mais ceux-ci peuvent devenir énormes volumineux. Packagist (la société à l’origine de Composer) propose toutefois une fonctionnalité de révision des mises à jour ; il existe donc des outils permettant de simplifier quelque peu cette tâche.

Fonctionnalités de sécurité intégrées

Un certain nombre de mesures de sécurité ont déjà été mises en place pour lutter contre les attaques visant la chaîne d'approvisionnement.

· Immuabilité de la version stable

· Le cadre stratégique en matière de dépendance

· Le recours au code source en cas d'échec du téléchargement du fichier ZIP est désormais désactivé par défaut

·      Analyses automatiques d’Aikido Security

·      Registre de transparence publique

Nouvelles fonctionnalités en cours de développement

·      Contrôle centralisé de la sécurité du portefeuille de paquets pour les projets de grande envergure, par exemple Symfony

·      Temps de recharge de la libération, pour permettre une analyse automatique

·      Vitrines de préparation à la publication

·      Authentification multifactorielle (MFA) obligatoire

·      Hébergement d’artefacts immuables par Packagist, pour renforcer la confiance dans les gestionnaires de paquets

Comment vous pouvez nous aider

Tout d'abord, vous pouvez dès à présent prendre plusieurs mesures pour renforcer votre sécurité. Parmi celles-ci, on peut citer

·      Activation de l’authentification multifactorielle (MFA)

·      Utilisez des outils tels que Zizmor pour assurer la sécurité de votre pipeline d'intégration continue

·      Assurez-vous d'utiliser Composer 2.0

·      Utilisez l’hébergement de Private Packagist pour répondre à vos besoins spécifiques en matière de sécurité.

Plus important encore, les développeurs et les organisations peuvent oublier les statistiques qui se cachent derrière un service qui est, par essence, gratuit. Packagist reçoit 4 800 requêtes par seconde, est de facto le seul gestionnaire de paquets PHP, et héberge 450 000 paquets installés environ 4 milliards de fois par mois. Bien qu’une partie du financement des fonctionnalités provienne de la Fondation PHP, il est essentiel que Packagist reçoive les fonds nécessaires pour maintenir cette infrastructure. Un programme de parrainage officiel est lancé ce mois-ci ; si votre organisation dépend de cette infrastructure, il est donc vital qu’elle obtienne le financement dont elle a besoin.

Jonathan Bossinger : « WordPress est mort, vive WordPress ! »

Ceux qui me connaissent ont sans doute remarqué que je mène une sorte de croisade contre une phrase célèbre que les gens ne cessent de répéter et qui est fausse. Si cela vaut pour PHP, on peut dire sans se tromper que WordPress fait l’objet exactement des mêmes opinions infondées. Le fait est qu’on ne peut pas continuer à représenter 40 % du Web si ce n’est pas une solution qui vaut la peine d’être utilisée.

Jonathan s'est attaché à démystifier une série d'idées reçues ; voici donc dix d'entre elles, classées de manière pratique, dont il a parlé.

Mythe n° 1 : un code hérité, non conforme aux principes de la programmation orientée objet (POO) de PHP

Ce fut une véritable surprise pour moi d'apprendre que toutes les nouvelles installations de WordPress utilisent désormais PHP 8.3 et intègrent des déclarations de types, des interfaces et des espaces de noms, suite à un effort de modernisation du code lancé à partir de 2020.

Mythe n° 2 : absence de moteur de modèles

Les thèmes de blocs utilisent désormais Block Markup, un langage de création de modèles basé sur les commentaires HTML. Les balises PHP de l'ancienne époque (quelqu'un a la nostalgie des pages HTML truffées de code PHP ?) ont disparu, donc oui : c'est désormais le cas.

Mythe n° 3 : WordPress est lent

Une autre critique qui a été formulée par le passé à l'encontre de PHP en général. WordPress dispose désormais d'un plugin « Performance Lab » qui permet d'évaluer les performances et d'améliorer la vitesse. Le chargement spéculatif a été intégré au cœur de WordPress 6.8, avec un gain de performances de 98,2 %.

Mythe n° 4 : tout est géré par un état global

Les blocs disposent désormais d'états indépendants, ce qui permet de séparer les portées front-end et back-end. L'utilisation traditionnelle de the_post() et d’autres horreurs du genre dont je me souviens, il y a de très nombreuses années, dans WordPress

Mythe n° 5 : les champs personnalisés nécessitent des extensions tierces

Avec l'introduction de l'API Block Bindings, il n'est désormais plus nécessaire de recourir presque systématiquement à une série de plugins tiers pour que les champs personnalisés fonctionnent.

Mythe n° 6 : il faut apprendre React

Matt Mullenweg s'est peut-être tiré une petite balle dans le pied avec cette déclaration lorsque le projet Gutenberg a commencé à être déployé. Après avoir fait remarquer que les développeurs devraient acquérir des compétences en JavaScript, certains développeurs PHP ont peut-être été inquiets. Je veux dire, je le serais moi-même, étant donné que j’éprouve une haine assez irrationnelle envers React. Les développeurs qui ne souhaitent pas s’occuper du front-end peuvent utiliser l’API Interactivity pour y parvenir ; l’interaction se fait alors avec des blocs dynamiques.

Mythe n° 7 : WordPress n'est pas sécurisé

Autre cas fréquent : de nombreuses mesures ont été prises pour s'assurer que les développeurs disposent des outils nécessaires pour éviter que cela ne se produise pas. Les mises à jour automatiques des plugins et des thèmes, la protection contre les retours en arrière et le hachage des mots de passe via bcrypt ont tous été mis en place, et WordPress lui-même ne présente aucune vulnérabilité critique non corrigée.

Mythe n° 8 : absence de gestion des dépendances

S'il est vrai que WordPress n'intègre pas d'origine la prise en charge de Composer, le projet Roots Bedrock permet justement de bénéficier de cette fonctionnalité. Cette même équipe a récemment lancé WP Packages, un dépôt Composer regroupant tous les plugins et thèmes gratuits disponibles sur wordpress.org.

Mythe n° 9 : une documentation obsolète

L'équipe a été très active, comme en témoigne le travail considérable qu’elle a consacré au blog des développeurs, avec la publication de tutoriels et de la série de vidéos « Learn WordPress ». Le portail des développeurs a fait l’objet d’une refonte complète et couvre désormais de manière exhaustive les thèmes, les plugins, l’éditeur de blocs et l’API REST.

Mythe n° 10 : on ne peut pas utiliser les exceptions natives de PHP moderne

Il est vrai que, par le passé, WordPress disposait de son propre objet Exception, WP_Error. Cette contrainte a désormais été supprimée, ce qui permet aux développeurs de créer librement leur propre gestion des exceptions personnalisée. L'équipe du cœur du projet discute actuellement de la possibilité de supprimer WP_Error du code.

Conclusion

Tout comme les développeurs qui pourraient juger PHP sur la base d’une expérience datant d’il y a 20 ans, cela vaut la peine d’envisager de réexaminer la question. Le fait est que les développeurs WordPress modernes utilisent des outils tels que PHPStan, PHPUnit, Composer, etc., mais la communauté au sens large n’en a tout simplement pas conscience. Dans cette optique, Jonathan lance un défi aux développeurs WordPress : écrire sur le développement moderne sur cette plateforme, et aux développeurs non-WordPress : lui donner une nouvelle chance.

Fabien Potencier : Symfony à grande échelle

Symfony a été le premier framework PHP que j'ai utilisé. D'ailleurs, lorsque je suivais une formation ponctuelle, j'ai été formé à Symfony 2. Depuis cette époque, le projet a connu une croissance fulgurante. Fabien en est à la tête depuis plus de 20 ans.

Quelles tâches de maintenance Fabien doit-il effectuer ? Eh bien, il y a plus de trois cents dépôts, avec 5 000 versions balisées par an. 25 % de tous les téléchargements sur Composer Packagist proviennent de Symfony (même si Fabien s'empresse de préciser que les téléchargements ont tendance à être un indicateur quelque peu trompeur en raison des téléchargements effectués par le pipeline).

Ce que je trouve vraiment intéressant chez Symfony, c'est la façon dont ce framework est structuré : c'est à la fois un framework à part entière et, simultanément, un ensemble de composants autonomes. Grâce à cette conception, il sert de moteur à d'autres grands projets tels que Joomla! et Drupal, mais aussi comme composants utilisés par des projets tels que Laravel et Magento, tous mentionnés par Fabien.

Pendant de nombreuses années, au début de ma carrière, le débat opposant les « microservices » au « monorepo » faisait rage. Il est donc intéressant de noter que Fabien nous raconte comment, dès le lancement de Symfony 2, il a pris la décision délibérée de tout regrouper dans un même dépôt, sous symfony/symfony. Un outil qu’il a créé, appelé Splitsh, gère l’installation : il écoute les webhooks GitHub qui récupèrent ensuite tous les autres paquets demandés lors de l’installation sous l’espace de noms symfony, notamment Symfony AI, Twig, Symfony UX et Symfony Console, pour n’en citer que quelques-uns. On appelle cela des « sub-splits ».

Comment Symfony a-t-il réussi à faire cela ?

Fabien présente les quatre axes principaux qui ont permis à Symfony d'en arriver là où il en est aujourd'hui.

Tout d'abord, la stabilité au sein de l’équipe principale. Fabien à la barre, 30 développeurs principaux dont beaucoup sont en poste depuis longtemps.

Ensuite, un framework . Je suis un très, très grand fan de cette approche, car lorsque je dois travailler dans l’univers Node, je suis constamment déconcerté par les très nombreuses options qui s’offrent à moi lors de la programmation. Il existe un style de code cohérent (« à la Symfony ») et des normes ouvertes (PSR).

Pour vos clients qui s'appuient sur ce framework, la cohérence est essentielle. Symfony prévoit deux versions mineures par an et une version LTS tous les deux ans.

Pour finir, un sujet qui me tient particulièrement à cœur en raison de la maintenance que nous devons effectuer sur le SDK PHP de Vonage : la gestion sémantique des versions. Je ne comprends pas comment nous pouvions publier des logiciels auparavant sans recourir au versionnage sémantique.

Automatisation et intelligence artificielle

L'un des aspects délicats de la maintenance d'un projet open source de cette envergure réside dans le fait qu’il faut disposer des processus adaptés et, par conséquent, des outils adéquats pour y parvenir. Pendant la majeure partie de l’existence de Symfony, de nombreuses étapes étaient effectuées manuellement. L’IA a toutefois changé la donne.

Fabien a créé des agents personnalisés pour prendre en charge la plupart des tâches répétitives et à grande échelle. Il s'agit notamment de mener les investigations nécessaires en cas de conflits de fusion complexes, d'autant plus que Symfony doit actuellement gérer six branches taguées.

Le processus de publication est désormais géré par un agent PHP développé par Fabien lui-même. Cet agent reçoit la commande de publication, demande de quel type de publication il s'agit, renvoie un plan de publication qui doit être validé, puis peut l'exécuter une fois la confirmation reçue. Il intègre même une fonctionnalité permettant de générer des brouillons d'articles de blog pour les publications.

Avantages et inconvénients de l'IA : la sécurité

C'est peut-être dû au rythme effréné auquel évolue l'ère de l'IA, mais les inconvénients ne sont pas toujours abordés aussi ouvertement. Fabien nous explique qu'auparavant, ils faisaient l'objet d'un Audit de sécurité une fois par mois. Désormais, ils en subissent un par jour. Récemment encore, ils ont publié une version de Symfony qui corrigeait 50 vulnérabilités courantes (CVE).

Ce volume considérable de cadence élevée est motivé par un seul facteur : les LLM. Si j’affirme qu’il y a selon moi des avantages et des inconvénients, c’est parce que l’équipe Symfony est désormais pratiquement contrainte d'utiliser des LLM pour corriger cette quantité de code, car si l'équipe Symfony ne le fait pas, quelqu’un d’autre trouvera une vulnérabilité CVE grâce à un LLM. L’autre inconvénient est de devoir passer au crible les réponses pour détecter les faux positifs, mais dans l’ensemble, c’est une avancée positive dans la mesure où Fabien vise à utiliser ces outils pour publier des versions renforcées, plutôt que de les corriger a posteriori.

Conclusion

En substance, Symfony ne cesse de se renforcer, et Fabien ainsi que l'équipe principale ont mis à profit tous les outils à leur disposition pour rester à la pointe d'un framework PHP qui accomplit certaines des tâches les plus exigeantes de tout le secteur. Personnellement, j’ai vu tant de changements (je crois que la sortie de Symfony Flex a coïncidé avec le moment où je suis passé à d’autres frameworks) et je suis revenu pour découvrir un éventail vertigineux de fonctionnalités, accompagné d’une documentation brillante.

À la prochaine…

Il y a eu huit interventions au total ; ne manquez donc pas la deuxième partie, où j'aborderai l'IA avec Ashley Hindle et Jeffrey Way, Drupal avec Mike Merchel, et les RFC PHP avec Larry Garfield.