Fin de support PHP, Symfony, AngularJS : le plan d'action

PHP 8.2 ne reçoit plus de correctifs de sécurité après le 31 décembre 2026. Symfony 6.4 cesse de recevoir des correctifs de bugs en novembre 2026. AngularJS n'est plus maintenu depuis fin 2021. Si votre application métier repose sur l'une de ces briques, le compte à rebours a commencé.

Une fin de support ne fait pas tomber l'application. Elle tourne le lendemain comme la veille. Ce qui change, c'est que chaque nouvelle faille reste ouverte, et que chaque mois d'attente rend la montée de version plus longue.

Les dates de fin de support qui comptent en 2026

Sources : php.net, symfony.com, endoflife.date.

Deux points pièges. Symfony 7.4 exige PHP 8.2 au minimum, et Symfony 8 exige PHP 8.4 : on ne monte donc pas Symfony sans regarder PHP, et inversement. Et une application en Symfony 5.4 reste couverte en sécurité, mais sur une base qui ne reçoit plus de correctifs de bugs et dont l'écosystème de bundles avance sans elle.

Pourquoi les mises à jour de sécurité comptent plus que jamais

Il y a quelques années, entre la publication d'une faille et son exploitation, on avait des semaines devant soi. Ce n'est plus le cas. Selon Mandiant (Google), le délai moyen avant exploitation est passé de 63 jours en 2018-2019 à 32 jours en 2021-2022, puis à 5 jours en 2023.

L'IA accélère encore le mouvement. Fin 2024, l'agent Big Sleep de Google a trouvé seul une faille exploitable dans SQLite, l'une des bases de données les plus répandues au monde (Project Zero). Ces outils servent aussi aux attaquants : chercher une faille dans une version ancienne et bien documentée d'un framework devient plus rapide et moins coûteux chaque année.

La conséquence est simple. Une mise à jour de sécurité ne peut plus attendre la prochaine fenêtre de maintenance trimestrielle : elle doit partir en production en quelques jours. Cela suppose trois choses : une version encore supportée (sinon il n'y a tout simplement pas de correctif à appliquer), un déploiement qui ne fait pas peur, et quelques tests pour vérifier que rien n'a cassé. Une application bloquée sur PHP 8.1 ou AngularJS n'a aucune des trois.

Que risque-t-on à rester sur une version non supportée ?

Le risque n'est pas une panne, c'est une dérive :

• La sécurité. Une faille publiée après la fin de support ne sera pas corrigée. Pour une application exposée sur internet qui manipule des données clients, c'est la question que posent un assureur cyber, un auditeur ou un grand compte dans son questionnaire sécurité.
• L'hébergement. Les hébergeurs et les images Docker officielles retirent les vieilles versions de PHP. Le jour où le serveur doit être reconstruit, l'ancienne version n'est plus disponible.
• Les dépendances. Les bibliothèques abandonnent les anciennes versions les unes après les autres. On finit bloqué sur une version d'un composant de paiement ou d'export parce que la suivante exige un PHP plus récent.
• Le coût. Monter d'une version à la suivante est un chantier de quelques jours. Rattraper trois ans de retard sur PHP, Symfony et une dizaine de bundles en même temps est un projet.

Le plan d'action en 5 étapes

1. Faire l'inventaire

Avant de toucher au code, on liste ce qui tourne réellement : la version de PHP en production (pas celle du poste du développeur), le composer.json et le composer.lock, le package.json pour le front, la version de la base de données et l'image de l'hébergement. composer outdated et npm outdated donnent un premier état des lieux en quelques minutes.

2. Mesurer l'écart

Symfony signale les fonctions dépréciées avant de les supprimer. Activer le journal des dépréciations sur un environnement de test montre précisément ce qui cassera à la version suivante. C'est l'outil le plus utile du chantier, et il est déjà là.

3. Sécuriser avant de bouger

Une montée de version sans tests, c'est une montée de version à l'aveugle. Pas besoin de viser une couverture parfaite : quelques tests sur les parcours critiques (se connecter, créer une commande, générer une facture, exporter) suffisent pour savoir si quelque chose a changé. C'est la même logique que pour une reprise de code : on stabilise d'abord, on fait évoluer ensuite.

4. Monter par paliers, de LTS en LTS

On ne saute pas de Symfony 4.4 à 7.4 en une fois. On passe de LTS en LTS (5.4, puis 6.4, puis 7.4), en corrigeant les dépréciations à chaque étape, et en montant PHP au rythme qu'exige chaque version. Des outils comme Rector automatisent une bonne partie des réécritures répétitives. Chaque palier part en production avant d'attaquer le suivant.

5. Traiter AngularJS à part

AngularJS ne se met pas à jour : il se remplace. La voie la moins risquée est la migration écran par écran vers un framework actuel, en commençant par les écrans les plus utilisés, avec les deux versions qui cohabitent le temps de la transition. Un support étendu payant existe chez des éditeurs spécialisés : il achète du temps, il ne règle pas le problème.

Combien de temps ça prend ?

Tout dépend de l'écart et de l'état du code, mais les ordres de grandeur sont stables :

• Une version de PHP en retard, Symfony déjà en LTS récente : quelques jours.
• Deux ou trois versions de retard sur PHP et Symfony : quelques semaines, par paliers.
• Un front AngularJS : un projet à part, à découper écran par écran, souvent plusieurs mois en parallèle de l'activité.

Le chiffre qui fait vraiment varier la facture n'est pas la version de départ, c'est l'absence de tests et de documentation. C'est pour cela que nous commençons toujours par un audit : il dit en quelques jours ce qui bloque, dans quel ordre le traiter, et ce que ça coûte. Le nôtre est à 2 500 € forfaitaires.

Faire en interne ou se faire accompagner

Si une équipe connaît bien l'application et a le temps de dérouler les paliers, elle peut le faire seule avec la méthode ci-dessus. Les cas où un regard extérieur paie vite : le développeur d'origine est parti, l'application n'a pas de tests, plusieurs composants sont en retard en même temps, ou la montée de version doit se faire sans interrompre l'activité.

Une fois à jour, le plus économique est de ne plus prendre de retard : une tierce maintenance applicative inclut justement ces montées de version au fil de l'eau, au lieu d'un rattrapage tous les cinq ans.

À lire aussi : la reprise de code et l'audit de projet, la TMA, avec les prix, et le logiciel métier sur mesure.