Symfony 8.2 doit sortir fin novembre 2026, avec une fin de support prévue en juillet 2027. La version demande PHP 8.4.0 ou plus récent. La branche reste en développement. Ses API peuvent donc changer avant la publication finale et les exemples doivent rester dans un projet de test.

<?php
namespace App\Controller;

use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

class AccountController extends AbstractController
{
    #[Route('/account/delete', name: 'app_delete_account')]
    #[IsGranted('IS_AUTHENTICATED_VERY_RECENTLY')]
    public function deleteAccount(): Response
    {
    }
}

Chaque composant Symfony fournira désormais son propre bundle, sa configuration et ses services. Symfony 8.2 ajoute 29 bundles, dont CacheBundle, HttpClientBundle, MailerBundle et MessengerBundle. L’installation d’un composant enregistre automatiquement son bundle, sans modification de config/bundles.php. Les réglages framework.* continuent de fonctionner sans dépréciation. La racine framework peut disparaître progressivement. framework.assets devient asset, framework.translator devient translation et framework.workflows devient workflow. Lock et semaphore acceptent directement une DSN. La commande de diagnostic devient debug:config mailer, à la place de debug:config framework mailer. Les formulaires n’activent plus automatiquement la validation. L’installation de symfony/validator suffit. RedirectController rejoint Routing et TemplateController rejoint TwigBundle. Les services des bundles supplémentaires sont créés à la demande, ce qui évite un coût supplémentaire sur les requêtes. FrameworkBundle reste le cœur du framework HTTP.

Les auteurs de bundles disposent de deux méthodes ConfigBuilder, aliasOf() et appendFromCallback(). aliasOf() transmet un nœud racine à la configuration d’une autre extension. Cette compatibilité conserve framework.workflows lorsque la configuration appartient à Workflow. appendFromCallback() ajoute des nœuds depuis un callback en conservant la chaîne fluide. Les classes déplacées hors de FrameworkBundle sont dépréciées.

La sécurité ajoute une réauthentification de type sudo. IS_AUTHENTICATED_RECENTLY valide une authentification effectuée dans les deux dernières heures par défaut. IS_AUTHENTICATED_VERY_RECENTLY réduit cette fenêtre à cinq minutes. Ces contrôles fonctionnent dans access_control, Twig et les attributs des contrôleurs. Les expressions de sécurité reçoivent is_recently_authenticated() et is_very_recently_authenticated(). Un cookie remember-me ne valide aucun de ces contrôles. Les deux durées se règlent en secondes avec recent_authentication_lifetime et very_recent_authentication_lifetime. Un refus renvoie HTTP 403 par défaut.

ReAuthenticationEntryPointInterface permet de rediriger l’utilisateur vers une confirmation de mot de passe, puis vers l’action initiale. Le firewall utilise pour cela re_authentication_entry_point. L’authenticator OIDC implémente cette interface et peut renvoyer l’utilisateur chez son fournisseur avec prompt=login. Symfony vérifie aussi le claim auth_time du jeton d’identité. Une connexion silencieuse depuis une ancienne session du fournisseur ne compte donc pas comme une authentification récente. Les tokens enregistrent les méthodes d’authentification utilisées et leur dernier horodatage. Les noms suivent la RFC 8176, OIDC les lit dans amr et les authenticators personnalisés peuvent les déclarer avec AuthenticationMethodBadge. Un trust resolver personnalisé peut imposer AuthenticationMethod::HARDWARE_KEY dans une fenêtre de cinq minutes.

Symfony 8.2 fournit aussi un authenticator oidc_login pour le flux Authorization Code complet d’OpenID Connect. Mathieu Santostefano a dirigé ce travail. Les paquets nécessaires sont symfony/http-client et web-token/jwt-library. Les endpoints du fournisseur sont découverts dans .well-known/openid-configuration. Une page protégée redirige vers le fournisseur, qui revient par défaut sur /oidc/callback. La recette Symfony Flex importe les routes de connexion, dont _oidc_login_start_main. State et nonce protègent le flux, PKCE est activé par défaut et les signatures des jetons sont vérifiées avec les clés JWKS mises en cache. Symfony valide iss, aud, exp, iat et la valeur iss de la réponse. Les endpoints doivent utiliser HTTPS, sauf les hôtes loopback en développement local. Les redirections ne sont pas suivies.

Le provider OIDC intégré peut créer des utilisateurs à partir des claims. Un fournisseur personnalisé implémentant AttributesBasedUserProviderInterface reçoit tous les claims comme deuxième argument de loadUserByIdentifier(). user_identifier_claim peut choisir email comme identifiant. user_data_source peut demander les claims du jeton d’identité plutôt que ceux de UserInfo. authorization_params ajoute des paramètres fixes et OidcAuthorizationRequestEvent permet de traiter ceux qui dépendent de la requête. L’authentification du client accepte client_secret_basic, client_secret_post, client_secret_jwt, private_key_jwt et none. Les refresh tokens, la déconnexion chez le fournisseur et max_age sont également prévus. oidc_login n’ajoute volontairement aucun badge remember-me, puisque le fournisseur gère l’authentification. max_age ou prompt=login permet d’en contrôler la fraîcheur.

Messenger reçoit une option outbox transactionnelle et une option claim_check. L’outbox écrit d’abord le message dans un transport Doctrine utilisant la même connexion que les données de l’application. Un relais l’envoie ensuite vers AMQP, Amazon SQS ou un autre broker cible. Une configuration courante utilise db_outbox et doctrine://default?queue_name=outbox. Deux workers distincts exécutent messenger:consume db_outbox et messenger:consume orders. Le délai s’applique dans l’outbox. Les erreurs de transfert suivent la stratégie de retry et le failure transport de l’outbox, les erreurs de traitement suivent ceux du transport cible. L’ordre des messages transférés n’est pas garanti.

claim_check place les messages qui dépassent une taille encodée dans un pool PSR-6. Le calcul inclut le corps et les headers. Le transport transmet un identifiant aléatoire et une somme de contrôle. Le worker recharge le message, vérifie son intégrité et le traite normalement. Redis, Valkey, Memcached, PDO et Doctrine DBAL font partie des pools compatibles. Les producteurs et les consommateurs doivent atteindre le même pool dédié. Sa durée de vie doit couvrir les délais, les retries et la conservation dans le failure transport. Une référence absente provoque ClaimCheckNotFoundException, encapsulée dans MessageDecodingFailedException, puis suit le parcours habituel de retry.

Le Serializer rend SerializedName et SerializedPath répétables et leur permet d’accepter des groupes. Les mappings YAML et XML bénéficient aussi de cette possibilité. Une propriété peut porter des noms différents pour des groupes comme api_v1 et api_v2. AbstractNormalizer::IGNORED_GROUPS et withIgnoredGroups() excluent certains groupes dans un contexte donné. #[Ignore] continue d’exclure une propriété partout. Une option de contexte active au choix la convention Validator du groupe Default. Des serializers nommés peuvent désormais être associés à MapRequestPayload, MapQueryString, Serialize et Messenger. L’API peut utiliser snake_case avec un service, tandis que messenger.transport.symfony_serializer en utilise un autre. Les erreurs de validation HTTP 422 utilisent toujours le serializer par défaut. Leurs chemins de propriétés ignorent le name converter du serializer nommé.

Le composant KeyManagement, encore expérimental, propose une API commune pour AWS KMS, Azure Key Vault, Google Cloud KMS et HashiCorp Vault. symfony/key-management contient les interfaces, le chiffrement par enveloppe et des backends locaux fondés sur libsodium et OpenSSL. Les bridges sont symfony/aws-key-management, symfony/azure-keyvault-key-management, symfony/google-cloud-key-management et symfony/hashicorp-vault-key-management. Le paquet de développement s’installe avec composer require symfony/key-management:^8.2@dev.

Le mode direct envoie les données au KMS et convient aux petites valeurs. AWS KMS impose une limite de 4 KB dans ce mode. Le mode enveloppe demande une clé de données, chiffre localement avec AES-256-GCM et conserve la clé protégée avec le ciphertext. L’application ne manipule que l’identifiant de la clé, comme un alias ou un ARN. Les clients sont configurés par DSN sous key_management. Un client sodium avec une clé intégrée convient au développement. EnvelopeEncrypterInterface, EncrypterInterface et DecrypterInterface exposent les services. #[Target] sélectionne un client secondaire. Le composant fournit key-management:encrypt, key-management:decrypt, key-management:generate-data-key et key-management:rewrap-data-keys. La barre de debug web affiche les appels aux clients KMS.

Les bridges Doctrine ajoutent EncryptedType et l’attribut BlindIndexed pour rechercher des colonnes chiffrées. Le chiffrement produit des ciphertexts aléatoires, donc l’index conserve un digest lié à la clé pour les recherches. Le service d’index Email demande un client KMS et une clé enveloppée créée par key-management:generate-data-key. Les types Doctrine chiffrés sont enregistrés par un service EncryptedTypes lors du boot du kernel. Le bridge DBAL peut stocker les clés de données dans une table. Chaque ligne ne conserve alors qu’une référence de 16 octets et le KMS n’est appelé qu’une fois par clé. Rewrap permet de migrer les clés vers un autre master key ou un autre fournisseur sans réécrire les données.

D’autres annonces concernent la signature et le chiffrement PGP/MIME avec PgpSigner et PgpEncrypter. S/MIME reçoit on_missing_certificate. Sa valeur par défaut send_unencrypted est dépréciée, et Symfony 9.0 lèvera une exception dans ce cas. Symfony 8.2 ajoute aussi un JSON Schema généré pour la configuration, l’inspection des wildcards de hiérarchie des rôles avec debug:roles, des graphes dans le profiler, des règles de cache distinctes pour CDN et navigateurs, des informations Cache-Status, des workers Messenger plus rapides avec traitement parallèle et améliorations AMQP, des modèles d’e-mails hébergés par le fournisseur avec réglages de suivi, ainsi que des optimisations pour les pages web, les API, la console, le développement et la construction du cache. La série Living on the edge du blog Symfony recense les annonces.