Symfony UX 3.3 : le support de Symfony Reprise et les nouveautés front

Symfony UX vient de passer un cap discret mais significatif : la version 3.3.0, publiée la semaine du 13 au 19 juillet 2026, ajoute le support de Symfony Reprise dans StimulusBundle — la nouvelle intégration Vite et Rsbuild que l'équipe core positionne comme le futur remplaçant de Webpack Encore. Cette sortie arrive un mois tout juste après un rappel plus sérieux : les versions 3.2.0 et 2.36.1, publiées le 19 juin 2026, corrigeaient deux vulnérabilités de sécurité, une XSS dans ux-icons et une traversée de répertoire dans ux-toolkit. De quoi rappeler qu'un écosystème frontend, même conçu pour rester léger, se traite avec la même rigueur de suivi de CVE que n'importe quelle dépendance Composer. Ce billet fait le point sur ce qu'apporte concrètement Symfony UX au front d'une application Symfony sans build lourd, sur ce qu'est Reprise, et sur ce que change réellement son support dans la 3.3.

Symfony UX en une définition : le front sans framework imposé

Symfony UX regroupe une famille de bundles — Stimulus, Turbo, LiveComponent, Autocomplete, Toolkit — qui ajoutent de l'interactivité côté client sans imposer React, Vue ou Angular, et sans faire basculer l'application vers une architecture API + SPA. Le principe directeur reste le même depuis la première version : le HTML généré côté serveur est la source de vérité, le JavaScript vient l'augmenter plutôt que le dupliquer. Pour une équipe Symfony qui n'a pas de besoin métier justifiant une séparation front/back stricte, c'est un gain de vélocité direct — pas de logique de rendu à maintenir deux fois, pas d'API REST à exposer juste pour afficher une liste paginée ou un formulaire réactif.

• Stimulus — contrôleurs JavaScript légers attachés au DOM via des attributs data-, sans étape de build obligatoire
• Turbo — navigation façon SPA (Drive, Frames, Streams) qui couvre la majorité des besoins sans une ligne de JS custom
• LiveComponent — composants Twig à état réactif, recalculés côté serveur et re-rendus par appels Ajax incrémentaux
• Autocomplete — champs de recherche filtrés côté serveur, branchés directement sur Doctrine ou une source de données existante
• AssetMapper — gestion des assets via importmaps natifs du navigateur, sans Node.js ni étape de bundling

Symfony Reprise : ce que c'est, et ce que ça n'est pas encore

Reprise est un nouveau package — symfony/reprise côté Composer, @symfony/reprise côté npm — qui rejoue pour Vite et Rsbuild le rôle que Webpack Encore tenait pour Webpack. Il fournit la colle Symfony nécessaire à ces bundlers : génération de entrypoints.json et manifest.json, tags Twig reprise_entry_script_tags et reprise_entry_link_tags pour injecter scripts et styles dans un template, versioning des assets via le helper asset(), serveur de dev et Hot Module Replacement branchés directement dans Twig, intégration des contrôleurs Stimulus, support CDN et Subresource Integrity. La différence de philosophie avec Encore est assumée : là où Encore embarquait toute la configuration Webpack et ses innombrables loaders, Reprise délègue la compilation, la minification et le code splitting au bundler choisi, et se concentre uniquement sur l'intégration côté Symfony.

Il faut cependant garder les pieds sur terre avant de migrer un projet en production. Le dépôt symfony/reprise n'a été rendu public que récemment et son premier commit ne remonte qu'à septembre 2025 — l'équipe Symfony le qualifie elle-même d'expérimental, avec des API encore susceptibles de bouger d'une version mineure à l'autre. Rien n'interdit de l'essayer sur un projet annexe ou une preuve de concept, mais l'adopter aujourd'hui sur une application critique reviendrait à parier sur une base encore mouvante. StimulusBundle 3.3 y ajoute un support de première classe, au même niveau qu'AssetMapper et Webpack Encore, ce qui est surtout le signal que l'équipe core investit sérieusement dans cette direction pour la suite.

Configurer Reprise : Vite, Rsbuild et Stimulus

Côté configuration, Reprise s'active comme n'importe quel plugin de bundler moderne. Pour Vite :

// vite.config.js — active le plugin Symfony Reprise
import { defineConfig } from 'vite';
import Symfony from '@symfony/reprise/vite';

export default defineConfig({
  build: {
    rolldownOptions: {
      input: {
        app: './assets/app.js',
      },
    },
  },
  plugins: [
    Symfony({
      // options
    }),
  ],
});

Et l'équivalent pour Rsbuild, pour les équipes qui préfèrent cet outil à Vite :

// rsbuild.config.js — équivalent pour Rsbuild
import { defineConfig } from '@rsbuild/core';
import Symfony from '@symfony/reprise/rsbuild';

export default defineConfig({
  source: {
    entry: {
      app: './assets/app.js',
    },
  },
  plugins: [
    Symfony({
      // options
    }),
  ],
});

Le bootstrap des contrôleurs Stimulus, lui, ne dépend plus du bundler choisi : @symfony/stimulus-bridge — spécifique à Webpack Encore — n'est d'ailleurs plus une dépendance npm par défaut depuis cette release. Sous Reprise, un seul appel suffit pour démarrer l'application et enregistrer automatiquement les contrôleurs déclarés dans controllers.json, en mode eager ou lazy, exactement comme le fait le loader d'AssetMapper :

// assets/app.js — démarre Stimulus via Symfony Reprise
import { startStimulusApp } from '@symfony/reprise/stimulus';

const app = startStimulusApp();
// app.register('mon-controleur', MonControleur) reste possible
// pour un contrôleur déclaré en dehors de controllers.json

Ce que la 3.3 change au-delà de Reprise

Le support de Reprise concentre l'attention, mais la 3.3 embarque une dizaine d'autres correctifs et ajouts, tous orientés qualité de vie et fiabilité :

• Toolkit Shadcn — deux nouveaux composants, Sonner (notifications toast) et Combobox (champ de saisie combiné à une liste filtrable), installables via php bin/console ux:install sonner --kit=shadcn
• Commande ux:install — la résolution des recettes devient insensible à la casse (Alert résout désormais alert) et les messages d'erreur suggèrent les alternatives les plus proches au lieu de laisser deviner
• Documentation des composants — un nouveau format unifié {# @prop #} et {# @block #}, lu par un ComponentDocParser et vérifié par un ComponentDocChecker, qui élimine la duplication entre commentaires et valeurs par défaut de la balise props
• Shadcn Tooltip — se ferme désormais au scroll et au redimensionnement, et n'intercepte plus les clics destinés aux éléments sous-jacents quand il est masqué
• LiveComponent — fin des erreurs 500 sur des payloads d'hydratation malformés, respect de data-live-ignore par le scanner de chargement, et support des propriétés de collection nullable
• Autocomplete — correctif de la clause LIKE ESCAPE qui cassait la recherche sur PostgreSQL

Ne pas oublier la sécurité : le rappel de juin 2026

Un mois avant la 3.3, les versions 3.2.0 et 2.36.1, publiées le 19 juin 2026, corrigeaient deux vulnérabilités qu'il valait mieux ne pas laisser traîner. La première, une injection XSS dans ux-icons : le composant rendait le contenu SVG sans le sanitizer, aussi bien pour les fichiers d'icônes locaux que pour les réponses à la demande du service Iconify, activé par défaut. Comme la fonction Twig ux_icon() marque sa sortie comme HTML sûr, un set d'icônes malveillant ou un endpoint Iconify compromis pouvait injecter des scripts et des gestionnaires d'événements arbitraires. La seconde, une traversée de répertoire dans ux-toolkit : la commande ux:install copiait les fichiers d'une recette de kit avec des chemins insuffisamment validés, ce qui permettait à une recette forgée d'écrire ou de lire des fichiers en dehors des répertoires prévus. Toute application utilisant ces deux bundles devait mettre à jour dès la publication du correctif, sans attendre la fenêtre de maintenance suivante. C'est un rappel utile : la surface d'attaque d'un projet Symfony ne se limite plus au code métier ou aux dépendances PHP historiques, elle inclut désormais l'outillage frontend qu'on installe d'un composer require distrait.

Faut-il migrer vers Reprise dès maintenant ?

Pour la grande majorité des projets Symfony actuels, la réponse est non — pas encore. AssetMapper reste une option mature et éprouvée pour se passer de Node.js, et Webpack Encore continue de fonctionner correctement pour les projets qui ont déjà investi dans sa configuration. Reprise vise un public différent : les équipes qui ont besoin de l'écosystème de plugins Vite ou Rsbuild — pour du CSS-in-JS avancé, des transformations spécifiques, une intégration avec un design system existant — et qui sont prêtes à absorber le risque d'une base encore expérimentale. À surveiller de près, donc, mais pas à généraliser sur un projet en production tant que le dépôt n'a pas atteint une release stable.

Le fil conducteur reste le même depuis plusieurs versions de Symfony UX : la Toolkit et ses composants Shadcn s'appuient directement sur le moteur TwigComponent introduit par Twig 3, tout comme LiveComponent. Reprise ne change rien à cette fondation — il ne fait que déplacer la couche de build, pas la façon dont les composants sont déclarés ou rendus côté Twig. C'est aussi ce qui explique pourquoi StimulusBundle peut supporter trois systèmes d'assets en parallèle sans dupliquer la logique applicative : AssetMapper, Encore et désormais Reprise ne sont jamais que des sources différentes pour le même controllers.json.

Cette montée en maturité du frontend accompagne d'ailleurs une tendance plus large observée depuis Symfony 8.1 et son ouverture aux applications HTTP-less : le framework élargit méthodiquement son terrain de jeu, que ce soit côté serveur avec les workers et les CLI tools, ou côté client avec un outillage front qui ne force plus la main vers un bundler unique. Dans les deux cas, le principe reste identique — proposer une option solide par défaut, et laisser chaque équipe choisir la complexité qu'elle est prête à assumer, sans jamais l'imposer d'en haut.

Reste que suivre ce rythme de release — UX, Reprise, correctifs de sécurité à appliquer sans délai, dépréciations à anticiper avant la prochaine LTS — demande une veille constante que peu d'équipes internes peuvent maintenir à temps plein sans y sacrifier leur roadmap produit. C'est exactement le rôle qu'un accompagnement Symfony dédié vient combler : garder une stack à jour en continu, arbitrer entre AssetMapper, Encore et Reprise selon le contexte réel du projet plutôt que par effet de mode, et transformer une veille chronophage en décisions déjà prêtes à l'emploi pour l'équipe.