Le 28 novembre 2022, PHP 7.4 est officiellement sorti de sa période de support, plus aucun correctif de sécurité n’étant produit depuis cette date. C’est ce repère précis qui a servi de point de départ à l’audit mené sur une plateforme de mise en relation entre artisans et particuliers, dont l’API REST headless tournait encore sur cette version depuis sa mise en ligne initiale, plusieurs années plus tôt.
Le rôle confié au chef de projet technique n’était pas de faire la montée de version lui-même, mais de produire un audit complet permettant de planifier l’opération sans mauvaise surprise : quelles extensions actives, quelles fonctions dépréciées utilisées dans le code métier, et surtout, quel impact potentiel sur le front qui consommait l’API depuis un serveur distinct.
Pourquoi cet audit était devenu urgent
Le projet fonctionnait sans incident apparent, ce qui rendait la demande difficile à justifier auprès de la direction : « si rien n’est cassé, pourquoi migrer ? ». L’argument retenu n’était pas la performance, marginale entre PHP 7.4 et une version plus récente sur ce projet précis, mais l’absence totale de correctif de sécurité depuis la fin de vie annoncée, un risque grandissant à mesure que des vulnérabilités seraient découvertes sans jamais être corrigées côté langage.
Le périmètre de l’audit
L’audit a commencé par un inventaire complet des dix-sept extensions actives sur le site, avec pour chacune la vérification de sa compatibilité annoncée avec PHP 8.0 et 8.1 sur le répertoire officiel des extensions WordPress. Trois extensions se sont révélées problématiques : deux n’avaient pas été mises à jour depuis plus de deux ans, la troisième signalait explicitement une incompatibilité avec PHP 8.
Le code métier propre au projet a ensuite été passé au crible avec l’outil PHP_CodeSniffer configuré avec le standard WordPress-Compat, qui repère les fonctions dépréciées ou supprimées entre versions de PHP. L’audit a relevé plusieurs usages de la fonction create_function(), définitivement supprimée en PHP 8.0, ainsi que des appels à des fonctions de tableau avec un ordre d’arguments qui devenait strictement typé dans les versions récentes.
vendor/bin/phpcs --standard=PHPCompatibilityWP \
--runtime-set testVersion 8.1 \
wp-content/plugins/artisans-api/Ce que le front a simplifié
Un point a nettement facilité l’audit : le front, développé séparément en Vue.js et hébergé sur une infrastructure distincte, ne connaissait absolument rien de la version de PHP utilisée côté WordPress. Il consommait l’API REST via des requêtes HTTP classiques, sans dépendance directe au runtime PHP. La montée de version pouvait donc, en théorie, se faire sans coordination avec l’équipe front, à condition que les réponses de l’API restent identiques en structure.
Les points de vigilance identifiés
- Trois extensions à remplacer ou à mettre à jour avant toute bascule
- Six occurrences de
create_function()à réécrire en fonctions anonymes classiques - Un endpoint personnalisé qui reposait sur un comportement implicite de tri de tableau, modifié entre PHP 7 et PHP 8
- Un environnement de préproduction à créer, absent jusque-là du projet
Un audit avant une montée de version majeure de PHP ne sert pas à rassurer, il sert à transformer une inconnue en liste de tâches. Une liste qui fait peur au premier regard est toujours préférable à une bascule en production sans elle.
Ce que cet audit n’a pas traité
La sécurité globale du projet, au-delà de la seule question de la fin de vie de PHP 7.4, n’entrait pas dans le périmètre de cette mission. L’audit s’est volontairement concentré sur la compatibilité technique de la montée de version, laissant à un travail distinct l’examen plus large des pratiques de sécurité de l’application, jugé hors sujet pour cette étape précise.
Le bilan de l’audit
Le document remis à la direction listait dix-sept extensions vérifiées, six corrections de code nécessaires et une estimation de deux semaines de travail avant une bascule vers PHP 8.1. La direction, convaincue par le repère de fin de vie officielle plutôt que par un argument de performance, a validé le calendrier proposé sans négociation supplémentaire.
En résumé
Un audit avant montée de version PHP sur un projet headless gagne à séparer clairement ce qui touche au code métier de ce qui touche au front consommateur de l’API. Dans ce cas précis, la séparation stricte entre les deux couches a nettement réduit le risque perçu de l’opération, le front n’ayant jamais eu besoin de connaître le détail de la version de PHP tournant côté serveur.
