Le headless commerce est devenu la réponse par défaut à toute question d’architecture depuis assez longtemps pour que la question intéressante ne soit plus ce que c’est mais quand ce n’est pas adapté. Personne dans l’écosystème ne publie cela, car tout le monde y vend du oui.
Nous réalisons des storefronts headless sur MedusaJS, mais nous maintenons aussi des clients sur Magento ou Shopify quand c’est la meilleure option. Voici le cadre que nous utilisons pour distinguer ces situations, et une évaluation honnête de la place de Medusa.js parmi les alternatives.
Note de version : cet article concerne Medusa 2.x (2.17 à la date de rédaction). Medusa 2.0 marque une rupture architecturale importante par rapport à la v1 — considérez tout article ou tutoriel datant de la v1 comme historique.
Ce que le headless change réellement
Dépouillé du marketing, le headless signifie que le moteur e-commerce et le storefront sont deux applications distinctes qui communiquent via une API. Tout le reste — composable, MACH, API-first — décrit jusqu’où va cette séparation.
Ce que cela vous apporte réellement :
- Liberté sur le front-end. Aucun système de thème à contourner, aucune syntaxe de template à détourner.
- Plusieurs canaux depuis un seul backend. Web, application, borne, marketplace, et désormais interfaces agents, tous servis par la même logique e-commerce.
- Déploiement indépendant. Le storefront est mis en ligne sans impacter le moteur e-commerce, et inversement.
- Remplacement de composants. Remplacez la recherche, le CMS ou le paiement sans changer de plateforme.
Ce que cela vous coûte, et c’est la partie que le discours commercial omet :
- Deux applications à maintenir au lieu d’une — hébergement, déploiements, surveillance, mises à jour de dépendances et correctifs de sécurité séparés.
- Tout ce que le monolithe fournissait d’office à reconstruire : SEO, sitemaps, données structurées, prévisualisation de contenu, redirections, pages d’erreur.
- Une équipe merchandising qui ne peut plus modifier elle-même, sauf si vous le prévoyez explicitement.
- Un besoin permanent d’ingénierie front-end, et non un projet ponctuel de lancement.
Le scénario d’échec headless le plus coûteux n’est pas technique. C’est une équipe marketing qui pouvait éditer une page d’accueil le lundi et doit désormais ouvrir un ticket. Prévoyez l’expérience d’édition, sinon vous déplacez le coût au lieu de le supprimer.
Les quatre conditions qui le justifient
D’après notre expérience, l’un de ces critères doit être réellement rempli. Pas de façon aspirée — concrètement, cette année.
1. Plusieurs front ends, réellement
Un storefront web plus une application native, ou plusieurs boutiques partageant un catalogue et une chaîne de commandes, ou un portail B2B en parallèle d’une boutique D2C. S’il n’y a qu’un seul storefront et aucun projet financé pour un second, la justification principale du headless ne s’applique pas à votre cas.
2. Une logique métier que la plateforme ne peut exprimer
Tarification dépendant des contrats, produits configurables avec de vraies contraintes techniques, workflow devis-commande, fiscalité multi-entités, routage complexe de la logistique. Si vos règles commerciales sont votre avantage concurrentiel, une plateforme qui les limite vous facture dans la mauvaise monnaie.
3. Une expérience front end qui fait le produit
Configurateurs, vente assistée, forte interactivité, expérience qui doit ressembler à une application plus qu’à un catalogue. Si votre storefront doit présenter des produits et encaisser, un bon thème le fait plus vite et pour moins cher.
4. Une économie de plateforme qui a changé
Les licences e-commerce d’entreprise atteignent six chiffres par an et évoluent avec votre croissance, pas votre usage. À un certain volume, ce poste de dépense finance à lui seul une équipe d’ingénierie. C’est une raison réelle et de plus en plus fréquente de migrer, et c’est une décision financière, non technique.
Quand nous disons non
Nous refusons régulièrement des projets headless pour ces raisons :
- Un seul storefront, catalogue classique, règles commerciales standards. Shopify ou Magento répondront mieux à vos besoins pour un coût inférieur.
- Aucune compétence front-end en interne et aucun projet d’en acquérir. Vous dépendrez d’une agence pour chaque modification de contenu, indéfiniment.
- La performance est la motivation. Un site lent l’est rarement à cause du monolithe. Il l’est à cause de ce qui a été construit dessus — nous l’avons détaillé pour les front ends Magento, et la logique s’applique ailleurs.
- L’équipe est réduite. Le headless multiplie la surface opérationnelle. En dessous d’une certaine taille, cette surface occupe toute la feuille de route.
- C’est une décision de CV. Peu flatteur, mais cela arrive. Une architecture choisie par intérêt plutôt que par besoin est la plus coûteuse.
La place de MedusaJS
Si le cadre de décision indique le headless, la question suivante est le choix du moteur. Medusa.js est un moteur e-commerce Node.js et TypeScript, open source, modulaire, auto-hébergeable, avec un starter officiel Next.js et une offre cloud managée.
Il est pertinent lorsque :
- Votre équipe maîtrise déjà TypeScript. C’est l’argument principal. Le moteur e-commerce et le storefront partagent le même langage, une seule équipe peut intervenir sur les deux — et le recrutement se fait sur des profils Node, pas des spécialistes.
- Vous souhaitez maîtriser et adapter la logique e-commerce. Le système de modules de Medusa est conçu pour l’extension, et vous pouvez consulter le code source en cas de besoin.
- Le coût de licence est un critère. Aucun frais par commande, aucune part de chiffre d’affaires.
- Le B2B est central. Comptes entreprise, devis et circuits de validation sont bien couverts, et c’est là que les moteurs open source surpassent le plus souvent les plateformes SaaS.
Ce n'est pas adapté lorsque :
- Vous avez besoin d’un large écosystème d’applications tierces. L’App Store de Shopify est un véritable atout, sans équivalent côté open source. Si votre activité repose sur des intégrations prêtes à l’emploi, ce critère prime sur l’architecture.
- Votre équipe travaille principalement en PHP. Passer à un backend Node implique de former ou de recruter — un coût réel à intégrer dans la comparaison.
- Vous exigez avant tout un engagement fournisseur. En open source, vous assumez le risque opérationnel. Medusa Cloud le réduit, sans le supprimer.
- Votre catalogue est volumineux et votre délai court. La performance sur catalogue étendu doit être validée sur vos propres données, pas supposée.
Validez avant de vous engager. Chargez votre vrai catalogue dans une instance Medusa 2.x et testez vos requêtes les plus exigeantes. Une semaine d’essai ici est l’assurance la moins chère sur un projet de cette ampleur.
La comparaison honnête
La liste réaliste pour un projet headless mid-market ou entreprise :
- MedusaJS — Node/TypeScript, open source, modulaire, auto-hébergé ou managé. Pertinent si votre équipe maîtrise JavaScript et souhaite garder la main sur la logique.
- Commercetools — la référence côté entreprise. Mature, bien supporté, tarifé en conséquence. À privilégier si la direction achats veut un fournisseur responsable et que la licence reste abordable à votre volume.
- Saleor — Python/Django, GraphQL-first, open source. À retenir si votre équipe est experte Python.
- Shopify Plus headless (Hydrogen) — conserve l’écosystème d’applications et le backend managé, tout en remplaçant le storefront. Souvent la solution pragmatique, mais sous-estimée car jugée « impure » architecturalement.
- Rester sur votre monolithe et refondre le front-end. L’option que personne ne met en short-list, mais qui est souvent la bonne.
Comparez-les sur les critères concrets : ce que votre équipe peut recruter, le coût total sur trois ans, qui assume la responsabilité en cas d’incident à 3h du matin, et la rapidité d’un retour en arrière. Les matrices de fonctionnalités convergent ; ces quatre points non.
Planifier une migration
Si vous migrez, évitez le basculement direct. La méthode éprouvée :
- Validez le moteur sur votre vrai catalogue, vos règles tarifaires et vos volumes de commandes — un spike, pas un projet.
- Développez le nouveau storefront sur l’ancien backend d’abord, si votre plateforme actuelle propose une API exploitable. Vous sécurisez la partie visible sans toucher au commerce.
- Migrez un marché, une marque ou un canal. Apprenez sur un périmètre réversible.
- Ne migrez le moteur commerce qu’en dernier, une fois le storefront stabilisé et l’équipe à l’aise avec la nouvelle stack.
- Laissez l’ancien système consultable plusieurs mois après. L’historique des commandes et les requêtes financières ne s’arrêtent pas au basculement.
Les aspects techniques de la migration — redirections, contrôle qualité des données, reconstructions d’intégrations — dépendent peu de la plateforme ; notre checklist replatforming en 40 points s’applique quasiment à l’identique.
Notre pratique MedusaJS et notre équipe de développement Medusa réalisent ces missions, et notre pratique de sélection de plateforme existe pour répondre à la question en amont — y compris lorsque nous recommandons de ne rien changer.
Questions fréquentes
Le headless commerce est-il plus rapide qu’une plateforme classique ?
Non, pas par nature. Un storefront headless bien conçu peut être très rapide, tout comme un thème bien construit. Les sites sont généralement lents à cause de ce qu’on y ajoute, pas de l’endroit où s’effectue le rendu. La performance seule n’est pas une raison suffisante pour passer au headless.
Qu’est-ce que MedusaJS et en quoi diffère-t-il de Shopify ?
Medusa.js est un moteur e-commerce open source développé en Node.js et TypeScript, que vous hébergez et étendez vous-même, en exposant une API plutôt qu’un storefront. Shopify est une plateforme gérée avec un large écosystème d’applications. Medusa privilégie le contrôle total de la logique e-commerce et l’absence de frais par commande, au détriment de l’écosystème et de la gestion déléguée.
Quel est le coût d’un projet headless commerce ?
Il est nettement supérieur à celui d’un projet à thème, car vous commandez deux applications au lieu d’une et devez reconstruire ce que le monolithe fournissait d’office : génération SEO, aperçu du contenu, redirections, outils d’édition. Prévoyez un budget pour le storefront, le moteur, les intégrations et une compétence front-end pérenne.
Peut-on passer au headless sans changer de plateforme ?
Souvent, et c’est l’option la plus sous-exploitée. Si votre plateforme actuelle expose une API exploitable, commencez par développer le nouveau storefront dessus. Vous gagnez la liberté front-end, vous reportez la partie risquée, et vous pouvez arrêter si cela ne fonctionne pas.
Lequel choisir : MedusaJS ou Commercetools ?
Ils répondent à des besoins différents. Commercetools est adapté aux entreprises qui veulent un fournisseur responsable et dont la licence reste abordable à leur volume. MedusaJS convient aux équipes à l’aise avec JavaScript, qui souhaitent maîtriser et adapter la logique e-commerce, et préfèrent investir le budget licence dans des ingénieurs.
Exploitez le framework avec nous
Présentez-nous vos canaux, vos règles commerciales et les langages de votre équipe : nous vous dirons si le headless se justifie — et quel moteur, le cas échéant. Nous conseillons de rester sur l’existant plus souvent que la réputation du framework ne le laisse penser. Contactez notre équipe : réponse sous un jour ouvré.