Le stack Laravel ultime pour 2026 : construire un CMS robuste avec Inertia 2, React 19 et Tailwind v4
En 2026, choisir la bonne architecture pour un CMS PHP est loin d'être trivial. WordPress accumule des centaines de CVE par semaine, les solutions SaaS comme Contentful ou Sanity affichent des tarifs prohibitifs pour les PME, et les alternatives Node.js (Strapi, Payload) ne conviennent pas aux équipes 100 % PHP. C'est ce constat qui a poussé le développeur Hamed Pakdaman à construire UnfoldCMS, un CMS self-hosted en Laravel livré comme un produit fini, pas comme un framework à assembler soi-même.
Cet article décortique les choix techniques derrière ce projet — un retour d'expérience particulièrement pertinent pour les équipes PHP/Symfony qui réfléchissent à leur stack applicatif en 2026.
Un stack moderne au service de la productivité
La combinaison choisie mérite qu'on s'y attarde :
- Laravel 11 comme socle backend
- Inertia 2 pour le pont entre le backend et le frontend sans API REST dédiée
- React 19 + TypeScript pour l'interface d'administration
- Tailwind v4 + shadcn/ui pour le design system (plus de 50 composants)
- MySQL / MariaDB en base de données
- Spatie pour la gestion des médias, des permissions (RBAC) et des logs d'activité
Le résultat tourne sur un VPS Hetzner à 5 €/mois avec environ 80 Mo de RAM au repos. C'est un indicateur fort : un stack bien dimensionné n'a pas besoin d'infrastructure surdimensionnée.
Pourquoi ce choix est pertinent pour les équipes Symfony ?
Bien que l'article porte sur Laravel, la philosophie est transposable. Inertia.js est disponible pour Symfony via des bundles communautaires. La logique de combiner un backend PHP maîtrisé avec un frontend React typé, sans passer par une API REST séparée, réduit considérablement la complexité de développement et les frictions entre équipes front et back.
183 pages d'administration : ce que ça signifie concrètement
Derrière ce chiffre impressionnant se cache une réalité structurelle : chaque module fonctionnel génère un ensemble cohérent de vues (liste, création, édition, prévisualisation, paramètres). Voici les modules intégrés nativement :
Gestion éditoriale
- Posts et Pages : un modèle unifié (
Post avec un enum content_type), mais des comportements distincts. Les posts s'indexent sous /blog/{slug}, les pages s'exposent à la racine du site.
- Éditeur de contenu : bloc par bloc, avec rendu live. Chaque bloc (texte, image, vidéo, code) est un composant React indépendant, stocké en JSON côté base de données.
- Pipeline de publication : brouillon → révision → planification → publication. Chaque transition est loguée via Spatie Activity Log.
Gestion des utilisateurs et permissions
Le RBAC est géré nativement avec Spatie Permission. Pas de compromis : les rôles, les permissions et les équipes sont configurables directement depuis l'interface d'administration. Pour des applications métier complexes, c'est un gain de temps considérable par rapport à des solutions tierces.
Médias et assets
Spatie Media Library gère les uploads, les conversions d'images et les collections. L'interface d'administration expose une médiathèque complète avec recherche, filtres et gestion des métadonnées.
Inertia 2 : le chaînon manquant entre PHP et React
Inertia.js est probablement la technologie la moins médiatisée de ce stack, alors qu'elle en est la clé de voûte. Son principe : le serveur PHP retourne des composants React hydratés avec des données, sans que le développeur ait besoin d'exposer ou de consommer une API REST.
Les bénéfices concrets :
- Authentification et sessions gérées côté serveur, sans JWT ni token à maintenir côté client.
- Validation côté serveur renvoyée directement dans les composants React via les props Inertia — pas de duplication de règles de validation.
- Navigation SPA fluide sans la complexité d'une architecture découplée.
- TypeScript de bout en bout : les types des props Inertia peuvent être générés automatiquement depuis le backend.
Pour les équipes habituées à Twig ou à des templates Symfony, Inertia représente une migration progressive vers React sans rupture architecturale brutale.
Ce que les équipes PHP/Symfony peuvent retenir
Même si UnfoldCMS est un projet Laravel, les enseignements sont universels :
1. Le self-hosting est un avantage compétitif. Face à la flambée des prix SaaS et aux problèmes de vendor lock-in, proposer à ses clients une solution auto-hébergée sur leur propre infrastructure redevient un argument commercial fort.
2. Assembler moins, livrer plus. Le choix de Spatie (Media Library, Permission, Activity Log) illustre une philosophie pragmatique : utiliser des packages éprouvés pour les fonctionnalités transverses, et concentrer l'effort de développement sur la valeur métier.
3. Tailwind v4 + shadcn/ui change la donne. La vitesse de construction d'interfaces cohérentes avec ce duo est sans commune mesure avec les approches CSS traditionnelles. Les 183 pages d'administration d'UnfoldCMS en sont la démonstration la plus convaincante.
4. Le typage TypeScript est non-négociable. Sur un projet de cette envergure, TypeScript sur le frontend n'est pas une option — c'est ce qui rend le code maintenable à l'échelle.
Conclusion
L'article original de Hamed Pakdaman est une lecture indispensable pour tout développeur PHP qui s'interroge sur son stack en 2026. Il ne s'agit pas d'un énième comparatif théorique, mais d'un retour d'expérience chiffré — 183 pages, un projet en production, un VPS à 5 €/mois — qui prouve que l'écosystème PHP est plus que jamais capable de rivaliser avec les solutions Node.js ou les CMS SaaS coûteux.
Chez MulerTech, nous suivons de près ces évolutions pour nos projets Symfony. L'intégration d'Inertia.js dans l'écosystème Symfony, combinée à React 19 et Tailwind v4, ouvre des perspectives très concrètes pour nos clients qui cherchent des applications robustes, maintenables et économiquement souveraines.
📖 Source originale : What 183 admin pages look like — building a full Laravel CMS in 2026 par Hamed Pakdaman sur DEV Community.
