PHP 9.0 : nouveautés, changements majeurs et impacts à venir

PHP 9.0 n'a pas encore de date de sortie officielle. La prochaine version sera PHP 8.6, prévue fin 2026. Mais PHP 9 se dessine déjà clairement : chaque version 8.x accumule des dépréciations qui seront transformées en erreurs ou supprimées dans la prochaine version majeure. L'approche est la même depuis PHP 7 : durcissement progressif du typage, promotion des warnings en erreurs, nettoyage de l'API standard. Cette évolution s'inscrit dans la continuité des PSRs, ces standards de l'écosystème PHP qui ont progressivement homogénéisé les pratiques de développement.

En attendant PHP 9, l'écosystème ne reste pas immobile. PHP 8.5 (novembre 2025) a apporté son lot de dépréciations et de nettoyages. Parmi les RFC en discussion pour les versions suivantes, le pipe operator (|>) et le partial function application pourraient enrichir la syntaxe du langage, mais leur inclusion n'est pas encore confirmée. Ces propositions illustrent la direction du langage vers plus d'expressivité.

Cet article recense les changements confirmés (dépréciations votées et acceptées) et les tendances probables. Il sera mis à jour au fur et à mesure des votes RFC.

Ce qui sera supprimé : les dépréciations confirmées

Les dépréciations votées en PHP 8.5 seront supprimées en PHP 9.0, comme celles votées en PHP 8.4 avant elles. Voici les plus impactantes pour les projets Symfony et PHP en général.

__sleep() et __wakeup() remplacés par __serialize() / __unserialize()

Les méthodes magiques __sleep() et __wakeup() sont dépréciées en PHP 8.5. En PHP 9, elles deviendront des erreurs ou seront ignorées. Le remplacement par __serialize() et __unserialize(), disponible depuis PHP 7.4, offre un modèle plus prévisible et compatible avec l'héritage d'objets. Les projets qui utilisent encore l'ancienne interface Serializable devront migrer les deux : l'interface et les méthodes magiques.

Les backticks (`) supprimés

L'opérateur backtick, alias de shell_exec(), est déprécié en PHP 8.5 et sera supprimé en PHP 9. La syntaxe prêtait à confusion avec les template strings d'autres langages. Utilisez shell_exec() explicitement.

null comme clé de tableau

L'utilisation de null comme offset de tableau ($array[null]) est dépréciée en PHP 8.5. En PHP 9, ce sera une erreur. La conversion implicite de null en chaîne vide "" était un piège classique. Initialisez vos clés explicitement.

Opérateurs ++ et -- sur les types non-entiers

PHP autorisait l'incrémentation de chaînes ('a9'++), de null ou de false via une coercion implicite. Ces comportements sont dépréciés depuis PHP 8.3 et deviendront des TypeError en PHP 9.0. La fonction str_increment(), introduite en PHP 8.3, couvre le cas légitime de l'incrémentation alphabétique.

Fin de la promotion implicite de false en tableau

L'écriture $x = false; $x[] = 'value'; transformait silencieusement un booléen en tableau. PHP 9.0 interdit cette coercion et exige une initialisation explicite.

Propriétés dynamiques interdites

Les propriétés dynamiques, dépréciées en PHP 8.2, provoqueront une erreur fatale en PHP 9.0. Les classes qui en dépendent devront utiliser #[AllowDynamicProperties] ou migrer vers des propriétés déclarées.

Warnings susceptibles d'être promus en erreurs

L'accès à une propriété sur null, l'utilisation d'un indice inexistant, la lecture d'une variable non définie : ces situations génèrent un warning depuis PHP 8.0. La tendance de chaque version majeure est de promouvoir ces warnings en erreurs fatales. Il est probable que PHP 9.0 franchisse ce pas pour plusieurs d'entre eux, même si aucune RFC spécifique n'a encore été votée sur ce point. Traiter ces warnings comme des erreurs dès aujourd'hui (via PHPStan ou un error handler strict) est la meilleure préparation.

Nettoyage de l'API standard

Fonctions no-op supprimées

Depuis la conversion des ressources en objets (PHP 8.0-8.4), plusieurs fonctions sont devenues des no-op : curl_close(), curl_share_close(), xml_parser_free(), finfo_close(), imagedestroy(). Elles sont dépréciées en PHP 8.5 et seront supprimées en PHP 9. Retirez ces appels de votre code, les objets sont nettoyés automatiquement.

Casts non-canoniques supprimés

Les formes (integer), (boolean), (double) et (binary) sont dépréciées en PHP 8.5. Utilisez (int), (bool), (float) et (string). Ce changement aligne les casts sur les noms de types utilisés dans les signatures et les annotations PHPStan.

Interpolation de chaînes simplifiée

Les syntaxes "${var}" et "${expr()}", dépréciées depuis PHP 8.2, seront supprimées en PHP 9. Seules resteront "$var" et "{$var}". La concaténation explicite remplace les expressions complexes. Ce nettoyage réduit la surface d'ambiguïté syntaxique et aligne PHP sur le comportement attendu par les analyseurs statiques.

$http_response_header supprimée

La variable prédéfinie $http_response_header, remplie implicitement par les fonctions de flux HTTP, est dépréciée en PHP 8.5. Utilisez stream_get_meta_data() ou une bibliothèque HTTP dédiée.

Reflection : méthodes no-op et ambiguës

Reflection*::setAccessible() (no-op depuis PHP 8.1), ReflectionClass::getConstant() pour les constantes inexistantes (retournait false de manière ambiguë) et ReflectionProperty::getDefaultValue() pour les propriétés sans défaut (retournait null de manière ambiguë) sont dépréciées. Utilisez hasConstant() et hasDefaultValue() pour vérifier l'existence avant d'accéder aux valeurs.

Renforcement de la sécurité

unserialize() et la gestion d'erreurs

La fonction unserialize() renvoie actuellement false ou génère un warning en cas de données corrompues. Une RFC propose d'introduire une exception dédiée en PHP 9.0 pour permettre un traitement structuré via try/catch. Ce changement n'est pas encore voté, mais la direction est claire : les fonctions qui échouent silencieusement devront lever des exceptions. Si vous désérialisez des données provenant de sources externes (sessions, caches distribués, messages de queue), préparez-vous à encapsuler ces appels dans un try/catch.

Directives INI de sécurité durcies

register_argc_argv sera forcé à Off pour les SAPIs non-CLI en PHP 9, éliminant un vecteur de pollution de variables. disable_classes, fondamentalement cassée (use-after-free, instabilité du moteur), est déjà supprimée en PHP 8.5.

Nouvelle licence pour PHP 9

Une RFC propose de relicenser PHP sous BSD-3-Clause à partir de PHP 9.0, remplaçant la licence PHP historique. Ce changement n'a pas d'impact technique sur votre code, mais il simplifie la compatibilité juridique avec les autres projets open source et modernise la gouvernance du langage.

Stratégie de migration : de l'audit au déploiement

Détecter les incompatibilités avant qu'elles ne cassent

La première étape consiste à activer E_DEPRECATED sur tous les environnements, y compris la CI. Sur un projet Symfony, configurez le handler d'erreurs pour convertir les dépréciations en exceptions dans les tests :

Copierset_error_handler(function (int $errno, string $errstr) {
    if ($errno === E_DEPRECATED) {
        throw new \ErrorException($errstr, 0, $errno);
    }
    return false;
});

Cette approche transforme chaque dépréciation en un test rouge, ce qui rend l'avancement de la migration mesurable.

Rector comme levier d'automatisation

Rector permet de maîtriser l'évolution de votre code Symfony et couvre une part significative des transformations requises : remplacement de __sleep()/__wakeup() par __serialize()/__unserialize(), correction des interpolations de chaînes, ajout des initialisations explicites de tableaux, remplacement des casts non-canoniques. Sur un projet de plus de 100 000 lignes, l'approche manuelle n'est pas viable.

L'ordre recommandé : exécuter Rector sur le code applicatif, valider la suite de tests, puis exécuter Rector sur les tests eux-mêmes.

Gérer les dépendances tierces

Le véritable goulot d'étranglement d'une migration majeure n'est jamais le code applicatif : ce sont les dépendances. Auditez vos composer.json avec composer outdated et vérifiez la compatibilité déclarée de chaque package. Les packages qui n'ont pas été mis à jour depuis PHP 8.4 devront être remplacés ou forkés. Symfony et Laravel publieront des versions compatibles PHP 9 ; les bundles communautaires moins maintenus représenteront le risque principal.

Ce qui reste incertain

Performances et JIT

Le compilateur JIT continuera d'être amélioré, mais les gains pour les applications web classiques (dominées par les I/O) resteront marginaux. Les bénéfices concernent surtout les traitements CPU-bound : calculs, manipulations de structures volumineuses, transformations d'images.

Concurrence et Fibers

PHP 9.0 pourrait renforcer l'intégration des Fibers (introduites en PHP 8.1) pour faciliter l'écriture de code concurrent. Les frameworks comme ReactPHP et Swoole s'appuient déjà dessus. Mais aucune RFC concrète n'a été votée à ce stade. C'est une tendance, pas une certitude.

Pattern matching

Une RFC de pattern matching est en discussion. Si elle est acceptée, ce serait l'ajout syntaxique le plus significatif depuis le match expression de PHP 8.0. Mais la complexité de la proposition rend son inclusion dans PHP 9.0 incertaine.

Vision architecturale : ce que PHP 9 signifie pour les grands projets

La trajectoire du langage est prévisible

Depuis PHP 7.0, chaque version majeure suit le même schéma : durcissement du typage, promotion des warnings en erreurs, suppression des dépréciations accumulées. Cette prévisibilité est un atout stratégique. Un architecte peut planifier les migrations sur un horizon de trois à cinq ans.

Impact sur l'écosystème des frameworks

Symfony et Laravel publieront des versions compatibles PHP 9. La documentation officielle de Symfony guide les équipes dans ces montées de version. Ces frameworks absorbent une part importante des changements du langage dans leurs couches d'abstraction. La migration du framework est généralement transparente pour le code applicatif, à condition que celui-ci respecte les bonnes pratiques : injection de dépendances, typage des arguments et retours, pas de suppression d'erreurs avec @. Les projets qui s'écartent de ces conventions paieront un coût de migration proportionnel à leur dette technique.

Préparer les grandes bases de code

Pour un projet de plusieurs centaines de milliers de lignes, la migration vers PHP 9.0 se planifie en trois phases. D'abord, la mise en conformité sur PHP 8.5 ou 8.6 avec zéro dépréciation. Ensuite, la mise à jour des dépendances vers des versions compatibles PHP 9. Enfin, le passage effectif au runtime PHP 9 avec une campagne de tests exhaustive.

La clé est de ne pas traiter la migration comme un projet ponctuel mais comme un processus continu. Les équipes qui activent E_DEPRECATED dès aujourd'hui et qui intègrent Rector dans leur pipeline de CI arriveront à PHP 9.0 sans friction. Pour les projets qui accusent un retard de version, une modernisation de l'application PHP permet de rattraper le temps perdu de manière structurée. Pour ceux qui envisagent un audit de code avant la migration, un regard extérieur permet souvent d'identifier les points de blocage avant qu'ils ne deviennent critiques.

Pour aller plus loin

• Développement PHP sur mesure, notre expertise PHP 8 et Symfony pour vos projets
• La Fondation PHP fête ses 3 ans, Bilan et perspectives de la Fondation PHP
• PHP.net, Site officiel du langage PHP et documentation des versions
• PHP RFC, Les propositions d'évolution du langage PHP
• The PHP Foundation, L'organisation qui finance le développement de PHP
• Dépréciations PHP 8.5, Liste complète des dépréciations votées pour PHP 8.5