Symfony 7.4 LTS ou 8.x : comment choisir la bonne version pour votre projet en 2026 ?

En septembre 2026, une application Symfony a deux trajectoires maintenues : Symfony 7.4 LTS, corrigée jusqu’en novembre 2028 (sécurité jusqu’en novembre 2029), ou la branche 8.x, aujourd’hui Symfony 8.1 (sortie fin mai 2026, maintenue jusqu’en janvier 2027), puis 8.2 en novembre 2026. Symfony 8.0 n’est plus maintenue depuis fin juillet 2026. Notre recommandation : 8.1 si votre équipe peut monter de version tous les six mois, 7.4 LTS si vos cycles de mise en production sont lourds, avec dans ce cas un objectif de passage à 8.4 LTS, prévue en novembre 2027.

Cet article, publié à la sortie de 7.4 et 8.0 et mis à jour en septembre 2026, vous aide à :

• comprendre la différence entre 7.4 LTS et la branche 8.x ;
• lire le calendrier de maintenance réel ;
• repérer les nouveautés techniques qui comptent ;
• construire un plan de migration concret.

1. Symfony 7.4 et 8.0 : mêmes fonctionnalités, deux stratégies

Symfony publie ses versions majeures en double : Symfony 8.0 = Symfony 7.4 sans les fonctionnalités dépréciées.

• 7.4 contient les nouveautés et toutes les couches de compatibilité : le code qui utilise d’anciennes API fonctionne encore, avec des avertissements de dépréciation.
• 8.0 supprime tout ce qui est déprécié : le framework est plus léger, mais le code qui utilise encore les anciennes API ne fonctionne plus.

Depuis, les deux trajectoires divergent : 8.1 a apporté de nouvelles fonctionnalités, 8.2 suivra en novembre 2026, alors que 7.4 ne reçoit plus que des correctifs.

1.1. Le calendrier de maintenance en septembre 2026

Source : symfony.com/releases, consulté le 30 septembre 2026.

Une version standard est maintenue huit mois : il faut donc monter de version mineure tous les six mois pour rester couvert. Ces montées (8.1 vers 8.2, par exemple) respectent la promesse de rétrocompatibilité de Symfony : elles sont généralement courtes si les dépréciations sont traitées au fil de l’eau.

1.2. Notre recommandation selon votre situation

• Nouveau projet : partez sur 8.1, puis suivez 8.2, 8.3 et 8.4 LTS. Vous profitez des nouveautés et vous étalez l’effort de migration.
• Application critique (banque, santé, industrie), mises en production lourdes, ou bundles pas encore compatibles 8.x : 7.4 LTS, avec un objectif de passage à 8.4 LTS avant la fin des correctifs de bugs de 7.4, en novembre 2028.
• Application en 8.0 : montez en 8.1 maintenant, 8.0 ne reçoit plus de correctifs de sécurité.
• Application en 6.4 : les correctifs de bugs s’arrêtent en novembre 2026 et la sécurité en novembre 2027. Planifiez dès maintenant la montée en 7.4.
• Application en 5.4 ou antérieure : la migration est un projet à part entière, qui commence par un audit technique.

La recommandation officielle de Symfony va dans le même sens : utiliser la dernière version stable dès que possible, plutôt que de rester figé sur une LTS.

2. Prérequis : PHP 8.4 pour toute la branche 8.x

Toutes les versions 8.x demandent PHP 8.4 au minimum. Symfony 7.4 accepte PHP 8.2, mais le calendrier de PHP pousse à monter quand même :

Source : php.net/supported-versions.

Avant même de parler de Symfony, la première question est donc : notre infrastructure est-elle prête pour PHP 8.4 ou 8.5 ? Serveurs, images Docker, pipeline d’intégration continue, extensions PHP, dépendances Composer. Nous commençons généralement par cet inventaire, puis par la migration de l’environnement, avant de toucher au cœur applicatif Symfony.

3. FormFlow : des formulaires multi-étapes natifs

C’est l’un des changements les plus visibles de 7.4 : les formulaires en plusieurs étapes (inscription, onboarding, configuration d’un produit) deviennent natifs. Jusqu’ici, il fallait gérer la session, la progression, les boutons Précédent/Suivant et la validation partielle à la main, ou passer par un bundle tiers.

Avec FormFlow, on étend AbstractFlowType, on déclare les étapes avec addStep() et on ajoute un « navigator » pour les boutons :

namespace App\Form;

use App\Model\UserSignUp;
use Symfony\Component\Form\Flow\AbstractFlowType;
use Symfony\Component\Form\Flow\FormFlowBuilderInterface;
use Symfony\Component\Form\Flow\Type\NavigatorFlowType;
use Symfony\Component\OptionsResolver\OptionsResolver;

final class UserSignUpType extends AbstractFlowType
{
    public function buildFormFlow(FormFlowBuilderInterface $builder, array $options): void
    {
        $builder->addStep('personal', UserSignUpPersonalType::class);
        $builder->addStep('professional', UserSignUpProfessionalType::class);
        $builder->addStep('account', UserSignUpAccountType::class);

        $builder->add('navigator', NavigatorFlowType::class);
    }

    public function configureOptions(OptionsResolver $resolver): void
    {
        $resolver->setDefaults([
            'data_class' => UserSignUp::class,
            'step_property_path' => 'currentStep',
        ]);
    }
}

Dans le contrôleur, le flow se manipule comme un formulaire, avec deux différences : isFinished() pour savoir si le parcours est terminé, et getStepForm() pour afficher l’étape courante.

#[Route('/inscription', name: 'app_signup')]
public function signUp(Request $request): Response
{
    $flow = $this->createForm(UserSignUpType::class, new UserSignUp())
        ->handleRequest($request);

    if ($flow->isSubmitted() && $flow->isValid() && $flow->isFinished()) {
        // enregistrer $flow->getData()

        return $this->redirectToRoute('app_signup_success');
    }

    return $this->render('signup/flow.html.twig', [
        'form' => $flow->getStepForm(),
    ]);
}

Le nom de l’étape courante sert de groupe de validation : chaque étape ne valide que ses propres champs. Résultat : moins de code d’assemblage et des formulaires complexes plus faciles à maintenir.

4. Configuration : fin du XML, nouveau format PHP

• Le format XML est déprécié en 7.4 et supprimé en 8.0.
• La configuration PHP « fluent » (les classes ConfigBuilder) est dépréciée en 7.4, au profit d’un format PHP à base de tableaux.

Ce nouveau format ressemble à du YAML, mais reste du PHP. Symfony génère un fichier config/reference.php qui décrit la forme de chaque configuration (« array shapes ») : votre IDE et vos outils d’analyse statique (PHPStan, Psalm) peuvent alors proposer l’autocomplétion et détecter les erreurs de type.

Exemple d’une configuration de sécurité avec connexion par formulaire :

// config/packages/security.php
namespace Symfony\Component\DependencyInjection\Loader\Configurator;

return App::config([
    'security' => [
        'providers' => [
            'app_user_provider' => [
                'entity' => ['class' => \App\Entity\User::class, 'property' => 'email'],
            ],
        ],
        'firewalls' => [
            'main' => [
                'lazy' => true,
                'provider' => 'app_user_provider',
                'form_login' => [
                    'login_path' => 'app_login',
                    'check_path' => 'app_login',
                ],
                'logout' => ['path' => 'app_logout'],
            ],
        ],
        'access_control' => [
            ['path' => '^/admin', 'roles' => 'ROLE_ADMIN'],
        ],
    ],
]);

Attention aux exemples anciens : l’option anonymous n’existe plus depuis Symfony 6.0. Un firewall lazy laisse passer les visiteurs non connectés, et c’est access_control qui décide des accès.

Le YAML reste pleinement supporté et reste le format recommandé par Symfony à ce jour. Si vous avez du XML, migrez-le vers YAML ou vers le nouveau format PHP avant de passer en 8.x.

5. JSON, mapping et dates : Symfony se renforce côté API

Trois composants introduits en expérimental dans 7.3 sont stables depuis 7.4 :

1. JsonPath : interroger des structures JSON complexes avec une syntaxe dédiée, utile pour traiter les réponses d’API tierces.
2. JsonStreamer : encoder et décoder du JSON rapidement et avec peu de mémoire, pour les gros volumes (exports, ETL, microservices).
3. ObjectMapper : transformer des objets en d’autres objets (entités, DTO, payloads d’API) sans écrire ce code à la main.

Côté dates, l’option input: 'date_point' des champs de formulaire de date et les types Doctrine DayPointType et TimePointType permettent de manipuler des DatePoint et de séparer proprement les dates « calendaires » (une échéance, un anniversaire) des instants précis. Pour les contrats, abonnements et réservations, c’est moins de surprises liées aux fuseaux horaires.

6. Qualité du code : un framework plus strict

6.1. Fin de Request::get()

Request::get() est dépréciée en 7.4 et supprimée en 8.0. Elle cherchait la valeur à la fois dans les paramètres de route, la query string et le corps POST : code ambigu, risques de collision, validation plus difficile. Il faut désormais être explicite :

$request->attributes->get('id');   // paramètres de route
$request->query->get('page');      // ?page=…
$request->request->get('email');   // données POST

Ou mieux, utiliser les attributs de mapping dans les contrôleurs : #[MapQueryParameter], #[MapQueryString], #[MapRequestPayload].

6.2. Commandes console invocables

Les commandes « invocables » (une classe, une méthode __invoke()) gagnent en 7.4 la gestion de l’interaction (#[Interact], #[Ask]), le mapping d’entrée vers un DTO (#[MapInput]) et le support des enums :

namespace App\Command;

use Symfony\Component\Console\Attribute\Argument;
use Symfony\Component\Console\Attribute\AsCommand;
use Symfony\Component\Console\Attribute\Option;
use Symfony\Component\Console\Command\Command;
use Symfony\Component\Console\Style\SymfonyStyle;

#[AsCommand(name: 'app:invoices:send', description: 'Envoie les factures du mois')]
final class SendInvoicesCommand
{
    public function __invoke(
        SymfonyStyle $io,
        #[Argument] string $month,
        #[Option] bool $dryRun = false,
    ): int {
        // ...
        $io->success(sprintf('Factures de %s traitées.', $month));

        return Command::SUCCESS;
    }
}

6.3. UUID v7 par défaut et validation vidéo

UuidFactory génère désormais des UUID v7 par défaut : ils intègrent un horodatage et s’indexent mieux en base de données. Une nouvelle contrainte Video permet aussi de valider les fichiers vidéo envoyés par les utilisateurs.

7. Plan de migration : par où commencer ?

Si vous êtes en Symfony 5.4, 6.4 ou 7.0 à 7.3, voici un plan réaliste :

1. Mettre l’infrastructure à niveau : PHP 8.4 (ou 8.5), extensions, images Docker, pipeline CI.

2. Monter d’abord en Symfony 7.4 : c’est la version « tampon », qui contient toutes les fonctionnalités de 8.0 avec les couches de compatibilité.

3. Traquer les dépréciations en lançant les tests :

   php bin/phpunit --display-deprecations

   Corrigez ce qui vient de votre code (Rector automatise une bonne partie des réécritures), et vérifiez que vos bundles tiers ont une version compatible 8.x.

4. Nettoyer la configuration : migrer le XML vers YAML ou PHP, retirer les options obsolètes.

5. Passer directement à la dernière 8.x maintenue, aujourd’hui 8.1 : inutile de passer par 8.0. Prévoyez une phase de recette et de tests de performance.

6. Installer un rythme : une montée de version mineure tous les six mois (8.2 en novembre 2026, 8.3, puis 8.4 LTS en novembre 2027), et le traitement des dépréciations dans la gestion normale de la dette technique.

8. Comment nous vous accompagnons

Nous concevons, développons et maintenons des applications métier, notamment en Symfony. Sur une montée de version, nous intervenons à chaque étape :

• Audit Symfony et PHP : versions, dépendances, configuration, performance, sécurité, cartographie des dépréciations et des risques. C’est l’objet de notre audit technique.
• Plan de migration : choix entre 7.4 LTS et 8.x, étapes et planning adaptés à vos contraintes produit.
• Mise en œuvre : refonte du code ancien, migration des formulaires complexes vers FormFlow, modernisation de la configuration, optimisation des API. Si l’application doit aussi évoluer en profondeur, voir moderniser une application.
• Rythme de mise à jour : nos équipes intègrent les montées de version dans la maintenance courante, pour ne plus subir de grosse migration.

Chaque projet a un lead technique Etixio qui porte les choix techniques, fait les revues de code et reste votre interlocuteur. Nos équipes travaillent dans votre environnement : vos dépôts, votre outil de tickets, vos règles de sécurité. Votre code, vos accès, vos outils : tout reste à vous.

Une fois en 7.4 ou 8.x, vous pouvez aussi ajouter des fonctions IA à votre application avec Symfony AI, compatible avec ces deux branches.

En résumé

• Symfony 8.0 n’est plus maintenue : les choix actuels sont 7.4 LTS ou 8.1, puis 8.2 en novembre 2026.
• La branche 8.x exige PHP 8.4 ; même en 7.4, visez PHP 8.4 ou 8.5.
• FormFlow, le nouveau format de configuration PHP, JsonStreamer, ObjectMapper et JsonPath sont disponibles dans les deux branches.
• La meilleure migration est la plus régulière : traiter les dépréciations au fil de l’eau coûte bien moins cher qu’une grosse migration tous les deux ans.

Vous voulez préparer votre migration vers Symfony 8, sécuriser vos choix techniques ou faire auditer une application Symfony existante ? Parlons-en : nous construisons avec vous un plan adapté à votre contexte.

FAQ