Application en PHP 7 ou Symfony 4 : risques réels et plan de migration progressif

L'application qui gère vos commandes, votre facturation ou vos échanges avec vos partenaires fonctionne. Les équipes s'en servent tous les jours et rien n'est en panne. Pourtant, si elle repose sur PHP 7, le langage dans lequel elle est écrite, ou sur Symfony 4, le framework PHP qui lui sert de charpente, ses fondations ne reçoivent plus aucun correctif de sécurité officiel : depuis novembre 2022 pour PHP 7.4, depuis novembre 2023 pour Symfony 4.4.

Si vous dirigez l'entreprise, la DSI ou le produit, vous n'avez pas besoin d'être développeur pour trancher. Il vous faut des dates officielles, une lecture honnête du risque et un plan de migration progressif, palier par palier, que vous pourrez présenter en comité puis suivre en point d'avancement. Pas de code, pas de dramatisation.

Ce qu'il faut avoir sous la main

Aucune compétence technique n'est requise pour suivre ce plan. En revanche, quatre éléments rendent la décision possible et la migration pilotable :

• Les versions en production : quelle version de PHP et quelle version de Symfony tournent réellement sur vos serveurs (votre équipe technique ou votre prestataire peut vous le dire).
• Les accès : le code source, le dépôt Git qui en garde l'historique et les environnements d'hébergement, ou un prestataire qui les détient.
• La liste des parcours métier critiques : facturation, prise de commande, exports comptables, connexions avec les partenaires, tout ce qui ne doit jamais s'arrêter.
• Un interlocuteur métier disponible pour valider chaque mise en production (la « recette »), car c'est lui qui sait si l'application se comporte comme avant.

Quatre mots de vocabulaire avant de commencer

Une version majeure (Symfony 4, 5, 6, 7, 8) peut casser la compatibilité avec la précédente : passer de l'une à l'autre demande d'adapter le code. Une version mineure (5.3, 5.4) ajoute des fonctionnalités en restant compatible avec la précédente, selon la promesse de rétrocompatibilité de Symfony, qui admet des exceptions (par exemple pour corriger une faille) : les tests restent nécessaires. Une version LTS (Long-Term Support, support à long terme) est une version mineure maintenue plus longtemps que les autres : c'est celle qu'on vise pour une application métier. Enfin, une dépréciation est un avertissement émis par le framework : « ce morceau de code fonctionne encore, mais il disparaîtra à la prochaine version majeure ». Ces avertissements sont la feuille de route de toute migration Symfony.

La contrainte : des calendriers de support publics et datés

Ni PHP ni Symfony ne s'arrêtent par surprise. Leurs calendriers sont publiés à l'avance, ce qui permet d'anticiper plutôt que de subir.

Côté PHP, chaque version reçoit deux ans de support actif (corrections de bugs et de sécurité), puis deux ans de correctifs de sécurité seuls, d'après la page des versions supportées de php.net, le site officiel du langage. Passé ce délai, la version est en fin de vie. Les dates sont sans appel, selon la liste officielle des versions en fin de vie : PHP 7.2 le 30 novembre 2020, PHP 7.3 le 6 décembre 2021, PHP 7.4 le 28 novembre 2022 (dernière version publiée : 7.4.33), PHP 8.0 le 26 novembre 2023 et PHP 8.1 le 31 décembre 2025.

Au 2 octobre 2026, quatre versions de PHP sont encore supportées : PHP 8.2 (sécurité seule jusqu'au 31 décembre 2026), PHP 8.3 (sécurité jusqu'au 31 décembre 2027), PHP 8.4 (support actif jusqu'au 31 décembre 2026, sécurité jusqu'au 31 décembre 2028) et PHP 8.5 (support actif jusqu'au 31 décembre 2027, sécurité jusqu'au 31 décembre 2029).

Côté Symfony, le processus de publication officiel fixe une version mineure tous les six mois, en mai et en novembre. Les versions qui se terminent par .4 sont des LTS : trois ans de corrections de bugs et quatre ans de correctifs de sécurité. Les autres versions, dites standard, sont maintenues huit mois. Concrètement :

• Symfony 4.4 : corrections de bugs jusqu'en novembre 2022, sécurité jusqu'en novembre 2023. Plus rien depuis.
• Symfony 5.4 : correctifs de sécurité seuls, prolongés jusqu'en février 2029 d'après sa page de version. C'est une exception : le calendrier standard s'arrêtait en novembre 2025, et l'extension est financée par Ibexa, éditeur de la plateforme Ibexa DXP bâtie sur Symfony 5.4, comme l'explique le blog officiel de Symfony.
• Symfony 6.4 : corrections de bugs jusqu'en novembre 2026, sécurité jusqu'en novembre 2027.
• Symfony 7.4, la LTS actuelle : corrections de bugs jusqu'en novembre 2028, sécurité jusqu'en novembre 2029.
• Symfony 8.1, version standard sortie en mai 2026, maintenue jusqu'à fin janvier 2027. Symfony 8.2 est attendue en novembre 2026.

Deux échéances proches méritent votre attention, même si votre application a déjà été modernisée : la fin des corrections de bugs de Symfony 6.4 en novembre 2026 et la fin des correctifs de sécurité de PHP 8.2 le 31 décembre 2026. Une application montée récemment en Symfony 6.4 sur PHP 8.2 a donc déjà son prochain rendez-vous.

Ce que « fin de support » veut dire concrètement

Une version en fin de support ne s'éteint pas. Votre application continue de répondre, vos utilisateurs ne voient rien. Ce qui change se joue sur quatre terrains.

Plus de correctifs de sécurité officiels

Quand une faille est découverte dans PHP 7.4 ou dans Symfony 4.4, plus personne ne publie de correctif officiel. La différence avec une version encore suivie est très concrète : la branche Symfony 5.4 a encore reçu en 2026 des correctifs de failles référencées publiquement (les CVE, le catalogue mondial des vulnérabilités connues), la branche 4.4 non. Une faille publiée est aussi une faille documentée pour qui voudrait l'exploiter.

L'hébergement : ça tourne, mais sans filet

La politique d'Azure App Service, le service d'hébergement d'applications de Microsoft, en donne un exemple : après la fin de support d'un langage, les applications continuent de tourner sans changement, mais l'hébergeur ne fournit plus ni correctif de sécurité ni support client pour cette version. Chaque hébergeur a ses propres règles : la question est à poser au vôtre, par écrit.

Des dépendances qui se figent

Une application moderne s'appuie sur des dizaines de bibliothèques externes : génération de PDF, connecteurs de paiement, envoi d'e-mails, SDK de partenaires. Leurs nouvelles versions exigent des versions récentes de PHP. Symfony 8 lui-même exige PHP 8.4 au minimum, selon sa page de version. Sur PHP 7, vous restez bloqué sur d'anciennes versions de ces bibliothèques, elles aussi de moins en moins suivies : l'application se fige, et chaque nouveau besoin devient un contournement.

Des compétences plus rares sur les anciennes versions

Les développeurs se forment et travaillent sur les versions actuelles. Plus l'écart grandit, plus il devient difficile de trouver quelqu'un qui maîtrise à la fois l'ancienne base et les pratiques d'aujourd'hui, et plus chaque intervention prend du temps.

Il existe un support étendu payant pour gagner du temps. Zend, éditeur spécialisé dans PHP, propose un support de long terme pour PHP 7.2, 7.3, 7.4 et 8.1. Côté framework, la documentation officielle de Symfony indique qu'un support professionnel est disponible auprès de SensioLabs, l'entreprise qui soutient le projet Symfony, une fois la maintenance d'une version terminée. L'offre de Zend fournit des correctifs de sécurité pour PHP ; la documentation de Symfony ne détaille pas, elle, le contenu du support de SensioLabs. Dans les deux cas, ces offres achètent du temps sans moderniser ni le code ni ses dépendances : c'est une solution d'attente, pas une migration.

Les risques réels, sans dramatiser

Il faut distinguer deux familles de risques. Le risque immédiat, c'est une faille non corrigée exploitée. Il pèse surtout si l'application est exposée sur Internet (portail client, extranet, API ouverte aux partenaires) ou si elle traite des données personnelles. Une application interne, accessible uniquement depuis le réseau de l'entreprise, est moins exposée, sans être à l'abri.

Le risque progressif est moins visible et souvent plus coûteux : une fonctionnalité demandée par le métier qu'on ne peut pas livrer faute de bibliothèque compatible, des interventions qui coûtent de plus en plus cher, une migration d'hébergement imposée à une date que vous n'avez pas choisie.

Votre situation est loin d'être isolée, du moins sur le web public. Selon W3Techs, service de mesure des technologies du web, au 2 octobre 2026, PHP 7 équipe encore 27,8 % des sites web qui utilisent PHP, toutes versions 7.x confondues (contre 64,4 % pour PHP 8). Ces chiffres portent sur des sites web publics, pas sur les applications internes, mais ils montrent que la situation est courante, et elle se traite. Une application en fin de support n'est pas en panne : c'est une dette qui grossit chaque mois, et plus on attend, plus l'écart de versions à rattraper est grand.

Évaluer l'existant avant de décider

Avant de choisir une option, il faut savoir de quoi on parle. Un audit technique répond à cette question. Il examine notamment :

• Les versions exactes de PHP, de Symfony et de chaque dépendance, et l'écart avec les versions supportées.
• Les tests automatisés : existent-ils, que couvrent-ils, tournent-ils encore ?
• La dette : bibliothèques abandonnées par leurs auteurs, code maison qui réinvente ce que le framework fait aujourd'hui, zones que personne n'ose toucher.
• Le front : la partie visible de l'application et ses outils de construction, souvent Webpack Encore sur les projets Symfony de cette génération.
• L'hébergement et le déploiement : comment l'application est mise en production, et ce que l'hébergeur accepte comme versions.
• La documentation : ce qui est écrit, ce qui n'existe que dans la tête de l'équipe.

Le front mérite souvent une attention particulière, car son outillage vieillit au même rythme que le reste : nous avons détaillé ce sujet dans notre article sur la migration de Webpack Encore vers Vite ou Rsbuild. Le livrable attendu d'un audit est double : une cartographie des risques (ce qui bloque, ce qui ralentit, ce qui est sain) et un chiffrage par scénario, qui vous permet de comparer les options sur une base factuelle.

Les options : support étendu, migration version par version, montée directe, réécriture

Quatre voies existent, et toutes relèvent de la reprise et modernisation d'applications existantes. Aucune n'est bonne dans l'absolu : chacune a ses conditions de pertinence.

Le support étendu

Il a du sens si l'application doit être remplacée ou décommissionnée à court terme, ou pour sécuriser la période pendant laquelle la migration se prépare. Il ne règle ni le gel des dépendances ni l'écart qui continue de se creuser.

La migration version par version

C'est la voie décrite par la documentation officielle de Symfony sur les montées de version majeure : passer d'abord par la dernière version mineure de la branche actuelle, corriger toutes les dépréciations signalées, puis monter à la version majeure suivante, et recommencer. Nous recommandons en plus de livrer chaque palier en production avant de passer au suivant, ce que la documentation n'impose pas. Cette voie est la plus prévisible, celle qui permet de continuer l'activité, et la plus adaptée à une application métier qui fonctionne.

La montée directe

Sauter de Symfony 4 à Symfony 7 en une seule opération est tentant sur le papier. En pratique, on perd le guide que constituent les dépréciations de chaque version intermédiaire, et l'on accumule tous les changements dans une seule livraison, difficile à tester et à remettre en arrière. Elle peut se justifier sur une application très petite, très bien testée, avec peu de dépendances.

La réécriture

Tout reprendre de zéro, c'est-à-dire une refonte complète, séduit quand le code est jugé trop dégradé. La documentation d'Amazon Web Services (AWS), le fournisseur cloud, consacrée au modèle du figuier étrangleur (strangler fig), traite d'un cas voisin : le passage d'une application monolithique à une architecture en microservices. Elle rappelle qu'une migration « big bang », réalisée en une seule opération, introduit un risque de transformation et de perturbation de l'activité, et note que pour une petite application, peu complexe, réécrire peut être plus efficace que migrer. Le raisonnement se transpose à une application PHP par analogie : AWS ne se prononce pas sur ce cas précis. Le figuier étrangleur lui-même est une variante intermédiaire : on remplace l'application fonctionnalité par fonctionnalité, derrière une façade commune, jusqu'à pouvoir éteindre l'ancienne. Il convient surtout aux applications volumineuses dont certaines parties méritent vraiment d'être reconstruites.

Le plan de migration progressif, étape par étape

Voici la trajectoire type pour une application en Symfony 4 sur PHP 7. Chaque étape a un but, un contenu et un résultat que vous pouvez constater. Chaque palier part en production séparément, pour que l'activité continue pendant toute la migration.

Étape 1 : poser un filet de tests sur les parcours critiques

But : pouvoir modifier l'application sans craindre de casser ce qui compte. Concrètement : l'équipe écrit des tests automatisés qui rejouent vos parcours critiques (créer une commande, émettre une facture, produire un export, recevoir un flux partenaire) et vérifient le résultat. Ces tests tournent à chaque modification. Résultat attendu : chaque parcours de votre liste est couvert par au moins un test qui passe au vert sur la version actuelle. Sans elle, chaque palier suivant devient un pari.

Étape 2 : stabiliser en Symfony 4.4 et éliminer les dépréciations

But : partir d'une base propre. Concrètement : si l'application est en Symfony 4.0 à 4.3, on la monte d'abord en 4.4, la dernière version de la branche, qui demande PHP 7.1.3 au minimum selon sa page de version. On corrige ensuite toutes les dépréciations signalées par le framework. Résultat attendu : application en 4.4, tests au vert, liste des dépréciations vide, condition pour aborder sereinement la version majeure suivante.

Étape 3 : monter en Symfony 5.4, premier retour sous correctifs

But : remettre le framework sous correctifs de sécurité le plus tôt possible. Concrètement : Symfony 5.4 demande PHP 7.2.5 au minimum, ce qui permet souvent de franchir ce palier sans changer de version de PHP tout de suite (à condition d'être au moins en PHP 7.2.5). Sa fenêtre de sécurité court jusqu'en février 2029, grâce à une extension exceptionnelle qui ne reflète pas le régime normal des LTS. On répète ensuite le travail sur les dépréciations, cette fois celles de la branche 5. Résultat attendu : application en production sur Symfony 5.4. Le framework est de nouveau couvert ; PHP, lui, ne l'est pas encore, d'où l'étape suivante.

Pour accélérer les corrections répétitives d'une version à l'autre, la documentation Symfony cite Rector, un outil open source qui automatise une partie des mises à jour de code PHP. Il fait gagner du temps sur les modifications mécaniques, sans remplacer ni les tests ni la recette métier.

Étape 4 : passer PHP en version 8

But : remettre le langage lui-même sous correctifs. Concrètement : en restant sur Symfony 5.4, l'équipe adapte le code et les dépendances à PHP 8, puis l'hébergement bascule sur la nouvelle version. La version cible se choisit selon la compatibilité effective de votre code et de vos dépendances, vérifiée en test : la toute dernière version de PHP n'est pas forcément atteignable dès ce palier. Plus la version retenue est récente, plus sa fin de support est lointaine (31 décembre 2029 pour PHP 8.5). Monter PHP en plusieurs fois, au rythme des paliers Symfony suivants, reste possible. Résultat attendu : application en production sur une version de PHP supportée. Pour la première fois depuis des années, langage et framework reçoivent tous deux des correctifs.

Étape 5 : franchir Symfony 6.4

But : poursuivre vers la LTS actuelle. Concrètement : Symfony 6.4 demande PHP 8.1 au minimum, mais PHP 8.1 est en fin de vie depuis le 31 décembre 2025 : visez PHP 8.2 ou plus. Avec une sécurité assurée jusqu'en novembre 2027 seulement, c'est un palier de passage, pas une destination. Résultat attendu : application en production sur Symfony 6.4, dépréciations de la branche 6 traitées.

Étape 6 : atteindre Symfony 7.4, la LTS actuelle

But : s'installer durablement. Concrètement : Symfony 7.4 demande PHP 8.2 au minimum, selon sa page de version. Comme PHP 8.2 sort du support le 31 décembre 2026, c'est le bon moment pour viser une version plus récente si vos dépendances le permettent. Résultat attendu : application sur la LTS actuelle, corrigée jusqu'en novembre 2028 pour les bugs et jusqu'en novembre 2029 pour la sécurité. Pour la plupart des applications métier, c'est la destination.

Étape 7 (optionnelle) : aller jusqu'à Symfony 8

But : profiter des dernières fonctionnalités. Concrètement : Symfony 8 demande PHP 8.4 au minimum. La version actuelle, 8.1, est une version standard maintenue jusqu'à fin janvier 2027 : choisir Symfony 8 aujourd'hui, c'est s'engager à suivre une version mineure tous les six mois. D'après le processus de publication, la prochaine LTS, Symfony 8.4, est attendue en novembre 2027. Résultat attendu : application sur la dernière version, avec une maintenance régulière planifiée.

Vérification : à quoi reconnaît-on qu'une étape est réussie

Vous n'avez pas besoin de lire le code pour savoir si la migration avance bien. Chaque palier se valide sur des critères observables :

• Les tests automatisés passent au vert sur la nouvelle version, y compris ceux des parcours critiques.
• Aucune dépréciation bloquante ne reste pour le palier suivant.
• La recette métier est validée par votre interlocuteur, sur les parcours qu'il a lui-même listés.
• La mise en production s'est faite sans incident, et l'application tourne normalement depuis plusieurs jours.
• L'écart avec les versions supportées s'est réduit : une échéance peut se rapprocher en chemin (novembre 2027 pour Symfony 6.4, contre février 2029 pour 5.4 grâce à son extension exceptionnelle), ce qui compte est la date atteinte à l'arrivée, novembre 2029 pour Symfony 7.4.

En point d'avancement, trois questions suffisent : sur quel palier sommes-nous en production aujourd'hui, qu'est-ce qui bloque le palier suivant, et quelle est la nouvelle date de fin de support de l'ensemble (la plus proche entre celle de PHP et celle de Symfony) ? Cette date peut se rapprocher au passage de Symfony 6.4 ; en revanche, si aucun palier n'est franchi au fil des mois, quelque chose ne va pas.

Ce qui fait varier le coût et le délai

Deux applications en Symfony 4 peuvent demander des efforts très différents. Le premier facteur est la taille et l'âge du code, puis la couverture de tests : une application sans aucun test oblige à construire le filet avant de commencer. Viennent ensuite les dépendances abandonnées, qu'il faut remplacer plutôt que mettre à jour, et la part de code spécifique qui contourne le framework au lieu de s'appuyer sur lui.

L'écart de versions compte évidemment : partir de Symfony 4.1 sur PHP 7.1 n'est pas partir de 4.4 sur PHP 7.4. Le front et ses outils, l'hébergement (une montée de PHP peut imposer de changer de serveur ou d'offre), la disponibilité du métier pour les recettes et les évolutions menées en parallèle pèsent aussi sur le calendrier. C'est pourquoi aucun chiffrage sérieux ne se fait à l'aveugle : il devient fiable une fois l'audit réalisé.

Rester à jour après la migration

Une fois sur Symfony 7.4, le plus dur est fait. Le rythme de Symfony est régulier : une version mineure tous les six mois, une LTS tous les deux ans. Suivre ce rythme au fil de l'eau, dans le cadre d'une maintenance applicative continue, coûte bien moins cher que de rattraper cinq ans de retard d'un coup. Les montées de version mineure sont décrites dans le guide officiel de Symfony et restent des opérations de routine quand elles sont faites régulièrement.