Symfony et PHP : deux calendriers qui ne sont pas alignés

Une application peut être sur une version de Symfony parfaitement supportée et tourner sur un PHP qui ne reçoit plus rien. La situation échappe facilement à la vigilance, parce que le tableau de bord de l'équipe suit le numéro du framework et pas celui de l'interpréteur. Les deux calendriers sont indépendants, et il faut les lire ensemble.

Le calendrier de PHP

Source : la page des versions supportées de php.net, relevée le 9 août 2026. Le rythme y est expliqué : deux ans de support complet à compter de la sortie stable, puis deux années supplémentaires réservées aux failles critiques. Retenez la deuxième ligne du tableau : PHP 8.2 n'est plus en support actif depuis fin 2024, ne reçoit plus que des correctifs de sécurité, et sortira complètement du support le 31 décembre 2026. C'est aussi le plancher exigé par toute la branche Symfony 7, donc une combinaison parfaitement légale aujourd'hui.

Le plancher PHP de Symfony est un minimum, pas une consigne

Source : le fichier de statut publié par symfony.com, qui expose le plancher de chaque version. Et voici le point décisif : ce chiffre est un minimum. Le processus de publication du projet précise que, pendant toute la durée de vie d'une version de Symfony, toutes les versions de PHP publiées entre-temps sont supportées, y compris les nouvelles majeures ; le maximum supporté est simplement la dernière version de PHP disponible. Une application en Symfony 6.4 n'est donc pas condamnée à PHP 8.1 : elle peut tourner sur PHP 8.4 sans changer de version de framework.

Ce que cela change : deux chantiers qu'on peut séparer

Puisque le plancher est un minimum, monter PHP et monter Symfony sont deux opérations indépendantes, qui peuvent se faire l'une après l'autre. C'est une bonne nouvelle opérationnelle, parce que ce sont deux types de risques différents : une montée de PHP touche le comportement du langage, une montée de Symfony touche les interfaces du framework. Les mener ensemble, c'est renoncer à savoir laquelle a cassé quoi.

L'ordre le plus économique est presque toujours PHP d'abord, pour trois raisons. Vous restaurez la couverture de sécurité de la couche la plus basse sans toucher au code applicatif. Vous rendez le terrain plus stable pour la montée suivante, puisque les dépendances récentes visent des PHP récents. Et vous devrez le faire de toute façon si votre cible est Symfony 8, dont le plancher est PHP 8.4.0. Les mainteneurs de Doctrine suggèrent d'ailleurs le même ordre dans leur propre document de montée, en recommandant de passer à PHP 8.4 avant d'attaquer la montée majeure de l'ORM.

Le décalage entre votre poste et le serveur

Un piège classique, décrit dans le guide officiel : les dépendances s'installent sans erreur sur votre machine mais échouent sur le serveur, parce que les deux ne font pas tourner le même PHP. Composer résout les contraintes contre la version de PHP qu'il détecte localement. Le réglage `platform` de `composer.json` permet de lui indiquer la version cible, celle du serveur, pour que la résolution corresponde à l'environnement réel. Sans lui, votre fichier de verrouillage décrit un environnement qui n'existe que chez vous.

Ce que la montée de PHP casse, et où le voir

Une montée de PHP ne se signale pas à l'installation, elle se manifeste à l'exécution : messages de dépréciation, changements de comportement sur les conversions de types, fonctions retirées. Chaque branche publie son guide de migration, par exemple celui de PHP 8.4, qui liste les changements rétro-incompatibles et les fonctionnalités dépréciées. Le lire avant de bouger prend peu de temps et évite de découvrir les ruptures une par une, en production.

Questions fréquentes