Aller au contenu principal

Migration Symfony · 3.4 → 4.4 → 5.4 → 6.4 → 7.4

Migrer de Symfony 3 à Symfony 7

Symfony 3.4 ne reçoit plus de correctifs de sécurité depuis novembre 2021 ; Symfony 7.4 reste couvert par les correctifs de sécurité jusqu’en novembre 2029. Le chemin sûr traverse 4 versions majeures en s’arrêtant sur chaque LTS : 3.4 → 4.4 → 5.4 → 6.4 → 7.4. PHP passe de 5.5.9 minimum à 8.2 minimum. Première rupture à traiter : services et alias seront privés par défaut en 4.0 : ne plus appeler $container->get() ; injecter les dépendances ou marquer public: true.

Où en est le support de Symfony 3.4 et 7.4 ?

Support de Symfony 3.4 et 7.4
CritèreSymfony 3.4Symfony 7.4
Sortienovembre 2017novembre 2025
Fin des correctifs de bugsnovembre 2020novembre 2028
Fin des correctifs de sécuriténovembre 2021novembre 2029
PHP minimum5.5.98.2

Statuts vérifiés le 08/11/2026 sur les pages officielles de version.

Les ruptures à traiter en premier

  1. Bloquant · 3.4Services et alias seront privés par défaut en 4.0 : ne plus appeler $container->get() ; injecter les dépendances ou marquer public: true.source
  2. Bloquant · 3.4L'auto-enregistrement de services lié à l'autowiring est déprécié : déclarer explicitement les services, ids égaux aux FQCN.source
  3. Bloquant · 5.0SimpleAuthenticatorInterface et ses variantes Form/PreAuthenticator sont supprimés : réécrire en authenticators Guard.source

Le chemin de migration, étape par étape

Chaque étape se termine sur une version sans dépréciation avant la majeure suivante : c’est la seule montée que la promesse de rétrocompatibilité de Symfony couvre. Avant de lancer le chantier, auditer la dette technique avec Bear Scan chiffre la dette qui ralentira chaque étape.

Côté outillage, Rector 2 ne s’appuie plus sur un set par version : withComposerBased(symfony: true) applique les règles de la version de Symfony installée, et withAttributesSets(symfony: true) convertit les annotations en attributs. On relance Rector après chaque montée de composer.json (configuration testée sur un passage vers Symfony 8).

Avant de quitter Symfony 3.4

PHP minimum : 5.5.9

  • BloquantServices et alias seront privés par défaut en 4.0 : ne plus appeler $container->get() ; injecter les dépendances ou marquer public: true.source
  • BloquantL'auto-enregistrement de services lié à l'autowiring est déprécié : déclarer explicitement les services, ids égaux aux FQCN.source
  • À traiterNe pas fixer strict=true sur la contrainte Choice est déprécié : l'ajouter partout où la contrainte est utilisée.source
  • À traiterYaml::PARSE_KEYS_AS_STRINGS est déprécié : mettre entre guillemets les clés numériques et booléennes dans les fichiers YAML.source
  • MineurLes syntaxes !php/object: et !php/const: avec deux-points sont dépréciées au profit de !php/object et !php/const.source
  • MineurLa classe ProcessBuilder est dépréciée : instancier directement Process avec un tableau d'arguments.source

Pièges rencontrés en migration

  • La 3.4 est le palier obligé avant 4.0 : activer le logging des dépréciations et les traiter toutes sur cette version, puisqu'elles deviennent des erreurs en 4.0.source
  • Les contrôleurs et commandes qui récupèrent leurs services via le conteneur (container->get) casseront au passage en 4.0 : les convertir en injection par constructeur.source

Symfony 4 (4.0, 4.1, 4.2, 4.3 et 4.4)

PHP minimum : 7.1.3

  • Bloquant · 4.0Les services sont privés par défaut : Container::get() sur un service privé n'est plus supporté.source
  • Bloquant · 4.0L'autowiring par type implémenté est supprimé : il faut un alias ou un id de service égal au FQCN.source
  • Bloquant · 4.0La découverte des commandes par convention (Command/ dans les bundles) est supprimée : les enregistrer comme services tagués.source
  • Bloquant · 4.1Les syntaxes de contrôleur bundle:controller:action et service:action sont dépréciées : utiliser serviceOrFqcn::method.source
  • Bloquant · 4.2La classe Controller de FrameworkBundle est dépréciée : étendre AbstractController (services non accessibles via le conteneur).source
  • Bloquant · 4.3La signature d'EventDispatcherInterface::dispatch() s'inverse : dispatch($event, $eventName) au lieu de dispatch($eventName, $event).source

Pièges rencontrés en migration

  • Adopter Symfony Flex impose de déplacer app/, web/ et var/ vers la nouvelle structure (config/, public/, templates/) ; la recette de migration est la partie la plus longue du passage.source
  • Les clés YAML non chaînes (true:, null:) sont rejetées : auditer les fichiers de configuration.source
  • Les références de contrôleurs à l'ancienne (AppBundle:Default:index) dans routing.yml et les annotations sont à convertir en FQCN avant la 5.0.source

Symfony 5 (5.0, 5.1, 5.2, 5.3 et 5.4)

PHP minimum : 7.2.5

  • Bloquant · 5.0SimpleAuthenticatorInterface et ses variantes Form/PreAuthenticator sont supprimés : réécrire en authenticators Guard.source
  • Bloquant · 5.0Controller et ContainerAwareCommand sont supprimés : étendre AbstractController et injecter les services dans les commandes.source

Étape intermédiaire, détaillée sur sa propre page : migration Symfony 4 → 5

Symfony 6 (6.0, 6.1, 6.2, 6.3 et 6.4)

PHP minimum : 8.1

  • Bloquant · 6.0Le composant Guard est supprimé : les authenticators doivent passer au système d'authentification (Passport, createToken() à la place de createAuthenticatedToken()).source
  • Bloquant · 6.0UserInterface perd getPassword() et getSalt() : il faut implémenter PasswordAuthenticatedUserInterface (et la variante Legacy pour un sel utilisateur).source

Étape intermédiaire, détaillée sur sa propre page : migration Symfony 5 → 6

Symfony 7 (7.0, 7.1, 7.2, 7.3 et 7.4)

PHP minimum : 8.2

  • Bloquant · 7.0L'intégration de doctrine/annotations est supprimée : routes, validation et serializer n'acceptent plus que les attributs PHP natifs.source
  • Bloquant · 7.0Les options framework.validation.enable_annotations et serializer.enable_annotations disparaissent, remplacées par enable_attributes.source
  • Bloquant · 7.0Command::$defaultName/$defaultDescription et ContainerAwareInterface/Trait sont supprimés : #[AsCommand] et injection de dépendances obligatoires.source
  • Bloquant · 7.0MessageHandlerInterface et MessageSubscriberInterface sont retirés : tous les handlers Messenger doivent utiliser #[AsMessageHandler].source
  • Bloquant · 7.3UserInterface::eraseCredentials() et TokenInterface::eraseCredentials() sont dépréciés : vider les secrets dans __serialize().source
  • Bloquant · 7.4Le format de configuration XML est déprécié pour le conteneur et la validation : migrer vers YAML, PHP ou attributs avant la 8.0.source

Pièges rencontrés en migration

  • PHP 8.2 devient le minimum : planifier la montée PHP (et Docker/CI) avant le passage en 7.0, qui est la vraie condition de blocage sur les hébergements anciens.source
  • Symfony 7.0 ne lit plus les annotations (@Route, @Assert…) : routes et contraintes doivent être déclarées en attributs PHP (#[Route], #[Assert\NotBlank]) avant la montée.source
  • Les nouveaux types natifs cassent les classes qui surchargent des méthodes Symfony sans return type : appliquer le patcher de types avant la montée.source

À lire sur le blog : De Symfony 7.4 LTS à la branche 8.x : éliminer les dépréciations proprement · Symfony 7.4 LTS : ce qu'il faut savoir avant de migrer

Ce que Symfony 7.4 vous apporte

  • 7.0 : 7.0 expose les mêmes fonctionnalités que la 6.4 mais sans aucun code déprécié : plus léger et plus strict.source
  • 7.1 : Nouveau composant TypeInfo qui extrait les types PHP depuis propriétés, méthodes et retours de fonctions via plusieurs sources.source
  • 7.2 : Attribut #[AsMessage] pour configurer le ou les transports directement dans la classe du message Messenger.source
  • 7.3 : Commandes invocables avec attributs d'entrée (#[Argument], #[Option]) pour décrire arguments et options dans la signature de __invoke().source
  • 7.4 : Formulaires multi-étapes (form flows) construits avec les concepts habituels de Symfony Form.source

Combien coûte cette migration ?

  • Petite application

    100 fichiers PHP, 15 entités, 2 bundles maison

    10 010 € HT

  • Application métier

    400 fichiers PHP, 60 entités, 6 bundles maison

    39 700 € HT

  • Plateforme

    1 200 fichiers PHP, 150 entités, 15 bundles maison

    140 190 € HT

Exemples de la grille Bear Upgrade pour Symfony 3 → 7 (tests à 20 %, sans PHPStan ni CI), pas des devis : le prix ferme est fixé au cadrage.

Pour une migration Bear Upgrade livrée en Merge Requests, Rector tourne d’abord en dry-run sur les transformations mécaniques, Claude Code traite les cas que Rector ne couvre pas, puis un développeur senior relit chaque Merge Request. Votre équipe veut reprendre la main ensuite ? Pensez à former votre équipe à Claude Code. Exemple concret : la migration Symfony d’un e-commerce bordelais, et après la migration, la maintenance des versions garde le socle à jour.

Sur une base aussi ancienne, l’audit d’abord : Bear Scan mesure tests, dépendances abandonnées et code mort avant de fixer le prix de la migration.

Questions fréquentes

Pour aller plus loin

Sources

Votre migration Symfony 3 → 7, livrée en Merge Requests

CI au vert garantie 7 jours après le merge. Un appel de cadrage suffit pour fixer le périmètre, le prix et le délai.