Notre stratégie pour quitter Shopify : évaluer les alternatives e-commerce headless

Shopify est vraiment efficace dans ce qu’il fait. Le taux de conversion au paiement est élevé, l’écosystème d’applications est vaste, la fiabilité opérationnelle est excellente et, pour un marchand qui souhaite vendre des produits sans construire d’infrastructure, la proposition de valeur est difficile à contester. Cela vaut la peine de l’affirmer clairement avant de décrire pourquoi nous avons fermé notre boutique sur cette plateforme — car la décision ne portait pas sur une inadéquation absolue de Shopify. La plateforme répondait mal aux exigences opérationnelles particulières qui s’étaient accumulées chez nous.

La plupart des récits de « sortie de Shopify » se concentrent sur les frais de transaction, les limitations des thèmes ou le désir d’une vitrine en ligne personnalisée. Ce sont de vraies raisons, mais ce ne sont pas les plus déterminantes. Le problème plus fondamental est que Shopify est optimisé pour un type particulier de marchand — volume élevé, catalogue standardisé, vente directe aux consommateurs — et ses contraintes deviennent des frictions lorsque vos exigences s’écartent de ce profil.

Ce que Shopify a bien fait

Le parcours de paiement est l’argument le plus solide de la proposition de valeur de Shopify. Des années d’optimisation sur des millions de boutiques ont produit un parcours de paiement qui favorise la conversion, gère correctement les cas limites et intègre les moyens de paiement sur différents marchés sans nécessiter de travail d’intégration personnalisée. Créer un parcours de paiement comparable de toutes pièces est un projet de plusieurs mois avec une charge de maintenance continue significative.

La couche opérationnelle — gestion des commandes, traitement logistique des commandes, retours, outils de service client — est également mature. L’interface d’administration impose des choix, mais elle traduit une réelle connaissance du fonctionnement des flux de travail de l’e-commerce à grande échelle. Les équipes qui ont besoin de former du personnel non technique pour gérer les commandes trouvent l’expérience utilisateur de Shopify bien plus accessible que toute alternative headless actuellement disponible.

L’écosystème d’applications, malgré sa réputation de coûts cachés, résout des problèmes réels. Plateformes d’avis, facturation des abonnements, programmes de fidélité, analyses avancées — ces intégrations fonctionnent parce que Shopify a standardisé les webhooks, les modèles de données et l’authentification dont dépendent les applications tierces. Dans une architecture headless, chacune de ces intégrations doit être construite sur mesure ou obtenue auprès de fournisseurs qui ne proposent pas forcément de prise en charge native de la plateforme choisie.

Les contraintes qui sont devenues bloquantes

Les limitations i18n ont été le premier point de friction. La prise en charge multilingue de Shopify, bien que nettement améliorée par rapport à son état initial, accorde encore une place secondaire aux marchés non anglophones. La gestion du contenu dans une douzaine de langues via l’administration Shopify est difficile au quotidien, et cette difficulté s’amplifie avec la taille du catalogue. Les applications de traduction aident, mais elles ajoutent des coûts et introduisent une complexité de synchronisation qu’une solution native éliminerait.

La question de la propriété des données est devenue le problème plus fondamental au fil du temps. Toute donnée opérationnelle importante — historique des commandes, dossiers clients, catalogue de produits — est stockée dans la base de données de Shopify, accessible via une API que Shopify contrôle. Les limites de débit de cette API, les politiques de conservation des données et les formats d’exportation sont déterminés par Shopify, pas par le marchand. Pour les équipes qui ont besoin d’exécuter des charges de travail analytiques sur leurs propres données opérationnelles, c’est une contrainte structurelle plutôt qu’une option de configuration.

La complexité du modèle de tarification était une troisième contrainte. Les produits avec de nombreuses variantes, la tarification personnalisée par segment de clientèle et les flux de travail basés sur des devis pour les clients professionnels se heurtent aux limites de variantes de Shopify (100 par produit jusqu’à ce que Shopify porte cette limite à 2 048 en octobre 2025) et à ses structures de tarification d’une manière qui nécessite des solutions de contournement de plus en plus complexes. La complexité des modèles Liquid qui en résulte devient une charge de maintenance de plus en plus lourde à mesure que le catalogue grandit.

L’évaluation : Medusa v2, Saleor, Commerce.js

L’évaluation était structurée autour de quatre critères : propriété des données (contrôle total sur la base de données, aucune limite d’API imposée par le fournisseur), richesse des fonctions i18n (prise en charge native de plusieurs devises, de plusieurs langues et de la tarification régionale), expérience des développeurs (qualité de la documentation, prise en charge de TypeScript, processus de développement local) et maturité opérationnelle (déploiements en production, modes de défaillance connus, taille de la communauté).

Medusa v2 a obtenu les meilleurs résultats sur l’expérience des développeurs. La réécriture v2 est une amélioration substantielle par rapport à l’architecture originale : le système de modules est bien conçu, les types TypeScript sont complets et le processus de développement local est rapide. La documentation s’est considérablement améliorée et reflète une équipe qui prend l’expérience des développeurs au sérieux. La contrainte est la maturité opérationnelle — v2 est relativement récente (Medusa 2.0 est sortie en octobre 2024), et les retours sur les déploiements en production sont moins nombreux et moins diversifiés que pour les plateformes plus établies. Les équipes passant à Medusa sont réellement des pionnières.

Saleor est le plus éprouvé des trois, avec une base plus large de déploiements en production et une API GraphQL qui est véritablement bien conçue. L’architecture multicanale — séparant le concept de « canaux » pour différents marchés, vitrines en ligne ou segments de clientèle — gère la complexité de tarification et de catalogue qui nous a éloignés de Shopify avec plus d’élégance que les alternatives. La maturité opérationnelle est la plus élevée des trois évaluées. Le compromis est un apprentissage plus exigeant et une API centrée sur GraphQL, qui demande un investissement dans l’outillage avant de pouvoir être utilisée efficacement.

Commerce.js occupe une position différente : c’est une API headless plutôt qu’une plateforme de commerce complète, conçue pour être combinée avec d’autres services plutôt qu’utilisée comme une solution complète. Pour les équipes avec de solides ressources d’ingénierie qui souhaitent un contrôle précis sur chaque composant, c’est un choix approprié. Pour les équipes cherchant à se débarrasser de la charge opérationnelle de Shopify sans ajouter une charge d’ingénierie équivalente sous une autre forme, ce n’est probablement pas le bon choix. Comme il s’agit d’une API hébergée, elle ne donne pas non plus un contrôle total sur la base de données, notre premier critère. Par ailleurs, en octobre 2026, Chec, l’entreprise derrière Commerce.js, a archivé son organisation GitHub (en octobre 2024) ; vérifiez donc l’état actuel du service avant de l’envisager.

Le parcours de migration

Le coût le plus sous-estimé dans une migration de plateforme est la migration des données, pas la migration de la base de code. Déplacer le catalogue de produits, les dossiers clients et l’historique des commandes de Shopify vers une nouvelle plateforme nécessite des scripts d’extraction personnalisés, une transformation des données pour correspondre au schéma cible et une gestion minutieuse des cas limites (produits avec plus de 100 variantes, clients avec des historiques d’adresses complexes, commandes partiellement traitées) qui représentent un petit pourcentage des enregistrements mais une grande partie du temps d’ingénierie de migration.

La transition opérationnelle — la période pendant laquelle le volume de commandes doit transiter par les deux systèmes pendant que la migration est validée — nécessite une planification minutieuse pour éviter le traitement logistique en double des commandes ou les communications en double aux clients. C’est la phase où la plupart des migrations rencontrent des problèmes qui n’avaient pas été anticipés lors de la planification, car les cas limites qui importent sont spécifiques au catalogue et à l’historique des commandes du marchand plutôt que généraux à l’e-commerce.

Cette évaluation et l’observation d’autres équipes confrontées à des décisions similaires montrent que le choix de la plateforme compte moins que la qualité de la planification de la migration. Medusa et Saleor sont tous deux capables de prendre en charge des opérations d’e-commerce en production, comme Commerce.js l’était au moment de notre évaluation. Les équipes qui réussissent les migrations headless sont celles qui investissent dans la compréhension des différences de modèle de données avant de commencer la migration, pas pendant.