Aller au contenu principal

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

Migrer de Symfony 2 à Symfony 6

Symfony 2.8 ne reçoit plus de correctifs de sécurité depuis novembre 2019 ; Symfony 6.4 reste couvert par les correctifs de sécurité jusqu’en novembre 2027. Le chemin sûr traverse 4 versions majeures en s’arrêtant sur chaque LTS : 2.8 → 3.4 → 4.4 → 5.4 → 6.4. PHP passe de 5.3.9 minimum à 8.1 minimum. Première rupture à traiter : formTypeInterface::getName() est déprécié : il faut passer à getBlockPrefix() ou aux noms de classe (FQCN) pour les types de formulaire.

Où en est le support de Symfony 2.8 et 6.4 ?

Support de Symfony 2.8 et 6.4
CritèreSymfony 2.8Symfony 6.4
Sortienovembre 2015novembre 2023
Fin des correctifs de bugsnovembre 2018novembre 2026
Fin des correctifs de sécuriténovembre 2019novembre 2027
PHP minimum5.3.98.1

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

Les ruptures à traiter en premier

  1. Bloquant · 2.8FormTypeInterface::getName() est déprécié : il faut passer à getBlockPrefix() ou aux noms de classe (FQCN) pour les types de formulaire.source
  2. Bloquant · 3.0Le composant Locale est supprimé : migrer vers Intl (par exemple Intl::getLanguageBundle()).source
  3. Bloquant · 4.0Les services sont privés par défaut : Container::get() sur un service privé n'est plus supporté.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, un audit Bear Scan avant de migrer 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 2.8

PHP minimum : 5.3.9

  • BloquantFormTypeInterface::getName() est déprécié : il faut passer à getBlockPrefix() ou aux noms de classe (FQCN) pour les types de formulaire.source
  • À traiterL'option cascade_validation des formulaires est dépréciée au profit de l'option constraints avec la contrainte Valid.source
  • À traiterLes scopes du conteneur (Definition::setScope(), ContainerBuilder::getScopes()) sont dépréciés ; le nouveau drapeau shared les remplace.source
  • À traiterAbstractVoter est déprécié : les voters doivent étendre la classe Voter.source
  • MineurLe paramètre session.cookie_httponly vaut désormais true par défaut : à vérifier si du JavaScript lit le cookie de session.source

Pièges rencontrés en migration

  • La 2.8 sert de palier de nettoyage : tout ce qu'elle déprécie est supprimé en 3.0. Corriger les dépréciations (formulaires, scopes, voters) avant de monter.source

Symfony 3 (3.0, 3.1, 3.2, 3.3 et 3.4)

PHP minimum : 5.5.9

  • Bloquant · 3.0Le composant Locale est supprimé : migrer vers Intl (par exemple Intl::getLanguageBundle()).source
  • Bloquant · 3.0Form::bind() et isBound() sont supprimées : utiliser submit(), isSubmitted() ou handleRequest().source
  • Bloquant · 3.0Le service request est supprimé : injecter request_stack et appeler getCurrentRequest().source
  • Bloquant · 3.2Appeler isValid() sur un formulaire non soumis est déprécié : écrire isSubmitted() && isValid().source
  • Bloquant · 3.2doctrine/annotations n'est plus une dépendance directe de FrameworkBundle : l'ajouter explicitement dans composer.json si vous utilisez des annotations.source
  • Bloquant · 3.3L'autowiring par types implémentés est déprécié (retiré en 4.0) : déclarer des alias ou nommer les services par FQCN.source

Pièges rencontrés en migration

  • Aucune couche de compatibilité : passer de 2.8 à 3.0 sans avoir éliminé toutes les dépréciations casse le code immédiatement. Les logs de dépréciation de la 2.8 sont le point de départ.source
  • Les routes en YAML ou annotations utilisant pattern, _method ou _scheme doivent toutes être réécrites.source
  • Version non LTS maintenue environ 14 mois : ne pas s'y arrêter, c'est un simple pas vers la 3.4 LTS.source

À lire sur le blog : Sécuriser votre app Symfony en 30 minutes : checklist OWASP

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

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

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
  • Bloquant · 6.0Les rôles IS_AUTHENTICATED_ANONYMOUSLY et IS_ANONYMOUS disparaissent : les règles access_control doivent utiliser PUBLIC_ACCESS.source
  • Bloquant · 6.0AbstractController n'expose plus get(), has(), getDoctrine() ni dispatchMessage() : l'injection par constructeur ou par méthode devient obligatoire.source
  • Bloquant · 6.2La classe et le service Symfony\Component\Security\Core\Security sont dépréciés : utiliser Symfony\Bundle\SecurityBundle\Security.source
  • Bloquant · 6.4L'intégration de doctrine/annotations est dépréciée : migrer routes, validation et serializer vers les attributs natifs, avant la suppression en 7.0.source

Pièges rencontrés en migration

  • PHP 8.0.2 minimum : la migration depuis 5.4 impose de monter PHP avant tout ; corriger d'abord toutes les dépréciations 5.4, car la 6.0 supprime ce que la 5.4 déprécie.source
  • Request::getMasterRequest() et MASTER_REQUEST sont renommés en getMainRequest() et MAIN_REQUEST : un simple rechercher-remplacer évite des erreurs fatales dans les listeners.source
  • Les propriétés publiques et protégées sont désormais considérées finales : surcharger une propriété d'une classe Symfony casse ; affecter sa valeur dans le constructeur.source

Ce que Symfony 6.4 vous apporte

  • 6.0 : Symfony 6.0 partage ses nouveautés avec la 5.4 : autocomplétion Console des options et valeurs, via les shells compatibles.source
  • 6.1 : Nouveau composant HtmlSanitizer pour transformer du HTML saisi par les utilisateurs en HTML sûr, en filtrant balises et attributs.source
  • 6.2 : Nouveau composant Clock pour rendre testable le code dépendant du temps.source
  • 6.3 : Attributs MapRequestPayload et MapQueryString pour mapper le corps ou la query string vers des DTO typés, avec validation automatique.source
  • 6.4 : Profiler de commandes (option --profile) pour analyser l'exécution des commandes console, et profiler Workflow avec vue graphique.source

Combien coûte cette migration ?

  • Petite application

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

    9 950 € HT

  • Application métier

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

    39 460 € HT

  • Plateforme

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

    139 300 € HT

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

Pour faire migrer votre application avec Bear Upgrade, 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 à la formation Claude Code sur vos projets. 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 2 → 6, 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.