Symfony 8.2 simplifie l’authentification à deux facteurs sans bundle dédié grâce aux preuves d’authentification conservées dans le token. L’exemple combine un mot de passe et un code SMS : un authenticator ajoute la seconde preuve, un voter exige les deux pour accéder à l’application et un point d’entrée redirige vers l’étape manquante. La configuration protège les routes par défaut, gère le cas « remember me » et limite les tentatives. Le code est testé sur la version de développement de Symfony 8.2.

Depuis Symfony 8.2, une ValidationFailedException non interceptée produit directement une réponse HTTP 422 structurée. L’article distingue les erreurs 400 (requête illisible), 415 (format non pris en charge), 422 (données invalides) et 409 (conflit). Il recommande le format Problem Details (RFC 9457), des chemins de champs et codes d’erreur stables pour les clients, ainsi qu’une gestion cohérente des violations d’unicité Doctrine. Enfin, il conseille de limiter le bruit des logs, surveiller les pics de 422 et tester le contrat de réponse plutôt que les messages traduits.

Dans cet article, l'équipe de JoliCode décrit comment ils ont migré un petit projet en production de Symfony 7.3 vers la toute récente version 8.0, en passant d’abord par la 7.4 pour corriger l’ensemble des dépréciations : après avoir mis à jour les « recipes » via Symfony Flex, ajusté les dépendances (souvent en forçant les forks des bundles encore non compatibles), modifié les imports d’attributs (ex. @Route → #[Route]) et les appels aux contraintes (remplacement d’arguments de type tableau par des arguments nommés), ils ont finalement basculé sous PHP 8.4 et lancé Symfony 8 avec succès en production. Le bilan est positif : l’opération s’est révélée relativement simple pour un petit code-base — mais JoliCode rappelle que, pour un projet sérieux, rester sur Symfony 7.4 (version LTS) reste un choix plus prudent.