La recommandation officielle de Symfony est d’opter autant que possible pour les versions régulières, et de monter régulièrement de 8.0 → 8.1 → 8.2… plutôt que de rester figé longtemps sur une LTS.

Concrètement :

• Choisir Symfony 7.4 LTS, c’est pertinent si :
  • vous avez une application métier très sensible (banque, santé, industrie),
  • les cycles de mise à jour sont lourds,
  • vous privilégiez la stabilité maximale à court terme, quitte à faire une grosse migration plus tard.
• Choisir Symfony 8.0, c’est pertinent si :
  • vous pouvez planifier des mises à jour tous les 6 mois,
  • vous voulez bénéficier en continu des nouveautés du framework,
  • vous préférez lisser l’effort de migration plutôt que le subir tous les 2 ans.

Chez Etixio, on conseille :

7.4 LTS pour les applis critiques très contraintes,
8.0 (puis 8.1, 8.2…) dès que l’équipe et le contexte projet le permettent.

2. Prérequis : Symfony 8.0 exige PHP 8.4

Symfony 8.0 fait un choix fort : il nécessite PHP 8.4 minimum.
Pourquoi c’est important pour vous ?

• Sécurité : PHP 8.4 fait partie des versions activement maintenues et corrigées.
• Performance : le cœur de Symfony s’appuie sur les dernières optimisations du langage.
• Syntaxe & DX : meilleure gestion des types, des attributs, des structures modernes, etc.

Avant même de parler Symfony, la première question à se poser est :

“Notre infra est-elle prête pour PHP 8.4 (serveurs, Docker, CI/CD, extensions, dépendances) ?”

Chez Etixio, on commence généralement par :

• un audit compatibilité PHP 8.4,
• puis la migration progressive de l’environnement,
• avant d’attaquer le cœur applicatif Symfony.

3. FormFlow : enfin des formulaires multi-étapes propres

C’est l’un des changements les plus visibles côté développeurs : les “form flows” arrivent en natif.

Jusqu’ici, pour un formulaire en plusieurs étapes (wizard d’inscription, onboarding, configuration produit…), il fallait :

• gérer la session à la main,
• suivre la progression de l’utilisateur,
• bricoler des boutons Précédent/Suivant,
• gérer validation partielle, états intermédiaires, etc.

Avec FormFlow, Symfony introduit un concept dédié :

• on étend AbstractFlowType au lieu d’AbstractType,
• on déclare les étapes avec addStep(),
• on ajoute un “navigator” pour la navigation automatique.

Exemple simplifié :
use Symfony\Component\Form\Flow\AbstractFlowType;
use Symfony\Component\Form\Flow\FormFlowBuilderInterface;

class UserSignUpFlowType extends AbstractFlowType
{

public function buildFormFlow(FormFlowBuilderInterface $builder, array $options): void
{

$builder->addStep(‘personal’, UserSignUpPersonalType::class);
$builder->addStep(‘professional’, UserSignUpProfessionalType::class);

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

}

Dans le contrôleur, on manipule un flow plutôt qu’un simple formulaire :

• isFinished() pour savoir quand le process est terminé,
• getStepForm() pour afficher uniquement l’étape courante.

Résultat :

• moins de code “glue”,
• une logique plus déclarative,
• des formulaires complexes (multi-étapes, conditionnels) beaucoup plus faciles à maintenir.

4. Configuration : fin du XML, montée en puissance du PHP typé

Symfony continue sa modernisation en profondeur de la configuration :

• XML est officiellement déprécié en 7.4 et supprimé en 8.0.
• le “fluent PHP config” disparaît également, au profit d’un format PHP plus simple.

4.1. Le nouveau format : PHP “array shapes”

Symfony introduit un format de config PHP basé sur des tableaux typés (“array shapes”) :

• l’écriture ressemble à du YAML,
• mais on reste en pur PHP, avec :
  • autocomplétion dans l’IDE,
  • analyse statique (PHPStan/Psalm),
  • validation de types.

Exemple typique :

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

use Symfony\Component\DependencyInjection\Loader\Configurator\App;

return App::config([

‘security’ => [

‘firewalls’ => [

‘main’ => [

‘pattern’ => ‘^/*’,
‘lazy’ => true,
‘anonymous’ => true,

],

],
‘access_control’ => [

[‘path’ => ‘^/admin’, ‘roles’ => ‘ROLE_ADMIN’],

],

],

]);

Pour les équipes :

• Dev & lead dev : un format aligné avec les outils modernes, plus facile à relire et refactorer.
• Organisation : la config devient plus navigable et fiable sur le long terme.

YAML reste bien sûr supporté et améliore lui aussi son autocomplétion grâce à des schémas JSON.

5. JSON, mapping & data : Symfony se muscle côté APIs

Symfony passe à la vitesse supérieure pour les applications orientées API et data intensive.

Trois composants, introduits en 7.3, sont désormais stables et pleinement supportés :

1. JsonPath
   • Permet de requêter des structures JSON complexes avec une syntaxe dédiée.
   • Très utile pour traiter des réponses d’API tierces.
2. JsonStreamer
   
   • Encode / décode du JSON très rapidement et avec peu de mémoire.
   • Parfait pour des flux volumineux (exports, ETL, microservices).
3. ObjectMapper

• • Simplifie le mapping entre entités, DTOs, payloads d’API, etc.
  • Fait gagner un temps énorme sur tout ce qui est “plomberie” de transformation de données, surtout avec les transformations de collections.

5.1. Meilleure gestion des dates “métier”

Les nouvelles options de formulaire (input = date_point) et les types Doctrine dédiés (DayPointType, TimePointType) permettent enfin de séparer proprement :

• les dates “pures” (un anniversaire, une échéance, qui ne dépend pas de fuseau horaire),
• les instants précis dans le temps.

Pour les applications métier (contrats, abonnements, réservations), c’est un vrai plus en fiabilité : moins de surprises liées aux timezones.

6. Qualité du code & sécurité : Symfony devient plus strict (et c’est une bonne nouvelle)

Les versions 7.4 / 8.0 sont aussi l’occasion de supprimer des APIs ambiguës et de renforcer les bonnes pratiques.

6.1. Fin de Request::get()

La méthode $request->get(‘id’) est supprimée en 8.0.

Pourquoi ?
Parce qu’elle mélangeait dans une même méthode :

• paramètres de route,
• query string,
• payload POST.

Résultat :

• code moins lisible,
• risques de collisions,
• surface d’attaque plus large en cas de mauvaise validation.

Désormais, il faut ê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 (#[MapQueryParameter], #[MapRequestPayload], etc.) directement dans les contrôleurs.

6.2. Commandes console : place aux commandes “invocables”

Les commandes invocables deviennent beaucoup plus puissantes :

• une simple classe,
• une méthode __invoke(),
• des attributs comme #[Argument], #[Input], #[Ask], #[Interact] pour gérer les arguments et l’interaction utilisateur.

C’est plus lisible, plus typé, plus simple à tester.

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

Symfony généralise l’usage d’UUID v7 (avec composante temporelle), plus adaptés aux index et tris en base de données.

On trouve aussi une nouvelle contrainte Video pour valider les fichiers vidéo (durée, format, dimensions…) en s’appuyant sur FFmpeg.

7. Plan de migration : par où commencer ?

Si vous êtes aujourd’hui sur Symfony 5.x, 6.x ou 7.0–7.3, voici un plan réaliste pour aller vers 7.4 / 8.0 :

1. Mettre l’infra à niveau
   • Migrer vers PHP 8.4 (ou à minima préparer l’environnement pour y arriver)
   • Vérifier extensions, images Docker, pipeline CI, etc.
2. Monter d’abord en Symfony 7.4
   • C’est la version “tampon” qui contient toutes les features de 8.0 avec les dépréciations.
3. Traquer les dépréciations
   

   en lançant les tests avec :

   php bin/phpunit –display-deprecations

   • corriger ce qui vient du code projet,
   • remonter les dépréciations côté bundles et dépendances.
4. Nettoyer la configuration
   • migrer progressivement le XML vers YAML ou PHP,
   • adopter les nouveaux formats PHP là où ça fait sens.
5. Basculer sur Symfony 8.0
   • une fois les dépréciations corrigées, la migration est beaucoup plus douce,
   • prévoir néanmoins une phase de QA / perf pour valider les changements.
6. Mettre en place un rythme de mise à jour
   • planifier les upgrades 8.1, 8.2, 8.3, 8.4,
   • intégrer la gestion des dépréciations dans la dette technique “normale” du projet.

8. Comment Etixio peut vous accompagner

Chez Etixio, nos équipes Symfony accompagnent déjà des clients sur cette transition vers Symfony 7.4 / 8.0 :

• Audit Symfony & PHP 8.4
  • état des lieux version, dépendances, configuration, perf, sécurité,
  • cartographie des dépréciations et des risques.
• Plan de migration sur mesure
  • choix entre 7.4 LTS et 8.0 (ou les deux étapes),
  • roadmap chiffrée, adaptée à vos contraintes produit et métier.
• Mise en œuvre
  • refactor de code legacy,
  • migration des formulaires complexes vers FormFlow,
  • modernisation de la configuration (PHP array shapes, fin du XML),
  • optimisation des APIs (JsonStreamer, ObjectMapper, JsonPath).
• Accompagnement des équipes
  • pair programming avec vos devs,
  • transfert de compétences sur les nouvelles pratiques Symfony,
  • aide à structurer un cycle de mise à jour régulier (et moins douloureux).

En résumé

• 7.4 et 8.0 ont les mêmes features : la différence, c’est la dette technique et le support.
• 8.0 exige PHP 8.4 et s’appuie à fond sur les features modernes du langage.
• FormFlow, la nouvelle configuration PHP, JsonStreamer/ObjectMapper/JsonPath et les nouvelles contraintes de validation offrent un vrai saut de qualité pour les projets sérieux.

Si vous voulez :

• préparer votre migration Symfony 8,
• sécuriser vos choix techniques,
• ou faire auditer un existant Symfony avant une refonte,

On peut en discuter et construire ensemble un plan concret adapté à votre contexte.