Sylius se présente comme une plateforme e-commerce « headless ». Concrètement, cela veut dire que toute la boutique (catalogue, panier, commande, compte client) est accessible par une API, et que la vitrine peut être une application totalement séparée. Mais Sylius sait aussi fonctionner avec sa propre vitrine, comme une boutique classique. Voici comment fonctionne le mode headless, ce qu'il apporte vraiment et quand il vaut mieux s'en passer.
L'essentiel
- L'API de Sylius est construite avec API Platform, sous le préfixe /api/v2, avec une partie boutique et une partie administration.
- Le parcours d'achat complet passe par l'API : panier, adresse, livraison, paiement, validation.
- L'équipe de Sylius maintient une vitrine React officielle, FrontWing, qui ne remplace pas la vitrine Twig.
- Le headless donne de la liberté sur l'interface, mais il faut alors maintenir deux applications.
Headless, c'est quoi exactement ?
Dans une boutique classique, le même logiciel gère les données (produits, commandes) et fabrique les pages que voit le client. En headless, on sépare les deux. Sylius garde les données et les règles de vente, et une autre application (un site Next.js, une application mobile, une borne en magasin) affiche la boutique en interrogeant l'API.
Sylius a été pensé pour cela dès sa conception : il se décrit lui-même comme une plateforme e-commerce headless open source construite sur Symfony et API Platform (site officiel de Sylius).
Comment fonctionne l'API de Sylius
L'API repose sur API Platform, le framework de référence pour créer des API avec Symfony. Elle est exposée sous le préfixe /api/v2, avec deux parties : /api/v2/shop pour tout ce que fait un client, et /api/v2/admin pour l'administration.
Le parcours d'achat se déroule entièrement par l'API. D'après la documentation officielle, on crée un panier avec POST /api/v2/shop/orders, qui renvoie un jeton de commande. On ajoute ensuite des articles, on renseigne l'adresse, on choisit la livraison et le paiement, puis on valide la commande, chaque étape étant une requête sur /api/v2/shop/orders/{jeton} (documentation « Using API »).
Les clients connectés s'authentifient avec un jeton JWT, envoyé dans l'en-tête Authorization: Bearer de chaque requête. Les invités peuvent commander sans compte, grâce au jeton de commande.
Un point d'attention : l'API évolue avec les versions. En passant à Sylius 2, les pare-feu de l'API ont été renommés et API Platform est passé en version 3 puis 4 (guide UPGRADE-2.0). Une vitrine headless doit donc être testée à chaque mise à jour majeure du back-end.
FrontWing, la vitrine React officielle
Pour éviter de partir d'une page blanche, l'équipe de Sylius a créé FrontWing, une vitrine React prête à l'emploi : page d'accueil, fiches produits, panier, tunnel de commande et compte client. Elle est maintenue par l'équipe principale de Sylius et a été migrée vers React Router 7 pour rester sur une base maintenue. FrontWing est une option : la vitrine Twig classique n'est pas abandonnée (FrontWing sur GitHub).
Vous pouvez aussi brancher n'importe quel autre front sur l'API : Next.js, Nuxt, une application mobile ou plusieurs vitrines différentes sur le même catalogue. Ce site est lui-même construit avec Next.js, une pile que nous connaissons bien.
Ce que le headless apporte vraiment
- Une interface sans contrainte. Le design et l'expérience ne dépendent plus du système de gabarits du back-end.
- Plusieurs points de vente sur un seul catalogue. Site, application mobile, borne, site B2B séparé : tous lisent les mêmes données.
- Des équipes indépendantes. Le front peut évoluer sans toucher au cœur de la boutique, et inversement.
- De la vitesse, si c'est bien fait. Un front rendu côté serveur et mis en cache peut être très rapide, ce qui compte pour les ventes et pour Google.
Ce qu'il coûte
- Deux applications à maintenir, à héberger et à mettre à jour, avec des versions qui doivent rester compatibles.
- Le référencement à reconstruire. Balises, données structurées, plan du site, redirections : tout ce que la vitrine Twig fournissait doit être refait côté front, avec un rendu côté serveur. Un passage en headless mal préparé fait perdre du trafic, comme une migration de boutique mal redirigée.
- Les modules d'affichage à réécrire. Un plugin qui ajoute un bloc dans la vitrine Twig n'apparaît pas tout seul dans un front React : il faut l'intégrer.
- Un budget plus élevé, au départ comme dans la durée.
Quand choisir le headless
Notre règle est simple : partez en headless si vous avez une raison précise, pas parce que c'est à la mode. Les bonnes raisons sont une application mobile qui doit partager le panier avec le site, plusieurs vitrines sur un même catalogue, ou une expérience que les gabarits classiques ne permettent pas. Pour une boutique B2C ou B2B classique (voyez aussi nos services e-commerce), la vitrine Twig de Sylius 2, désormais construite avec Bootstrap 5 et Symfony UX, coûte moins cher à faire vivre.
Si vous comparez encore les plateformes, notre article Sylius ou PrestaShop depuis le rachat de 2026 pose les critères. Et si votre boutique est encore en Sylius 1.x, la priorité est ailleurs : voyez la fin du support de Sylius 1.14.
Nous en parler
Nous construisons et maintenons des vitrines Next.js et des boutiques Sylius, classiques ou headless, depuis la métropole lilloise. Pour savoir si le headless a du sens pour votre projet, rendez-vous sur notre page agence Sylius à Lille.
Sources consultées le 1er octobre 2026 : site officiel de Sylius ; documentation Sylius « Using API » ; guide UPGRADE-2.0 ; Sylius FrontWing.
