Les objets paresseux natifs

Le système de proxy de Symfony, utilisé pour l’initialisation paresseuse des services et les proxies d’entités de Doctrine, a historiquement reposé sur la génération de code. Les classes proxy étaient générées au cache warmup, stockées sous forme de fichiers, et chargées à la demande. Ça fonctionnait, mais ça ajoutait une vraie complexité : des fichiers générés à gérer, un cache à invalider, du code qui ne ressemblait en rien à la classe qu’il proxyifiait.

PHP 8.4 a ajouté des objets paresseux natifs. Symfony 8.0 les utilise. Le LazyGhostTrait et le LazyProxyTrait qui alimentaient l’ancien système sont supprimés. La création de proxy est maintenant une opération à l’exécution soutenue par le moteur lui-même, pas une étape de génération de code.

Pour les développeurs d’applications, le changement est essentiellement invisible : les services paresseux fonctionnent toujours. Pour les auteurs de frameworks et bibliothèques, une surface significative de complexité vient de disparaître.

FormFlow

Les formulaires multi-étapes ont toujours été un exercice DIY dans Symfony. Gestion de session, suivi des étapes, validation partielle, navigation entre les étapes : chaque projet roulait sa propre solution ou importait un bundle tiers.

8.0 introduit FormFlow : un mécanisme intégré pour les wizards de formulaires multi-étapes. Les étapes sont définies comme une séquence de types de formulaires, la validation partielle est scopée à l’étape courante, et la gestion de session est gérée automatiquement.

#[AsFormFlow]
class CheckoutFlow extends AbstractFormFlow
{
    protected function defineSteps(): Steps
    {
        return Steps::create()
            ->add('shipping', ShippingType::class)
            ->add('payment', PaymentType::class)
            ->add('review', ReviewType::class);
    }
}

La config XML et PHP fluent supprimées

La dépréciation de 7.4 du format de configuration PHP fluent devient une suppression définitive dans 8.0. La configuration XML sort aussi comme format de première classe. Les formats supportés pour la configuration applicative sont maintenant YAML et tableaux PHP. L’empreinte rétrécit, mais ce qui reste est genuinement meilleur.

Ce qui est supprimé d’autre

• Le support PHP 8.2 et 8.3 (8.4 minimum)
• ContainerAwareInterface et ContainerAwareTrait
• L’usage interne de LazyGhostTrait et LazyProxyTrait par Symfony
• La surcharge de méthode HTTP pour GET et HEAD (seul POST a du sens sémantiquement)

Symfony 8.0 est une rupture propre, et ce genre de rupture ne devient possible que quand le plancher PHP s’élève. Les objets paresseux de PHP 8.4 sont l’exemple le plus clair : la fonctionnalité existe maintenant dans le langage, donc le framework peut simplement arrêter de l’implémenter.

Console devient plus ergonomique pour les commandes invocables

Les commandes invocables reçoivent une mise à niveau significative. L’attribut #[Input] transforme un DTO en bag d’arguments/options de la commande. Fini d’appeler $input->getArgument() dans le handler :

#[AsCommand(name: 'app:send-report')]
class SendReportCommand
{
    public function __invoke(
        #[Input] SendReportInput $input,
    ): int {
        // $input->email, $input->dryRun, etc.
        return Command::SUCCESS;
    }
}

BackedEnum est supporté dans les commandes invocables, donc une option déclarée comme enum Status est validée et castée automatiquement. Les commandes interactives reçoivent les attributs #[Interact] et #[Ask] pour déclarer les prompts de questions en ligne. CommandTester fonctionne avec les commandes invocables sans câblage supplémentaire.

Le Routing trouve ses propres contrôleurs

Les routes définies via #[Route] sur les classes de contrôleurs sont auto-enregistrées sans avoir besoin d’une entrée resource: explicite dans config/routes.yaml. Le tag routing.controller est appliqué automatiquement. On contrôle toujours quels répertoires sont scannés, mais la config YAML rétrécit jusqu’à un pointeur vers un répertoire plutôt qu’une liste de fichiers manuelle.

#[Route] reçoit aussi un paramètre _query pour définir des paramètres de query à la génération, et plusieurs environnements dans l’option env.

Sécurité : CSRF et OIDC reçoivent de meilleurs outils

#[IsCsrfTokenValid] reçoit un argument $tokenSource pour spécifier d’où vient le token (header, cookie, champ de formulaire) plutôt que de s’appuyer sur une convention fixe. SameOriginCsrfTokenManager ajoute la validation du header Sec-Fetch-Site, un mécanisme de protection CSRF natif au navigateur qui n’a pas besoin d’injection de token du tout.

La commande security:oidc-token:generate crée des tokens pour tester les endpoints protégés OIDC en local. Plusieurs endpoints de découverte OIDC sont maintenant supportés, utile dans les setups multi-tenant où chaque tenant a son propre identity provider.

Deux nouvelles fonctions Twig : access_decision() et access_decision_for_user() exposent le résultat du voter d’autorisation dans les templates sans passer par la façade de sécurité. #[IsGranted] peut être sous-classé pour les patterns d’autorisation répétés qui méritent leur propre attribut nommé.

ObjectMapper et JsonStreamer sortent d’expérimental

Les deux composants introduits dans 7.x sont stables dans 8.0. ObjectMapper mappe entre objets sans transformateurs écrits à la main, via une configuration basée sur des attributs. JsonStreamer lit et écrit de grands JSON sans charger le document entier en mémoire, et il supporte maintenant les propriétés synthétiques : des champs virtuels calculés à la sérialisation.

JsonStreamer abandonne aussi sa dépendance sur nikic/php-parser. La génération de code pour le reader/writer utilise maintenant un mécanisme interne plus simple, supprimant une lourde dépendance de dev.

Uid par défaut vers UUIDv7

UuidFactory génère maintenant UUIDv7 par défaut au lieu d’UUIDv4. La différence : v7 est ordonné dans le temps, donc les UUIDs générés se trient chronologiquement. Ça compte beaucoup pour la performance des index de base de données. MockUuidFactory fournit une génération déterministe d’UUID dans les tests.

Yaml lève une erreur sur les clés dupliquées

Auparavant, un fichier YAML avec deux clés identiques gardait silencieusement la dernière. 8.0 lève une erreur de parsing. Ça attrape de vrais bugs : les clés dupliquées dans services.yaml ou config/packages/*.yaml sont presque toujours des erreurs de copier-coller et on veut définitivement être informé.

Validator : contrainte Video et protocoles wildcard

Une contrainte Video rejoint la contrainte Image pour valider les fichiers vidéo uploadés (type MIME, durée, codec). La contrainte Url accepte protocols: ['*'] pour autoriser n’importe quel schéma conforme à la RFC 3986, utile pour stocker des URLs arbitraires qui incluent git+ssh://, file://, ou des schémas d’application personnalisés.

Messenger : retry natif SQS et nouveaux événements

Le transport SQS peut maintenant utiliser sa propre configuration native de retry et de dead-letter queue au lieu du middleware de retry de Symfony. Pour les queues à haut volume sur AWS, ça supprime un aller-retour par PHP pour les échecs transitoires. Un MessageSentToTransportsEvent se déclenche après qu’un message est dispatché, portant des informations sur quels transports l’ont réellement reçu.

messenger:consume reçoit --exclude-receivers pour se combiner avec --all.

Mailer : transport Microsoft Graph

Un nouveau transport envoie des emails via l’API Microsoft Graph, ce que Microsoft recommande pour les applications sur Azure Active Directory ces jours-ci. Les autres options (relai SMTP, Exchange EWS) fonctionnent encore, mais Graph est le bon choix pour les nouveaux déploiements Azure.

Workflow : transitions pondérées

Les transitions peuvent maintenant déclarer des poids. Quand plusieurs transitions sont activées depuis la même place, celle avec le poids le plus élevé gagne. Ça permet d’exprimer la priorité directement dans la définition du workflow sans ajouter un guard qui lit un compteur externe.

return (new Definition(states: ['draft', 'review', 'published']))
    ->addTransition(new Transition('publish', 'review', 'published', weight: 10))
    ->addTransition(new Transition('reject', 'review', 'draft', weight: 1));

Lock : LockKeyNormalizer

LockKeyNormalizer normalise une clé de lock vers une string cohérente avant le hachage. Utile quand la clé est dérivée d’entrées utilisateur ou de données externes qui peuvent varier en espaces blancs ou casse : le normalizer s’assure que la même clé logique correspond toujours au même lock.

HttpFoundation : méthode QUERY et parsing de corps plus propre

La méthode IETF QUERY (une méthode sûre et idempotente avec un corps, contrairement à GET) est maintenant supportée partout dans la stack : Request, cache HTTP, WebProfiler et HttpClient. Si on construit des APIs de recherche qui nécessitent un corps de requête structuré et veulent aussi du cache, QUERY est le bon choix sémantique.

Request::createFromGlobals() parse maintenant automatiquement le corps des requêtes PUT, DELETE, PATCH et QUERY.

Config : schéma JSON pour la validation YAML

Symfony 8.0 auto-génère un fichier JSON Schema pour chaque section de configuration. Les IDEs qui supportent JSON Schema pour les fichiers YAML (VS Code, PhpStorm) peuvent maintenant valider config/packages/*.yaml contre ces schémas et fournir de l’autocomplétion sans plugin. Le schéma est généré pendant le cache warmup et placé dans config/reference.php.

Runtime : auto-détection FrankenPHP

Le composant Runtime détecte FrankenPHP automatiquement et active le mode worker sans package supplémentaire ni variable d’environnement. Si $_SERVER['APP_RUNTIME'] est défini, cette classe de runtime a la priorité. On peut aussi choisir le renderer d’erreurs basé sur APP_RUNTIME_MODE, ce qui est utile quand on fait tourner la même codebase dans des contextes HTTP et CLI avec des besoins de présentation d’erreurs différents.

La signature de messages dans Messenger

La sécurité des transports dans Messenger a toujours été le problème de l’application à résoudre. 7.4 ajoute la signature de messages : un mécanisme basé sur des stamps qui signe les messages dispatchés et valide les signatures à la réception.

Le cas d’usage cible est les scénarios multi-tenant ou de transport externe où on a besoin d’une preuve cryptographique qu’un message n’a pas été altéré ni injecté depuis l’extérieur. La configuration vit au niveau du transport :

framework:
    messenger:
        transports:
            async:
                dsn: '%env(MESSENGER_TRANSPORT_DSN)%'
                options:
                    signing_key: '%env(MESSENGER_SIGNING_KEY)%'

Configuration en tableaux PHP

Les formats de configuration de Symfony ont toujours été YAML (défaut), XML et PHP. Le format PHP existait mais était maladroit : un DSL builder fluent qui nécessitait du chaînage de méthodes et ne donnait rien d’utile à l’IDE.

7.4 remplace le format fluent par des tableaux PHP standard. Les IDEs peuvent maintenant vraiment l’analyser, config/reference.php est auto-généré comme référence avec annotations de types, et le résultat ressemble à des données plutôt qu’à du code :

return static function (FrameworkConfig $framework): void {
    $framework->router()->strictRequirements(null);
    $framework->session()->enabled(true);
};

Le format fluent est déprécié. Les tableaux sont l’avenir, et honnêtement c’est un meilleur format.

Améliorations OIDC

#[IsSignatureValid] valide les URLs signées directement dans les contrôleurs, supprimant le boilerplate de la validation manuelle. OpenID Connect supporte maintenant plusieurs endpoints de découverte, et une nouvelle commande security:oidc-token:generate rend le dev et les tests beaucoup moins pénibles.

La fenêtre de support

7.4 LTS : bugs jusqu’en novembre 2028, correctifs de sécurité jusqu’en novembre 2029. Le chemin vers 8.4 LTS (la prochaine cible long terme) passe par les notices de dépréciation de 7.4 et la mise à jour PHP 8.4. Corriger les dépréciations maintenant et le saut vers 8.x sera beaucoup moins douloureux.

Les attributs deviennent plus précis

#[CurrentUser] accepte maintenant les types union, ce qui compte en pratique quand une route est accessible par plus d’une classe utilisateur :

public function index(#[CurrentUser] AdminUser|Customer $user): Response

#[Route] accepte un tableau pour l’option env, donc une route de debug active seulement en dev et test n’a plus besoin de deux définitions séparées. #[AsDecorator] est maintenant répétable, ce qui signifie qu’une classe peut décorer plusieurs services à la fois. Les signatures de méthode #[AsEventListener] acceptent les types d’événements union. #[IsGranted] reçoit une option methods pour limiter une vérification d’autorisation à des verbes HTTP spécifiques sans dupliquer la route.

La classe Request arrête d’en faire trop

Request::get() est dépréciée, et franchement bonne débarrassance. La méthode cherchait dans les attributs de route, puis les paramètres de query, puis le corps de la requête, dans cet ordre, retournant silencieusement ce qu’elle trouvait en premier. Cette ambiguïté causait de vrais bugs. Elle est supprimée dans 8.0 ; dans 7.4 elle fonctionne encore mais déclenche une dépréciation. Les remplacements sont explicites : $request->attributes->get(), $request->query->get(), $request->request->get().

Le parsing du corps pour les requêtes PUT, PATCH, DELETE et QUERY arrive en même temps. Auparavant Symfony ne parsait application/x-www-form-urlencoded et multipart/form-data que pour POST. Ces mêmes types de contenu sont maintenant parsés pour les autres méthodes accessibles en écriture aussi, ce qui tue un contournement REST API courant.

La surcharge de méthode HTTP pour GET, HEAD, CONNECT et TRACE est dépréciée. Surcharger une méthode sûre avec un header était de toute façon toujours sémantiquement cassé. On peut maintenant autoriser explicitement seulement les méthodes qui ont du sens pour son application :

Request::setAllowedHttpMethodOverride(['PUT', 'PATCH', 'DELETE']);

Les Workflows acceptent les BackedEnums

Les places et transitions de Workflow peuvent maintenant être définies avec des backed enums PHP, à la fois en YAML (via le tag !php/enum) et en config PHP. Le marking store fonctionne avec les valeurs d’enum directement, donc le modèle de domaine et la définition du workflow utilisent enfin les mêmes types :

framework:
    workflows:
        blog_publishing:
            initial_marking: !php/enum App\Status\PostStatus::Draft
            places: !php/enum App\Status\PostStatus
            transitions:
                publish:
                    from: !php/enum App\Status\PostStatus::Review
                    to: !php/enum App\Status\PostStatus::Published

Étendre la validation et la sérialisation pour les classes tierces

Besoin d’ajouter des métadonnées de validation ou de sérialisation à une classe d’un bundle qu’on ne possède pas ? 7.4 a #[ExtendsValidationFor] et #[ExtendsSerializationFor] pour ça. On écrit une classe compagnon avec ses annotations supplémentaires, on pointe l’attribut vers la classe cible, et Symfony fusionne les métadonnées à la compilation du conteneur :

#[ExtendsValidationFor(UserRegistration::class)]
abstract class UserRegistrationValidation
{
    #[Assert\NotBlank(groups: ['my_app'])]
    #[Assert\Length(min: 3, groups: ['my_app'])]
    public string $name = '';

    #[Assert\Email(groups: ['my_app'])]
    public string $email = '';
}

Symfony vérifie à la compilation que les propriétés déclarées existent réellement sur la classe cible. Un renommage ne cassera pas silencieusement la validation.

DX : ce qui ne fait pas la une mais compte

Le helper Question dans Console accepte un timeout. Demander à l’utilisateur de confirmer quelque chose, et s’il ne répond pas en N secondes, la réponse par défaut s’applique. Très pratique dans les scripts de déploiement qui ne peuvent pas se permettre d’attendre éternellement un humain.

messenger:consume reçoit --exclude-receivers. Combiné avec --all, il permet de consommer depuis tous les transports sauf des spécifiques :

bin/console messenger:consume --all --exclude-receivers=low_priority

Le mode worker FrankenPHP est maintenant auto-détecté. Si le processus tourne dans FrankenPHP, Symfony bascule en mode worker automatiquement. Pas de package supplémentaire nécessaire.

La commande debug:router cache les colonnes Scheme et Host quand toutes les routes utilisent ANY, ce qui supprime beaucoup de bruit de la sortie par défaut. Les méthodes HTTP sont maintenant aussi colorées.

Les tests fonctionnels reçoivent $client->getSession() avant la première requête. Auparavant il fallait faire au moins une requête pour accéder à la session, ce qui était agaçant. Maintenant on peut pré-remplir les tokens CSRF ou les flags A/B en amont :

$session = $client->getSession();
$session->set('_csrf/checkout', 'test-token');
$session->save();

Lock : store DynamoDB

DynamoDbStore arrive comme nouveau backend de Lock. Utile dans les déploiements AWS-natifs où Redis n’est pas dans la stack, et ça fonctionne exactement comme n’importe quel autre store :

$store = new DynamoDbStore('dynamodb://default/locks');
$factory = new LockFactory($store);

Bridge Doctrine : types day point et time point

Deux nouveaux types de colonnes Doctrine : day_point stocke une valeur date uniquement (sans composant heure) et time_point stocke une valeur heure uniquement, tous deux mappant vers DatePoint. Bien quand le domaine sépare genuinement la date de l’heure :

#[ORM\Column(type: 'day_point')]
public DatePoint $birthDate;

#[ORM\Column(type: 'time_point')]
public DatePoint $openingTime;

Routing : paramètres de query explicites

La clé _query dans la génération d’URL permet de définir les paramètres de query explicitement, séparément des paramètres de route. Ça compte quand un paramètre de route et un paramètre de query partagent le même nom :

$url = $urlGenerator->generate('report', [
    'site' => 'fr',
    '_query' => ['site' => 'us'],
]);
// /report/fr?site=us

WebLink : parsing des en-têtes Link entrants

HttpHeaderParser parse les en-têtes de réponse Link en objets structurés. Avant ça, parser des en-têtes Link depuis des réponses d’API nécessitait soit d’importer une bibliothèque tierce, soit d’écrire des regex. Le cas d’usage : les APIs HTTP qui annoncent des ressources liées ou la pagination via des en-têtes Link, comme le fait l’API GitHub.

Le parsing HTML5 est plus rapide sur PHP 8.4

DomCrawler et HtmlSanitizer basculent vers le parser HTML5 natif de PHP 8.4 quand il est disponible. Pas de changements de code nécessaires de votre côté. Le parser natif est plus rapide et plus conforme à la spec que le fallback précédent. Sur PHP 8.2 ou 8.3, rien ne change.

Translation : StaticMessage

StaticMessage implémente TranslatableInterface mais ne traduit intentionnellement pas. Elle passe la string inchangée quelle que soit la locale. Le cas d’usage : les réponses d’API qui doivent rester dans une langue fixe quelle que soit la locale de l’utilisateur, ou les entrées de log d’audit où on doit préserver le texte original tel quel.

La suppression la plus visible : les annotations Doctrine. @Route, @ORM\Column, @Assert — disparus. Les attributs PHP natifs sont l’approche recommandée depuis Symfony 5.2. 7.0 rend juste ça officiel.

Les attributs partout

La migration des annotations vers les attributs est principalement mécanique : la syntaxe passe de @ à #[], et les références de classes passent des classes d’annotation Doctrine aux classes d’attribut PHP :

// avant
/** @Route('/users', methods={"GET"}) */

// après
#[Route('/users', methods: ['GET'])]

Le vrai gain n’est pas juste la syntaxe : les attributs sont validés par le moteur PHP, pas un parseur de docblock. Les IDEs peuvent les résoudre sans plugins personnalisés. Les outils d’analyse statique les comprennent nativement. Fini les “ça échoue silencieusement à l’exécution à cause d’une faute de frappe dans un commentaire.”

Workflow avec attributs PHP

Les listeners et guards d’événements Workflow peuvent maintenant être enregistrés via des attributs :

#[AsGuard(workflow: 'order', transition: 'ship')]
public function canShip(Event $event): void
{
    if (!$event->getSubject()->isPaymentConfirmed()) {
        $event->setBlocked(true);
    }
}

Le profiler de workflow, un panneau dédié montrant le marquage courant et les transitions disponibles, est un outil de debug vraiment utile quand on travaille avec des machines à états complexes.

DatePoint dans le composant Clock

DatePoint, le DateTime immutable avec gestion stricte des erreurs introduit dans 6.4, est maintenant la façon recommandée de travailler avec les dates. Combiné avec les propriétés readonly de PHP 8.2, les objets-valeur de dates dans le code de domaine deviennent presque trivialement propres :

readonly class Order {
    public function __construct(
        public DatePoint $createdAt,
        public ?DatePoint $shippedAt = null,
    ) {}
}

Ce que 7.0 supprime

La liste complète des suppressions : le support des annotations Doctrine, le bridge du composant Templating, le bridge ProxyManager, le bridge Monolog pour les versions inférieures à 3.0, et le transport Sendinblue (remplacé par Brevo). Le support PHP 8.0 et 8.1 se termine aussi. 8.2 est le plancher maintenant.

Monter de 6.4 avec toutes les notices de dépréciation corrigées, et 7.0 est fluide. Sauter cette étape et on s’expose à une mauvaise surprise.

Scheduler et AssetMapper diplômés

Deux composants qui sont sortis en expérimental dans 6.3 sont maintenant stables : Scheduler et AssetMapper. Stable signifie des APIs verrouillées, plus de mises en garde @experimental, et ils apparaissent correctement dans le guide de mise à jour. On peut vraiment compter sur eux maintenant.

Scheduler reçoit #[AsCronTask] et #[AsPeriodicTask] pour l’enregistrement de tâches par attribut, la modification de planning à l’exécution avec recalcul du heap, FailureEvent, et une option --date sur schedule:debug. AssetMapper ajoute le support des fichiers CSS dans l’importmap, une commande outdated, une commande audit, et le préchargement automatique via WebLink.

#[AsCronTask('0 2 * * *')]
class NightlyReportMessage {}

#[AsPeriodicTask(frequency: '1 hour')]
class HourlyCleanupMessage {}

Le câblage de services reçoit deux nouveaux attributs

#[AutowireLocator] et #[AutowireIterator] ont atterri dans 6.4 et sont stables dans 7.0. Ils remplacent la configuration verbose XML/YAML des service locators taggués par quelque chose qu’on peut juste mettre directement en PHP :

class HandlerRegistry
{
    public function __construct(
        #[AutowireLocator('app.handler', indexAttribute: 'key')]
        private ContainerInterface $handlers,
    ) {}
}

#[Target] est aussi plus intelligent : quand un service a un alias d’autowiring nommé comme invoice.lock.factory, on peut maintenant écrire #[Target('invoice')] au lieu du nom complet de l’alias. Moins de bruit quand le type dit déjà ce qu’on veut.

Messenger reçoit une gestion plus précise des échecs

RejectRedeliveredMessageException dit au worker de ne pas retenter un message, ce qui est pratique quand un message arrive deux fois à cause d’un timeout d’ack du transport et qu’on a besoin d’une sémantique exactly-once. messenger:failed:remove --all vide tout le transport d’échec en un coup, pas de boucle nécessaire. Les retries échoués peuvent aussi aller directement au transport d’échec, en contournant entièrement la queue de retry.

Plusieurs hôtes Redis Sentinel sont maintenant supportés dans le DSN :

redis-sentinel://host1:26379,host2:26379,host3:26379/mymaster

Console reçoit les noms de signaux et le profilage de commandes

SignalMap mappe les entiers de signaux à leurs noms POSIX. Quand un worker attrape SIGTERM, le log dit maintenant SIGTERM au lieu de 15. Petite chose, vraie amélioration. ConsoleTerminateEvent est dispatché même quand le processus se termine via signal, ce qui n’était pas le cas avant 7.0.

Le profilage de commandes arrive aussi : passer --profile à bin/console et les données collectées vont directement dans le profiler Symfony, navigable depuis l’UI web.

Form : des petites choses qui s’accumulent

ChoiceType reçoit une option duplicate_preferred_choices. La définir à false et on arrête de montrer la même option deux fois quand les choix préférés chevauchent la liste complète. FormEvent::setData() est déprécié pour les événements où les données sont déjà verrouillées à ce point du cycle de vie. La barre oblique auto-fermante sur les éléments <input> est aussi supprimée : <input> est un élément void en HTML5 et la barre oblique était techniquement invalide.

Le support des enums dans les formulaires est bien fait : ChoiceType rend les backed enums directement, et les enums translatable reçoivent leurs labels via le translator sans câblage personnalisé.

HttpFoundation : small but useful

Response::send() reçoit un paramètre $flush. Passer false pour bufferiser la sortie sans la flusher au client, utile quand on enchaîne des middlewares qui doivent inspecter la réponse avant qu’elle quitte le processus.

UriSigner passe de HttpKernel à HttpFoundation, où il appartient sémantiquement. Même nom de classe, namespace différent.

Les cookies reçoivent le support CHIPS (Cookies Having Independent Partitioned State), le mécanisme navigateur pour les cookies cross-site dans une partition first-party. Ça ne compte que si on construit des widgets embarquables, mais bon à savoir que c’est là.

Translation : provider Phrase et sortie arborescente

Phrase rejoint Crowdin et Lokalise comme provider de traduction supporté. Le configurer dans config/packages/translation.yaml et les commandes translation:push / translation:pull gèrent la synchronisation.

translation:pull reçoit une option --as-tree qui écrit les fichiers de traduction en YAML imbriqué plutôt qu’en clés à notation pointée plate. Si c’est vraiment mieux dépend entièrement de l’équipe.

LocaleSwitcher::runWithLocale() passe maintenant la locale courante comme argument au callback, évitant un appel getLocale() à l’intérieur :

$switcher->runWithLocale('fr', function (string $locale) use ($mailer) {
    $mailer->send($this->buildEmail($locale));
});

Quelques choses dans Serializer et DomCrawler

L’attribut Context du Serializer peut maintenant cibler des classes spécifiques, donc un seul DTO peut se comporter différemment pendant la (dé)sérialisation selon quelle classe détient le contexte. TranslatableNormalizer arrive pour normaliser les objets qui implémentent TranslatableInterface : le translator est appelé pendant la normalisation, pas avant.

Crawler::attr() reçoit un paramètre $default. Au lieu de null-checker la valeur de retour, on passe une valeur de repli :

$src = $crawler->attr('src', '/placeholder.png');

assertAnySelectorText() et assertAnySelectorTextContains() rejoignent l’ensemble d’assertions DomCrawler. Ils passent si au moins un élément correspondant satisfait la condition, plutôt que d’en exiger que tous correspondent.

HttpClient : réponses HAR pour les tests

MockResponse accepte maintenant les fichiers HAR (HTTP Archive). Enregistrer de vraies interactions HTTP dans le navigateur ou avec un proxy, déposer le fichier .har dans les fixtures de tests, et les rejouer :

$client = new MockHttpClient(HarFileResponseFactory::createFromFile(__DIR__.'/fixtures/api.har'));

Bien mieux qu’écrire des stubs de réponse à la main quand on traite avec une API complexe.

AssetMapper

La gestion frontend moderne dans Symfony, ça voulait dire Webpack Encore. Encore fonctionne : il gère la transpilation, le bundling, le versioning, le hot reload. Il nécessite aussi Node.js, une étape de build séparée, et une quantité non négligeable de configuration pour ce qui est souvent un frontend assez modeste.

AssetMapper prend une position différente. Les navigateurs modernes supportent les modules ES nativement. Au lieu de bundler, livrer les fichiers tels quels, laisser le navigateur résoudre les imports via une importmap, et gérer les dépendances vendor via des fichiers téléchargés plutôt que des packages npm.

composer require symfony/asset-mapper
php bin/console importmap:require lodash

Pas de Node.js. Pas de npm. Pas d’étape de build. Les fichiers JavaScript et CSS sont versionnés et servis directement, avec un digest dans l’URL pour le cache busting. Pour les applications où le frontend n’est pas la principale préoccupation d’ingénierie, ça supprime toute une chaîne d’outils de l’équation.

6.4 ajoute les fichiers CSS à l’importmap, le préchargement CSS automatique via WebLink, et des commandes pour auditer et mettre à jour les dépendances vendor. L’expérience package.json, sans npm.

Scheduler

Le composant Scheduler (planification de tâches périodiques et de style cron sans runner externe) sort d’expérimental et devient stable. L’API utilise des attributs :

#[AsCronTask('0 * * * *')]
class HourlyReport implements ScheduledTaskInterface
{
    public function run(): void { ... }
}

Soutenu par les transports Messenger, les tâches tournent dans tout environnement où un worker est en cours d’exécution. Pour beaucoup de cas d’usage, ça remplace le pattern classique entrée cron + commande console.

Webhook et RemoteEvent

Aussi diplômés d’expérimental : le composant Webhook gère les webhooks entrants depuis des services externes. Au lieu d’écrire des contrôleurs bruts qui parsent les payloads et dispatchent des événements à la main, on configure des parseurs pour des services connus (Stripe, GitHub, Mailgun) et on obtient des événements typés.

DatePoint

Une nouvelle classe DatePoint dans le composant Clock : un wrapper DateTime immutable qui lève des exceptions sur les modificateurs invalides au lieu de retourner silencieusement false. Petite chose, mais significative pour le code qui manipule des dates et veut réellement savoir quand quelque chose va mal.

La fenêtre de support

6.4 LTS reçoit des corrections de bugs jusqu’en novembre 2026 et des correctifs de sécurité jusqu’en novembre 2027. Le chemin de 6.4 vers 7.4 (la prochaine LTS) passe par les notices de dépréciation de 6.4, comme d’habitude.

Routes sans strings magiques

Les alias de routes basés sur le FQCN sont maintenant générés automatiquement. Si une méthode de contrôleur a une seule route, Symfony crée un alias en utilisant son nom de classe complet :

// Auparavant : seul 'blog_index' fonctionnait
// Maintenant : les deux fonctionnent de manière identique
$this->urlGenerator->generate('blog_index');
$this->urlGenerator->generate(BlogController::class.'::index');

Pour les contrôleurs invocables, l’alias est juste le nom de classe. L’avantage pratique : navigation IDE et sécurité au refactoring — on référence une constante de classe, pas une string qui peut silencieusement diverger.

Deux nouveaux attributs DI

#[AutowireLocator] et #[AutowireIterator] rejoignent la famille d’attributs DI. Au lieu de configurer des service locators et des itérables taggués en YAML, on les déclare juste sur les paramètres du constructeur :

public function __construct(
    #[AutowireLocator([FooHandler::class, BarHandler::class])]
    private ContainerInterface $handlers,
) {}

Alias, services optionnels (préfixés avec ?), et injection de paramètres via SubscribedService sont tous supportés. Le locator charge paresseusement, donc seuls les handlers qu’on appelle vraiment sont instanciés.

Messenger reçoit des handlers intégrés

Trois nouvelles classes de message couvrent des tâches courantes qui nécessitaient auparavant des handlers personnalisés.

RunProcessMessage dispatche une commande Process via le bus. RunCommandMessage fait de même pour les commandes console. Les deux retournent un objet de contexte avec le code de sortie et la sortie. PingWebhookMessage pingue une URL, ce qui est utile pour surveiller les tâches planifiées sans mettre en place un service de health-check dédié :

$this->bus->dispatch(new RunCommandMessage('cache:clear'));
$this->bus->dispatch(new PingWebhookMessage('GET', 'https://healthchecks.io/ping/abc123'));

Le problème d’héritage des sous-processus a aussi été résolu avec PhpSubprocess. Quand on lance PHP avec une limite mémoire personnalisée (-d memory_limit=-1), les processus enfants lancés avec Process ne l’héritent pas. PhpSubprocess le fait :

$sub = new PhpSubprocess(['bin/console', 'app:heavy-import']);

Sécurité : trois corrections pour des situations réelles

Le profiler montre maintenant comment les badges de sécurité ont été résolus pendant l’authentification : lesquels ont passé, lesquels ont échoué, et pourquoi. Avant, il fallait ajouter de la sortie de debug manuellement quand un authentificateur personnalisé ne se comportait pas bien.

Le throttling de login via RateLimiter hache maintenant automatiquement les PII dans les logs. Les adresses IP et les noms d’utilisateur sont hachés avec le secret du kernel avant d’être écrits. Pas de config nécessaire, pas de regex sur les lignes de log.

Les patterns de firewall acceptent maintenant des tableaux :

firewalls:
    no_security:
        pattern:
            - "^/register$"
            - "^/api/webhooks/"

Fini les acrobaties regex pour les exclusions multi-chemins.

Déconnexion sans contrôleur bidon

La route de déconnexion nécessitait auparavant un contrôleur qui ne faisait rien que lever une exception, avec un commentaire expliquant que oui, c’est intentionnel. 6.4 élimine ça :

# config/routes/security.yaml
_security_logout:
    resource: security.route_loader.logout
    type: service

Le route loader s’en occupe. Le contrôleur bidon est parti. Flex met à jour la recette.

Le sérialiseur en meilleure forme

Trois améliorations du sérialiseur qui résolvent chacune un vrai problème.

Attribut #[Groups] au niveau de la classe : appliquer un groupe à la classe entière, puis surcharger par propriété. Utile quand une ressource a un groupe de sérialisation par défaut et quelques champs qui nécessitent un contrôle plus fin.

Les objets translatable ont maintenant un normaliseur dédié. Les strings translatable (enveloppant TranslatableInterface de Doctrine) sont traduites vers la locale passée via NORMALIZATION_LOCALE_KEY pendant la normalisation. Avant ça, il fallait écrire un normaliseur personnalisé.

En mode debug, les erreurs de décodage JSON utilisent maintenant seld/jsonlint pour de meilleurs messages. Au lieu de “Syntax error”, on obtient la ligne et ce qui s’est vraiment passé :

Parse error on line 1: {'foo': 'bar'}
           ^ Invalid string, used single quotes instead of double quotes

Profilers pour les choses qui n’étaient pas des requêtes HTTP

Le profiler de commande étend le profiler existant aux commandes console. Ajouter --profile à n’importe quelle commande et obtenir une entrée complète dans le profiler : entrée/sortie, temps d’exécution, mémoire, requêtes en base, messages de log. Les commandes qui nécessitaient --verbose plus du timing manuel ont maintenant la même expérience de debug que les requêtes HTTP.

Le profiler de workflow fait de même pour les machines à états. Un nouveau panneau montre une représentation graphique des workflows et les transitions déclenchées pendant la requête. Zéro configuration.

L’accumulation de DX

Plusieurs additions plus petites qui se combinent.

renderBlock() et renderBlockView() sur AbstractController permettent de rendre un bloc Twig nommé et de le retourner comme Response ou string. Pratique pour les réponses Turbo Stream où on veut mettre à jour un fragment sans une action de contrôleur complète.

Le processeur d’env defined retourne un booléen plutôt que la valeur : true si la variable existe et n’est pas vide, false sinon. Utile pour les feature flags pilotés par des variables d’environnement :

parameters:
    is_feature_enabled: '%env(defined:FEATURE_FLAG_KEY)%'

HttpClient accepte maintenant max_retries par requête, surchargeant la stratégie globale de retry. La méthode filter() du composant Finder accepte un second argument pour élaguer des répertoires entiers tôt, ce qui compte quand on cherche dans de grands arbres.

La méthode click() de BrowserKit accepte maintenant des paramètres serveur comme en-têtes supplémentaires, utile dans les tests fonctionnels qui doivent simuler des appels API authentifiés en suivant des liens.

L’impersonation devient utilisable dans les templates

Deux nouveaux helpers Twig : impersonation_path() et impersonation_url(). Ils génèrent les URLs correctes incluant le paramètre de query switch-user, qui est configurable et n’a aucune raison d’être codé en dur dans les templates. Les associer avec l’existant impersonation_exit_path() pour le flux complet d’impersonation admin.

Contrôle des locales, partout où ça manquait

Trois lacunes comblées. TemplatedEmail a maintenant une méthode locale() pour rendre les emails dans la langue du destinataire. runWithLocale() du locale switcher passe maintenant la locale comme argument au callback, donc on n’a pas à la capturer depuis la portée extérieure. Et app.enabledLocales est disponible dans Twig, donc on peut construire des sélecteurs de langue sans coder en dur les listes de locales.

Déployer sur des filesystems en lecture seule

APP_BUILD_DIR est maintenant une variable d’environnement reconnue par le kernel. La définir pour rediriger les artefacts compilés (cache du router, proxies Doctrine, traductions préchargées) vers un répertoire qui existe, même quand le répertoire cache par défaut n’existe pas. MicroKernelTrait l’utilise automatiquement. WarmableInterface a reçu un paramètre $buildDir pour supporter cette séparation : les warmers de cache personnalisés qui écrivent des artefacts en lecture seule doivent se mettre à jour en conséquence.

Ce n’est pas juste un bump de version. C’est un engagement à construire contre le langage actuel plutôt que le plancher historique.

Le système de sécurité, enfin reconstruit

Le composant de sécurité Symfony a deux systèmes. L’ancien (AnonymousToken, GuardAuthenticatorInterface, un enchevêtrement d’interfaces qui vous faisaient implémenter des méthodes dont vous n’aviez pas besoin) avait été déprécié. 6.0 le supprime entièrement.

Le nouveau système de sécurité (security.enable_authenticator_manager: true en 5.x) est maintenant le seul système. C’est plus propre : une seule interface à implémenter, séparation claire entre authentification et autorisation, vérification des credentials basée sur des passeports. La migration depuis les anciens guard authenticators n’est pas indolore, mais la destination est beaucoup moins confuse.

La classe Path du Filesystem

Travailler avec des chemins de fichiers en PHP est fondamentalement un problème de manipulation de strings. __DIR__, concaténation, realpath(), séparateurs spécifiques à la plateforme : la bibliothèque standard donne des primitives mais pas vraiment un modèle.

La nouvelle classe Path gère ça :

use Symfony\Component\Filesystem\Path;

Path::join('/var/www', 'html', '../uploads'); // /var/www/uploads
Path::makeRelative('/var/www/html', '/var/www'); // html
Path::isAbsolute('./relative/path'); // false

Multiplateforme, sans effets de bord, sans accès au filesystem nécessaire. Aussi dans 6.0 : support des patterns .gitignore imbriqués dans Finder.

Les enums dans le système de formulaires

En s’appuyant sur les fondations posées par 5.4, 6.0 pousse le support des enums plus loin. Les valeurs BackedEnum font des allers-retours à travers les formulaires et le sérialiseur sans transformateurs personnalisés. Le composant de formulaire comprend les cases d’enum comme options de choix nativement.

Ce que 6.0 supprime

La liste des suppressions est extensive : l’ancien système de sécurité, le composant Templating, le support des annotations PHP (remplacées par les attributs natifs), le support du cache Doctrine, ContainerAwareTrait. Six années de marqueurs @deprecated accumulés, finalement nettoyés.

Les applications qui avaient pris au sérieux les warnings de dépréciation de 5.4 avaient un chemin de migration propre. Celles qui ne l’avaient pas fait avaient du travail à faire.

La complétion automatique était toujours le manque

Le composant Console a reçu l’autocomplétion shell, et c’est proprement intégré : définir une méthode complete() sur sa commande, et Tab dans Bash suggère des valeurs valides pour les options et arguments.

class DeployCommand extends Command
{
    public function complete(CompletionInput $input, CompletionSuggestions $suggestions): void
    {
        if ($input->mustSuggestOptionValuesFor('env')) {
            $suggestions->suggestValues(['prod', 'staging', 'dev']);
        }
    }
}

Toutes les commandes Symfony intégrées ont reçu la complétion aussi : debug:router, cache:pool:clear, lint:yaml, et une quinzaine d’autres. Exécuter bin/console completion bash >> ~/.bashrc et c’est terminé.

Messenger, maintenant avec attributs et traitement par lots

L’attribut #[AsMessageHandler] remplace l’ancienne MessageHandlerInterface. Moins de boilerplate, et on peut maintenant configurer l’affinité de transport et la priorité directement sur l’attribut :

#[AsMessageHandler(fromTransport: 'async', priority: 10)]
class SendWelcomeEmailHandler
{
    public function __invoke(UserRegistered $message): void { ... }
}

L’autre ajout significatif : BatchHandlerInterface. Quand on insère un millier de lignes, traiter les messages un par un est du gaspillage. Les batch handlers collectent les messages et les traitent en groupes. La taille de lot par défaut est 10, contrôlée par BatchHandlerTrait::shouldFlush(). L’Acknowledger gère le succès et l’échec individuels dans le lot.

reset_on_message: true dans la config Messenger réinitialise les services du conteneur entre les messages. Auparavant, un buffer Monolog pouvait se remplir à travers la gestion des messages et personne ne s’en rendait compte avant la production. Ça évite cette catégorie de bugs de stateful sans nécessiter de nettoyage manuel.

Le conteneur DI devient plus expressif

Trois changements qui comptent en pratique.

Les types union et intersection s’autowire maintenant. PHP 8.1 a ajouté les types intersection, et Symfony 6.0 les câble :

public function __construct(
    private NormalizerInterface&DenormalizerInterface $serializer
) {}

Ça fonctionne tant que les deux interfaces pointent vers le même service via les alias d’autowiring.

TaggedIterator et TaggedLocator ont reçu les options defaultPriorityMethod et defaultIndexMethod. On n’a plus besoin de YAML pour exprimer l’ordonnancement ou l’indexation pour les services taggués :

public function __construct(
    #[TaggedIterator(tag: 'app.handler', defaultPriorityMethod: 'getPriority')]
    private iterable $handlers,
) {}

SubscribedService (l’attribut qui remplace la magie implicite de ServiceSubscriberTrait) rend l’accès paresseux aux services explicite et typable :

#[SubscribedService]
private function mailer(): MailerInterface
{
    return $this->container->get(__METHOD__);
}

La validation reçoit trois nouveaux outils

CssColor valide les valeurs de couleurs CSS dans les formats voulus : hex, RGB, HSL, couleurs nommées, ou n’importe quel mélange. Utile pour les champs de configuration de thème où on veut accepter #ff0000 mais pas red, ou vice versa.

#[Assert\CssColor(formats: Assert\CssColor::HEX_LONG)]
private string $brandColor;

Cidr valide la notation CIDR pour IPv4 et IPv6, avec des options pour fixer la version et contraindre la plage de masque réseau. Les outils d’infrastructure et les formulaires de config réseau ont enfin une contrainte de première classe.

Le troisième ajout n’est pas une nouvelle contrainte. Ce sont les attributs imbriqués PHP 8.1 qui rendent les contraintes composées existantes utilisables sans XML. AtLeastOneOf, Collection, All, Sequentially : tout ça nécessitait auparavant des contournements d’annotation. Maintenant ça fonctionne juste comme attributs :

#[Assert\Collection(
    fields: [
        'email' => new Assert\Email(),
        'role'  => [new Assert\NotBlank(), new Assert\Choice(['admin', 'user'])],
    ]
)]
private array $payload;

Le sérialiseur, nettoyé

Deux choses. D’abord, le contexte de sérialisation est maintenant configurable globalement au lieu d’être répété à chaque appel serialize() :

# config/packages/serializer.yaml
serializer:
    default_context:
        enable_max_depth: true

Ensuite, l’option COLLECT_DENORMALIZATION_ERRORS change comment le sérialiseur gère les erreurs de type à la désérialisation. Au lieu de lever une exception au premier problème, il les collecte tous et les expose via PartialDenormalizationException. Si on écrit une API qui désérialise des corps de requête, c’est la différence entre retourner “le premier champ qui échoue” et “tous les champs qui échouent” dans une seule réponse.

Les utilitaires de string que personne ne savait vouloir

trimPrefix() et trimSuffix() sur les classes UnicodeString / ByteString. Pas glamour, mais supprimer un préfixe connu avec ltrim() est un piège subtil : ça supprime des caractères, pas des strings. Ceux-ci sont corrects :

use function Symfony\Component\String\u;

u('file-image-001.png')->trimPrefix('file-');   // 'image-001.png'
u('report.html.twig')->trimSuffix('.twig');     // 'report.html'

Aussi dans cette version : NilUlid pour les ULIDs à valeur zéro, perMonth() et perYear() sur RateLimiter pour quand les limites horaires n’ont pas de sens, et appendToFile() dans le composant Filesystem a reçu un paramètre LOCK_EX optionnel pour les écrivains concurrents.

Déboguer l’environnement

debug:dotenv est une nouvelle commande console qui montre quels fichiers .env ont été chargés et d’où vient chaque valeur. Quand on a .env, .env.local, .env.test, et .env.test.local qui se battent et que quelque chose ne va pas, cette commande dit exactement quel fichier a gagné. Elle n’apparaît que quand le composant Dotenv est utilisé, ce qui est le cas pour toute application Symfony standard.

5.4 est la version LTS, et son rôle est de porter autant que possible le jeu de fonctionnalités de 6.0 tout en conservant la compatibilité 5.x. C’est aussi la première version de Symfony qui comprend réellement les fonctionnalités de PHP 8.1.

Support des enums

PHP 8.1 a introduit les enums natifs. Symfony 5.4 les embrasse immédiatement :

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
}

Le type de formulaire EnumType rend les enums sous forme de listes déroulantes, sans transformateurs personnalisés. Le validateur comprend les backed enums. Le sérialiseur mappe les valeurs d’enum sur leur type de backing et inversement. Trois composants mis à jour d’un coup, ce qui a rendu la migration des bases de code des pseudo-constantes enum vers les vrais enums PHP 8.1 étonnamment fluide.

Cache des voters de sécurité

La CacheableVoterInterface permet aux voters qui s’abstiennent toujours sur un attribut donné de le signaler au système de sécurité, qui peut alors les ignorer lors des vérifications suivantes. Pour les applications avec de nombreux voters, le gain sur les vérifications de permissions s’accumule vite. Petit changement, perceptible en pratique.

Messenger continue de mûrir

Le traitement par batch de Messenger (gérer plusieurs messages en une seule transaction au lieu d’un par un) est maintenant stable. Rate limiting par transport. Les dead letter queues bénéficient de meilleurs outils. Après des années en mode « expérimental », Messenger en 5.4 est enfin la fondation async sur laquelle on peut s’appuyer pour des charges sérieuses.

La Console a eu sa touche Tab

Symfony 5.4 embarque l’autocomplétion shell pour toutes les commandes. Appuyez sur Tab et le shell suggère les noms de commandes, les valeurs d’arguments et les valeurs d’options. Pour les commandes intégrées, ça fonctionne sans configuration. Pour les commandes personnalisées, ajoutez une méthode complete() :

use Symfony\Component\Console\Completion\CompletionInput;
use Symfony\Component\Console\Completion\CompletionSuggestions;

public function complete(CompletionInput $input, CompletionSuggestions $suggestions): void
{
    if ($input->mustSuggestOptionValuesFor('format')) {
        $suggestions->suggestValues(['json', 'xml', 'csv']);
    }
}

Pas d’interface requise, juste la méthode et Symfony s’en charge. La communauté a aussi passé en revue toutes les commandes intégrées (debug:router, cache:pool:clear, secrets:remove, lint:twig, et une dizaine d’autres) pour ajouter les compléments avant la sortie.

Les routes peuvent être des alias maintenant

Le composant de routing supporte désormais les alias : une route peut pointer vers une autre. Le cas d’usage évident, c’est renommer une route sans casser tout ce qui génère encore des URLs avec l’ancien nom.

# config/routes.yaml
admin_dashboard:
    path: /admin

# ancien nom conservé pendant la transition
dashboard:
    alias: admin_dashboard
    deprecated:
        package: 'acme/my-bundle'
        version: '2.3'

Générer une URL avec dashboard fonctionne toujours, mais déclenche un avertissement de dépréciation. Des chemins de renommage propres pour les bundles qui doivent maintenir des noms de routes publics tout en avançant.

Les exceptions sont mappées aux codes HTTP dans la config

Avant 5.4, mapper une classe d’exception à un code HTTP signifiait implémenter HttpExceptionInterface ou écrire un listener. Maintenant c’est juste une entrée YAML :

# config/packages/framework.yaml
framework:
    exceptions:
        App\Exception\PaymentRequiredException:
            status_code: 402
            log_level: warning
        App\Exception\MaintenanceException:
            status_code: 503
            log_level: info

L’exception n’a rien à implémenter. Le framework lit la map, définit le code de statut, loggue au niveau configuré. Pratique pour les exceptions métier qui n’ont aucune raison de connaître HTTP.

Deux nouvelles contraintes de validation

5.4 ajoute Cidr et CssColor au composant Validator.

Cidr valide la notation réseau (adresse IP plus masque de sous-réseau) avec un contrôle sur la version IP acceptée et les bornes de la valeur du masque :

#[Assert\Cidr(version: 4, netmaskMin: 16, netmaskMax: 28)]
private string $allowedSubnet;

CssColor valide qu’une chaîne est une couleur CSS valide. Utile pour les éditeurs de thème, la config CMS, ou toute interface qui laisse les utilisateurs choisir des couleurs :

#[Assert\CssColor(
    formats: Assert\CssColor::HEX_LONG,
    message: "La couleur d'accentuation doit être une valeur hex à 6 chiffres.",
)]
private string $accentColor;

Attributs PHP imbriqués pour les contraintes de validation

Symfony 5.2 avait ajouté les contraintes de validation en attributs PHP, mais PHP 8.0 avait une limitation sur les attributs imbriqués. Les contraintes complexes comme All, Collection, ou AtLeastOneOf étaient impossibles à exprimer avec la syntaxe d’attribut seule. PHP 8.1 a levé cette restriction, et 5.4 en tire le meilleur parti :

use Symfony\Component\Validator\Constraints as Assert;

class CartItem
{
    #[Assert\All([
        new Assert\NotNull(),
        new Assert\Range(min: 1),
    ])]
    private array $quantities;

    #[Assert\AtLeastOneOf(
        constraints: [new Assert\Email(), new Assert\Url()],
        message: 'Doit être un email ou une URL valide.',
    )]
    private string $contact;
}

Pas de docblocks d’annotations, pas de mapping XML. Des attributs PHP 8.1 purs, de bout en bout.

Injection de dépendances : trois choses à savoir

Les itérateurs taggués peuvent maintenant être injectés dans des service locators, qui n’acceptaient auparavant que des listes de services explicites. L’autowiring des types union fonctionne quand les deux côtés de l’union résolvent vers le même service, ce qui est courant avec les interfaces du serializer :

public function __construct(
    private NormalizerInterface & DenormalizerInterface $serializer
) {}

#[SubscribedService] remplace l’introspection automatique que ServiceSubscriberTrait faisait implicitement. C’est maintenant un attribut explicite sur les méthodes, ce qui rend la dépendance visible sans aucune magie :

use Symfony\Contracts\Service\Attribute\SubscribedService;

class SomeService implements ServiceSubscriberInterface
{
    #[SubscribedService]
    private function router(): RouterInterface
    {
        return $this->container->get(__METHOD__);
    }
}

Messenger : attributs, état des workers et reset de services

Les handlers Messenger peuvent abandonner MessageHandlerInterface en faveur de #[AsMessageHandler], qui permet aussi de lier un handler à un transport spécifique et de définir sa priorité, sans toucher au YAML :

#[AsMessageHandler(fromTransport: 'async', priority: 10)]
class ProcessOrderHandler
{
    public function __invoke(ProcessOrder $message): void { /* ... */ }
}

L’état des workers est maintenant inspectable via WorkerMetadata dans les event listeners, utile quand vous avez des workers sur plusieurs transports et avez besoin de savoir lequel a déclenché un événement donné.

Les workers longue durée accumulent de l’état entre les messages : buffers de l’entity manager, caches en mémoire, connexions ouvertes. La nouvelle option reset_on_message prend en charge la réinitialisation de tous les services réinitialisables entre les messages :

framework:
    messenger:
        reset_on_message: true

Serializer : collecter les erreurs plutôt que lever

Désérialiser du JSON externe dans un DTO typé levait une exception dès la première discordance de type. L’option COLLECT_DENORMALIZATION_ERRORS change ça : toutes les erreurs de type sont collectées dans une PartialDenormalizationException, pour que vous puissiez retourner un 400 propre avec la liste complète des problèmes par champ :

try {
    $dto = $serializer->deserialize($request->getContent(), OrderDto::class, 'json', [
        DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
    ]);
} catch (PartialDenormalizationException $e) {
    return $this->json(
        array_map(fn($err) => ['path' => $err->getPath(), 'expected' => $err->getExpectedTypes()], $e->getErrors()),
        400
    );
}

Le contexte par défaut du serializer peut aussi être défini globalement en YAML, pour ne plus passer les mêmes options à chaque appel.

Négociation de langue intégrée

Deux nouvelles options du framework gèrent l’en-tête Accept-Language sans listeners personnalisés :

framework:
    enabled_locales: ['en', 'fr', 'de']
    set_locale_from_accept_language: true
    set_content_language_from_locale: true

Avec ça en place, Symfony lit la langue préférée du navigateur, choisit la meilleure correspondance parmi enabled_locales, définit la locale de la requête, et ajoute un en-tête Content-Language à la réponse. L’attribut de route {_locale} a toujours la priorité quand il est présent.

Traduction : extraction, pas mise à jour

La commande translation:update est renommée en translation:extract. L’ancien nom reste comme déprécié. La distinction compte : la commande n’écrit jamais dans une base de données, elle extrait les chaînes traduisibles des fichiers source. Le nouveau nom dit enfin ce qu’elle fait.

lint:xliff gagne aussi une option --format=github qui sort les erreurs en annotations GitHub Actions, pour que les échecs de lint de traduction apparaissent en commentaires de revue de PR plutôt que de se noyer dans les logs.

Raccourcis du contrôleur élagués

Trois raccourcis d’AbstractController sont dépréciés : getDoctrine(), dispatchMessage(), et la méthode générique get() pour récupérer des services arbitraires du container. La direction, c’est l’injection par constructeur explicite. Pour getDoctrine() en particulier :

// avant
$em = $this->getDoctrine()->getManager();

// après — injecter directement
public function __construct(private EntityManagerInterface $em) {}

Request::get() est aussi déprécié. Il cherchait dans les attributs de route, la query string et le corps POST dans un ordre non documenté, ce qui était une excellente façon d’obtenir des résultats surprenants. Utilisez $request->query->get(), $request->request->get(), ou $request->attributes->get() et soyez explicite sur la provenance de la valeur.

La classe utilitaire Path

Le composant Filesystem reçoit une classe Path portée depuis webmozart/path-util. Elle gère les cas tordus que dirname() et realpath() ratent :

use Symfony\Component\Filesystem\Path;

Path::canonicalize('../config/../config/services.yaml'); // '../config/services.yaml'
Path::getDirectory('C:/');                               // 'C:/' (dirname() retourne '.')
Path::getLongestCommonBasePath([
    '/var/www/project/src/Controller/FooController.php',
    '/var/www/project/src/Controller/BarController.php',
    '/var/www/project/src/Entity/User.php',
]);
// '/var/www/project/src'

Utile dès que votre code manipule des chemins qui traversent les frontières des OS ou qui contiennent des segments relatifs.

Les petites choses qui s’accumulent

debug:dotenv montre quels fichiers .env ont été chargés et quelle valeur chaque variable résout. La première chose qu’on cherche quand un comportement spécifique à un environnement déraille.

Le composant String ajoute trimPrefix() et trimSuffix() pour retirer des préfixes ou suffixes connus sans écrire un calcul de substr :

u('file-image-0001.png')->trimPrefix('file-');    // 'image-0001.png'
u('template.html.twig')->trimSuffix('.twig');      // 'template.html'

DomCrawler reçoit innerText(), qui retourne uniquement le texte direct d’un nœud, à l’exclusion des éléments enfants. text() retourne tout y compris le texte imbriqué ; innerText() retourne uniquement le contenu propre du nœud. Petite différence, mais ça compte quand on fait du scraping.

Le composant RateLimiter étend son support des intervalles avec perMonth() et perYear(), pour les applications qui ont besoin de limiter des événements sur des fenêtres plus longues : envois de newsletters, remises à zéro de quotas API, limites de forfaits annuels.

Le composant Finder respecte maintenant les fichiers .gitignore dans tous les sous-répertoires quand vous appelez ignoreVCSIgnored(true), pas seulement à la racine. Les règles des répertoires enfants supplantent celles des parents, exactement comme git lui-même.

La fenêtre LTS

5.4 reçoit des corrections de bugs jusqu’en novembre 2024 et des correctifs de sécurité jusqu’en novembre 2025. La migration de 5.4 vers 6.4 (la prochaine LTS) est intentionnellement fluide : corrigez les avertissements de dépréciation de 5.4, et le saut vers 6.x devient mécanique.

La couche de dépréciation en 5.4 pointe vers tout ce que 6.0 supprime : les derniers morceaux de l’ancien système de sécurité, ContainerAwareTrait, et quelques patterns legacy de formulaires et de serializer.

Le composant String

La gestion des chaînes en PHP est notoirement éparpillée : des fonctions avec préfixe par-ci (str_), avec suffixe par-là (strpos), un support d’encodage incohérent, et rien d’orienté objet en vue. Le composant String enveloppe tout ça dans une API fluide orientée objet avec support Unicode :

use Symfony\Component\String\UnicodeString;

$str = new UnicodeString('  Hello World  ');
echo $str->trim()->lower()->replace(' ', '-'); // hello-world

L’ajout pratique, c’est le Slugger, un générateur de slug locale-aware qui gère vraiment correctement les caractères accentués :

$slug = $slugger->slug('L\'été à Montréal'); // l-ete-a-montreal

Avant, il fallait intégrer une bibliothèque tierce ou en écrire une soi-même. Maintenant ça ship avec FrameworkBundle, disponible par défaut.

Notifier

Le courrier électronique est géré par Mailer. SMS, notifications push, messages de chat : pas de solution first-party, jusqu’à maintenant. Le composant Notifier en ajoute une : une interface unifiée sur des dizaines de canaux et fournisseurs.

La même notification peut atterrir sur Slack, déclencher un SMS via Twilio, ou finir comme notification push, tout configuré via des DSN. Ajouter un nouveau canal, c’est un changement de config, pas un changement de code.

Le coffre-fort de secrets

Stocker des secrets dans des fichiers .env fonctionne, mais les valeurs sont en clair, les environnements partagés sont une galère, et il n’y a aucun moyen natif de chiffrer quoi que ce soit au repos.

Symfony 5.0 ajoute une famille de commandes secrets: et un mécanisme de coffre-fort. Les secrets sont chiffrés avec une paire de clés stockée hors du dépôt. Les fichiers chiffrés sont commités ; la clé de déchiffrement ne l’est pas. En production, la clé arrive comme variable d’environnement ou est injectée depuis un gestionnaire de secrets.

php bin/console secrets:set DATABASE_PASSWORD
php bin/console secrets:decrypt-to-local --force

Pas une solution de gestion de secrets à part entière, mais un vrai pas en avant par rapport à un fichier .env en clair qui traîne non chiffré dans le dépôt.

Mailer reçoit une couche de notification

Le composant Mailer est arrivé en 4.4. Ce que la 5.0 ajoute par-dessus, c’est la NotificationEmail : un email pré-stylisé et responsive construit sur Foundation for Emails, avec une API explicite pour les niveaux d’importance et les boutons d’appel à l’action :

use Symfony\Bridge\Twig\Mime\NotificationEmail;

$email = (new NotificationEmail())
    ->from('alerts@example.com')
    ->to('admin@example.com')
    ->subject('Disk usage critical')
    ->markdown('The disk on **prod-01** is at 94%. Check it now.')
    ->action('Open dashboard', 'https://example.com/servers')
    ->importance(NotificationEmail::IMPORTANCE_URGENT);

Pas de template à écrire, pas de CSS inline à dompter. Pour les alertes transactionnelles, les notifications de facturation et les emails système, ça couvre 80 % de ce dont on a besoin sans toucher à quoi que ce soit.

Les firewalls paresseux et le problème de cache

Chaque firewall stateful dans Symfony charge l’utilisateur depuis la session à chaque requête, que l’action en ait besoin ou non. Ce qui signifie que toute réponse est non-cacheable par défaut, même pour des pages qui ne touchent jamais à $this->getUser().

La 5.0 ajoute le mode lazy pour les firewalls, qui diffère l’accès à la session jusqu’à ce que le code appelle réellement is_granted() ou accède au token utilisateur :

# config/packages/security.yaml
security:
    firewalls:
        main:
            pattern: ^/
            anonymous: lazy

Les pages qui n’ont pas besoin de l’utilisateur redeviennent cacheables. Les nouveaux projets obtiennent ça par défaut via la recette Flex ; les existants ont besoin d’un changement de config en une ligne.

Les migrations de mots de passe sans grand soir

Migrer une app en production de bcrypt vers argon2id impliquait jusqu’ici de forcer une réinitialisation du mot de passe pour chaque utilisateur. Le PasswordUpgraderInterface rend ça progressif : à la connexion, Symfony vérifie si le hash stocké correspond à l’algorithme courant. Sinon, il le re-hash sur place et appelle votre upgrader pour le sauvegarder :

// src/Repository/UserRepository.php
class UserRepository extends ServiceEntityRepository implements PasswordUpgraderInterface
{
    public function upgradePassword(UserInterface $user, string $newHashedPassword): void
    {
        $user->setPassword($newHashedPassword);
        $this->getEntityManager()->flush();
    }
}

Associez ça à algorithm: auto dans la config de l’encodeur, et les anciens hashs migrent silencieusement à mesure que les utilisateurs se connectent. Pas de script de migration, pas de downtime, pas de friction pour l’utilisateur.

ErrorHandler remplace Debug

Le composant Debug est parti. Son remplaçant, ErrorHandler, fait le même travail (convertir les erreurs PHP en exceptions, afficher de belles pages d’erreur) mais sans nécessiter Twig. Pour les apps API qui ne rendent jamais de HTML, ça compte : ErrorHandler génère les erreurs dans le format de la requête (JSON, XML, texte) en suivant RFC 7807 :

{
    "title": "Not Found",
    "status": 404,
    "detail": "Sorry, the page you are looking for could not be found"
}

La config de routing passe de TwigBundle à FrameworkBundle, et c’est la seule étape de migration pour la plupart des projets. Une ligne, c’est fait.

Les listeners d’événements, enfin moins verbeux

Enregistrer un listener d’événement kernel impliquait auparavant de nommer explicitement l’événement dans le tag de service. Symfony 5.0 l’infère depuis la signature de méthode :

// Pas de configuration de tag au-delà de kernel.event_listener
final class SecurityListener
{
    public function onKernelRequest(RequestEvent $event): void
    {
        // Symfony lit le type hint et détermine l'événement
    }
}

# config/services.yaml
App\EventListener\SecurityListener:
    tags: [kernel.event_listener]

Utilisez __invoke() et ça fonctionne de la même façon. Enregistrez en masse tout un répertoire de listeners avec un seul bloc resource, et Symfony détermine quel événement chacun gère.

HttpClient grandit

Le composant HttpClient est arrivé en 4.4 comme stable. La 5.0 ajoute quelques choses utiles par-dessus :

L’authentification NTLM pour les environnements d’entreprise, le buffering conditionnel via un callback (bufferiser les grandes réponses seulement quand le content-type correspond), une option max_duration qui plafonne le temps total de requête indépendamment des conditions réseau, et toStream() pour transformer n’importe quelle réponse en un flux PHP standard pour le code qui attend du fread() :

$response = $client->request('GET', 'https://api.example.com/large-export', [
    'max_duration' => 30.0,
    'buffer' => fn(array $headers): bool => str_contains($headers['content-type'][0] ?? '', 'json'),
]);

// Le streamer plutôt que de tout charger en mémoire
$stream = $response->toStream();

Le client a aussi obtenu une interopérabilité complète avec PSR-18 et HTTPlug v1/v2, donc toute bibliothèque qui dépend de ces abstractions fonctionne directement avec lui.

Ce que la 5.0 supprime

La 5.0 abandonne tout ce qui était déprécié en 4.4. Les plus notables :

• WebServerBundle (utilisez symfony server:start depuis l’outil CLI à la place)
• L’AnonymousToken de l’ancien système de sécurité (remplacé par NullToken)
• Les anciens noms d’événements de formulaire
• Le ClassLoader interne de Symfony
• Le composant Debug (remplacé par ErrorHandler)

Si vous avez fait tourner votre app 4.4 avec les notices de dépréciation actives et corrigé les avertissements, la mise à niveau vers la 5.0 ne nécessite aucun changement de code.

La fonctionnalité qui mérite d’être mise en avant est arrivée en 4.2 et a mûri tout au long des 4.3 et 4.4 : HttpClient.

HttpClient

Les options HTTP natives de PHP (file_get_contents avec des contextes de flux, cURL, Guzzle) ont chacune leur propre modèle, leurs propres bizarreries et leur propre coût d’abstraction. Symfony 4.2 a introduit HttpClient, un client HTTP first-party avec une seule API pour plusieurs transports.

L’interface est claire :

$response = $client->request('GET', 'https://api.example.com/users');
$users = $response->toArray();

L’implémentation est asynchrone par défaut. Les réponses sont paresseuses : la requête réseau n’a pas lieu tant qu’on ne lit pas réellement la réponse. Plusieurs requêtes peuvent être initiées et résolues au fil de l’arrivée des données, sans threads ni callbacks.

Le transport mock intégré (MockHttpClient) rend les tests d’appels HTTP indolores sans avoir à démarrer des serveurs ou patcher des fonctions globales.

Mailer

Également stabilisé en 4.4 : le composant Mailer, qui remplace SwiftMailerBundle comme solution d’email recommandée. Le transport se configure via DSN :

MAILER_DSN=smtp://user:pass@smtp.example.com:587

L’approche DSN signifie que changer de fournisseur (Mailgun, Postmark, SES, SMTP local) est un changement de config, pas un changement de code. Les tests d’emails utilisent un spooler par défaut dans les environnements hors production.

Messenger se mâture

Le composant Messenger a atterri en 3.4 à titre expérimental. En 4.4, il est stable et éprouvé en production : gestion de messages asynchrones avec logique de retry, transport d’échec, et adaptateurs pour AMQP, Redis, Doctrine, et les transports in-process.

Le pattern qu’il permet (traiter une requête de façon synchrone, dispatcher du travail de façon asynchrone, réessayer en cas d’échec) remplace toute une classe de setups Gearman/RabbitMQ qui nécessitaient des bibliothèques tierces et une configuration conséquente.

La fenêtre LTS

La 4.4 est supportée pour les bugs jusqu’en novembre 2022 et pour les correctifs de sécurité jusqu’en novembre 2023. Si vous êtes sur la 4.x et recherchez la stabilité, c’est un endroit confortable où rester. Les avertissements de dépréciation qu’elle introduit pointent directement vers ce que la 5.0 exigera.

Le composant Messenger, de l’expérimental à la production

Messenger est arrivé en 4.1 comme une expérience. Le concept était simple : dispatcher un objet message vers un bus, le traiter immédiatement ou le router vers un transport pour un traitement asynchrone. En 4.3 et 4.4, l’expérience était devenue de l’infrastructure.

La release 4.3 a ajouté un transport d’échec dédié. Quand un message échoue après toutes les tentatives de retry, il va quelque part de récupérable plutôt que de simplement disparaître :

framework:
    messenger:
        failure_transport: failed
        transports:
            async: '%env(MESSENGER_TRANSPORT_DSN)%'
            failed: 'doctrine://default?queue_name=failed'
        routing:
            App\Message\SendEmail: async

Les messages qui atterrissent dans failed peuvent être inspectés et retentés manuellement. Avant ça, les messages en échec étaient une entrée de log et un mal de tête. Après, c’est une file qu’on peut vraiment travailler.

Le dispatching d’événements, avec les objets en première place

Depuis le début, le système d’événements de Symfony utilisait des noms d’événements en chaîne comme identifiant principal. On définissait OrderEvents::NEW_ORDER = 'order.new_order', on écoutait cette chaîne, et on passait l’objet événement comme paramètre secondaire.

La 4.3 a inversé ça. L’objet événement passe en premier, et le nom de l’événement devient optionnel :

// Avant
$dispatcher->dispatch(OrderEvents::NEW_ORDER, $event);

// 4.3+
$dispatcher->dispatch($event);

Omettez le nom et Symfony utilise le nom de classe comme identifiant. Les listeners et subscribers peuvent maintenant référencer la classe directement :

public static function getSubscribedEvents(): array
{
    return [
        OrderPlacedEvent::class => 'onOrderPlaced',
    ];
}

Les événements HttpKernel ont été renommés en conséquence : GetResponseEvent est devenu RequestEvent, FilterResponseEvent est devenu ResponseEvent. Les anciens noms sont restés comme alias pendant toute la 4.x.

VarDumper obtient un serveur

Un dump() dans un contrôleur qui retourne du JSON, et votre sortie de debug se retrouve injectée directement dans le corps de la réponse. Pour le développement d’API, c’est suffisamment agaçant pour que les gens désactivent le dumping complètement.

La 4.1 a ajouté un serveur VarDumper qui capture les dumps séparément :

bin/console server:dump

Configurez la destination du dump dans config/packages/dev/debug.yaml :

debug:
    dump_destination: "tcp://%env(VAR_DUMPER_SERVER)%"

Maintenant, dump() dans votre contrôleur API envoie les données vers la console du serveur au lieu de polluer la réponse. Le serveur affiche le dump avec le fichier source, la requête HTTP qui l’a déclenché, et le timestamp.

VarExporter, pour quand var_export() vous déçoit

var_export() a deux problèmes : il ignore la sémantique de sérialisation et sa sortie n’est pas conforme à PSR-2. Le composant VarExporter de la 4.2 corrige les deux.

$exported = VarExporter::export([123, ['abc', true]]);
// Retourne :
// [
//     123,
//     [
//         'abc',
//         true,
//     ],
// ]

Plus important encore, il gère correctement les objets implémentant Serializable, __sleep, et __wakeup. Là où var_export() abandonne silencieusement les méthodes de sérialisation et exporte les propriétés brutes, VarExporter produit du code qui appelle les mêmes hooks qu’unserialize() utiliserait. Le cas d’usage pratique est le préchauffage du cache : générer des fichiers PHP que OPcache peut charger sans ré-exécuter des calculs coûteux.

Des mots de passe vérifiés contre les bases de données de violations

La contrainte NotCompromisedPassword est arrivée en 4.3. Elle vérifie les mots de passe soumis contre la base de données de violations d’haveibeenpwned.com sans envoyer le vrai mot de passe nulle part.

use Symfony\Component\Validator\Constraints as Assert;

class User
{
    #[Assert\NotCompromisedPassword]
    public string $plainPassword;
}

L’implémentation utilise la k-anonymité : on hash le mot de passe en SHA-1, on envoie seulement les cinq premiers caractères à l’API, on récupère tous les hashs correspondants, on vérifie localement. Le mot de passe ne quitte jamais votre serveur. Pour les formulaires d’inscription, ajouter cette contrainte c’est une ligne et un signal de sécurité vraiment utile.

Workflow obtient du contexte

Le composant Workflow existait avant la 4.x, mais la 4.3 a ajouté la propagation de contexte : la possibilité de passer des données arbitraires à travers une transition et d’y accéder dans les listeners.

$workflow->apply($article, 'publish', [
    'user' => $user->getUsername(),
    'reason' => $request->request->get('reason'),
]);

Le contexte arrive dans TransitionEvent et est stocké aux côtés du marquage. Pour les pistes d’audit, c’est la différence entre savoir qu’une transition s’est produite et savoir qui l’a déclenchée et pourquoi. On peut aussi injecter du contexte depuis un subscriber sans toucher à chaque appel apply(), ce qui est pratique pour les préoccupations transversales comme les timestamps ou l’utilisateur courant.

L’autowiring est devenu plus intelligent

La 4.2 a ajouté la liaison par type et par nom simultanément. Avant, on pouvait lier par type (LoggerInterface) ou par nom ($logger), mais pas les deux en même temps. Ça posait problème quand un service a besoin de deux implémentations différentes de la même interface :

services:
    _defaults:
        bind:
            Psr\Log\LoggerInterface $orderLogger: '@monolog.logger.orders'
            Psr\Log\LoggerInterface $paymentLogger: '@monolog.logger.payments'

class OrderService
{
    public function __construct(
        private LoggerInterface $orderLogger,   // gets monolog.logger.orders
        private LoggerInterface $paymentLogger, // gets monolog.logger.payments
    ) {}
}

La correspondance exige que le type et le nom de l’argument s’alignent, donc pas de risque d’injecter accidentellement le mauvais logger.

ErrorHandler remplace le composant Debug

Le composant Debug, inchangé depuis 2013, avait une dépendance maladroite sur TwigBundle même pour les apps API-only. Toute exception non attrapée dans une API JSON rendait une page d’erreur HTML à moins d’écrire des listeners d’exception personnalisés.

La 4.4 extrait ça dans un composant ErrorHandler dédié. Pour les requêtes non-HTML, les réponses d’erreur suivent désormais RFC 7807 nativement :

{
    "title": "Not Found",
    "status": 404,
    "detail": "Sorry, the page you are looking for could not be found"
}

Pas besoin de Twig. Le format suit l’en-tête Accept : JSON pour les requêtes JSON, XML pour les requêtes XML. Pour personnaliser davantage, on fournit un normalizer via le composant Serializer plutôt qu’un template Twig.

Le préchargement PHP 7.4, câblé automatiquement

PHP 7.4 a introduit le préchargement OPcache : charger des fichiers en mémoire partagée avant l’arrivée de toute requête, pour qu’ils soient disponibles sous forme d’opcodes compilés dès la toute première requête. Le gain pratique est de 30 à 50 % de temps de réponse en moins sans changer une ligne de code.

Le bémol c’est la configuration : il faut spécifier exactement quels fichiers précharger dans php.ini. Symfony 4.4 génère ce fichier automatiquement dans le répertoire de cache :

; php.ini
opcache.preload=/path/to/project/var/cache/prod/App_KernelProdContainer.preload.php
opcache.preload_user=www-data

Lancez cache:warmup en production et pointez OPcache vers le fichier généré. Symfony précharge le container, les routes compilées et les templates Twig : les fichiers lus à chaque requête et qui ne changent jamais entre les déploiements.

Console : codes de retour et NO_COLOR

Deux petites choses en 4.4 qui auraient honnêtement dû exister plus tôt. Les commandes qui ne retournent pas d’entier depuis execute() déclenchent maintenant un avertissement de dépréciation. En 5.0, le type de retour devient obligatoire. Retourner 0 pour le succès, non-zéro pour l’échec : comportement Unix standard, et ça rend l’intégration avec les superviseurs de processus et les pipelines CI sans ambiguïté.

protected function execute(InputInterface $input, OutputInterface $output): int
{
    // ...
    return Command::SUCCESS; // = 0
}

Le deuxième point : le support de la variable d’environnement NO_COLOR, suivant la convention de no-color.org. Activez-la et toutes les commandes console de Symfony abandonnent les codes d’échappement ANSI quelle que soit la capacité déclarée par le terminal. Utile pour les environnements CI qui capturent la sortie en texte et qui s’étranglent sur les codes couleur intégrés dans les logs.

4.0, c’est une philosophie différente. La Symfony Standard Edition, ce point de départ monolithique qui embarquait tout et vous laissait retirer ce dont vous n’aviez pas besoin, a disparu. À sa place : un microframework qui grandit.

Flex

Symfony Flex est un plugin Composer qui change la façon dont on installe les packages Symfony. Avant Flex, ajouter un bundle impliquait : l’installer via Composer, l’enregistrer dans AppKernel.php, ajouter la config dans config/, mettre à jour le routing si nécessaire. Quatre étapes, toutes manuelles.

Avec Flex, installer un package exécute une “recette” : un ensemble d’étapes automatisées qui enregistre le bundle, génère un squelette de config et câble le routing. Installer Doctrine :

composer require symfony/orm-pack

Cette commande installe les packages, crée config/packages/doctrine.yaml, ajoute les stubs de variables d’environnement dans .env, et enregistre tout. Une commande, zéro étape manuelle.

Les recettes sont contribuées par la communauté et hébergées sur un serveur central. La qualité varie, mais pour les packages majeurs elles sont maintenues en parallèle des packages eux-mêmes.

La nouvelle structure de projet

Le layout de la Standard Edition (app/, src/, web/) est remplacé par une structure plus légère. La config se trouve dans config/, découpée par environnement. Le répertoire public s’appelle désormais public/, plus web/. Le kernel est plus petit. Les controllers sont des classes ordinaires, plus besoin d’extends Controller.

Plus important encore, le services.yaml par défaut utilise les conventions d’autowiring de la 3.3 qui rendent la configuration explicite des services largement inutile. Les nouveaux projets démarrent minimaux et grossissent en ajoutant ce dont ils ont réellement besoin.

Services privés par défaut

La plus grosse rupture de compatibilité de la 4.0 pour les apps existantes : tous les services sont privés par défaut. On ne peut plus récupérer un service directement depuis le container, il doit être injecté. C’est le bon choix du point de vue de l’injection de dépendances, mais ça casse tout ce qui utilisait $this->get('service_id') dans les controllers.

Le chemin de migration, c’est AbstractController, qui fournit les mêmes méthodes pratiques via des service locators lazy plutôt qu’un accès direct au container.

Ce qui a été supprimé

4.0 est propre parce qu’il supprime tout ce qui était déprécié en 3.4 :

• Les anciens événements de formulaire, les anciennes interfaces de sécurité, les anciens formats de configuration
• Le support de PHP < 7.1.3
• Le composant ClassLoader
• Le support ACL dans le SecurityBundle

Les suppressions sont musclées. Les apps qui ont sauté la correction de leurs dépréciations 3.4 vont souffrir. Celles qui ont fait le ménage avant ont une migration tranquille.

Symfony 4.0, c’est le reset dont le framework avait besoin. La Standard Edition avait accumulé des années de “c’est comme ça qu’on fait” que Flex balaie d’un coup.

Des variables d’environnement qui connaissent leur type

Avant 3.4 et 4.0, les variables d’environnement étaient des chaînes. Toujours. Essayer d’injecter DATABASE_PORT dans un paramètre de type int plantait silencieusement ou explosait avec une erreur de type. Le correctif était laid : caster en PHP ou éviter les paramètres typés.

4.0 embarque des processeurs de variables d’environnement qui gèrent la conversion au niveau du container :

parameters:
    app.connection.port: '%env(int:DATABASE_PORT)%'
    app.debug_mode: '%env(bool:APP_DEBUG)%'

Au-delà du casting, les processeurs peuvent décoder du base64, charger depuis des fichiers, parser du JSON, ou résoudre des paramètres du container dans une valeur. La combinaison json:file: est devenue un pattern propre pour charger des secrets depuis des fichiers montés dans des déploiements conteneurisés :

parameters:
    env(SECRETS_FILE): '/run/secrets/app.json'
    app.secrets: '%env(json:file:SECRETS_FILE)%'

Vous pouvez aussi écrire des processeurs personnalisés en implémentant EnvVarProcessorInterface et en taguant le service. Ça ressemble à de la sur-ingénierie jusqu’au jour où vous en avez besoin.

Des services taggués sans boilerplate

Avant 4.0, rassembler tous les services portant un tag donné dans un service signifiait écrire un compiler pass. Quarante lignes de PHP pour dire “donne-moi tout ce qui est tagué app.handler.”

3.4 a introduit le raccourci YAML !tagged, et 4.0 l’emporte avec lui :

services:
    App\HandlerCollection:
        arguments: [!tagged app.handler]

La collection est lazy par défaut quand elle est type-hintée en iterable, donc les services ne sont pas instanciés tant qu’on n’itère pas dessus. Ça a remplacé toute une catégorie de compiler passes qui n’existaient que pour construire des listes.

PHP comme format de configuration

YAML est la valeur par défaut depuis si longtemps que ça semble obligatoire. Ce n’est pas le cas. 4.0 embarque une configuration en PHP via une interface fluent :

// config/services.php
return function (ContainerConfigurator $container) {
    $services = $container->services()
        ->defaults()
            ->autowire()
            ->autoconfigure();

    $services->load('App\\', '../src/')
        ->exclude('../src/{Entity,Repository}');
};

La même approche fonctionne pour les routes. L’avantage pratique : autocomplétion de l’IDE, vérification des types, et vraie logique PHP dans la configuration sans la syntaxe d’interpolation %. YAML n’est pas près de disparaître, mais maintenant vous avez le choix.

Argon2i, parce que bcrypt vieillissait déjà

Symfony 3.4/4.0 a ajouté le support d’Argon2i, vainqueur du Password Hashing Competition 2015. La configuration tient en une ligne :

security:
    encoders:
        App\Entity\User:
            algorithm: argon2i

Argon2i est intégré à PHP 7.2+ et disponible via l’extension sodium sur les versions antérieures. Comme bcrypt, il se sale lui-même, inutile de gérer des colonnes de sel. Contrairement à bcrypt, il est conçu pour résister aux attaques par GPU avec une utilisation mémoire configurable. Si vous démarrez un nouveau projet sur 4.0, il n’y a vraiment aucune raison de choisir bcrypt.

La couche formulaire reçoit un thème Bootstrap 4

Le thème de formulaire Bootstrap 3 existant remonte à Symfony 2.x. Bootstrap 4 arrive comme option de premier ordre en 4.0 :

twig:
    form_themes: ['bootstrap_4_layout.html.twig']

Plus utile en pratique : les types d’input HTML5 tel et color sont désormais disponibles comme types de formulaire TelType et ColorType. Avant, il fallait écrire des types personnalisés ou surcharger des widgets bruts pour ça.

Binding de service local

Les bindings _defaults globaux s’appliquent à tous les services. Parfois on a besoin d’un binding limité à une classe ou un namespace spécifique, comme des instances de logger différentes pour des sous-systèmes différents.

4.0 supporte bind par service exactement pour ça :

services:
    App\Service\OrderService:
        bind:
            Psr\Log\LoggerInterface: '@monolog.logger.orders'

    App\Service\PaymentService:
        bind:
            Psr\Log\LoggerInterface: '@monolog.logger.payments'

Même interface, deux implémentations différentes, pas de factory, pas de configuration supplémentaire. Petite fonctionnalité, mais elle élimine toute une catégorie de bidouilles bancales.

3.4 n’est pas une version de fonctionnalités. Elle livre exactement les mêmes fonctionnalités que 3.3, plus chaque avertissement de dépréciation que 4.0 va rendre obligatoire. Son seul objectif est d’être l’outil de migration : monter de 3.3 à 3.4, corriger ce qui apparaît dans les logs, puis passer à 4.0 proprement.

Pourquoi les versions LTS comptent dans le modèle Symfony

Symfony publie une nouvelle version mineure tous les six mois. Ce rythme serait brutal pour les applications en production, donc le projet désigne chaque quatrième mineure comme LTS : trois ans de corrections de bugs, quatre de correctifs de sécurité. Ce qui signifie que les équipes peuvent cibler 3.4 et arrêter de penser aux mises à jour pendant un moment.

3.4 est la dernière LTS de la ligne 3.x. Si on est encore sur 2.x ou un 3.x ancien, c’est la zone d’atterrissage.

La couche de dépréciations

Chaque fonctionnalité supprimée par 4.0 est dépréciée dans 3.4. Faire tourner son application sur 3.4 avec les notices de dépréciation activées transforme les logs en une liste de tâches. Les plus courantes :

• Les services sans visibilité explicite (public/private) génèrent des warnings — 4.0 rend tous les services privés par défaut
• ControllerTrait est déprécié au profit de AbstractController
• Les anciennes interfaces d’authentificateur de sécurité sont marquées pour suppression
• La configuration de services YAML seule sans annotations d’autowiring déclenche des warnings

Le workflow prévu : monter sur 3.4, faire tourner la suite de tests avec les notices de dépréciation comme erreurs (SYMFONY_DEPRECATIONS_HELPER=max[self]=0 dans PHPUnit), corriger tout ce qui échoue. Après ça, la montée vers 4.0 est essentiellement mécanique.

La fenêtre de support

3.4 LTS reçoit des corrections de bugs jusqu’en novembre 2020 et des correctifs de sécurité jusqu’en novembre 2021. C’est une marge confortable pour les applications qui ne peuvent pas suivre chaque version. Le coût : rester sur l’architecture 3.x, sans Flex, sans structure micro-framework, sans autowiring zéro-config par défaut.

Le pont est là. Savoir si et quand on le traverse est une décision business, pas technique.

Les services passent privés

3.4 a inversé la visibilité par défaut des services de public à privé. Avant, $container->get('app.my_service') était du code parfaitement normal. Après, c’est un anti-pattern qui génère un warning de dépréciation dans 3.4 et casse complètement dans 4.0.

La raison est simple : récupérer des services directement depuis le conteneur masque les dépendances et déjoue l’analyse statique. En injectant via le constructeur, le conteneur peut optimiser le graphe, supprimer les services inutilisés, et détecter les erreurs à la compilation. En les récupérant à l’exécution, il ne peut pas.

Pour les applications qui utilisent déjà l’autowiring, la migration est généralement légère. Le point délicat ce sont les contrôleurs qui étendent Controller et appellent $this->get('quelque-chose'). La correction consiste à passer à AbstractController, qui fournit les mêmes raccourcis mais via des service locators paresseux plutôt que l’accès direct au conteneur.

Pour les services qui ont vraiment besoin d’être publics (accédés depuis du code legacy ou des tests fonctionnels), les marquer explicitement :

services:
    App\Service\LegacyAdapter:
        public: true

Lier les arguments scalaires une seule fois

Un point de friction classique avec l’autowiring : les arguments de constructeur scalaires. Si dix services ont tous besoin de $projectDir, il fallait configurer chacun individuellement. La clé bind sous _defaults règle ça :

services:
    _defaults:
        autowire: true
        autoconfigure: true
        bind:
            $projectDir: '%kernel.project_dir%'
            $mailerDsn: '%env(MAILER_DSN)%'
            Psr\Log\LoggerInterface $auditLogger: '@monolog.logger.audit'

Tout service avec un paramètre de constructeur nommé $projectDir reçoit la valeur liée automatiquement. On peut aussi lier par type-hint, ce qui gère le cas courant où plusieurs canaux de logger existent et on en a besoin d’un spécifique. Les liaisons dans _defaults s’appliquent à tous les services du fichier ; on peut surcharger par service si nécessaire.

Injecter les services taggués sans compiler pass

Avant 3.4, collecter tous les services avec un tag donné nécessitait d’écrire un compiler pass. Il y a maintenant un raccourci YAML :

services:
    App\Chain\TransformerChain:
        arguments:
            $transformers: !tagged app.transformer

class TransformerChain
{
    public function __construct(private iterable $transformers) {}
}

La notation !tagged crée un IteratorArgument : les services sont instanciés paresseusement au fil de l’itération, donc les transformers non utilisés ne sont jamais construits. Pour l’ordonnancement, ajouter un attribut priority à la définition du tag sur chaque service.

Un logger livré avec le framework

Pas de Monolog ? Pas de problème. Symfony 3.4 inclut un logger PSR-3 qui écrit sur php://stderr par défaut. On l’injecte avec Psr\Log\LoggerInterface :

use Psr\Log\LoggerInterface;

class MyService
{
    public function __construct(private LoggerInterface $logger) {}

    public function doSomething(): void
    {
        $this->logger->warning('Quelque chose de douteux s\'est produit', ['context' => 'ici']);
    }
}

Le niveau minimum par défaut est warning. La cible est les workloads container et Kubernetes où stderr est le puits de logs naturel. C’est délibérément minimal : pas de handlers, pas de processors, pas de channels. Quand on en a besoin, on installe Monolog.

Les Guard authenticators ont reçu une méthode supports()

La méthode getCredentials() du composant Guard jouait un double rôle : décider si l’authentificateur devait gérer la requête, et extraire les credentials. Retourner null était le signal pour passer. Ça rendait le contrat confus.

3.4 a ajouté supports() pour séparer ces responsabilités :

class ApiTokenAuthenticator extends AbstractGuardAuthenticator
{
    public function supports(Request $request): bool
    {
        return $request->headers->has('X-API-TOKEN');
    }

    public function getCredentials(Request $request): array
    {
        // N'est appelé que quand supports() retourne true.
        // Doit toujours retourner des credentials maintenant.
        return ['token' => $request->headers->get('X-API-TOKEN')];
    }
}

L’ancienne GuardAuthenticatorInterface est dépréciée. L’avantage pratique : les classes de base peuvent implémenter la logique partagée getUser() et checkCredentials(), tandis que les sous-classes ne surchargent que supports() et getCredentials(). Une responsabilité chacune.

Deux nouvelles commandes de debug

debug:autowiring remplace l’ancien debug:container --types pour découvrir quels type-hints fonctionnent avec l’autowiring :

$ bin/console debug:autowiring log

Autowirable Services
====================

  Psr\Log\LoggerInterface
      alias to monolog.logger
  Psr\Log\LoggerInterface $auditLogger
      alias to monolog.logger.audit

Passer un mot-clé pour filtrer. Fini de deviner si c’est LoggerInterface ou Logger.

debug:form donne la même capacité d’introspection pour les types de formulaires :

$ bin/console debug:form App\Form\OrderType label_attr

Option: label_attr
  Required: false
  Default: []
  Allowed types: array

Sans arguments, il liste tous les types de formulaires enregistrés, extensions et guessers. Avec un nom de type et un nom d’option, il montre toutes les contraintes sur cette option. Avant ça, on lisait le source ou on tâtonnait.

Les sessions sont devenues plus strictes par défaut

3.4 implémente SessionUpdateTimestampHandlerInterface de PHP 7.0, ce qui apporte deux choses : les écritures de session paresseuses (écrites seulement quand les données ont vraiment changé) et la validation stricte des ID de session (les IDs qui n’existent pas dans le store sont rejetés plutôt que créés silencieusement, ce qui bloque une classe d’attaques de fixation de session).

Les anciennes classes WriteCheckSessionHandler, NativeSessionHandler et NativeProxy sont dépréciées. Le MemcacheSessionHandler (note : pas Memcached) est supprimé, puisque l’extension PECL sous-jacente a arrêté de recevoir des mises à jour pour PHP 7.

Les thèmes de formulaires Twig peuvent maintenant être scopés

Les thèmes de formulaires globaux s’appliquent à tous les formulaires dans l’application. Si un formulaire a besoin d’un look complètement différent, il n’y avait pas de moyen propre de se désinscrire. Le mot-clé only gère ça :

{% raw %}{% form_theme orderForm with ['form/order_layout.html.twig'] only %}{% endraw %}

Le mot-clé only désactive tous les thèmes globaux pour ce formulaire, y compris le form_div_layout.html.twig de base. Le thème personnalisé doit alors soit fournir tous les blocs qu’il utilise, soit les importer explicitement avec {% raw %}{% use 'form_div_layout.html.twig' %}{% endraw %}.

Surcharger les templates de bundle sans boucles infinies

Surcharger un template de bundle qu’on avait aussi besoin d’étendre causait autrefois une erreur de référence circulaire. Surcharger @TwigBundle/Exception/error404.html.twig et essayer aussi d’en hériter ? L’ancienne résolution de namespace suivait la surcharge et bouclait indéfiniment.

3.4 a introduit le préfixe @! pour référencer explicitement le template de bundle original, en contournant toutes les surcharges :

{% raw %}{# templates/bundles/TwigBundle/Exception/error404.html.twig #}
{% extends '@!Twig/Exception/error404.html.twig' %}

{% block title %}Page non trouvée{% endblock %}{% endraw %}

@TwigBundle résout vers la surcharge si elle existe. @!TwigBundle résout toujours vers l’original. Surcharger-et-étendre, sans les acrobaties.

Le problème de l’autowiring

Avant 3.3, le DI de Symfony était puissant mais verbeux. Chaque service devait être déclaré explicitement dans services.yml avec ses arguments listés. L’autowiring existait depuis 3.1, mais il était opt-in par service et avait assez de cas limites pour vous mordre. Les équipes écrivaient soit des montagnes de YAML, soit s’appuyaient sur des bundles tiers pour réduire le bruit.

3.3 a réécrit les defaults. Avec autoconfigure: true et autowire: true définis une seule fois dans la section defaults, chaque classe dans src/ devient automatiquement un service, et ses dépendances de constructeur sont résolues par type. Ce qui prenait vingt lignes de YAML ne prend maintenant plus rien :

services:
    _defaults:
        autowire: true
        autoconfigure: true
    App\:
        resource: '../src/'

Ce bloc unique est toute la configuration de services pour la plupart des applications. Le framework découvre les services, injecte les dépendances, et applique les tags (command, event subscriber, voter…) en fonction des interfaces que chaque classe implémente.

Les conditionnels instanceof

Le mot-clé instanceof dans la configuration des services gère le tagging qui nécessitait auparavant une déclaration explicite :

services:
    _instanceof:
        Symfony\Component\EventDispatcher\EventSubscriberInterface:
            tags: ['kernel.event_subscriber']

Tout service implémentant EventSubscriberInterface reçoit le tag automatiquement. Même chose pour Command, Voter, MessageHandlerInterface. Le boilerplate s’évapore.

Le composant Dotenv

Avant 3.3, Symfony n’avait aucun moyen natif de charger des fichiers .env. La réponse standard était un package tiers. Le nouveau composant Dotenv lit .env et peuple $_ENV et $_SERVER, faisant de la configuration basée sur l’environnement un citoyen de première classe enfin.

Découverte des services depuis le filesystem

L’option resource rassemble tout. Au lieu d’enregistrer chaque classe individuellement, on pointe le conteneur vers un répertoire et il scanne les classes PSR-4 :

services:
    App\:
        resource: '../src/'
        exclude: '../src/{Entity,Migrations}'

Chaque classe trouvée devient un service avec son FQCN comme service ID. L’option exclude gère les cas comme les entités Doctrine qu’on ne veut pas que le conteneur touche. Et non, ce n’est pas de la magie : c’est un scan filesystem à la compilation, donc le coût est payé une fois pendant le cache warmup, pas par requête.

Quand on a besoin d’un sous-ensemble du conteneur

Les service locators résolvent une tension spécifique : certains services ont légitimement besoin d’accéder de manière paresseuse à un ensemble variable d’autres services, mais injecter le conteneur entier est un anti-pattern — ça masque les dépendances et déjoue l’analyse statique. La solution est un locator qui déclare explicitement ce qu’il contient.

services:
    App\Handler\HandlerLocator:
        class: Symfony\Component\DependencyInjection\ServiceLocator
        tags: ['container.service_locator']
        arguments:
            -
                App\Command\CreateOrder: '@App\Handler\CreateOrderHandler'
                App\Command\CancelOrder: '@App\Handler\CancelOrderHandler'

    App\Bus\CommandBus:
        arguments: ['@App\Handler\HandlerLocator']

Le locator implémente ContainerInterface de PSR-11, donc la classe réceptrice type-hinte contre Psr\Container\ContainerInterface. Les services à l’intérieur sont instanciés de manière paresseuse : si un handler donné n’est jamais appelé pendant une requête, il n’est jamais construit.

Et à propos de PSR-11 : Symfony 3.3 a fait implémenter ce standard à son conteneur. Ce qui signifie que toute bibliothèque attendant un conteneur PSR-11 fonctionne maintenant directement avec le conteneur Symfony, sans adaptateur.

Le routing est devenu plus rapide

Le composant de routing a réécrit comment il génère les fichiers dump. Dans une application avec 900 routes, la correspondance d’URL est passée de 7,5 ms à 2,5 ms par correspondance : une réduction de 66%. Les optimisations vivent dans la sortie compilée, pas dans le chemin d’exécution, donc les définitions de routes existantes en bénéficient automatiquement après un cache clear.

Trouver la racine du projet sans compter les séparateurs de répertoires

Avant 3.3, obtenir la racine du projet nécessitait le pattern délicieusement maladroit %kernel.root_dir%/../, parce que getRootDir() pointait vers le répertoire app/. La nouvelle méthode getProjectDir() remonte depuis le fichier kernel jusqu’à trouver composer.json et retourne ce répertoire.

// Avant
$path = $this->getParameter('kernel.root_dir') . '/../var/data.db';

// Après
$path = $this->getParameter('kernel.project_dir') . '/var/data.db';

Le paramètre correspondant est %kernel.project_dir%. Si vous déployez sans composer.json, vous pouvez surcharger la méthode dans votre classe kernel et retourner n’importe quel chemin qui fait sens.

Les messages flash sans toucher l’objet session

L’ancienne façon d’itérer les messages flash dans Twig nécessitait de passer par app.session.flashbag, ce qui forçait aussi le démarrage de la session qu’il y ait des messages ou non. Le nouveau helper app.flashes évite les deux :

{% raw %}{% for label, messages in app.flashes %}
    {% for message in messages %}
        <div class="flash-{{ label }}">{{ message }}</div>
    {% endfor %}
{% endfor %}{% endraw %}

S’il n’y a pas de messages flash, la session ne démarre jamais. On peut aussi filtrer par type : app.flashes('error') ne retourne que les messages d’erreur.

La commande encode-password est devenue intelligente

La commande console security:encode-password est devenue plus futée. Au lieu d’exiger qu’on passe la classe utilisateur en argument, elle liste maintenant les classes utilisateur configurées et laisse choisir :

$ bin/console security:encode-password

  For which user class would you like to encode a password?
  [0] App\Entity\User
  [1] App\Entity\AdminUser

Elle normalise aussi la configuration des encodeurs pour gérer les cas limites avec des noms d’utilisateur au format email que la version précédente corrompait silencieusement en remplaçant @ par des underscores. Beau rattrapage.

HTTP/2 push et resource hints

Le composant WebLink gère l’en-tête HTTP Link, qui dit aux navigateurs (et aux proxies HTTP/2) de précharger, prérécupérer ou se préconnecter à des ressources avant même que la page les demande. Il se présente sous forme de fonctions Twig :

{% raw %}{{ preload('/fonts/custom.woff2', { as: 'font', crossorigin: true }) }}
{{ prefetch('/api/next-page-data.json') }}
{{ dns_prefetch('https://fonts.googleapis.com') }}{% endraw %}

Chaque appel ajoute un en-tête Link correspondant à la réponse. Pour les applications derrière un proxy capable HTTP/2, ça peut déclencher un server push avant même que le navigateur ait parsé le HTML. On l’active dans config.yml :

framework:
    web_link:
        enabled: true

Des dépréciations auxquelles on peut vraiment faire confiance

La compilation du conteneur générait des avertissements de dépréciation qui disparaissaient au prochain chargement de page parce que le conteneur mis en cache était déjà construit. 3.3 persiste ces messages sur disque et les affiche dans la barre de débogage web aux côtés des dépréciations de la phase de requête. Si une classe est dépréciée pendant la compilation des services, vous le verrez sans avoir à vider le cache d’abord.

Ce que ça a signifié pour 4.0

Les defaults d’autowiring de 3.3 sont exactement ce que Symfony 4.0 a adopté comme nouvelle structure de projet standard. Le services.yaml de chaque nouveau projet Symfony 4 est essentiellement le snippet ci-dessus. Si on avait déjà assimilé ce que 3.3 introduisait, le “nouveau mode” de 4.0 semblait familier plutôt qu’étranger.

La direction était claire : moins de configuration, plus de convention. Laisser PHP comprendre ce qu’il faut câbler ensemble.