En 2021, j'ai converti un projet client aux config builders fluides arrivés avec Symfony 5.3. Chaînes de méthodes, autocomplétion, toute l'expérience SecurityConfig. J'avais l'impression de configurer un framework comme un adulte. Quatre ans plus tard, ce format est déprécié en 7.4 et absent du chemin recommandé, et ma première réaction a été un long soupir devant mon bureau. Ma seconde réaction, après avoir vraiment lu le raisonnement, c'est que Symfony fait le bon choix, et je veux défendre cette position même si elle m'a coûté un après-midi de migration.

D'abord les faits. Symfony 8.0 est sorti le 27 novembre 2025, en parallèle de la 7.4 LTS. Même base de code, moins tout ce que la 7.4 a déprécié. Cela inclut le XmlFileLoader, à la fois pour les définitions de services et pour les routes, déprécié via la PR #60568 de Mathieu Lechat en octobre 2025 et désormais tout simplement absent. Si ton appli, ou n'importe quel bundle de ton répertoire vendor, dépend encore du chargement d'un services.xml ou d'un routes.xml, elle ne démarrera pas sur 8.0. YAML, lui, est explicitement à l'abri : l'équipe core a dit que sa dépréciation n'est pas prévue, et les recipes continuent de le générer par défaut.

Voici l'argument que je veux poser : pendant vingt ans, on a traité le format de config comme une affaire de goût, et ce cadrage a toujours été un peu faux. La vraie question, c'est ce que tes outils peuvent vérifier avant la compilation du conteneur. XML avait un schéma, certes, mais l'écosystème n'a jamais construit de support éditeur moderne autour, et Flex ne l'a jamais écrit. Les builders fluides avaient l'air conviviaux pour le développeur, mais Nicolas Grekas a expliqué le défaut fatal : ils verrouillent chaque arbre de config dans une forme canonique unique, ce qui rend impossibles les mises à jour automatiques de recipes. Un format qui se bat contre ton gestionnaire de paquets perd, peu importe à quel point il se lit bien.

Ce qui remplace les deux est instructif. Le nouveau format PHP, ce sont de simples tableaux enveloppés dans App::config() ou Routes::config(), et l'astuce, c'est que Symfony génère des métadonnées de forme de tableau dans un fichier config/reference.php que PHPStan, Psalm et PhpStorm peuvent consommer. Ta config devient quelque chose qu'un analyseur statique peut contrôler, clés erronées comprises, avant même que tu lances cache:clear en staging. YAML a reçu le même traitement sous un autre angle : la 7.4 ajoute des schémas JSON pour les fichiers services, routes, validation et serializer, référencés via un commentaire yaml-language-server que les éditeurs détectent. Deux formats, tous deux vérifiables par la machine. C'est de la convergence, pas de l'agitation.

Maintenant la concession honnête, parce qu'il y en a une vraie. XML a été pendant des années le format officiellement recommandé pour les auteurs de bundles, et pas mal de paquets encore à peu près maintenus livrent toujours leur câblage interne dans un Resources/config/services.xml. Ces bundles ne se dégradent pas en douceur sur 8.0, ils cessent de fonctionner, point. Et les builders fluides ont duré quatre ans entre leur introduction et leur dépréciation, exactement le genre de durée de vie qui fait hésiter les équipes avant d'adopter la moindre nouveauté du framework. Le fichier reference.php a aussi ses aspérités : il change à chaque modification de dépendance, donc tes pull requests se remplissent de diffs bruyants, et au moins un utilisateur a vu la génération casser à cause d'un glob comme **/*.graphql dans une valeur de config. Rien de tout ça n'est gratuit.

J'atterris quand même là où j'atterris, pour deux raisons. Un : personne n'est poussé du haut de la falaise. La 7.4 LTS embarque quatre ans de support de sécurité, fait tourner anciens et nouveaux formats côte à côte, et te donne un journal de dépréciations que tu peux réellement traiter. Il existe un convertisseur communautaire sur github.com/GromNaN/symfony-config-xml-to-php qui réécrit le XML des bundles vers le format tableau, et envoyer sa sortie en PR upstream est une façon franchement utile de passer une heure. Deux : Symfony est d'une candeur inhabituelle sur son propre calendrier : le blog dit noir sur blanc que le format tableau n'est pas encore le défaut recommandé, parce que le support éditeur des formes de tableaux complexes reste inégal et que Flex ne parle toujours que YAML. Un framework qui dit « voilà la direction, mais ne saute pas tout de suite » a regagné un peu de confiance après l'épisode des builders fluides, du moins à mes yeux.

Du coup, mon conseil pratique s'écarte de l'enthousiasme des formats dans les deux sens. Laisse ton YAML qui fonctionne tranquille, ajoute les commentaires de schéma, profite de l'autocomplétion. Écris la config vraiment nouvelle au format tableau si ton équipe fait tourner PHPStan de toute façon, parce que c'est là que se trouve le levier. Et avant même de créer ta branche pour la 8.0, greppe ton répertoire vendor à la recherche de config XML, parce que le bundle oublié depuis 2019 est ce qui va réellement te bloquer. Ce qui me laisse avec la question que je n'arrête pas de retourner : quand le format tableau aura mûri et que Flex saura l'écrire, est-ce que la config YAML devient discrètement du legacy d'ici cinq ans, ou est-ce qu'un format lisible par un humain avec validation par schéma est tout simplement le meilleur état final pour la config applicative ? J'ai changé d'avis deux fois cette semaine. Dis-moi où tu atterris.