Fin de support PHP en 2026 : méthode d'audit et plan de montée de version

Vous héritez d'applications PHP qui n'avancent pas au même rythme et devez présenter une trajectoire crédible à votre direction. La bonne réponse n'est pas de lancer partout une mise à niveau identique. Il faut d'abord établir ce qui s'exécute réellement, distinguer la fin du support actif de la fin de vie complète (le détail des branches figure dans notre panorama de PHP en 2026), puis transformer ce constat en lots de travail, en risques explicites et en décisions arbitrables.

Le calendrier de support PHP donne le cadre de priorité. Il ne remplace ni l'analyse de l'exposition d'une application, ni l'étude de ses dépendances, ni la vérification de sa capacité de recette. Un parc se traite comme un portefeuille : une application sous une branche encore couverte par des correctifs de sécurité n'appelle pas la même décision qu'une application sous une branche sortie de support complet. Sur une application Symfony, cette phase recoupe la démarche décrite dans notre guide audit et reprise de code Symfony.

Le calendrier PHP fixe l'urgence, pas le périmètre des travaux

Le premier livrable d'un audit doit être lisible par une direction non spécialiste : une vue du parc confrontée au cycle de support officiel. PHP applique une règle claire : chaque branche reçoit du support actif, puis du support de sécurité uniquement, avant sa fin de vie complète. Cette distinction est essentielle, car elle évite deux erreurs fréquentes : présenter toute version qui n'est plus activement maintenue comme une crise immédiate, ou considérer qu'un support de sécurité est une autorisation de différer indéfiniment le travail.

Au moment de l'audit, PHP 8.5 est la branche qui offre l'horizon de support le plus long. PHP 8.4 reste en support actif jusqu'au 31 décembre 2026, puis en support de sécurité jusqu'au 31 décembre 2028. PHP 8.3 n'est plus en support actif, mais reste couverte en sécurité jusqu'au 31 décembre 2027. PHP 8.2 ne reçoit plus que du support de sécurité, jusqu'au 31 décembre 2026. PHP 8.1 n'apparaît plus dans le tableau des versions prises en charge : elle est en fin de vie complète et ne doit plus être utilisée en production.

Cette lecture doit être associée à une source explicite dans le dossier de décision : https://www.php.net/supported-versions.php. Elle donne à la direction un repère objectif, mais elle ne dit pas encore quelle application traiter en premier. Une vitrine très exposée sous PHP 8.2 peut exiger une action avant un outil interne sous PHP 8.1, si cet outil est isolé, bientôt retiré et sans données sensibles. À l'inverse, l'absence de support de PHP 8.1 doit faire l'objet d'une décision formelle, même si le risque opérationnel semble faible.

Le calendrier sert donc à définir une obligation de décision. Pour chaque application, l'équipe doit pouvoir dire si elle sera montée de version, remplacée, retirée ou temporairement maintenue sous dérogation. Une simple ligne indiquant la version PHP n'est pas un plan ; c'est le début du problème.

Construire un inventaire qui reflète l'exécution réelle

Les inventaires issus d'un tableur, d'un outil de gestion de parc ou de la mémoire des équipes sont souvent incomplets. La version déclarée dans un dépôt peut différer de celle du conteneur livré. La version de l'interpréteur accessible en ligne de commande peut également ne pas être celle qui traite les requêtes web. L'audit doit donc privilégier la preuve d'exécution : image déployée, configuration de l'environnement, journal de livraison, manifeste de dépendances et résultat des contrôles réalisés dans le contexte pertinent.

Créez une fiche homogène par application. Son objectif n'est pas de documenter toute l'architecture, mais de permettre une décision de priorité et une estimation de travail. La fiche doit rester consultable, attribuée à un responsable et reliée à une preuve technique. Sans cette discipline, le portefeuille devient rapidement un assemblage de déclarations incompatibles.

• Service et périmètre métier : identifiez ce que l'application rend comme service, ses utilisateurs, ses interfaces et les conséquences d'une indisponibilité.
• Runtime PHP observé : consignez la branche constatée dans l'environnement réellement exécuté, ainsi que le mode de déploiement qui la fournit.
• Dépendances : relevez le fichier Composer, le verrouillage effectif, les extensions PHP requises et les bibliothèques qui contraignent une montée de version.
• Socle applicatif : notez le framework, sa branche de maintenance, les composants structurants et les conventions de code qui pèsent sur la migration.
• Qualité de validation : qualifiez les tests disponibles, les jeux de données utilisables, les parcours métier contrôlables et la capacité de retour arrière.
• Exposition : décrivez l'accès public ou interne, les données traitées, les échanges externes et les mécanismes d'authentification.
• Responsabilité : désignez l'équipe capable de décider, de corriger et de valider, sans supposer qu'un dépôt possède encore un mainteneur actif.

Les premières commandes de collecte ne résolvent pas l'audit, mais elles évitent de démarrer sur des hypothèses. Exécutez-les dans les dépôts et les environnements où les outils sont installés et configurés. Archivez le résultat avec la fiche concernée, plutôt que de recopier manuellement une version dans un tableau.

php -v
composer check-platform-reqs
composer show --direct
composer outdated --direct
vendor/bin/phpstan analyse
vendor/bin/phpcs
vendor/bin/rector process --dry-run

composer check-platform-reqs confronte les exigences de plateforme déclarées par les dépendances à l'environnement disponible. Il ne prouve pas que tous les parcours fonctionnent, mais il révèle rapidement une incompatibilité de runtime ou d'extension. composer show --direct et composer outdated --direct donnent une première lecture des dépendances directement assumées par le projet. Les outils d'analyse statique et de style servent, eux, à rendre visible le volume de diagnostics et à identifier les zones qui nécessiteront une revue humaine.

Ne réduisez pas l'inventaire à Composer. Une extension installée hors du projet, une variable de plateforme, une tâche planifiée ou un script de maintenance peuvent empêcher une bascule alors que l'application web semble compatible. Le bon inventaire inclut donc les processus asynchrones, les commandes d'administration et les interfaces de déploiement. C'est souvent là que se cachent les écarts entre une recette rassurante et une mise en production fragile.

Mesurer le risque applicatif plutôt que classer par version seule

Une colonne intitulée version PHP ne mesure pas le risque réel. Elle mesure une partie du risque de support. Pour prioriser correctement, associez ce statut à l'exposition de l'application, à l'importance de ses flux, à la difficulté prévisible du changement et à sa capacité de récupération. Cette approche permet d'expliquer pourquoi deux applications sur la même branche ne reçoivent pas forcément la même priorité.

Le risque de support est simple à qualifier : PHP 8.1 correspond à une absence complète de support ; PHP 8.2 et PHP 8.3 restent sous couverture de sécurité, mais n'ont plus de support actif ; PHP 8.4 demeure encore dans sa phase active ; PHP 8.5 offre la meilleure fenêtre connue dans le calendrier fourni. Le risque de service est différent : il dépend de ce que l'application porte réellement, de son exposition et de la qualité des garde-fous qui l'entourent.

• Exposition externe : un service accessible depuis l'extérieur, ou relié à des partenaires, doit être considéré avec plus d'attention qu'un outil strictement isolé.
• Sensibilité fonctionnelle : les traitements qui portent des données sensibles ou un processus métier critique augmentent l'enjeu d'une absence de correctif.
• Surface de changement : un code ancien, des dépendances abandonnées, des extensions spécifiques ou des intégrations peu documentées rendent l'effort moins prévisible.
• Capacité de validation : des tests exécutables, une recette métier disponible et un retour arrière praticable réduisent le risque de livraison.
• Maintenabilité : l'absence de responsable, de documentation utile ou de chaîne de livraison fiable transforme une migration simple en opération de remise sous contrôle.

Une matrice qualitative est préférable à un score artificiellement précis. Classez les applications selon des niveaux compréhensibles, par exemple action immédiate, migration planifiée, surveillance avec échéance ou retrait à confirmer. Chaque classement doit contenir une justification courte. Une direction ne finance pas une couleur dans un tableau ; elle arbitre un risque documenté, un service rendu et une trajectoire proposée.

Pour les applications totalement sorties de support, ne laissez pas la décision implicite. Si une montée immédiate est impossible, formalisez une dérogation : raison du report, périmètre exposé, mesures compensatoires disponibles, responsable de l'acceptation du risque et condition de sortie. Cette dérogation ne rend pas PHP 8.1 acceptable en production ; elle rend le risque visible et attribué pendant qu'une solution est préparée.

Le même principe vaut pour les branches en support de sécurité uniquement. PHP 8.3 reste couverte jusqu'au 31 décembre 2027, ce qui laisse une fenêtre de préparation, mais son support actif est terminé. PHP 8.2 reste couverte jusqu'au 31 décembre 2026, dans un horizon proche au moment de l'audit. Ces applications doivent apparaître dans le plan avec une échéance interne antérieure à la fin de couverture, afin de conserver du temps pour les imprévus et les validations métier.

Le résultat attendu est une carte de risque exploitable : elle ne prétend pas prédire toutes les régressions, mais elle rend explicites les hypothèses. Une application sans tests n'est pas seulement un sujet de qualité ; elle devient un facteur de coût et de risque pour toute montée de version. Une application dont le retrait est crédible n'est pas nécessairement un candidat à la modernisation : elle peut être un candidat à la suppression de dette.

Prioriser le portefeuille sans confondre urgence et précipitation

Une fois le risque qualifié, ordonnez les travaux en fonction de la décision la plus rationnelle pour chaque application. La priorité n'est pas toujours la modernisation complète. Certains services doivent être retirés, consolidés ou remplacés. D'autres peuvent être sécurisés par une montée ciblée vers une branche compatible avec leur framework et leurs dépendances, avant d'envisager un chantier plus large. Le choix de la branche cible du framework obéit a la même logique de calendrier, détaillée dans notre guide migrer vers Symfony 8 ou rester en LTS.

Le premier groupe rassemble les applications sous PHP 8.1 encore exposées ou importantes pour l'activité. Elles nécessitent une décision de remédiation immédiate, car leur runtime est sorti de support complet. Le deuxième groupe concerne les applications sous PHP 8.2 dont l'exposition, la valeur métier ou la complexité justifie de préparer le travail sans attendre la fin de leur support de sécurité. Les applications sous PHP 8.3 doivent être placées sur une trajectoire de migration assumée : elles ne sont pas abandonnées, mais elles ne doivent pas devenir le prochain héritage à risque.

PHP 8.4 mérite une lecture plus nuancée. Elle est encore en support actif jusqu'au 31 décembre 2026, mais cet horizon est proche. Pour une application stable, bien testée et difficile à faire évoluer, une montée vers PHP 8.4 peut parfois être une étape cohérente si elle débloque un problème immédiat. Pour une application déjà prête, viser PHP 8.5 réduit le risque de recommencer prochainement le même chantier. Le choix dépend moins d'une préférence technique que de la capacité réelle à absorber le changement.

Le framework peut verrouiller ou simplifier cette décision. Symfony 8.x exige PHP 8.4.0 au minimum, Symfony 7.x exige PHP 8.2.0 au minimum et Symfony 6.4 exige PHP 8.1.0 au minimum. Symfony 8.1 est la version stable courante ; Symfony 7.4 est la LTS courante ; Symfony 6.4 reste une LTS prise en charge. Symfony 8.0 est déjà non maintenue. Ces éléments viennent éclairer les contraintes de socle, mais ne dispensent jamais de vérifier les dépendances concrètes de chaque projet. La page de référence est https://symfony.com/releases.

Présentez la feuille de route sous forme de vagues de décision, pas comme une liste de dépôts à convertir. Chaque vague doit regrouper des applications ayant un objectif de risque commun et des dépendances de livraison compatibles. Évitez de concentrer dans la même période des applications à forte incertitude métier, des changements de plateforme et une refonte de framework. Cela donne l'illusion d'un programme ambitieux, mais rend les retards impossibles à isoler.

Un portefeuille priorisé doit aussi protéger la capacité de l'équipe. Réserver du temps pour les correctifs apparus pendant les recettes, les mises à jour de dépendances et la documentation est une condition de crédibilité. Une direction acceptera plus facilement une trajectoire qui expose ses incertitudes qu'un calendrier apparemment exact, incapable d'absorber le premier écart.

Découper l'effort pour produire une estimation défendable

Chiffrer une montée de version comme une simple modification de l'image PHP est une erreur de pilotage. Le runtime n'est qu'une couche. L'effort doit être découpé en unités de travail dont les hypothèses et les critères d'acceptation sont visibles. Cette méthode permet de distinguer ce qui est connu, ce qui doit être investigué et ce qui relève d'un arbitrage produit ou métier.

Commencez par un lot de découverte. Il sert à faire tourner l'application sur le runtime cible, à exécuter les vérifications de plateforme, à analyser les dépendances et à établir les premiers écarts. Ce lot n'est pas du temps perdu avant le travail réel : il produit les informations nécessaires pour que l'estimation suivante soit honnête. Il doit se conclure par une décision sur la cible, les incompatibilités observées et les options de traitement.

• Plateforme d'exécution : adaptez l'image, les extensions, la configuration de service, les tâches planifiées et les mécanismes de livraison.
• Dépendances : mettez à jour les bibliothèques nécessaires, traitez les contraintes de versions et vérifiez les exigences de plateforme déclarées.
• Code applicatif : corrigez les incompatibilités détectées, les usages obsolètes et les conventions qui empêchent l'analyse ou les tests.
• Contrats externes : rejouez les échanges avec les services tiers, les flux asynchrones, les imports, les exports et les tâches d'administration.
• Validation métier : préparez les parcours de recette, les données nécessaires, les critères de succès et la décision de mise en production.
• Exploitation : vérifiez l'observabilité, les procédures de retour arrière, les alertes pertinentes et la documentation d'exploitation.

Pour chaque lot, formulez l'estimation sous forme d'une plage de charge liée à un niveau de confiance, sans transformer une hypothèse en engagement ferme. La plage dépend de preuves disponibles : tests qui passent sur le runtime cible, dépendances compatibles, environnement reproductible, accès aux experts métier et capacité à déployer sans interruption excessive. Si ces preuves manquent, l'incertitude doit apparaître comme une ligne de travail distincte, pas être absorbée silencieusement dans une estimation globale.

Le dossier destiné à la direction doit séparer l'effort de remédiation du coût d'inaction. Le premier comprend les lots techniques et de validation. Le second décrit le statut de support, l'exposition, les conséquences possibles d'un défaut de correction et la difficulté croissante à trouver une trajectoire de compatibilité. Cette séparation évite un débat stérile entre une équipe qui parle de versions et une direction qui demande pourquoi le travail ne peut pas être reporté.

Ajoutez des critères de sortie concrets. Une application n'est pas considérée comme traitée parce qu'une demande de changement a été fermée. Elle l'est lorsque le runtime cible est déployé, que les dépendances sont verrouillées de manière cohérente, que les contrôles automatisés et métier convenus ont été exécutés, que le retour arrière est connu et que la fiche de parc a été mise à jour. La définition de terminé protège le programme contre les migrations seulement déclaratives.

Enfin, ne mélangez pas dans le même chiffre la remise en support et la modernisation souhaitable. Passer sur une branche supportée est un objectif de réduction du risque. Remplacer une architecture, revoir une interface ou modifier un processus métier peut être utile, mais ce sont des décisions séparées. Les regrouper sans le dire gonfle le périmètre, ralentit la remédiation et rend le financement plus difficile à défendre.

Préparer les montées de version par des preuves de compatibilité

Le travail de préparation doit produire des signaux exploitables avant d'engager une bascule. Une analyse statique, une installation des dépendances sur le runtime cible et une exécution de tests ne remplacent pas une recette métier, mais elles réduisent l'espace d'incertitude. L'objectif est de savoir où l'équipe devra réellement intervenir et où le changement relève uniquement du socle de livraison.

PHP 8.5 apporte notamment l'opérateur pipe |>. La valeur placée à gauche est transmise comme argument unique au callable situé à droite. Cette fonctionnalité peut améliorer la lisibilité de certaines transformations, mais elle ne constitue pas un motif de migration à elle seule. Dans un audit de parc, elle sert surtout à rappeler qu'une cible de runtime se valide par l'exécution et non par une lecture superficielle du code.

$email = "  User@Example.com  "
    |> trim(...)
    |> strtolower(...);

$slug = $email
    |> (fn(string $value) => str_replace(' ', '-', $value));

Une arrow function utilisée dans un pipeline doit être parenthésée. Le callable placé à droite doit accepter un seul paramètre. La documentation officielle de l'opérateur fonctionnel est disponible à l'adresse https://www.php.net/manual/fr/language.operators.functional.php. Une présentation complémentaire figure sur https://php.watch/versions/8.5/pipe-operator.

PHP 8.5 introduit aussi clone with, l'attribut #[\NoDiscard] et la fonction get_error_handler(). Ces évolutions peuvent être utiles dans un code qui adopte cette branche, notamment pour les objets immuables, les retours qui ne doivent pas être ignorés ou l'inspection du gestionnaire d'erreurs. Elles ne doivent pas transformer un chantier de remédiation en programme de réécriture. La règle saine est de séparer ce qui est requis pour atteindre une branche supportée de ce qui relève d'une amélioration opportuniste.

Établissez une chaîne de preuve adaptée à chaque application : installation reproductible, analyse des exigences de plateforme, analyse statique, tests disponibles, recette des flux sensibles, déploiement sur un environnement représentatif et préparation du retour arrière. Lorsque l'un de ces éléments est absent, le risque ne disparaît pas ; il doit être inscrit dans le lot de travail. Une migration sans environnement reproductible est avant tout un chantier de fiabilisation de livraison.

Les outils ne donnent pas un verdict magique. PHPStan peut remonter des incohérences de types ou de contrats, PHP_CodeSniffer peut rendre visibles les écarts de conventions, Rector peut proposer des transformations et Composer peut révéler des contraintes de dépendances. Leur valeur réside dans la répétabilité : ils transforment un diagnostic manuel difficilement comparable en éléments que l'équipe peut rejouer, examiner et suivre dans le temps. Notre méthode de refactorisation d'un projet PHP legacy détaille l'usage de ces outils.

Installer une gouvernance qui empêche le retour de la dette

Un programme de montée de version échoue lorsqu'il se limite à un effort ponctuel. Dès que l'urgence s'éloigne, les applications moins visibles sortent du radar, les dépendances vieillissent et les images de runtime restent figées. La sortie durable consiste à intégrer le statut de support dans la gestion normale du parc, au même titre que la disponibilité, les incidents ou la sécurité.

Conservez un registre vivant des applications avec leur runtime observé, leur cible, leur statut de support, leur responsable, leur niveau de risque et leur prochaine décision attendue. Ce registre doit être revu dans les instances qui arbitrent réellement la capacité des équipes. S'il demeure dans un document technique non consulté, il ne réduit aucun risque.

La chaîne de livraison doit également rendre visibles les écarts. Une application qui déclare une plateforme incompatible avec sa cible, qui ne peut plus installer ses dépendances ou qui ne passe plus ses contrôles doit produire un signal actionnable. L'objectif n'est pas de bloquer toute livraison sur le moindre diagnostic ; c'est d'empêcher qu'une incompatibilité connue reste invisible jusqu'au prochain changement majeur.

Définissez une politique de cible par famille applicative. Elle indique quelle branche PHP est admise pour une nouvelle application, quelle branche est tolérée temporairement pour une application existante et quelles conditions déclenchent une migration ou un retrait. La politique doit s'appuyer sur le calendrier de support officiel et sur la compatibilité du socle réellement utilisé. Elle ne doit pas être une règle abstraite que les équipes contournent faute de capacité.

Traitez les dérogations comme des objets de gouvernance temporaires. Une dérogation doit porter un propriétaire, une justification, des mesures de réduction d'exposition et une sortie attendue. Son rôle est d'éviter que le risque se cache derrière un mot comme historique ou complexe. Lorsqu'une application ne peut plus être maintenue de manière raisonnable, le retrait ou le remplacement doit redevenir une option explicite dans le portefeuille.

Le plan défendable est donc celui qui relie chaque décision à une preuve : statut de support vérifié, exposition documentée, dépendances observées, capacité de validation connue, lots estimés et responsable identifié. La direction obtient une lecture du risque et des arbitrages à rendre. L'équipe obtient un ordre de travail réaliste, qui évite de traiter indistinctement toutes les versions PHP comme si elles portaient la même urgence.

Références de support PHP : https://www.php.net/supported-versions.php. Références des versions Symfony : https://symfony.com/releases.