Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
Sylius Storefront et Twig : vers un frontend découplé
Oui, Sylius affiche son storefront côté serveur avec Twig, la couche de templating de Symfony, associée à Bootstrap pour le style et à Symfony UX pour l'interactivité. Cela lie chaque changement visible du frontend au cycle de release de Sylius. Le bundle API Platform, inclus nativement, permet de découpler le storefront, mais tout le travail de construction du frontend revient alors à votre équipe, sauf si une couche frontend dédiée vient s'y ajouter.
Ce que signifie concrètement « Sylius utilise des templates Twig »
Sylius est un projet Symfony full-stack. Le storefront natif est une structure de thème Twig : les pages catégorie, produit et checkout existent sous forme de templates Twig dans des bundles de thème, l'habillage visuel repose sur Bootstrap, et les points d'interactivité (mise à jour du panier, filtres, formulaires) passent par Symfony UX avec Turbo, Stimulus et parfois des Live Components. Modifier le thème signifie surcharger des fichiers Twig, reconstruire le bundle, puis redéployer l'application Symfony.
C'est une base solide et éprouvée pour une équipe Symfony. Ce que beaucoup de boutiques Sylius découvrent en grandissant, c'est que frontend et backend partagent le même cycle de déploiement. Une équipe marketing qui veut une nouvelle landing page ou une variante de campagne a besoin d'un développeur Symfony et d'une fenêtre de release identique à celle de chaque mise à jour backend.
Le problème que rencontrent beaucoup d'équipes Sylius
Deux éléments se percutent. D'abord, chaque montée de version de Sylius (par exemple de 1.x vers 2.x) peut toucher la structure du thème Twig, car les conventions de bundle et les points d'ancrage des templates évoluent avec elle. Une mise à jour backend devient discrètement un projet frontend. Ensuite, les équipes marketing n'ont pas d'éditeur visuel. Chaque changement de section, chaque test A/B, chaque nouvelle page de campagne passe par un ticket développeur, car les templates Twig sont du code, pas une mise en page éditable.
Sylius connaît ce point et y répond avec le bundle API Platform pour les équipes qui veulent sortir du rendu côté serveur : des endpoints REST et GraphQL pour les produits, les catégories, le panier et le checkout. C'est la bonne base technique pour un storefront découplé. Ce qu'API Platform ne fournit pas, c'est un storefront construit sur cette base. Les équipes qui font ce pas seules reconstruisent le routage, le SEO, le cache, l'expérience de checkout et une bibliothèque de composants en partant de zéro, généralement avec un projet Next.js ou Nuxt dédié et une équipe dédiée pour le faire vivre.
Comment Laioutr résout cela, sans remplacer Sylius
Laioutr est Sylius Technology Partner officiel. Ce partenariat est la base du positionnement ici : Sylius reste votre backend, votre catalogue produit, la logique de checkout, la gestion des commandes et l'espace admin continuent de fonctionner sans changement. Laioutr devient la couche frontend au-dessus, connectée exactement via l'interface API Platform que Sylius fournit déjà.
Concrètement : Laioutr dialogue directement avec vos endpoints REST et GraphQL Sylius, sans code de liaison sur mesure, et livre des composants PDP, PLP, panier et checkout comme un stack composable prêt à l'emploi. Le marketing dispose de Studio, notre éditeur visuel, pour construire des landing pages, des variantes de campagne et des ajustements de section sans ticket développeur, directement dans le storefront en direct plutôt que dans une preview isolée.
L'effet en une phrase : vous quittez le train de releases Twig, les changements frontend ne sont plus liés aux releases mineures ou majeures de Sylius, et vous gagnez un éditeur visuel que le storefront Twig natif n'a jamais offert. Un schéma comparable se retrouve dans Headless Frontend for Sylius : un storefront composable pour le backend open source Symfony, où la même connexion API Platform porte un déploiement composable plus large.
Ce que vous gagnez
- Temps. Avec le storefront Twig natif: Un changement de landing page exige un ticket dev et un déploiement Symfony. Avec Laioutr sur Sylius API Platform: Nouvelles landing pages et variantes de campagne dans Studio, sans ticket dev.
- Argent. Avec le storefront Twig natif: Chaque montée de version Sylius risque de devenir un projet de thème Twig. Avec Laioutr sur Sylius API Platform: Cycle de release frontend découplé de la fenêtre de mise à jour Sylius.
- Qualité. Avec le storefront Twig natif: La performance et l'accessibilité dépendent de l'état du thème. Avec Laioutr sur Sylius API Platform: Core Web Vitals et composants conformes WCAG comme propriété de la plateforme.
FAQ
Sylius prend-il en charge le commerce headless ? Oui, via le bundle API Platform, Sylius expose des endpoints REST et GraphQL. Ce qui manque, c'est un storefront prêt à l'emploi sur cette base, et c'est la partie que Laioutr livre.
Faut-il remplacer Sylius pour découpler ? Non. Laioutr est Sylius Technology Partner et se place comme couche frontend au-dessus de votre backend Sylius existant, sans replatforming.
Combien de temps prend généralement la bascule ? Généralement quatre à six semaines jusqu'au premier storefront Sylius en production sur Laioutr, selon l'ampleur de votre configuration API Platform.
Prochaines étapes
Si votre storefront Sylius commence à buter sur les limites de la structure de thème Twig, la prochaine étape est une démo de 30 minutes où nous confrontons votre configuration API Platform au stack composable de Laioutr. Réserver une démo frontend Sylius.
Plus sur la plateforme Laioutr
À propos de l'auteur : Marcel Thiesies est CEO & Co-Founder de Laioutr. Il accompagne directement les équipes Sylius sur la question de détacher le storefront du rythme de release du backend, sans abandonner leur investissement Symfony existant.