Shopify+ vs. SFCC.
Ce que la comparaison
de licence occulte.

Il existe une conversation que j'ai presque chaque trimestre avec un directeur marketing ou technologique qui vient de terminer un processus d'appel d'offres et est convaincu d'avoir pris la bonne décision financière en choisissant Shopify+ plutôt que Salesforce Commerce Cloud. La logique est directe. SFCC est la plateforme d'entreprise coûteuse. Shopify+ est l'alternative moderne et flexible. Les mathématiques semblent évidentes. Ce n'est pas le cas.

Chez TechSparq, nous avons implémenté les deux plateformes pour des marques d'entreprise en Afrique du Nord, Europe et Amérique du Nord. Nous avons construit des déploiements SFCC couvrant 21 vitrines mondiales simultanément. Nous avons exploité Shopify+ pour des marques de commerce de détail régionales se développant vers de nouveaux marchés. Nous ne sommes des défenseurs de l'un ou l'autre. Nous sommes ceux qui comprennent ce que chaque plateforme coûte réellement, non seulement pour la licence mais pour fonctionner, entretenir et évoluer, et nous avons vu ce qui arrive quand les marques choisissent selon la mauvaise comparaison.

Il existe également un troisième chemin que la plupart des évaluations ignorent complètement. Les deux plateformes offrent une option headless. Shopify Hydrogen, Composable Storefront de SFCC. Les deux représentent un moyen fondamentalement différent de construire, et tous deux nécessitent un type d'équipe fondamentalement différent. Nous y reviendrons. D'abord, la comparaison que la plupart des marques font réellement.

L'écosystème d'applications que personne n'oublie d'ajouter

Le chiffre que tout le monde regarde en comparant ces plateformes est le poste de licence. La licence d'entreprise SFCC est un coût important et visible. Elle est négociée au niveau du contrat, se trouvant dans une ligne budgétaire facile à contester. Le plan de base de Shopify+ est une fraction de cela. Le tableau de comparaison s'écrit lui-même.

Ce que ce tableau omet, c'est ce qu'un vrai déploiement d'entreprise Shopify+ nécessite réellement pour fonctionner. Pour une marque de classe moyenne, l'écosystème d'applications de Shopify est l'un de ses véritables points forts. Pour une marque d'entreprise opérant sur plusieurs marchés avec des exigences complexes en matière de tarification, de réglementation et de fulfillment, cet même écosystème devient un problème de gestion de fournisseurs avec une facture mensuelle composée.

Les catégories sont prévisibles, incluant le marketing par email et SMS, la fidélité et les avis, la recherche avancée, la conformité fiscale, la gestion des retours, les abonnements, la gestion multilingue et multirégionale, la fonctionnalité B2B, une plateforme de données client et les outils de service client. SFCC inclut la plupart de cela en natif, y compris le calcul fiscal, la recherche avancée, la gestion de contenu multi-locale, la fonctionnalité de catalogue B2B et un OMS capable intégré. Shopify+ nécessite des outils externes de premier plan pour la plupart, intégrés et entretenus séparément.

Dans une boutique régionale unique, cette surcharge est gérable. À cinq, sept ou dix marchés avec des configurations séparées par boutique, vous avez construit une couche opérationnelle parallèle qui n'apparaît pas dans la comparaison de licence mais apparaît absolument dans votre budget opérationnel.

L'économie des modules complémentaires n'est pas un défaut dans la conception de Shopify. C'est le modèle. Pour la marque pour laquelle il a été construit, c'est une force. Vous choisissez exactement ce dont vous avez besoin, parmi une marketplace approfondie d'outils éprouvés. Pour les marques d'entreprise où « ce dont vous avez besoin » couvre une douzaine de domaines fonctionnels sur plusieurs géographies, vous gérez un portefeuille de fournisseurs plutôt que d'exploiter une plateforme.

Le problème DevOps que personne ne mentionne pendant le cycle de vente

Le deuxième endroit où la comparaison trompe concerne le coût d'ingénierie. Le modèle de licence de Shopify+ est simple. L'architecture opérationnelle de Shopify+ pour un déploiement d'entreprise multi-marché et multi-réglementaire ne l'est pas.

Shopify gère le commerce international via deux mécanismes. Ce sont les Expansion Stores (instances Shopify séparées par marché) et Shopify Markets, leur solution internationale native plus récente. Chaque approche a des contraintes réelles qui importent à l'échelle de l'entreprise.

Expansion stores et l'approche d'entreprise traditionnelle

Les Expansion Stores restent la norme pour les déploiements mondiaux d'entreprise où les marchés ont des environnements réglementaires vraiment différents. Chaque magasin est une base de code séparée, un déploiement de thème séparé, une configuration de pile d'applications séparée. Quand vous changez quelque chose de fondamental (un flux de paiement, une intégration de fidélité, une règle de tarification), vous le déployez sur chaque instance de magasin séparément. À trois magasins régionaux, c'est gérable. À sept, dix ou vingt-et-un marchés, vous avez construit une fonction DevOps pour entretenir ce qui devrait être une plateforme de commerce.

La complexité se multiplie quand vous tenez compte de ce qui est vraiment différent marché par marché, y compris la logique de juridiction fiscale, le routage OMS pour les partenaires de fulfillment locaux, les exigences réglementaires y compris le RGPD, le traitement de la TVA entre les marchés et les variations des lois de protection des consommateurs. Exigences en matière de méthodes de paiement locales. Gestion du langage et de la devise qui va au-delà de la traduction dans le comportement du commerce réellement localisé.

Shopify Markets, amélioré mais avec des limites toujours présentes

Shopify Markets s'est amélioré considérablement dans les versions récentes, et pour les marques avec des exigences internationales relativement simples, c'est une alternative sérieuse aux Expansion Stores. Les limites sont toujours réelles. Les marques d'entreprise opérant dans des marchés avec des différences réglementaires significatives, en particulier en Afrique du Nord, où nos clients font du commerce sur des juridictions avec des exigences distinctes, se retrouvent souvent encore avec des Expansion Stores car les cas limites dans Markets sont exactement ceux qui décrivent leur activité.

L'architecture multisite de SFCC

SFCC a été conçu pour cela. Son architecture multisite native exécute plusieurs marchés à partir d'une instance unique avec tarification localisée, assortiment localisé, contenu localisé et comportement de paiement localisé gouverné centralement. Le modèle de gouvernance nécessite un travail initial, mais vous ne gérez pas l'infrastructure. Au lieu de cela, vous gérez la configuration. Cette différence à l'échelle n'est pas incrémentielle. C'est architectural. L'équipe entretenant 21 vitrines mondiales Columbia Sportswear sur SFCC ne gérait pas 21 opérations DevOps parallèles. Elle gérait une plateforme unique avec 21 configurations.

Où Shopify+ gagne vraiment

Ce n'est pas un cas contre Shopify+. Shopify est une plateforme exceptionnelle pour une classe spécifique de problèmes, et la minimiser serait malhonnête.

La mise en place est véritablement plus facile. L'interface d'administration de Shopify est l'un des outils commerciaux les mieux conçus du commerce. Merchandiser un catalogue, configurer des promotions, configurer des règles d'expédition, intégrer une équipe. Tout cela est plus rapide et plus intuitif que sur n'importe quelle plateforme d'entreprise. SFCC Business Manager possède une capacité énorme et une courbe d'apprentissage qui l'accompagne. Une équipe de merchandising sans expérience SFCC sera productive sur Shopify en quelques jours. La même équipe sur SFCC aura besoin de semaines pour atteindre la confiance opérationnelle.

Pour les marques D2C à fort volume, l'infrastructure de conversion est exceptionnelle. Shopify Checkout est l'une des expériences de paiement les plus conversionnelles du commerce. Le réseau Shop Pay, les options de paiement accélérées et la maturité de l'écosystème d'intégration de paiement sont de véritables avantages concurrentiels. Pour une marque ciblée sur un marché unique, croissant rapidement, exploitant un catalogue de produits ciblé, Shopify+ est très souvent la bonne réponse.

L'écosystème de développeurs est incomparablement plus large. Il y a plus de développeurs Shopify dans le monde que de développeurs SFCC. Plus d'offre signifie des tarifs plus bas, un embauche plus rapide et plus de flexibilité quand vous devez agrandir votre équipe ou faire appel à une aide extérieure. Pour une marque qui doit bouger rapidement et ne nécessite pas d'infrastructure mondiale complexe, le vivier de talents de Shopify est un avantage opérationnel véritable.

L'équation du coût de développement

SFCC est construit sur une pile technologique propriétaire. Son ascendance est Demandware, acquise par Salesforce en 2016, et son architecture centrale reste le modèle de cartouche, le modèle ISML et l'environnement de configuration Business Manager que Demandware a construit. Salesforce a ajouté une couche moderne avec Composable Storefront et PWA Kit et continue d'investir dans la plateforme. Mais les développeurs qui implémentent bien SFCC sont des spécialistes. Le processus de certification est réel. Les tarifs du marché des développeurs reflètent cette rareté.

Les développeurs Shopify sont abondants. La limite inférieure du marché des talents Shopify est considérablement plus basse car l'écosystème est beaucoup plus large. Pour les marques sans équipes techniques internes, la différence de coût de développement total sur un travail de portée équivalente peut être significative.

Le point qui change l'analyse. Si la portée du travail n'est pas équivalente, la comparaison des coûts ne l'est pas non plus. Un déploiement multi-marché nécessitant des Expansion Stores séparées avec gestion de codebase parallèle, une construction headless personnalisée utilisant Shopify Hydrogen et un workflow B2B de gros manuel personnalisé n'est pas une construction plus simple et moins chère. C'est une construction complexe utilisant une plateforme qui n'a pas été conçue nativement pour cette complexité. Vous payez pour construire à contre-courant.

Il y a un point plus profond ici qui refait rarement surface dans les évaluations de plateforme. Chez TechSparq, nous avons une philosophie spécifique sur les développeurs avec lesquels nous travaillons et investissons. Nous ne priorisons pas les développeurs formés d'abord sur la plateforme A ou la plateforme B. Nous recherchons des développeurs personnalisés hardcore, ce qui signifie des ingénieurs qui comprennent ce qui se passe sous les couvertures avant qu'ils n'aient jamais touché un cadre spécifique au commerce. Ensuite et seulement ensuite nous investissons dans la formation spécifique à la plateforme.

La raison est simple. Les développeurs personnalisés qui comprennent vraiment les systèmes sous-jacents dépassent les problèmes sur lesquels les développeurs orientés plateforme se bloquent. Vous voyez cela constamment dans les fils Reddit et les questions StackOverflow. Développeurs qui ont appris Shopify comme point d'entrée, ou ont eu leur premier travail sérieux sur les cartouches SFCC, frappant des murs qu'un ingénieur généraliste fort traverserait. Non pas parce que ces développeurs ne sont pas capables (beaucoup sont excellents), mais parce qu'ils ont appris la plateforme avant d'apprendre le métier. Quand quelque chose casse en dehors du schéma standard, ils recherchent le message du forum. Nos ingénieurs recherchent la source.

Cela importe pour la comparaison de plateforme car cela change le calcul sur la complexité technique. Shopify Hydrogen et SFCC Composable Storefront récompensent tous deux la capacité technique approfondie. La question n'est pas quel développeur de plateforme est moins cher. C'est si votre partenaire d'implémentation a des ingénieurs qui peuvent réellement déverrouiller le plafond de la plateforme.

Omnicanal, OMS et POS. Où le fossé devient un canyon.

C'est la section qui décide l'évaluation pour toute marque opérant le commerce de détail physique aux côtés du commerce numérique. Et c'est la section la plus souvent ignorée jusqu'à ce qu'il soit trop tard.

Le tableau omnicanal

Le commerce de détail d'entreprise ne vit pas dans un canal. Il vit sur un site web, une expérience mobile, les magasins physiques, un canal de gros, un portail B2B et de plus en plus une couche de commerce social. La question n'est pas si votre plateforme supporte l'omnicanal. Les deux le font. La question est à quel point, comment nativement, et combien cela coûte quand les canaux divergent.

L'architecture de SFCC a été construite avec l'omnicanal comme premier principe. Un catalogue unique peut alimenter des vitrines illimitées avec tarification localisée, assortiment et contenu. Les données client, l'historique des commandes et le statut de fidélité sont unifiés sur tous les points de contact par conception. La visibilité de l'inventaire est gérée centralement et partagée sur tous les canaux. La couche omnicanal n'est pas boulonnée. Elle est structurelle.

L'histoire omnicanale de Shopify+ s'est considérablement améliorée. Shopify Markets, Shopify POS et l'écosystème plus large couvrent les bases. Pour les marques opérant des scénarios omnicanal complexes sur un réseau de magasins régionaux, la capacité native atteint souvent son plafond. Vous ajoutez des applications. Vous construisez un middleware personnalisé. Vous concevez autour de contraintes que SFCC n'a simplement pas sous la même forme.

OMS. La décision la plus importante de votre évaluation de plateforme

La gestion des commandes est où le commerce d'entreprise devient réel. L'OMS gère ce qui se passe après le clic sur le bouton d'achat. Elle gère le routage de la commande vers le bon lieu d'accomplissement, la gestion de la logique de livraison divisée et de la commande en rupture de stock, le traitement des retours et échanges, l'impulsion des règles d'accomplissement en fonction des SLA du transporteur, de la disponibilité des stocks et de la stratégie de distribution régionale.

Salesforce Order Management est un compagnon natif à SFCC, et l'intégration est aussi proche sans friction que possible dans le commerce d'entreprise. Nous avons implémenté Salesforce OMS aux côtés de Commerce Cloud, Marketing Cloud, Service Cloud et Loyalty Cloud chez Empower Global. Cela incluait cinq produits Salesforce fonctionnant comme un système connecté unique. Ce type de flux de données unifié sur le commerce, l'accomplissement, le service et la fidélité est véritablement difficile à reproduire via des intégrations. Quand un client appelle au sujet d'une commande, l'agent de service voit les mêmes données que l'OMS a. Quand un point de fidélité est déclenché par un retour, il est affiché automatiquement.

Pour Shopify+, la situation de l'OMS est plus fragmentée. Shopify a une fonction interne de gestion des commandes qui gère bien les scénarios D2C simples. Quand la complexité augmente (routage multi-entrepôt, livraison divisée, logique de retour complexe, flux de travail d'accomplissement B2B, accomplissement transfrontalier avec différentes exigences en matière de transporteur et de réglementation), les marques intègrent généralement un OMS tiers. Chacun est un système capable. Chacun nécessite un projet d'intégration qui vit entre deux plateformes plutôt que dans une architecture native, ce qui signifie qu'il nécessite maintenance, surveillance et reengineering chaque fois que l'une ou l'autre plateforme change. Le coût à long terme de cette dépendance est sous-estimé dans presque chaque évaluation dont nous avons fait partie.

POS. L'histoire est plus complexe que le marketing ne le suggère

Shopify POS est véritablement fort pour le cas d'usage pour lequel il a été conçu, c'est-à-dire les environnements de détail simples exploitant un catalogue de produits cohérent entre canaux physiques et numériques. Pour une marque avec un nombre de magasins modéré, un catalogue ciblé et des exigences omnicanal relativement simples, Shopify POS est rapide à déployer et efficace à exploiter.

Les fissures apparaissent à l'échelle de l'entreprise. Les configurations de produits complexes (commandes personnalisées, production sur commande, SKU à variation élevée, tarification B2B à la caisse) nécessitent une personnalisation que Shopify POS ne supporte pas nativement. Les marques opérant dans des zones géographiques où Shopify Payments n'est pas disponible font face à une complexité d'intégration de paiement POS que l'architecture Shopify POS ne gère pas proprement. Cela couvre une partie significative de l'Afrique du Nord, des parties de l'Europe de l'Est et certains marchés APAC.

SFCC n'a pas de produit POS natif de la même manière que Shopify. L'approche d'entreprise est d'intégrer les meilleurs systèmes POS de classe, y compris Oracle MICROS, Aptos, Cegid, LS Retail, qui se connectent via les APIs omnicanal de SFCC. Le résultat, quand correctement implémenté, est un enregistrement client unifié et une image d'inventaire à travers le numérique et le physique qui surpasse ce que l'architecture native de Shopify fournit à l'échelle. Pour les marques avec infrastructure POS existante (ce qui est la plupart des détaillants d'entreprise), c'est souvent un avantage, pas une contrainte. SFCC s'intègre au POS que vous exploitez déjà. Shopify+ vous demande de passer à Shopify POS ou de construire un pont personnalisé.

La question des dossiers clients unifiés

Chaque évaluation omnicanal revient finalement à une question. C'est quand un client achète dans un magasin à Dubaï, le retourne à Riyad, appelle le service client de Londres et ouvre un email à Paris, votre système sait-il qui il est à chaque étape ?

SFCC, combiné avec Salesforce Customer 360, fournit cela nativement. Les données client sur le commerce, le service, le marketing et la fidélité vivent dans une plateforme. Chaque point de contact lit et écrit dans le même enregistrement. Shopify+ peut approximer cela via des intégrations telles qu'une CDP comme Segment, une plateforme de fidélité et un outil de service qui ensemble peuvent construire une vue unifiée. Cette unification est conçue sur trois systèmes séparés, pas fournie par un seul. Cela fonctionne. Cela nécessite une maintenance continue pour rester fonctionnel. Quand l'un de ces systèmes change son modèle de données, son API ou sa structure tarifaire, la vue unifiée doit être revalidée.

Pour les marques où cet enregistrement client unifié est un impératif commercial stratégique (commerce de luxe, environnements de service à fort contact, marchés où la fidélité et la relation sont le mécanisme de rétention principal), l'architecture native importe plus que la comparaison de licence ne le suggère.

Headless. Le troisième chemin que les deux plateformes offrent.

La plupart des évaluations de plateforme la cadrent comme un binaire. Vous avez Shopify+ ou SFCC. Il existe une troisième option qui mérite une égale considération, et les deux plateformes proposent une version. Le commerce headless, c'est-à-dire le découplage de l'expérience frontend de la plateforme backend, a évolué de l'expérimental au courant dominant. La question n'est plus si aller headless, mais si votre équipe a la capacité de le faire correctement.

Shopify Hydrogen

Shopify Hydrogen est le cadre headless officiel de Shopify. C'est une pile basée React construite sur Remix qui se connecte à l'API Storefront de Shopify. Elle donne aux développeurs le contrôle total sur le frontend tandis que Shopify continue de gérer le backend du commerce, y compris le panier, le paiement, les paiements, l'inventaire, les commandes. L'expérience développeur est moderne, la documentation est solide, et Shopify a sérieusement investi pour faire de Hydrogen le chemin canonique pour les constructions frontend sophistiquées sur leur plateforme.

Le compromis est réel. Hydrogen déplace la complexité de la plateforme à l'implémentation. Tout ce que les thèmes hébergés de Shopify gèrent automatiquement (optimisation des performances, gestion des mises à jour, compatibilité de l'éditeur de thème) devient maintenant la responsabilité de votre équipe. Les projets Hydrogen nécessitent des ingénieurs véritablement forts en React et Remix, à l'aise avec les fondamentaux web et expérimentés dans les décisions de performance et de caching qui importent à l'échelle. Le vivier de développeurs capable de faire Hydrogen bien est plus petit que le marché plus large des développeurs Shopify. Hydrogen supprime l'avantage de vitesse pour lequel Shopify est connu et le remplace par les demandes d'une application web personnalisée.

SFCC Composable Storefront

La réponse de Salesforce est la Composable Storefront, construite sur leur PWA Kit et infrastructure Managed Runtime. Elle découple complètement le frontend, le fournissant comme une application web progressive basée React connectée à SFCC via l'API. L'expérience de développement est moderne. Les performances de chargement de page sur une implémentation bien construite de PWA Kit sont véritablement plus rapides que SFRA. Et le frontend est complètement portable. Il n'est pas verrouillé à l'environnement d'hébergement de SFCC de la même manière que l'architecture couplée l'est.

Le défi est la maturité de l'intégration. L'écosystème de cartouches tierces pour SFRA est profond et battu en combat. Ce qui était une installation de cartouche en SFRA devient du développement personnalisé en Composable. Les équipes migrant de SFRA à Composable, ou construisant net-new sur Composable, doivent reconstruire les intégrations qui étaient auparavant prêtes à l'emploi. Le gain en performance et expérience développeur est réel. L'investissement pour y arriver est réel aussi.

Ce que headless nécessite réellement

Voici la partie de la conversation headless que la plupart des agences ne vous diront pas. Headless n'est pas un moyen de rendre une plateforme compliquée plus simple. C'est un moyen de prendre plus de responsabilité directe pour le frontend en échange de plus de contrôle et de plus de performance. Shopify Hydrogen et Composable Storefront récompensent ce compromis. Les deux punissent les équipes qui ne sont pas véritablement équipées pour cela.

Chez TechSparq, nous avons construit notre pratique technique avant que l'un ou l'autre de ces cadres existe. Nous avons commencé comme une maison de développement personnalisé. Nos ingénieurs ne sont pas des développeurs qui ont appris Shopify ou SFCC en premier et ont dû apprendre les fondamentaux web plus tard. Nous avons trouvé des développeurs qui comprenaient le métier au niveau des systèmes (comment les navigateurs rendent, comment fonctionne la mise en cache HTTP, ce qui se passe réellement dans un cycle de rendu React) et les avons formés aux plateformes. Cet ordre importe énormément dans les constructions headless.

La raison pour laquelle cela importe est visible dans chaque fil StackOverflow et chaque message Reddit sur les problèmes Hydrogen ou PWA Kit. Vous voyez des développeurs qui ont appris la plateforme en premier frappant des murs qui ne sont pas des problèmes Shopify ou Salesforce. Ce sont des problèmes d'ingénierie web fondamentaux. Ils recherchent un message de forum. Un ingénieur qui comprend ce qui se passe réellement au niveau du protocole et du navigateur traverse ces mêmes murs. Pas parce qu'il est plus expérimenté dans cette plateforme spécifique, mais parce qu'il comprend le système sous-jacent sur lequel la plateforme est construite.

Headless est le bon choix pour les marques qui ont besoin d'une performance maximale, d'une flexibilité maximale ou d'expériences frontend qui vont au-delà de ce que le système de template d'une plateforme a été conçu pour supporter. Ce n'est pas le bon choix pour les marques dont la contrainte principale est la vitesse de mise au marché, dont l'équipe manque d'expertise React ou dont l'organisation n'est pas prête à prendre la complexité opérationnelle qui accompagne une application web personnalisée. Sachez quelle catégorie vous êtes avant de choisir le chemin.

Le cadre de décision

Ce sont les signaux que nous regardons quand une marque prend vraiment la décision entre ces plateformes.

Spécifiquement sur headless, et si vous choisissez entre Hydrogen et Composable Storefront, la question concerne moins les plateformes elles-mêmes et davantage les forces existantes de votre équipe. Les forts ingénieurs React avec des fondations au niveau des systèmes peuvent s'exécuter bien sur l'un ou l'autre. La formation à la plateforme est apprenante. Les fondamentaux d'ingénierie ne le sont pas.