PHP 9 représente une rupture volontaire avec des comportements historiques tolérants du langage pour aller vers une exécution plus stricte, des types plus expressifs et une API standardisée; cet article détaille les principaux changements prévus, leur impact pour les développeurs et les actions à prévoir pour préparer la migration.
Contexte et calendrier
PHP 9 n’a pas encore de date de sortie officielle au moment de la rédaction; le développement est décrit comme encore en phase de planification et il est attendu après plusieurs versions intermédiaires, notamment 8.5 et 8.6, qui servent de transition vers les changements plus profonds de PHP 9.
Types et typage renforcés
La version cible introduit des types plus précis et de nouvelles possibilités de composition de types, notamment l’ajout attendu de types littéraux standalone pour null, true et false, ainsi que la prise en charge de formes disjonctives complexes (DNF types) permettant de combiner unions et intersections pour des signatures de fonctions plus exprimées et sûres.
Cette évolution se traduit aussi par un durcissement des conversions implicites : des fonctions qui acceptaient auparavant null ou d’autres valeurs « tolérées » lèveront des erreurs de type, et certains comportements automatiques, comme la création implicite de tableaux à partir d’échelles, seront restreints.
Gestion des erreurs et robustesse
PHP 9 transforme plusieurs avertissements historiques en erreurs ou exceptions, ce qui force les traitements explicites des cas anormaux. Par exemple, les tentatives d’accès à des variables non définies ou d’utilisation de propriétés dynamiques devraient déclencher des erreurs plutôt que de simples notices; de même, l’échec d’un unserialize() est prévu pour lever une exception dédiée, facilitant la gestion centralisée des échecs de désérialisation.
Une autre piste annoncée est la possibilité de dissimuler certains paramètres sensibles dans les backtraces afin de réduire les risques de fuite d’informations dans les logs d’erreur en production.
Évolutions de la syntaxe et du langage
Plusieurs syntaxes ambiguës ou anciennes sont supprimées ou dépréciées définitivement : l’interpolation de chaînes via ${…} est citée comme dépréciée, et des comportements d’incrémentation de chaînes « exotiques » sont corrigés — l’ancien comportement d’incrément sur certaines chaînes sera retiré et une fonction dédiée str_increment() sera proposée pour les usages nécessitant l’ancien comportement.
Les constantes et les traits gagnent en expressivité, par exemple avec la possibilité déclarée d’avoir des constantes dans les traits, ce qui élargit l’usage réutilisable des traits sans bricolage.
API standard, suppression de code obsolète et signatures nettoyées
PHP 9 poursuivra la suppression de fonctionnalités déjà dépréciées dans les branches 8.1 à 8.4, ce qui entraînera des ruptures pour du code Legacy qui n’a pas été migré. Par ailleurs, des signatures de fonctions natives seront rationalisées : des fonctions multi‑usage seront scindées pour clarifier l’intention et plusieurs méthodes SPL ou DateTime verront leurs signatures ajustées.
La suppression progressive d’APIs obsolètes et la clarification des signatures visent à rendre le code utilisateur plus lisible et à réduire les comportements surprises lors d’appels aux fonctions natives.
Sécurité, hasard et utilitaires
Un nouveau ou remanié module de génération aléatoire est évoqué, apportant une API plus moderne, plus sûre et plus performante pour les besoins cryptographiques et non‑cryptographiques; cela implique une migration des usages anciens basés sur des fonctions obsolètes vers la nouvelle extension random.
D’autres ajustements pratiques sont mentionnés, comme la dépréciation de utf8_encode()/utf8_decode() et l’ajout d’un modificateur « n » dans PCRE, ainsi que des fonctions utilitaires pour travailler plus proprement avec les tableaux et un opérateur pipe en 8.5 qui illustre la direction stylistique prise en amont de PHP 9.
Impact pour les projets et préparation
Les conséquences pratiques sont claires : la migration vers PHP 9 nécessite une phase de préparation active. Il est recommandé d’auditer le code pour identifier et corriger les utilisations de propriétés dynamiques, remplacer les patterns qui s’appuient sur conversions implicites, capturer explicitement les retours de unserialize() et passer en revue les extensions et bibliothèques tierces pour s’assurer qu’elles supportent les nouvelles signatures et exceptions.
Tester avec les versions intermédiaires 8.5 et 8.6 et suivre les RFC et discussions sur les internals est la meilleure stratégie pour anticiper les ruptures et planifier des correctifs progressifs plutôt qu’un portage de dernière minute.
Points d’attention concrets pour les développeurs
- Rechercher et corriger l’usage de variables non initialisées et de propriétés dynamiques afin d’éviter des erreurs fatales sur PHP 9.
- Remplacer les dépendances à des comportements permissifs par du code explicite vérifiant les types et valeurs attendus.
- Mettre à jour les bibliothèques de génération aléatoire vers la nouvelle extension lorsque celle‑ci sera disponible.
- Surveiller les dépréciations de fonctions telles que utf8_encode/décode et interpolation via ${} et adapter les chaînes et templates en conséquence.
Exemple d’adaptation (illustration)
Si votre code s’appuie sur l’incrémentation d’une chaîne particulière pour générer des clés séquentielles, il faudra remplacer ce pattern par un appel explicite à une fonction dédiée ou par une logique contrôlée, afin d’éviter des erreurs au passage vers PHP 9.
Ressources et suivi
Les principaux axes de travail sont annoncés dans les articles et synthèses publiés sur le sujet, qui détaillent les suppressions prévues, les RFC en discussion et les suggestions d’API pour un PHP plus strict. Pour rester à jour, il faut suivre les RFCs du dépôt officiel PHP et les notes de version des branches 8.5 et 8.6, qui servent de précurseurs aux changements majeurs attendus en 9.0.
Rappel final
PHP 9 s’annonce comme une version de clarification et de durcissement : les changements visent la prévisibilité, la sécurité et la lisibilité du code, au prix d’un travail de migration pour les bases de code existantes. Nous vous recommandons de commencer dès maintenant l’audit de vos codes et ainsi de profiter des versions intermédiaires pour valider les correctifs afin de favoriser la bascule vers php9 lorsque cette version sera effective.

