5 Plateformes E-commerce Open Source pour les Développeurs

Pour les ingénieurs frontend qui construisent un storefront headless en 2026, les backends commerce open source les plus solides à évaluer sont Medusa, Saleor, Vendure, Sylius et Shopware. Chacun est API-first, activement maintenu, et s’intègre proprement avec un storefront Next.js ou tout autre framework basé sur React — mais ils se distinguent nettement par leur runtime, leur modèle d’API (REST vs GraphQL), leur modèle de licence, et la charge opérationnelle que vous assumez lors d’un hébergement en propre. Cet article a pour but de vous aider à sélectionner l’un d’eux pour un projet sur lequel vous vous apprêtez à investir des semaines d’intégration et des années de maintenance.

WooCommerce, Magento et PrestaShop méritent une mention honnête ici : ce sont des écosystèmes matures, largement déployés, avec de vastes marketplaces de plugins et des outils marchands que les plateformes présentées ci-dessous n’ont pas encore atteints. Mais leur centre de gravité reste le monde WordPress et les templates d’administration, et non les storefronts pilotés par API écrits en TypeScript. Si votre storefront est une application Next.js qui appelle un SDK typé ou un endpoint GraphQL, les cinq plateformes ci-dessous constituent la shortlist pertinente. Si votre storefront est un site CMS thématisé administré par une équipe marketing, vous n’êtes pas au bon endroit.

Le commerce headless n’est plus une tendance à vendre — c’est désormais l’architecture par défaut pour les storefronts greenfield. La question n’est plus de savoir s’il faut découpler le storefront du moteur commerce, mais quel moteur vous offre la meilleure expérience développeur pour les années de développement fonctionnel qui suivront.

Comment choisir : tableau comparatif

La façon la plus rapide de réduire une shortlist est de placer les plateformes côte à côte sur les dimensions qui comptent vraiment pour un développeur de storefront. Le tableau ci-dessous résume les cinq candidats ; les compteurs d’étoiles et les versions de release évoluent en permanence, considérez-les donc comme un point de départ et vérifiez sur la page GitHub releases de chaque projet avant de vous engager.

Deux colonnes méritent qu’on s’y attarde. La colonne licence ne raconte pas toute l’histoire : Vendure et Shopware livrent tous deux un core sous licence MIT pleinement utilisable en production, aux côtés d’offres commerciales de plateforme managée sous licence distincte. C’est un élément à intégrer dans l’évaluation budgétaire, non un piège — le core open source est genuinement utilisable sans souscrire au niveau plateforme payant. La colonne empreinte d’hébergement reflète les services minimaux que vous opérerez en production, et c’est là que Saleor diverge significativement des options basées sur Node.

Medusa — Commerce headless Node.js/TypeScript avec modules et workflows v2

Medusa est un backend commerce headless Node.js/TypeScript dont la version v2 a restructuré la plateforme autour de modules commerce indépendants — produits, panier, commandes, inventaire, tarification — chacun pouvant être remplacé par une implémentation personnalisée ou un service tiers. Consultez la documentation officielle v2 pour l’architecture des modules et des workflows.

Pour un ingénieur frontend, le résultat est la plateforme la plus composable des cinq présentées ici. Le code du storefront communique avec le serveur Medusa via un client JavaScript typé ; la personnalisation backend s’effectue en écrivant des modules et des workflows en TypeScript qui cohabitent dans le même monorepo que le reste des services de votre équipe si vous le souhaitez. Le starter Next.js officiel disponible dans la documentation Medusa vous fournit un storefront fonctionnel avec panier, checkout et flux de compte en une seule commande create-medusa-app.

Les points forts de Medusa :

• Alignement des types de bout en bout. Le serveur est en TypeScript ; le SDK storefront est en TypeScript ; les modules personnalisés sont en TypeScript. Aucune étape de codegen entre les schémas et les types du storefront.
• Workflows. Medusa v2 expose une primitive workflow explicite pour les opérations commerce multi-étapes (passer une commande, effectuer un retour, etc.), ce qui facilite le raisonnement sur la logique longue durée et compensable par rapport aux chaînes de transactions implicites.
• Développement local simple. Un seul processus Node contre PostgreSQL, plus Redis pour les tâches en arrière-plan.

Les points de vigilance avec Medusa :

• REST-first. L’API principale de Medusa est REST. Les storefronts qui souhaitent un unique endpoint GraphQL et des types générés par codegen trouveront Saleor plus naturel.
• Migration v1 → v2. Les codebases encore sur Medusa v1 font face à un travail de migration non négligeable ; le système de modules, l’admin et les APIs ont tous subi des changements substantiels.

Choisissez Medusa si votre équipe est TypeScript-native, que vous souhaitez une maîtrise totale de la personnalisation dans votre propre langage, et qu’une ergonomie REST + SDK typé vous convient. Évitez Medusa si vous souhaitez une couche de données GraphQL-only ou si vous avez besoin d’un ensemble d’outils d’administration et de merchandising complet dès le premier jour.

Saleor — Commerce headless GraphQL-first sur Python/Django

Saleor est une plateforme commerce headless Python/Django avec une API GraphQL-first. Chaque opération commerce — requêtes produits, mutations de checkout, gestion des commandes, comptes clients — transite par un unique endpoint GraphQL versionné, documenté dans la référence API Saleor. Le codebase est sous licence BSD-3-Clause ; consultez le fichier LICENSE sur GitHub.

La conception GraphQL-first a le plus d’impact au niveau de la couche storefront. Un storefront Next.js peut co-localiser ses besoins en données avec ses composants en utilisant urql, Apollo ou graphql-request, exécuter graphql-codegen contre le schéma de Saleor, et obtenir des hooks de requêtes et de mutations entièrement typés sans écrire une couche d’adaptation REST séparée. Une requête typique pour une page produit ressemble à ceci :

query ProductBySlug($slug: String!, $channel: String!) {
  product(slug: $slug, channel: $channel) {
    id
    name
    slug
    description
    variants {
      id
      name
      quantityAvailable
    }
  }
}

Cette unique requête retourne exactement ce que la page affiche — pas de sur-récupération de données, pas d’appel d’inventaire séparé, pas d’utilitaire de formatage de prix qui diverge de la représentation monétaire côté serveur. Saleor publie également un exemple officiel de storefront Next.js (dépôt storefront) que vous pouvez forker plutôt que de construire from scratch.

Les points de vigilance avec Saleor :

• Empreinte opérationnelle. Saleor auto-hébergé nécessite Python, PostgreSQL, Redis et un processus worker Celery pour les tâches asynchrones. C’est plus lourd qu’une combinaison Node + Postgres, un point important à connaître si votre équipe n’opère pas déjà une stack Python.
• Discipline de versioning du schéma. Une plateforme GraphQL-first signifie que les changements de schéma cassants sont visibles. Saleor publie de nouvelles versions mineures avec des notes de migration claires, mais les storefronts qui ne fixent pas le schéma et ne régénèrent pas les types rencontreront des régressions silencieuses après les mises à jour.

Choisissez Saleor si vous souhaitez un unique endpoint GraphQL, que vous êtes à l’aise pour opérer une stack Python, et que votre équipe storefront maîtrise les clients GraphQL et le codegen. Évitez Saleor si votre équipe n’a aucune expérience opérationnelle Python et que vous préférez maintenir l’ensemble de la stack sur Node.

Vendure — Framework TypeScript/NestJS avec un Core MIT et un niveau Platform commercial

Vendure est un framework commerce headless TypeScript/NestJS avec une API GraphQL et un admin basé sur Angular. C’est la seule plateforme de cette comparaison qui livre son API de plugins, sa couche de services et ses extensions de schéma GraphQL en TypeScript avec une inférence de types complète — ce qui signifie que les plugins personnalisés et le code storefront partagent un seul langage et un seul modèle de types. La documentation Vendure couvre le système de plugins, les APIs GraphQL duales Shop/Admin, et le modèle de données.

Le Core open source de Vendure (sous licence MIT) est un moteur commerce headless pleinement fonctionnel. La Vendure Platform commerciale ajoute l’hébergement managé, le support entreprise et des modules additionnels, mais n’est pas requise pour opérer un storefront en production. Cette séparation mérite d’être bien comprise avant adoption : le Core est genuinement complet, et « open source » ne signifie pas « démo aux fonctionnalités limitées ».

Du point de vue du storefront, Vendure expose deux APIs GraphQL — Shop pour les opérations storefront publiques et Admin pour les outils back-office. Les deux sont introspectables et compatibles avec le codegen. NestJS sous-tend le serveur, ce qui signifie que les plugins personnalisés suivent un pattern module-provider familier si votre équipe a une expérience NestJS.

Les points forts de Vendure :

• TypeScript partout. Serveur, plugins, extensions de l’UI admin et storefront — un seul système de types.
• Architecture de plugins propre. Les champs personnalisés, les hooks de cycle de vie et les extensions de schéma GraphQL sont des fonctionnalités de première classe, pas des ajouts après coup.
• Hébergement léger. Un seul processus Node contre PostgreSQL ou MySQL. Le flux de démarrage par défaut utilise SQLite pour le développement local.

Les compromis de Vendure :

• Écosystème plus restreint. Comparé à Saleor ou Medusa, le catalogue de plugins et d’intégrations tiers est plus limité. Vous écrirez davantage de code de glue vous-même.
• Admin en Angular. Si votre équipe prévoit de personnaliser fortement l’UI admin et est exclusivement React, c’est un coût de changement de contexte à anticiper.

Choisissez Vendure si vous souhaitez la stack commerce headless la plus TypeScript-native et type-safe disponible, et que vous êtes prêt à développer certaines intégrations vous-même. Évitez Vendure si vous avez besoin du marketplace de plugins le plus large dès le premier jour ou si vous ne pouvez pas tolérer un admin Angular.

Sylius — Framework commerce Symfony avec REST et GraphQL via API Platform

Sylius est un framework e-commerce open source construit sur Symfony (PHP). Il se positionne comme un framework plutôt qu’une plateforme clé en main : il fournit les primitives commerce (produits, canaux, commandes, promotions, paniers) et suppose que vous les composerez pour construire l’application dont votre métier a réellement besoin. La documentation Sylius couvre le modèle de composants et les bundles Symfony.

Pour les ingénieurs frontend, Sylius est pertinent grâce à sa couche API. Sylius s’intègre avec API Platform pour exposer des endpoints REST et GraphQL sur son modèle de données, ce qui le rend utilisable comme backend headless pour un storefront Next.js ou tout autre storefront JavaScript. Le storefront par défaut utilise des templates Twig — adapté aux builds traditionnels, ignorable si vous optez pour le headless.

Les points forts de Sylius :

• Profondeur Symfony. Si votre organisation maîtrise Symfony, Sylius s’intègre plus naturellement dans l’écosystème PHP enterprise que toute autre plateforme ici.
• Personnalisation via les idiomes du framework. Surchargez les services, événements et entités en utilisant les patterns Symfony standard. Pas de DSL de plugin propriétaire.
• Licence MIT, sans niveau commercial requis. L’intégralité du codebase Sylius sous MIT est votre base de construction.

Les compromis de Sylius :

• Runtime PHP. Une équipe Next.js sans expérience opérationnelle PHP hérite de PHP-FPM, Composer et des outils Symfony pour le backend.
• Plus d’assemblage requis. Sylius assume honnêtement son rôle de framework. Vous écrirez plus de code qu’avec Medusa ou Saleor pour atteindre la parité fonctionnelle avec une plateforme clé en main.

Choisissez Sylius si vous avez une maîtrise Symfony en interne et que vous souhaitez un framework commerce que vous pouvez entièrement façonner selon votre domaine. Évitez Sylius si votre équipe est exclusivement JS et que vous préférez ne pas opérer un runtime PHP aux côtés de vos services Node.

Shopware 6 — Backend PHP/Symfony avec des outils marchands avancés et un storefront Vue.js

La Community Edition MIT de Shopware 6 est un backend commerce complet avec des options de déploiement traditionnelles et headless, exposant une REST Store API aux côtés de son framework de storefront basé sur Vue.js. Les plans commerciaux Rise, Evolve et Beyond ajoutent l’hébergement managé, des capacités B2B avancées et des fonctionnalités de support entreprise, mais le core open source est utilisable en production sans licence commerciale. La documentation développeur Shopware couvre la Store API, l’Admin API et les systèmes d’apps et de plugins.

Shopware est la plateforme la plus complète en termes de fonctionnalités marchandes dans cette comparaison. Le CMS « Shopping Experiences » fournit un page builder drag-and-drop pour les pages marketing ; le rule builder prend en charge des règles dynamiques de tarification, de livraison et de promotions sans code ; les outils d’administration sont genuinement avancés. Pour un développeur qui construit un storefront Next.js, la Store API est REST et bien documentée, et il existe des starters communautaires Next.js qui la consomment.

Les points forts de Shopware :

• Outils marchands out-of-the-box qu’aucune des plateformes developer-first ci-dessus n’égale.
• Position forte sur le marché européen avec un écosystème de partenaires mature.
• Headless hybride. Vous pouvez utiliser le storefront Vue.js par défaut ou passer entièrement en headless via la Store API.

Les compromis de Shopware :

• Empreinte opérationnelle PHP + Elasticsearch. Plus lourd à auto-héberger que les options Node.
• Système de plugins PHP-centrique. La personnalisation backend est en PHP/Symfony, même si votre storefront est en TypeScript.

Choisissez Shopware si vous avez besoin de fonctionnalités marchandes substantielles out-of-the-box et que vous êtes à l’aise pour opérer une stack Symfony/PHP. Évitez Shopware si votre équipe est exclusivement JS et que vous préférez une option plus légère et developer-first comme Medusa ou Vendure.

Quand Spree est une alternative pertinente

Si Shopware vous semble trop orienté entreprise et que votre équipe a une expérience Ruby on Rails, Spree Commerce est une alternative raisonnable. Il est sous licence MIT, entièrement piloté par API, supporte les configurations multi-boutiques et multi-vendeurs, et existe depuis suffisamment longtemps pour que les patterns Rails soient bien établis. Le compromis est similaire à celui de Sylius : Ruby on Rails à la place de Symfony, mais la même nature de décision — adopter l’écosystème d’un framework serveur mature en échange d’un runtime non-JS.

Facteurs de décision côté frontend

Au niveau de l’intégration storefront, cinq facteurs déterminent si un backend se révèle productif ou pénible : l’ergonomie TypeScript, la compatibilité Next.js, le cold start en développement local, l’architecture de plugins et la profondeur de la documentation.

Ergonomie TypeScript et codegen. Medusa et Vendure livrent tous deux des SDKs TypeScript alignés avec les types du serveur sans étape de génération séparée. Le schéma GraphQL de Saleor se consomme idéalement via graphql-codegen, ce qui ajoute une étape de build mais produit d’excellents hooks typés. Sylius et Shopware vous obligent à modéliser les réponses API vous-même ou à utiliser des clients générés par la communauté.

Compatibilité Next.js. Medusa et Saleor maintiennent tous deux des exemples officiels de storefront Next.js compatibles avec l’App Router. Vendure dispose de starters communautaires. Sylius et Shopware sont généralement consommés par des storefronts Next.js via des appels API directs ou des SDKs communautaires — faisable, mais vous écrivez davantage de code d’intégration vous-même.

Expérience de développement local. Medusa et Vendure offrent le cold start le plus rapide — installez les dépendances, exécutez une migration, démarrez le serveur, c’est fait. Saleor est bien documenté mais plus lourd en raison des prérequis Python + Redis + Celery ; Docker Compose est recommandé. Shopware et Sylius supposent un environnement de développement PHP fonctionnel ; les images Docker simplifient les choses mais les composants mobiles sont plus nombreux.

Architecture de plugins et d’extensions. Les cinq plateformes supportent les extensions personnalisées, mais l’expérience développeur diffère. Les plugins Vendure sont des modules TypeScript avec des hooks de cycle de vie type-safe. Les modules Medusa v2 sont des classes TypeScript avec un contrat clair. Saleor utilise des « apps » basées sur des webhooks qui s’exécutent comme des services séparés — une frontière d’isolation plus forte mais une surcharge opérationnelle accrue. Sylius et Shopware utilisent les systèmes de bundles/plugins de Symfony.

Qualité de la documentation. Parmi les cinq, Medusa, Saleor, Vendure et Shopware maintiennent tous des sites de documentation avec des références API, des tutoriels et des aperçus d’architecture raisonnablement à jour avec les releases. La documentation de Sylius est complète mais suppose une maîtrise de Symfony.

Défaillances récurrentes indépendantes du choix de plateforme

Un mode de défaillance courant en production dans les storefronts headless — quelle que soit la plateforme backend de cet article — est le mismatch d’hydratation React sur les pages produits, où les prix rendus côté serveur, les compteurs de stock ou les chaînes localisées divergent de ce que le client affiche après avoir récupéré des données fraîches. Autres patterns récurrents : la divergence silencieuse de l’état du panier lorsque le panier client et la session serveur se désynchronisent après une défaillance réseau ; les scripts de prestataires de paiement (Stripe, Adyen, PayPal) qui échouent à se charger ou s’initialiser et ne se manifestent que par un bouton de checkout bloqué ; et les changements de schéma cassants après une mise à jour backend qui produisent des champs null cryptiques plutôt que des erreurs explicites.

Ces défaillances sont indépendantes de la plateforme mais varient en termes de débogage selon la façon dont le backend expose le contexte d’erreur dans ses réponses API. Les erreurs GraphQL de Saleor portent des codes structurés ; les réponses REST de Medusa incluent des types d’erreurs ; Shopware et Sylius exposent le format d’erreur structuré de Symfony. Quelle que soit votre plateforme, instrumenter le storefront avec un outil de session replay comme OpenReplay — pour capturer l’état réel du DOM, les requêtes réseau, les erreurs console et les interactions utilisateur menant à un panier défaillant ou un checkout cassé — permet de faire le lien entre « l’utilisateur dit que le checkout est cassé » et un rapport de bug reproductible. Le produit de session replay d’OpenReplay est conçu spécifiquement pour cette catégorie de débogage frontend en production.

Prendre la décision

La shortlist se réduit rapidement dès lors que vous pondérez la maîtrise linguistique de l’équipe et la préférence de la couche de données du storefront. Une équipe TypeScript-native qui construit un storefront Next.js avec un SDK typé devrait évaluer Medusa en premier et Vendure en second. Une équipe souhaitant un unique endpoint GraphQL et prête à opérer une stack Python devrait évaluer Saleor. Une équipe maîtrisant Symfony devrait évaluer Sylius pour une approche orientée framework ou Shopware pour les outils marchands les plus complets. Exécutez le quickstart local pour votre ou vos deux premiers candidats avant de vous engager — un après-midi de docker-compose up et une visite de l’admin vous apprendront plus qu’une semaine supplémentaire de lecture comparative.

FAQ

Gain Debugging Superpowers

Unleash the power of session replay to reproduce bugs, track slowdowns and uncover frustrations in your app. Get complete visibility into your frontend with OpenReplay — the most advanced open-source session replay tool for developers. Check our GitHub repo and join the thousands of developers in our community.