Fin de support Symfony 6.4 : migrer vers Symfony 7.4 LTS, avec un plan, un calendrier et un budget réalistes

Quand se termine le support de Symfony 6.4 ?

Symfony 6.4 est une version LTS (support long terme) sortie en novembre 2023. Voici ce qu'indique la page officielle des versions Symfony, consultée le 22 octobre 2026 :

Il y a donc deux dates à retenir. À partir de décembre 2026, un bug signalé sur Symfony 6.4 ne sera plus corrigé. À partir de décembre 2027, une faille de sécurité non plus. Symfony 7.4 LTS, sortie en novembre 2025, est la version qui permet de tenir jusqu'à fin 2029.

Symfony est notre framework back-end principal, avec plus de 15 ans de pratique. Le site que vous lisez tourne lui-même sous Symfony 6.4 en octobre 2026 : ce guide décrit aussi notre propre plan. Si vous préférez confier la migration à une équipe, consultez notre page développement Symfony.

Fin de vie de Symfony 6.4 : qu'est-ce que cela change concrètement ?

La fin de support n'arrête pas votre application. Elle change simplement qui porte le risque.

• Jusqu'en novembre 2026 : correctifs de bugs et de sécurité. C'est la fenêtre confortable pour migrer.
• De novembre 2026 à novembre 2027 : correctifs de sécurité uniquement. Les régressions et les incompatibilités restent en l'état, et chaque nouvelle version de PHP ou de bibliothèque crée un peu plus de frottement.
• Après novembre 2027 : plus rien. Toute faille publiée dans un composant Symfony (HttpKernel, Security, Form, Serializer) reste ouverte chez vous jusqu'à une migration faite dans l'urgence.

Certains effets arrivent avant la date officielle :

1. PHP a déjà pris de l'avance. Symfony 6.4 accepte PHP 8.1, qui n'a plus de correctifs de sécurité depuis fin 2025. Beaucoup d'applications 6.4 tournent encore dessus.
2. Les bundles avancent sans vous. Les mainteneurs abandonnent le support de Symfony 6 dans leurs nouvelles versions majeures.
3. Les audits le voient. Questionnaires sécurité de vos clients, rapports de tests d'intrusion, due diligence technique avant une levée de fonds ou un rachat : un framework hors support y apparaît en rouge.
4. Plus on attend, plus le saut est grand. Une application 6.4 qui attend 2028 devra encaisser d'un coup les changements de 7.4 et de 8.x.

Faut-il viser Symfony 7.4 LTS ou Symfony 8 ?

Pour la plupart des produits, Symfony 7.4 LTS : trois ans de correctifs de bugs, quatre ans de sécurité, compatible PHP 8.2 et plus, et c'est la version sur laquelle les bundles tiers se testent en priorité.

Symfony 8.x a du sens si votre équipe met à jour tous les six mois, en routine. Chaque version mineure 8.x est maintenue environ huit mois et exige PHP 8.4. Bonne nouvelle : un code sans dépréciation sous 7.4 est à un petit pas de 8.0, car une version majeure de Symfony ne supprime que ce que la dernière mineure a déprécié. Passer à 7.4 maintenant laisse les deux options ouvertes.

Migration Symfony 6.4 vers 7.4 : le plan étape par étape

La méthode officielle, que nous appliquons, tient en une phrase : d'abord supprimer les dépréciations, ensuite changer de version. Voici le plan que nous suivons chez nos clients.

1. Auditer le code et les dépendances

On part des faits, pas d'une estimation au doigt mouillé :

• composer outdated et composer why-not symfony/framework-bundle 7.4 listent les paquets qui bloquent.
• Chaque bundle tiers est vérifié : existe-t-il une version compatible Symfony 7 ? Les bundles abandonnés sont la principale source de mauvaises surprises.
• On mesure les dépréciations : suite de tests avec le PHPUnit Bridge, bin/console debug:container --deprecations et le journal des dépréciations du profiler sur les pages clés.
• On note la version de PHP en production, en CI et sur les postes des développeurs.

Sur notre propre site, l'audit du composer.json trouve tout de suite deux blocages : sensio/framework-extra-bundle et doctrine/annotations. SensioFrameworkExtraBundle est abandonné et ne supporte pas Symfony 7, et Symfony 7 ne lit plus les annotations Doctrine pour le routing, la validation ou la sérialisation. Les deux doivent disparaître avant la bascule. Ce sont les deux blocages que nous rencontrons le plus souvent dans les applications 6.x.

2. Passer à une version de PHP supportée

Symfony 7.4 demande PHP 8.2 minimum, mais le support sécurité de PHP 8.2 s'arrête le 31 décembre 2026 (php.net, consulté en octobre 2026). Visez PHP 8.4 si votre hébergement et vos extensions le permettent : il est supporté jusqu'à fin 2028. Faites la montée de PHP dans une mise en production à part, toujours sous Symfony 6.4, pour savoir exactement quelle modification a cassé quoi. PHPStan et les règles PHP de Rector, lancés contre la version cible, font le gros du repérage.

3. Supprimer les dépréciations sous 6.4

C'est là que se trouve l'essentiel du travail. Les points typiques d'un code 6.4 :

• Annotations vers attributs PHP : @Route, @ORM\..., @Assert\..., @Groups. Rector convertit la plupart automatiquement.
• Fonctions de SensioFrameworkExtraBundle vers leurs équivalents natifs : #[MapEntity] et les argument resolvers à la place de @ParamConverter, #[IsGranted] à la place de @Security, #[Template] du bridge Twig à la place de @Template.
• Types de retour sur les méthodes surchargées (voters, normalizers, commandes, event subscribers), qui deviennent obligatoires.
• Classes et interfaces supprimées, comme ContainerAwareInterface, et anciennes clés de configuration de la sécurité.
• Vos propres appels à des API dépréciées, repérés grâce au journal.

Ces corrections partent dans la branche principale par petites pull requests, pendant que le produit continue de tourner sous 6.4. Objectif : zéro dépréciation dans les tests et sur les parcours principaux.

4. Mettre à jour ou remplacer les bundles

Chaque bundle passe à une version compatible à la fois Symfony 6.4 et 7.x, quand elle existe. Pour un bundle abandonné, trois options : un fork maintenu, un remplaçant, ou rapatrier dans votre code la petite partie que vous utilisez. Doctrine ORM 3 et DBAL 4 arrivent souvent dans la discussion : ils sont indépendants de Symfony 7.4 et peuvent attendre une étape suivante si vos bundles acceptent encore ORM 2.x, ce qui réduit le risque.

5. Changer de version et mettre à jour les recipes

Passez extra.symfony.require et les contraintes symfony/* à 7.4.*, lancez composer update "symfony/*" --with-all-dependencies, puis composer recipes:update pour revoir les changements de configuration recipe par recipe. Lisez les fichiers UPGRADE-7.0.md à UPGRADE-7.4.md des composants que vous utilisez. Videz le cache, réchauffez-le en environnement de production et corrigez ce qui casse.

6. Tester sérieusement

Suite automatisée d'abord, puis vérification manuelle des parcours qui rapportent : inscription et connexion, paiement ou facturation, imports et exports, commandes planifiées, workers Messenger, e-mails et génération de PDF. La sécurité (firewalls, voters, hachage des mots de passe) et les formulaires méritent des tests explicites, car ce sont eux qui ont le plus changé entre 6.x et 7.x. Si l'application a peu de tests, écrivez des tests de caractérisation sur ces parcours avant l'étape 3, pas après.

7. Déployer progressivement

Préproduction avec des données proches de la production, puis production avec le monitoring d'erreurs ouvert et un retour arrière prêt. Si l'application tourne sur plusieurs serveurs ou plusieurs clients, commencez par une petite partie du trafic. Gardez la branche 6.4 déployable une ou deux semaines. Ensuite, montez d'un niveau PHPStan et ajoutez en CI un job qui échoue à la moindre nouvelle dépréciation : la future migration vers 8.x sera courte.

Combien de temps dure une migration Symfony selon la taille du projet ?

Fourchettes typiques tirées de nos chantiers de mise à jour, pour un ou deux développeurs seniors, en partant de Symfony 6.4, tests et mise en production compris.

Ce qui fait monter d'une ligne : des bundles abandonnés, beaucoup d'annotations et de SensioFrameworkExtraBundle, une sécurité maison, un gros écart de version PHP et l'absence de tests. Ce qui fait descendre : un code 6.4 déjà sans dépréciation et une CI qui fait tourner PHPStan.

À titre de repère, notre plateforme Ritoria compte 54 entités métier sous Symfony, ce qui la place entre « moyen » et « gros ». Un système métier comme notre ERP sur mesure pour une société de maintenance aéronautique aux États-Unis, avec planning, stock et mises à jour en temps réel via Mercure, se situe aussi dans cette zone, à cause du nombre de parcours à tester.

Check-list de migration Symfony 6.4 vers 7.4

• Versions de PHP en production, en CI et en local relevées
• composer outdated et paquets bloquants passés en revue
• Compatibilité Symfony 7 vérifiée pour chaque bundle, plan prévu pour les bundles abandonnés
• Monitoring d'erreurs et restauration de sauvegarde testée
• Tests sur les parcours critiques (tests de caractérisation si la couverture est faible)
• PHP passé en 8.2+ (8.4 recommandé) dans une mise en production à part
• Annotations converties en attributs avec Rector
• SensioFrameworkExtraBundle et doctrine/annotations supprimés
• Zéro dépréciation dans la suite de tests et sur les pages principales
• Contraintes symfony/* et extra.symfony.require passées à 7.4.*
• composer recipes:update revu recipe par recipe
• Sécurité, formulaires, serializer et workers Messenger testés explicitement
• Mise en préproduction avec des données réalistes
• Mise en production avec monitoring et plan de retour arrière
• Job CI qui échoue sur toute nouvelle dépréciation

Quels sont les principaux risques ?

La migration elle-même est prévisible. Les projets dérapent quand on saute l'audit et qu'un bundle abandonné apparaît en sixième semaine.

Combien coûte réellement une migration vers Symfony 7.4 ?

Le coût suit les jours-homme. En France, un développeur Symfony senior en freelance ou en ESN se facture typiquement entre 500 et 800 EUR par jour en 2026, parfois plus à Paris. Appliqué au tableau ci-dessus, cela donne une fourchette typique de 3 000 à 10 000 EUR pour une petite application propre, de 10 000 à 30 000 EUR pour une application moyenne, et plus de 30 000 EUR pour une grosse plateforme. Une équipe senior en Ukraine coûte en général deux à trois fois moins cher par jour pour le même travail.

Chez nous, un projet de migration Symfony démarre à 10 000 USD, avec un devis forfaitaire après un court appel de cadrage :

Si l'audit montre une application plus ancienne que 6.4, ou sans framework, il s'agit d'un projet de modernisation : notre guide pour moderniser une application PHP legacy décrit ce chemin. Si vous préférez un budget mensuel pour la maintenance et les mises à jour continues, une équipe de développement dédiée est souvent plus simple.

Quand profiter de la migration pour ajouter de l'IA ?

Quand la fonctionnalité IA touche le code que vous testez déjà pendant la migration, et que votre calendrier supporte quelques semaines de plus. Le filet de tests, le travail sur la CI et les tests de non-régression ne se paient alors qu'une fois.

Les bonnes raisons de combiner :

1. La fonctionnalité IA s'appuie sur Symfony récent. Workers Messenger, rate limiter, attributs et HttpClient récent sont la base des fonctionnalités IA, et les nouveaux bundles liés à l'IA ciblent d'abord les versions actuelles de Symfony.
2. Même équipe, mêmes tests. Les développeurs qui viennent de cartographier vos bundles, votre sécurité et votre modèle de données construisent la fonctionnalité IA plus vite.
3. Un seul plan de mise en production. D'abord la migration, puis la fonctionnalité IA sur le socle à jour quelques semaines plus tard, dans le même projet.

Gardez-les séparées si la migration est urgente (échéance d'audit de sécurité, par exemple) ou si la fonctionnalité IA n'est encore qu'une idée sans parcours utilisateur clair. Dans ce cas, migrez maintenant et validez l'idée ensuite, par exemple avec un AI Sprint de 4 semaines au forfait de 10 000 USD.

Notre propre produit AI Resume Master tourne sous PHP et Symfony avec React et Python, et a atteint 50 000 utilisateurs actifs mensuels. La façon dont nous intégrons OpenAI ou Claude dans Symfony est détaillée dans notre guide pour intégrer l'IA dans une application Symfony.

Notre avis

Planifiez la migration maintenant, tant que Symfony 6.4 reçoit encore des correctifs de bugs, et visez Symfony 7.4 LTS sur PHP 8.4. Procédez en trois mises en production : PHP, dépréciations, puis changement de version. Commencez par un court audit pour que le bundle abandonné soit trouvé en première semaine, pas en sixième. Pour une application métier typique, c'est un projet de 3 à 12 semaines au coût connu d'avance, et chaque mois d'attente l'alourdit.

Pour confier ce chantier à une équipe, consultez notre page développement Symfony ou contactez-nous avec vos versions actuelles de Symfony et de PHP et la sortie de composer outdated.