---
title: 'Symfony 8.2 : les dix nouveautés à connaître'
description: 'Panorama des nouveautés de Symfony 8.2 : formulaires et workflows en attributs, chiffrement de colonnes Doctrine, OpenID Connect, Messenger outbox et workers parallèles, composant JsonSchema pour les agents IA.'
pubDate: 2026-11-02
family: 'php-symfony'
tags: []
heroImage: '/images/symfony-8-2-les-dix-nouveautes-a-connaitre.webp'
videoUrl: 'https://www.youtube.com/watch?v=Sn8vcWB8nW4'
faq:
  - question: 'Quelle version de PHP faut-il pour Symfony 8.2 ?'
    answer: "Symfony 8.2 demande PHP 8.4 ou plus : la page de release annonce PHP 8.4.0 minimum et le composer.json de la branche 8.2 déclare php >=8.4.1. C'est la même exigence que la branche 8.x, donc pas de saut de version PHP supplémentaire pour qui suit déjà la 8.1."
  - question: 'Symfony 8.2 est-elle déjà sortie ?'
    answer: 'Non. Au moment de cet article, la page officielle des releases indique le statut « Under development » avec une sortie prévue en novembre 2026 et une fin de support en juillet 2027. Les fonctionnalités décrites ici viennent de la branche 8.2 du dépôt et peuvent encore bouger avant la sortie.'
  - question: "Où suivre l'état exact des nouveautés de Symfony 8.2 ?"
    answer: 'Dans le guide UPGRADE-8.2.md du dépôt, qui liste les changements et les dépréciations, et dans la catégorie « living on the edge / 8.2 » du blog officiel, qui publie un article par fonctionnalité. Les deux sources sont mises à jour au fil des fusions de pull requests.'
---

Symfony 8.2 se prépare : la version mineure est encore en développement, mais la branche 8.2 du dépôt contient déjà l'essentiel des fonctionnalités. Cet article passe en revue les dix nouveautés présentées dans la vidéo, en les confrontant aux sources officielles : guide de mise à jour, code de la branche et articles du blog Symfony.

## Ce que Symfony 8.2 change, et où en est la version

La page officielle des releases donne le cadre : Symfony 8.2 est en statut « Under development », avec une sortie prévue en novembre 2026, une fin de support en juillet 2027 et une exigence de **PHP 8.4.0 minimum** ([symfony.com/releases/8.2](https://symfony.com/releases/8.2)). Le `composer.json` de la branche 8.2 précise `php >=8.4.1` ([dépôt symfony/symfony, branche 8.2](https://github.com/symfony/symfony/blob/8.2/composer.json)).

Il s'agit d'une version mineure : le guide de mise à jour rappelle qu'il ne doit pas y avoir de rupture de compatibilité importante, seulement des ruptures mineures signalées explicitement ([UPGRADE-8.2.md](https://github.com/symfony/symfony/blob/8.2/UPGRADE-8.2.md)). Ce guide est la référence à lire avant de tenter une montée de version, et il évolue jusqu'à la sortie.

## Un bundle par composant

C'est le changement structurel le plus visible. La majeure partie de ce que configure `FrameworkBundle` est déplacée dans un bundle livré par le composant lui-même : `asset`, `asset_mapper`, `cache`, `html_sanitizer`, `http_client`, `json_streamer`, `lock`, `mailer`, `messenger`, `notifier`, `property_access`, `property_info`, `rate_limiter`, `remote_event`, `router`, `scheduler`, `semaphore`, `serializer`, `translation`, `type_info`, `uid`, `validation`, `web_link`, `webhook` et `workflow` ([UPGRADE-8.2.md, section FrameworkBundle](https://github.com/symfony/symfony/blob/8.2/UPGRADE-8.2.md)).

Concrètement :

- chaque bundle s'enregistre automatiquement quand son composant est installé, et ses services sont chargés sans configuration ;
- `<clé>.enabled: false` désactive le bundle concerné ;
- l'ancienne clé `framework.*` continue de fonctionner comme alias, avec trois noms différents au niveau racine : `framework.assets` devient `asset`, `framework.translator` devient `translation` et `framework.workflows` devient `workflow` ;
- les clés transférées disparaissant de la configuration du framework, `debug:config framework <clé>` ne résout plus : il faut utiliser `debug:config <clé>`.

Deux nuances à garder en tête : `CacheBundle` et `RouterBundle` sont enregistrés indépendamment de leur configuration, et les bundles de composants retirent à la compilation les services dont les dépendances manquent, par exemple leurs pools de cache quand aucun pool `cache.system` n'existe.

## Formulaires et workflows déclarés en attributs

Les formulaires peuvent désormais être déclarés directement sur une classe de données, avec l'attribut `#[AsFormType]` et `DataClassType` dans le composant Form ([src/Symfony/Component/Form/Attribute/AsFormType.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/Form/Attribute/AsFormType.php), [DataClassType.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/Form/DataClassType.php)). Même logique côté Workflow, où `#[AsWorkflow]`, `#[Place]`, `#[Transition]` et les attributs d'écouteurs remplacent la configuration déclarative ([src/Symfony/Component/Workflow/Attribute/AsWorkflow.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/Workflow/Attribute/AsWorkflow.php)).

Le composant Form apporte aussi d'autres changements dans cette version : `createStepGroup()` sur `FormFlowBuilderInterface`, un identifiant rendu sur l'élément `<form>` pour les enfants utilisant l'option `form_attr`, et `CollectionType` qui crée ses entrées à partir des données de vue plutôt que du modèle. Côté workflow, `WorkflowInterface::getMarking()` accepte un argument `$context`.

Attention à la rupture mineure signalée dans le guide : la priorité de `AsEventListener` et des attributs `As*Listener` du Workflow est désormais `?int` et vaut `null` par défaut, ce qui signifie « aucune priorité déclarée ». Un code qui lisait cette propriété comme un entier doit passer à `$attribute->priority ?? 0`.

## Chiffrer des colonnes Doctrine

Symfony 8.2 introduit le composant **KeyManagement**, absent de la branche 8.1, qui abstrait les systèmes de gestion de clés (AWS KMS, Azure Key Vault, Google Cloud KMS, HashiCorp Vault Transit, Scaleway, serveurs KMIP) derrière une petite API d'encryption/décryption et de génération de clés de données ([README du composant](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/KeyManagement/README.md)).

Deux ponts Doctrine sont publiés comme paquets séparés :

- `symfony/doctrine-dbal-key-management` fournit un type DBAL qui décore un type parent avec du chiffrement d'enveloppe au niveau colonne, exposé sous le type `encrypted_string` ;
- `symfony/doctrine-orm-key-management` fournit l'attribut `#[BlindIndexed]` qui remplit un index aveugle à chaque flush.

Le chiffrement étant randomisé, deux valeurs identiques produisent deux chiffrés différents : un `WHERE email = ?` ne matchera jamais. Le composant répond à ce problème avec un index aveugle, une empreinte keyed stockée dans une colonne voisine, égale pour des valeurs égales. Le README précise les limites à connaître avant de l'utiliser : la colonne d'index révèle quelles lignes partagent une valeur et à quelle fréquence, l'étiquette n'est pas authentifiée (un écrivain en base peut la copier sur une autre ligne) et le composant est marqué **expérimental**, donc hors promesse de compatibilité ascendante.

## OpenID Connect natif et réauthentification

Le composant Security embarque une couche OIDC : `OidcDiscovery`, `OidcJwks`, `OidcLogoutToken` et `OidcEndedSessions` côté `Security\Http\Oidc`, plus les classes OIDC du côté authentificateur ([src/Symfony/Component/Security/Http/Oidc](https://github.com/symfony/symfony/tree/8.2/src/Symfony/Component/Security/Http/Oidc)). Côté `SecurityBundle`, le guide de mise à jour signale des évolutions autour du `OidcTokenHandler`, dont la dépréciation de `enforce_at_jwt_type` (l'option passera à `true` par défaut en 9.0) et un passage des jetons rejetés du niveau `error` à `debug`.

La vidéo mentionne également un **Sudo Mode** pour réauthentifier les actions sensibles. Je ne l'ai pas retrouvé dans le guide UPGRADE-8.2.md ni dans les sources de la branche 8.2 au moment d'écrire ces lignes : considère cette nouveauté comme annoncée par la vidéo et vérifie son état dans les sources officielles avant de compter dessus.

## Messenger : outbox, inbox et workers parallèles

Plusieurs évolutions concernent le traitement asynchrone :

- **Outbox** : la classe `OutboxStamp` marque un message stocké dans un transport outbox avec le nom du transport vers lequel il doit être transféré ([src/Symfony/Component/Messenger/Stamp/OutboxStamp.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/Messenger/Stamp/OutboxStamp.php)). Le blog officiel documente la partie inbox dans un article dédié ([New in Symfony 8.2: Messenger Inbox](https://symfony.com/blog/new-in-symfony-8-2-messenger-inbox)).
- **Workers parallèles** : `ParallelExecutionStrategy` exécute les messages sur un pool de workers via Amp, un message à la fois par worker, en gardant les handlers batch sur le worker qui détient leur état ([src/Symfony/Component/Messenger/Execution/ParallelExecutionStrategy.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/Messenger/Execution/ParallelExecutionStrategy.php)).
- **Transports signés** : les messages sont signés par un sérialiseur créé pour chaque transport, et non plus par des décorateurs de services de sérialisation. Le guide donne l'exemple de configuration d'un transport `async_signed` avec `sign: true`, et signale la dépréciation de la signature limitée aux handlers portant l'option `sign`.
- **Batchs** : quand un worker consomme le message qui remplit le batch d'un handler utilisant `BatchHandlerTrait`, le batch n'est plus traité pendant la distribution de ce message mais juste après, dans une distribution à part.

Ces changements sont les plus sensibles en production : si tu consommes des transports signés, le guide recommande de mettre à jour les applications consommatrices avant celles qui envoient.

## Event Dispatcher compilé et JsonSchema pour les agents IA

Le service `event_dispatcher` est désormais une instance de `CompiledEventDispatcher` : `CompileListenersPass` compile les appels `addListener()` des définitions du dispatcher, et appeler `addListener()`, `addSubscriber()`, `removeListener()` ou `removeSubscriber()` sur ce dispatcher est déprécié. Pour ajouter un écouteur à la volée, le guide propose d'encapsuler le dispatcher partagé dans un `ScopedEventDispatcher` ([src/Symfony/Component/EventDispatcher/CompiledEventDispatcher.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/EventDispatcher/CompiledEventDispatcher.php)). Un test qui ajoutait un écouteur au service `event_dispatcher` est l'endroit le plus probable où rencontrer cette dépréciation.

Enfin, le nouveau composant **JsonSchema** génère des schémas JSON à partir de types PHP. Son moteur vient du paquet `json-schema` d'API Platform, sans les parties spécifiques à API Platform, et le générateur lit les propriétés via PropertyInfo : le schéma suit donc les métadonnées du serializer et les contraintes du Validator ([New in Symfony 8.2: JsonSchema Component](https://symfony.com/blog/new-in-symfony-8-2-jsonschema-component), [src/Symfony/Component/JsonSchema/SchemaGenerator.php](https://github.com/symfony/symfony/blob/8.2/src/Symfony/Component/JsonSchema/SchemaGenerator.php)). C'est ce qui le rend intéressant pour les agents IA : OpenAPI utilise JSON Schema pour documenter les corps d'API, et les outils MCP s'en servent pour décrire les arguments attendus par un outil.

L'article officiel montre l'usage documenté suivant, **non exécuté pour cet article** :

```php
use App\Entity\Book;
use Symfony\Component\JsonSchema\SchemaGenerator;
use Symfony\Component\TypeInfo\Type;

$generator = SchemaGenerator::create();
$schema = $generator->generate(Type::object(Book::class));

echo json_encode($schema, \JSON_PRETTY_PRINT);
```

Résultat attendu d'après la documentation : une contrainte `NotBlank` devient `minLength: 1`, et une propriété sans valeur par défaut apparaît dans `required`. La configuration gère ensuite le dialecte (`OpenAPI 3.1`, `OpenAPI 3.0` ou JSON Schema 2020-12) et les groupes de sérialisation.

## Suivre la sortie avant de migrer

Aucun des extraits de cet article n'a été exécuté sur un projet : ils proviennent du guide de mise à jour, du code de la branche 8.2 et des articles du blog officiel. Avant de migrer, garde deux réflexes :

- lis [UPGRADE-8.2.md](https://github.com/symfony/symfony/blob/8.2/UPGRADE-8.2.md) en entier, il liste les dépréciations qui te concernent directement, notamment côté FrameworkBundle, Messenger et EventDispatcher ;
- parcours la catégorie [living on the edge / 8.2](https://symfony.com/blog/category/living-on-the-edge/8.2), qui publie un article par fonctionnalité au fil des fusions.

Pour voir la démonstration de ces dix nouveautés et le détail de chacune, regarde la vidéo complète sur la chaîne Pentiminax.

## Questions fréquentes

**Quelle version de PHP faut-il pour Symfony 8.2 ?**

Symfony 8.2 demande PHP 8.4 ou plus : la page de release annonce PHP 8.4.0 minimum et le composer.json de la branche 8.2 déclare php >=8.4.1. C'est la même exigence que la branche 8.x, donc pas de saut de version PHP supplémentaire pour qui suit déjà la 8.1.

**Symfony 8.2 est-elle déjà sortie ?**

Non. Au moment de cet article, la page officielle des releases indique le statut « Under development » avec une sortie prévue en novembre 2026 et une fin de support en juillet 2027. Les fonctionnalités décrites ici viennent de la branche 8.2 du dépôt et peuvent encore bouger avant la sortie.

**Où suivre l'état exact des nouveautés de Symfony 8.2 ?**

Dans le guide UPGRADE-8.2.md du dépôt, qui liste les changements et les dépréciations, et dans la catégorie « living on the edge / 8.2 » du blog officiel, qui publie un article par fonctionnalité. Les deux sources sont mises à jour au fil des fusions de pull requests.