Migrer un projet Symfony legacy de PHP 7.4 à PHP 8.1

Pourquoi migrer

PHP 7.4 est en fin de vie depuis longtemps : plus de correctifs de sécurité, plus de support officiel. Sur un projet backend critique tournant sur OpenShift, rester dessus n'était plus tenable, ni côté sécurité, ni côté performance.

Les points de friction principaux

Typage strict et signatures de méthodes

PHP 8 est nettement plus strict sur la cohérence des types entre classes parentes et enfants. Plusieurs services legacy avaient des signatures incohérentes qui passaient silencieusement en 7.4 mais levaient des erreurs fatales en 8.1.

Dépréciations de fonctions

Certaines fonctions historiques (create_function, certains usages de each()) ont été supprimées. Un audit statique du code avec PHPStan en amont permet de lister ces cas avant même de changer la version d'exécution.

Nullable types implicites

PHP 8.1 interdit les paramètres nullable implicites sans déclaration explicite ?type. C'est le genre de warning silencieux en 7.4 qui devient bloquant en 8.1 — un bon test suite CI est indispensable pour les détecter tous.

Stratégie de migration retenue

Audit statique complet avec PHPStan niveau élevé pour lister les incompatibilités avant de toucher à l'environnement d'exécution
Montée de version des dépendances Composer en parallèle, package par package, en vérifiant la compatibilité PHP 8.1 de chaque librairie tierce
Environnement de test dédié sur OpenShift avec la nouvelle version, pipeline Jenkins dupliqué pour valider avant bascule
Bascule progressive avec possibilité de rollback rapide sur l'ancienne image de build

Ce qui a le plus surpris

Le vrai coût n'était pas le changement de version PHP lui-même, mais la dette technique qu'il a fallu affronter en même temps : du code qui fonctionnait "par accident" en 7.4 et qui a nécessité une vraie clarification des contrats entre classes.

À retenir

Une migration de version PHP majeure n'est jamais juste une histoire de changer un numéro dans un fichier de config. C'est l'occasion de forcer une remise à niveau de la qualité du code — mieux vaut la voir comme un projet à part entière plutôt qu'une simple tâche technique.