React et Symfony ne s’opposent pas : Symfony documente deux façons de les faire cohabiter, et le bon choix dépend d’une seule question — qui possède le routage de l’application ?

La vidéo en bas de page montre l’une des deux approches. Voici comment elles se situent aujourd’hui, parce que l’écosystème front de Symfony a bougé.

Deux approches, pas une seule

La documentation Symfony présente le choix sans détour : soit tu construis le HTML côté PHP avec Twig, soit tu confies le front à un framework JavaScript. Les deux sont documentées, les deux fonctionnent.

Ce qui tranche, c’est le routage. Si React doit gérer les URL de l’application, Symfony ne peut plus rendre les pages : il devient une API.

Approche 1 : des îlots React dans du Twig

C’est le cas le plus fréquent sur un site existant. Tu gardes Twig et Symfony pour les pages, et tu montes un composant React dans un coin de l’interface — un tableau de bord, un sélecteur, un éditeur.

Le défaut d’un nouveau projet Symfony est AssetMapper, recommandé pour les nouveaux projets : il tourne entièrement en PHP, ne demande aucune étape de build, et s’appuie sur les import maps natives du navigateur. Tu ajoutes un paquet avec php bin/console importmap:require.

Sa limite est structurelle et vaut pour React : AssetMapper ne compile pas le JSX. Les fichiers .jsx ont besoin des outils natifs de l’écosystème React pour être transformés en JavaScript exécutable. Sur ce point précis, Webpack Encore reste l’outil adapté, avec son preset React activé par .enableReactPreset(). À noter si tu reprends une configuration ancienne : depuis Encore 7.0, webpack.config.js s’écrit en syntaxe ESM et Encore.getWebpackConfig() est asynchrone, donc à attendre avec await.

Approche 2 : Symfony en API pure, React devant

C’est l’approche que la documentation Symfony met en avant dès que tu utilises un framework front avec son propre routeur : construis le front avec les outils natifs du framework, et traite Symfony comme une API. API Platform est cité comme l’outil adapté, et sa distribution standard livre justement un backend Symfony, un front Next.js et une interface d’administration React, le tout dockerisé.

Côté React, la documentation officielle oriente aussi vers un framework plutôt que vers un assemblage manuel : Next.js, React Router ou Expo selon la cible. Monter un projet React « à la main » avec Vite n’est recommandé que si aucun framework ne convient à tes contraintes.

Où en est Webpack Encore

Encore n’est ni mort ni abandonné : il reçoit des correctifs de bugs et des mises à jour de dépendances, mais plus de nouvelles fonctionnalités. C’est un mode maintenance assumé, pas une dépréciation.

La relève côté bundler s’appelle Symfony Reprise, annoncée le 31 juillet 2026. Ce n’est pas un bundler : c’est une couche d’intégration pour Vite et Rsbuild, qui génère les fichiers entrypoints.json et manifest.json compatibles avec Encore et remplace les helpers Twig tag pour tag. Le paquet est en version 0.x : à regarder, pas encore à déployer en production.

Et si tu préfères rester en Twig ?

Avant de choisir React, un détour vaut le coup : Symfony UX Twig Components permet de construire des composants interactifs sans quitter Twig, ce qui suffit souvent à éviter un second écosystème dans le projet.

Pour aller plus loin, la documentation front-end de Symfony détaille la comparaison AssetMapper et Encore, et la documentation React explique pourquoi elle oriente vers des frameworks plutôt que vers un montage manuel.