Pourquoi fait-on toujours du Twig (et pas du React) pour certaines interfaces métiers

Depuis quelques années, on assiste à une véritable déferlante de frameworks JavaScript. React, Vue, Angular… difficile d’ouvrir un projet GitHub ou de consulter un appel d’offres sans croiser ces noms.

React, en particulier, a séduit par sa promesse : construire des interfaces ultra-réactives, composées de briques modulaires, capables de rivaliser avec l’ergonomie d’une application desktop. Et il faut le reconnaître : pour certains projets, c’est un game changer.

Mais dans la réalité de nos métiers, et surtout dans celle de nos clients, la donne est souvent différente. Beaucoup de projets Symfony ou de solutions métiers internes n’ont pas besoin d’un front-end React.

Pas besoin de composants React partout. Pas besoin d’alourdir le serveur avec un second build. Pas besoin de recruter des profils supplémentaires juste pour maintenir le JavaScript.

Chez Mintfull, on a été challengés sur ce sujet plus d’une fois : “Pourquoi vous ne partez pas sur React ?”. Notre réponse tient en deux mots : pertinence technique.

Parce qu’au-delà de la mode, notre rôle est de livrer des produits fiables, performants et maintenables. Et bien souvent, un rendu serveur en PHP avec Symfony + Twig fait parfaitement le job.

Comme le résume KNP Labs :

« Certaines applications n’ont pas besoin de framework JavaScript… aucun programme n’a besoin de complexité superflue. »

Tout est dit.

Le piège du “tout-React” : une mode qui coûte cher

Ces dernières années, React est devenu la réponse par défaut à quasiment toutes les problématiques front-end. C’est un outil puissant, avec un écosystème riche. Mais l’adopter sans discernement, c’est comme utiliser une Formule 1 pour livrer du pain : impressionnant sur le papier, inefficace dans la pratique.

Dans beaucoup de projets que nous auditons, nous retrouvons les mêmes symptômes :

• Une intégration de React complète alors que le site se limite à des formulaires CRUD et des pages de listing.

• Une application Symfony doublée d’une API REST, uniquement pour servir un front React… qui aurait pu être rendu directement par Twig.

• Des composants JavaScript fragmentés, dont la complexité dépasse de loin les besoins réels du produit.

Le résultat, c’est :

• Plus de temps de développement : création d’une API, gestion des appels AJAX, mise en place d’un routeur côté client.

• Plus de points de défaillance : un bug côté front peut bloquer l’affichage complet de la page HTML.

• Plus de coûts : besoin d’un profil JavaScript avancé en plus d’un développeur PHP.

• Plus de maintenance : deux stacks à faire évoluer en parallèle.

Et soyons honnêtes : dans 80 % des solutinos métiers, ce choix n’apporte aucune valeur mesurable à l’utilisateur final.

Un rendu serveur rapide, fiable et optimisé, avec juste une pincée de JavaScript là où c’est nécessaire, suffit largement.

Twig + Symfony : un combo sous-estimé (et pourtant redoutable)

On a parfois l’impression que Twig n’est qu’un “vieux” moteur de templates PHP.

C’est une vision totalement dépassée. Dans les faits, Twig est devenu un moteur de rendu serveur ultra-performant, capable de rivaliser avec bien des solutions front modernes… tout en restant simple à utiliser et à maintenir.

Un socle technique solide

Quand on démarre un projet Symfony, Twig s’intègre naturellement :

• Il se marie avec tous les composants natifs : routing, sécurité, formulaires, validation, pagination…

• Il permet de créer des pages HTML propres et modulaires, avec héritage de templates, macros et inclusions.

• Il force une séparation nette entre code métier PHP et affichage, limitant les risques de mélange incontrôlé.

Un gain de productivité immédiat

Avec Twig, pas besoin de mettre en place une architecture complexe.

On installe Symfony, on crée un contrôleur, on génère une page HTML… et c’est parti.

Pas de configuration Webpack, pas de bundler, pas d’hydratation côté client avant d’afficher le contenu.

Ce qui veut dire :

• Des délais de livraison réduits

• Moins de boilerplate à écrire

• Des modifications simples et rapides

Sécurité et performance incluses

Twig échappe automatiquement toutes les variables affichées dans les templates.

Résultat : une protection native contre les failles XSS, sans avoir à rajouter de filtre ou de middleware côté JavaScript.

Côté performance, le rendu serveur permet à l’utilisateur de voir sa page complète dès la première réponse du serveur, sans attendre que le navigateur télécharge et exécute un bundle JS.

Un langage accessible

Pour un développeur habitué à PHP, utiliser Twig est naturel.

Sa syntaxe proche du HTML le rend compréhensible même pour un intégrateur ou un développeur junior.

À l’inverse, démarrer sur une application React nécessite de maîtriser JSX, la gestion d’état, les hooks, et l’écosystème JavaScript.

Ce que vous perdez avec React… quand vous n’en avez pas besoin

React est puissant. Mais cette puissance a un prix, et pas seulement sur la feuille de mission du développeur JavaScript senior que vous allez devoir recruter.

Mettre en place une un site en React implique un écosystème complet à maintenir : gestion d’état, API REST ou GraphQL, serveur de build, stratégies de SEO, optimisation des performances client…

Si vos besoins sont simples, ce coût n’est pas justifié.

Un impact direct sur la performance utilisateur

Avec un rendu React classique (sans SSR), le navigateur reçoit d’abord une page presque vide, puis télécharge un bundle JavaScript qui va reconstruire le contenu à l’écran. Résultat :

• Temps d’affichage initial plus long

• Utilisateurs sur connexion lente pénalisés

• Impression de “lenteur” malgré la puissance du back-end

À l’inverse, un rendu serveur via Twig envoie directement la page HTML complète, prête à être affichée immédiatement.

Une architecture plus lourde à maintenir

En optant pour une intégration de React dans un Symfony, vous devez :

• Maintenir deux stacks : PHP côté serveur et JavaScript côté client

• Dupliquer parfois la logique (validation des formulaires, règles métier…)

• Gérer des dépendances supplémentaires (state manager, router, outils de tests front)

Chaque mise à jour technique ou changement d’API nécessite de toucher à deux couches différentes, ce qui augmente le risque de bugs.

Des coûts de développement et de formation plus élevés

Former une équipe Symfony à Twig est simple : tout reste dans l’écosystème PHP.

Former la même équipe à React, c’est une autre histoire : JSX, hooks, lifecycle, rendering conditionnel, gestion d’état, libraries spécifiques…

Si vous n’avez pas besoin de la flexibilité d’une SPA, ce temps de formation et d’intégration est un investissement peu rentable.

Un SEO plus complexe

Même si des solutions comme Next.js permettent de faire du SSR avec React, cela ajoute encore une couche technique à gérer.

Pour une application métier interne, le SEO n’est peut-être pas prioritaire. Mais pour un back-office accessible en ligne ou un module comme un store locator, un rendu serveur Symfony/Twig est SEO-friendly par défaut.

Oui, React est génial. Mais pas partout.

Ne nous méprenons pas : chez Mintfull, nous savons utiliser React et nous l’apprécions.

C’est l’un des frameworks JavaScript les plus puissants du marché, et il brille dans certains cas précis.

Le problème, c’est quand on le sort de son terrain de jeu naturel pour l’imposer à des projets qui n’en tirent aucun bénéfice.

Quand React devient la meilleure option

Un composant React excelle lorsque :

• L’interface doit se mettre à jour en temps réel sans rechargement de page (tableaux de bord live, chat, suivi d’inventaire en direct…)

• L’expérience utilisateur doit rivaliser avec celle d’une application native, avec des transitions fluides, des animations complexes et des interactions multiples

• On envisage un développement multi-plateformes, par exemple avec React Native, pour réutiliser la base de code et les compétences front

• On travaille sur une architecture découplée où le front et le back sont deux services totalement indépendants, reliés par une API

Une flexibilité qui a un coût

Oui, React permet de créer des interfaces modernes et modulaires. Mais cette flexibilité :

• Nécessite un state management solide (Redux, Zustand, ou équivalent)

• Demande de maîtriser l’hydratation côté client et les optimisations de rendering

• Impose de penser l’UX différemment, en termes de composants et d’événements plutôt qu’en simples pages

Pour un CTO ou un lead technique, cela signifie aussi :

• Plus de dépendances à maintenir

• Plus de profils spécifiques à recruter

• Plus de temps d’intégration avant la mise en production

Notre approche

Chez Mintfull, on ne part pas d’un outil, on part du besoin.

Si une application Symfony peut être optimisée avec un peu de JavaScript léger, on reste sur Twig.

Si la vision produit impose une application React complexe avec plusieurs composants front-end, on le fait, mais avec la même exigence : code clair, architecture maîtrisée, performance maximale.

Deux projets concrets où Twig a fait la différence

Cas client 1 – BACK IPLN : un tunnel de reprise optimisé de bout en bout

IPLN est une référence lyonnaise dans la vente de matériel photo et vidéo.

Leur besoin : créer un service innovant de reprise, permettant à un client de vendre son matériel en quelques étapes simples, avec le choix entre un virement bancaire ou un bon d’achat valable sur le site e-commerce IPLN.fr.

Sur le papier, certains auraient proposé une application React complète, avec une API Symfony en back.

Nous avons choisi une autre voie : développer une application Symfony full-stack, avec Twig pour le rendu serveur.

Pourquoi ?

• Performance initiale : le tunnel de reprise se charge immédiatement, même sur des connexions lentes, car tout est généré côté serveur.

• Ergonomie : les formulaires utilisent le composant Form Symfony, offrant une validation côté serveur robuste et simple à maintenir.

• Maintenance : un développeur PHP peut reprendre le code sans devoir connaître React ou son écosystème.

• Sécurité : Twig échappe automatiquement toutes les variables, réduisant les risques de failles XSS.

• Dynamisme ciblé : quelques scripts JavaScript légers améliorent l’UX (auto-complétion, champs conditionnels) sans nécessiter une intégration de React.

Résultat : un projet Symfony qui tourne toujours parfaitement plusieurs années après sa mise en ligne, avec un coût de maintenance réduit et une satisfaction client intacte.

Dans ce contexte, utiliser React aurait complexifié l’architecture sans bénéfice concret pour l’utilisateur final.

Cas client 2 – Store Locator Opal : un module multi-CMS performant

Opal est leader dans la vente de lunettes aux opticiens, avec plus de 10 000 points de vente.

Leur besoin : un Store Locator avancé permettant aux clients de trouver un revendeur, filtrer par marque, localisation, ou autres critères, tout en étant intégrable sur plusieurs sites (Prestashop, WordPress…).

Nous avons choisi de développer le Store Locator en PHP avec Symfony et Twig, plutôt que de passer par une intégration de React.

Pourquoi ?

• Compatibilité multi-CMS : un module PHP s’intègre facilement dans un thème Prestashop ou WordPress, sans nécessiter un environnement JavaScript complexe.

• Synchronisation automatisée : les données sont directement mises à jour depuis l’ERP d’Opal, éliminant toute intervention manuelle.

• Accessibilité : le Store Locator est fonctionnel même si le JavaScript est désactivé.

• Performance : l’affichage initial est immédiat grâce au rendu côté serveur, avec des filtres dynamiques ajoutés via JS léger.

Avec une application React, chaque site aurait nécessité un environnement front spécifique et une intégration plus lourde.

Ici, le choix de Twig a permis un déploiement rapide, un code mutualisable et une maintenance simplifiée.

Conclusion : le bon outil pour le bon projet

En matière de développement web, il n’existe pas de solution universelle ou de solution miracle.

Le choix entre Symfony + Twig et une application React ne devrait jamais se résumer à “ce qui est à la mode” ou “ce que tout le monde utilise”.

Chez Mintfull, notre approche est simple : nous choisissons l’outil qui sert le projet, pas la tendance.

Cela signifie :

• Utiliser React quand l’interface doit être ultra-dynamique, multi-plateforme, ou pilotée par de nombreux composants front-end interconnectés.

• Rester sur un rendu serveur avec Twig quand la priorité est la performance initiale, la simplicité de maintenance, et un coût maîtrisé.

• Profiter de la puissance du framework PHP Symfony pour créer des applications stables, sécurisées et prêtes à évoluer.

La maturité technique, c’est savoir dire non

Un CTO ou un responsable technique expérimenté sait que multiplier les couches technologiques augmente mécaniquement :

• Le temps de mise en production

• Les risques de bugs

• Les coûts de maintenance

À l’inverse, faire simple avec un moteur de templates comme Twig, c’est miser sur :

• Un cycle de développement plus rapide

• Un code lisible et maintenable par n’importe quel développeur PHP

• Une architecture claire, sans surcouche inutile

• Un rendu immédiat pour l’utilisateur, même sur des connexions faibles