🛒 Sylius : e-commerce headless construit sur Symfony et API Platform

📚 Introduction

Sylius est, à mes yeux, le projet e-commerce PHP le plus intéressant à suivre depuis 5 ans. Construit sur Symfony et API Platform, sous licence MIT, il vise un public clair : les équipes qui veulent un e-commerce sur-mesure, sans payer la licence d’un Commerce Cloud ni hériter de la complexité historique de Magento.

J’ai utilisé Sylius sur deux projets B2B en agence. Le constat est simple : quand tu connais Symfony, tu te sens chez toi en cinq minutes. Pas de syntaxe propriétaire, pas de couche d’abstraction maison, juste du code Symfony bien organisé. C’est le sujet de ce post : pourquoi Sylius mérite une vraie place dans la stack PHP de 2026, et quand l’éviter.

🧱 La promesse : Symfony, pas un fork

Sylius n’est pas un CMS qui ajoute des fonctionnalités e-commerce. C’est un ensemble de bundles Symfony que tu intègres dans une application Symfony standard. Les Resource, les Repository, les EventListener que tu écris ressemblent à tout ce que tu écris déjà.

Le projet est composé de plusieurs blocs :

Sylius Core : produits, commandes, clients, taxes, promotions. C’est la base réutilisable.
API Platform intégré nativement, qui expose l’ensemble en REST et GraphQL.
Sylius Admin : back-office Twig/Bootstrap, complet et fonctionnel out-of-the-box.
Sylius Shop : frontend de référence Twig, à remplacer le plus souvent par ton propre frontend Next.js / Nuxt / Astro.

L’installation est un composer create-project classique :

composer create-project sylius/sylius-standard my-shop
cd my-shop
php bin/console sylius:install
symfony serve

Et la dernière version stable, Sylius 2.2.6 (juin 2026), tourne sur Symfony 7+ avec PHP 8.2 minimum.

🔌 Headless par design

Le storefront Twig livré avec Sylius reste fonctionnel pour MVP rapides, mais le pattern moderne consiste à le bypasser et à consommer l’API Platform exposée par Sylius. Tu construis ton frontend dans le framework que tu veux : Next, Nuxt, Astro, Solid, peu importe.

Les avantages sont les mêmes qu’ailleurs : performance (SSR + ISR), DX, isolation entre backend métier et UI marketing. La spécificité Sylius : l’API n’est pas un greffon, c’est la couche de référence. Le back-office consomme la même API que ton frontend.

GET /api/v2/shop/products?filter[name]=t-shirt
Authorization: Bearer ...

Pour ceux qui ont vu mes posts sur les agents IA, Sylius + API Platform en mode headless te place exactement dans la situation où un agent peut interagir avec ton catalogue via MCP. Le même pattern que dans Laravel Boost appliqué au commerce.

🧰 Personnalisation : le bon niveau d’abstraction

C’est sur la personnalisation que Sylius brille face à Shopify ou Magento. Le framework expose des Extension Points explicites pour chaque concept métier :

Tu surcharges une entity Sylius en étendant la classe et en pointant ton mapping Doctrine.
Tu déclares un ResourceProcessor pour intervenir avant ou après la persistance d’une commande.
Tu enregistres un nouveau type de promotion via la PromotionAction interface.
Tu écris un PaymentMethod custom qui s’intègre nativement avec les PaymentStateMachine.

Tout passe par les conventions Symfony : services autowiré, tagués, configurés dans des YAML clairs. Aucun XML, aucun fichier system.xml à 2000 lignes.

use Sylius\Component\Promotion\Action\PromotionActionInterface;
 
final class GiftCardPromotionAction implements PromotionActionInterface
{
	public function execute(
		PromotionSubjectInterface $subject,
		array $configuration,
		PromotionInterface $promotion,
	): bool {
		// ...
	}
}

Et tu déclares le service avec un tag :

services:
	App\Promotion\Action\GiftCardPromotionAction:
		tags:
			- { name: 'sylius.promotion_action', type: 'gift_card', label: 'Gift Card' }

🧪 BDD et qualité

Sylius est l’un des rares projets PHP de cette taille où chaque feature est couverte par des scenarios Behat lisibles en Gherkin. La suite de tests est massive et tu peux la lancer sur ton fork pour valider tes modifications. Cette discipline déteint sur les contributeurs : la PR moyenne contient une feature et son scénario.

Pour une équipe qui hérite d’un Sylius, c’est un gros plus : tu peux écrire un scenario qui décrit le bug, le faire échouer, le corriger. La documentation vivante.

🎯 Quand choisir Sylius

Tu veux un e-commerce headless dont le backend est extensible profondément.
Tu as une équipe Symfony et tu veux capitaliser sur cette compétence.
Tu fais du B2B (workflows complexes, customer hierarchies, devis) où Shopify ne suit pas.
Tu construis un multi-vendor marketplace : avec Open Marketplace (plugin communautaire) ou en custom sur la base existante.
Tu veux rester maître de ton hosting (Docker, K8s) sans verrou SaaS. Voir Coolify pour l’orchestration auto-hébergée.

⚠️ Quand éviter Sylius

Tu fais un mono-shop B2C standard avec 50 SKUs : Shopify reste plus rapide à déployer.
Tu n’as personne de senior Symfony dans l’équipe : Sylius récompense la maîtrise du framework. Sans, tu vas patiner.
Tu cherches un produit clé en main fonctionnel : Sylius est un framework, pas une appli. Le polish marketing est à construire.
Tu attends une marketplace de thèmes : il n’y en a pas vraiment. Tu construis ton frontend.

🎉 Conclusion

Sylius est la réponse PHP la plus solide à la question “comment je construis un e-commerce sur-mesure sans repartir de zéro et sans payer une licence”. Le projet est mature, la communauté active, l’écosystème de plugins respectable. Ce n’est pas le bon choix pour tout le monde, mais quand c’est le bon choix, il l’est vraiment.

Pour les équipes Symfony : c’est probablement la corde la plus utile à ajouter à ton arc en 2026 si tu touches au commerce. Pour les autres : au minimum, c’est un excellent codebase à étudier pour comprendre comment structurer un Symfony à taille réelle.