Montée de version Symfony : comment planifier sans risque ?
Cycle LTS, deprecation notices, Rector PHP, PHPStan et tests de non-regression : la méthode pour migrer Symfony sans casser votre application.
Nos clients types
Votre application Symfony 5.4 arrive en fin de support LTS. Votre application Symfony 4.4 est déjà hors support depuis 2023. Votre application Symfony 3.4 est un risque de sécurité majeur. Quelle que soit votre situation, la montée de version Symfony est une opération technique inevitable que chaque equipe PHP doit planifier régulièrement. Bien préparée, elle se deroule en 5 a 15 jours sans incident. Mal préparée, elle devient un cauchemar de regressions, de bundles incompatibles et de déploiements annules. Voici la méthode que nous appliquons chez Nehos pour migrer Symfony en toute sécurité, testee sur plus de 40 projets en production.
#Comprendre le cycle de release Symfony : LTS, standard et end-of-life
Symfony suit un calendrier de release extrêmement prévisible, ce qui en fait l'un des frameworks les plus faciles a planifier en termes de montées de version. Une version mineure sort tous les 6 mois (en mai et en novembre). Une version majeure sort tous les 2 ans. La dernière version mineure de chaque cycle majeur (x.4) est désignée comme version LTS et reçoit des correctifs de sécurité pendant 4 ans. Concrètement, voici la timeline des versions LTS récentes : Symfony 3.4 LTS sorti en novembre 2017 avec un end-of-life en novembre 2021, Symfony 4.4 LTS sorti en novembre 2019 avec un end-of-life en novembre 2023, Symfony 5.4 LTS sorti en novembre 2021 avec un end-of-life en novembre 2025, Symfony 6.4 LTS sorti en novembre 2023 avec un end-of-life en novembre 2027, et Symfony 7.x (la version actuelle) avec un support actif. Si votre application tourne sur une version dont le support est termine, vous ne recevez plus de correctifs de sécurité. Chaque CVE découverte dans le framework reste non corrigée sur votre installation. C'est un risque que nous identifions systématiquement lors de nos audits de reprise et qui justifie a lui seul une montée de version.
#Étape 1 : corriger toutes les deprecation notices
La force du processus de migration Symfony repose sur les deprecation notices. Symfony ne casse jamais une fonctionnalité sans l'avoir d'abord marquee comme depreciated dans la version précédente. Concrètement, si vous êtes en Symfony 5.4 et que vous souhaitez monter en 6.x, toutes les deprecation notices de la version 5.4 correspondent a des fonctionnalités qui seront supprimées en 6.0. La méthode est donc simple : résolvez toutes les deprecation notices en 5.4, puis la montée en 6.0 se fera sans rupture de compatibilité. Pour identifier les deprecation notices, utilisez le Profiler Symfony en environnement de dev et parcourez les flux critiques de votre application. Le panneau Deprecations du Profiler liste chaque appel deprecated avec le fichier, la ligne et le message de remplacement. Vous pouvez aussi activer le logger de deprecations en production (avec un sampling de 1%) pour capturer les deprecations qui n'apparaissent que dans des conditions réelles d'utilisation. L'objectif est d'atteindre zero deprecation notice avant de tenter la montée de version. Chaque deprecation non corrigée est une bombe a retardement qui explosera en erreur fatale après la migration.
#Étape 2 : automatiser les refactorings avec Rector PHP
Rector PHP est l'outil qui transforme les montées de version Symfony d'un cauchemar manuel en une opération largement automatisée. Rector est un outil de refactoring automatique qui analyse votre code source et applique des règles de transformation prédéfinies. Pour une migration Symfony, Rector propose des sets de règles spécifiques à chaque version. Par exemple, le set symfony64 corrige automatiquement les deprecations entre Symfony 5.4 et 6.4 : remplacement des classes renommées, mise à jour des signatures de méthodes, adaptation des configurations YAML vers les nouvelles syntaxes. L'installation est simple via Composer et la configuration se fait dans un fichier rector.php a la racine du projet. Nous recommandons de lancer Rector en mode dry-run d'abord pour previsualiser les changements, puis de valider chaque transformation avant de l'appliquer. Rector ne couvre pas 100% des cas : les modifications de logique métier, les adaptations de templates Twig et les refactorings de tests doivent être faits manuellement. Mais il automatise généralement 60 a 80% du travail, ce qui réduit considérablement le temps de migration. Chez Nehos, nous utilisons Rector sur chaque migration Symfony et nous maintenons un jeu de règles custom pour les patterns récurrents dans nos projets clients.
#Étape 3 : valider avec PHPStan au niveau 6 minimum
Après avoir corrige les deprecations et applique Rector, l'étape suivante est une analyse statique rigoureuse avec PHPStan. PHPStan analyse votre code PHP sans l'executer et detecte les erreurs de type, les appels a des méthodes inexistantes, les variables non définies et les incohérences logiques. Nous exigeons un passage au niveau 6 minimum (sur une échelle de 0 à 9) pour valider une migration. Le niveau 6 verifie les types de retour des méthodes, les types des parametres, les appels de méthodes sur des types potentiellement null et les accès à des propriétés inexistantes. C'est le niveau ou PHPStan detecte les problèmes que l'exécution en dev ne revele pas mais qui causeront des erreurs en production sur des cas d'utilisation marginaux. La demarche pratique consiste a installer PHPStan avec l'extension Symfony (phpstan-symfony) qui comprend le conteneur de services, a configurer le fichier phpstan.neon avec les chemins a analyser, puis a lancer l'analyse et corriger les erreurs par ordre de sévérité. Sur une application de 50 000 lignes de code, une première analyse PHPStan au niveau 6 revele généralement entre 200 et 800 erreurs. C'est normal et ne doit pas décourager. La majorité des erreurs sont des types manquants ou des null checks absents qui se corrigent rapidement.
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
#Étape 4 : tests de non-regression sur les flux critiques
→ Pour aller plus loin : découvrez nos outils gratuits — calculateurs ROI, diagnostics techniques et quiz interactifs pour affiner votre réflexion.
Les tests automatises sont votre filet de sécurité ultime lors d'une montée de version. Sans tests, vous ne pouvez pas savoir si la migration a introduit une regression tant que vos utilisateurs ne l'ont pas constatée en production. La stratégie de test pour une migration se concentre sur les flux critiques métier : le parcours d'authentification (login, registration, password reset), les flux transactionnels (commande, paiement, facturation), les intégrations API tierces (passerelles de paiement, ERP, CRM) et les exports de données et rapports. Pour chaque flux critique, nous écrivons ou complétons des tests fonctionnels avec PHPUnit et le WebTestCase de Symfony qui simulent un parcours utilisateur complet et vérifient les codes HTTP, les redirections, les contenus de réponse et les états de la base de données. Si l'application n'a aucun test avant la migration (ce qui est malheureusement frequent), nous recommandons d'écrire au minimum les tests des 10 flux les plus critiques avant de commencer la migration. Cet investissement de 2 à 3 jours evite des jours de debug post-migration. Les tests doivent passer en vert sur la version actuelle avant la migration, puis être re-executes sur la nouvelle version pour valider l'absence de regression.
#Étape 5 : Symfony Flex et la modernisation de la structure du projet
Symfony Flex a transforme la structure des projets Symfony à partir de la version 4.0. Si votre application est antérieure a Symfony 4 ou si elle n'a jamais été migrée vers la structure Flex, cette étape est nécessaire. Flex remplace le système de bundles par des recipes qui configurent automatiquement les packages, impose une structure de repertoires standardisée (src/, config/, templates/, public/) et simplifie la configuration avec des fichiers YAML dans config/packages/. La migration vers Flex peut être faite avant ou pendant la montée de version majeure. Notre recommandation est de la faire avant, sur la version stable actuelle, pour isoler les deux types de changements. Les points de friction les plus frequents lors de la migration Flex sont la réorganisation des fichiers de configuration (passage de app/config/ a config/), le remplacement du AppKernel par le Kernel Flex, la migration des parametres de services.yml vers services.yaml avec l'autowiring et l'autoconfigure et la mise à jour du front controller web/app.php vers public/index.php. Chacun de ces changements est documente dans le guide officiel de migration Symfony et peut être teste indépendamment.
#Planning type d'une montée de version Symfony
Voici un planning réaliste pour une montée de version majeure (par exemple Symfony 5.4 vers 6.4) sur une application de taille moyenne (30 000 a 80 000 lignes de code). Le jour 1 est consacre a l'inventaire des deprecation notices et a l'estimation du volume de travail. Les jours 2 a 4 sont dédiés à la correction des deprecations et a l'application de Rector. Le jour 5 est reserve a l'analyse PHPStan et a la correction des erreurs détectées. Les jours 6 a 7 sont consacres a la montée de version effective (composer update) et a la resolution des incompatibilités. Les jours 8 a 10 sont dédiés à l'exécution des tests de non-regression et a la correction des regressions. Les jours 11 a 12 sont reserves au déploiement en staging, aux tests manuels et a la validation métier. Le jour 13 est le déploiement en production avec monitoring renforce. Ce planning suppose une application avec une couverture de tests existante raisonnable. Sans tests, ajoutez 3 a 5 jours pour écrire les tests des flux critiques en amont de la migration.
#Conclusion : la montée de version est un investissement, pas un coût
Reporter une montée de version Symfony est une économie de court terme qui se transforme en dette technique coûteuse. Chaque version ignorée augmente l'écart a rattraper et le risque de regression lors de la migration. Notre recommandation : planifiez une montée de version mineure tous les 6 mois et une montée de version majeure tous les 2 ans, en suivant le cycle LTS de Symfony. C'est exactement ce que nos contrats TMA couvrent dans le volet maintenance preventive.
Questions frequentes : montée de version Symfony
Une montée de version mineure (par exemple 6.3 vers 6.4) prend généralement 1 a 3 jours sur une application de taille moyenne. Une montée de version majeure (5.4 vers 6.4) prend 5 a 15 jours selon la taille de l'application, le nombre de deprecations a corriger et la couverture de tests existante. Si vous sautez plusieurs versions majeures (par exemple 3.4 vers 7.x), comptez 15 a 30 jours car chaque saut majeur doit être fait sequentiellement : 3.4 vers 4.4, puis 4.4 vers 5.4, puis 5.4 vers 6.4, puis 6.4 vers 7.x. C'est pourquoi il est crucial de ne pas accumuler de retard.
Non, Symfony ne supporte pas les sauts de version majeure. Chaque version majeure supprime les fonctionnalités dépréciées dans la version précédente. Si vous êtes en Symfony 4.4 et que vous souhaitez monter en 7.x, vous devez passer par 5.4, puis 6.4, puis 7.x. Chaque étape necessite de corriger les deprecations de la version intermédiaire avant de passer à la suivante. Tenter de sauter directement de 4.4 à 7.x produira des centaines d'erreurs fatales car les classes et méthodes supprimées en 5.0, 6.0 et 7.0 seront toutes absentes simultanément.
Non. Rector automatise typiquement 60 a 80% des transformations nécessaires lors d'une montée de version Symfony. Il excelle sur les remplacements de classes, les mises à jour de signatures de méthodes et les adaptations de configuration. En revanche, il ne gere pas les modifications de logique métier, les adaptations de templates Twig, les refactorings de tests et les cas ou le code utilise des patterns non standard ou des hacks. Après chaque passage de Rector, une revue manuelle est indispensable pour verifier que les transformations automatiques n'ont pas introduit de regressions subtiles, notamment dans la gestion des cas limites.
C'est recommande mais pas obligatoire. Chaque version de Symfony requiert une version minimale de PHP : Symfony 5.4 requiert PHP 7.2.5 minimum, Symfony 6.4 requiert PHP 8.1 minimum et Symfony 7.x requiert PHP 8.2 minimum. Si votre version de PHP est compatible avec la version cible de Symfony, vous pouvez monter Symfony d'abord et PHP ensuite. Notre recommandation : montez PHP avant Symfony, car les nouvelles versions de PHP apportent des améliorations de performance et de sécurité qui bénéficient a l'ensemble de l'application. Utilisez Rector avec les sets php82 ou php83 pour automatiser les adaptations syntaxiques liées a la montée de PHP.