Salesforce Commerce Cloud.
Ce que personne ne vous dit
avant le lancement.

Salesforce Commerce Cloud est l'une des plateformes de commerce d'entreprise les plus capables du monde. C'est aussi l'une des plus mal comprises. Les marques la choisissent pour le logo, la promesse de l'IA Einstein, et l'écosystème Salesforce. La punition commence bien avant le lancement. Certaines équipes n'y arrivent jamais. SFCC exige des développeurs logiciels chevronnés vivant à l'intérieur de l'écosystème Salesforce. Sans eux, les dépassements budgétaires commencent dès le premier sprint, les calendriers glissent dès le premier mois, et certains engagements ne dépassent tout simplement pas le lancement.

Une chose que la plupart des gens ne disent pas à haute voix. Vous construisez sur Demandware. Salesforce a acquis Demandware en 2016 pour 2,8 milliards de dollars et l'a réaffecté Salesforce Commerce Cloud cette même année. L'infrastructure fondamentale, le modèle cartouche, le modèle ISML, Business Manager, l'architecture pipeline - tout cela est l'ADN de Demandware. Salesforce a investi lourdement par-dessus, particulièrement avec l'IA Einstein et Composable Storefront. Mais SFCC d'entreprise reste fondamentalement une plateforme Demandware. Les développeurs qui n'ont jamais vécu à l'intérieur de cet écosystème sous-estiment régulièrement la courbe d'apprentissage.

Salesforce construit aussi quelque chose appelé Commerce on Core, son produit de commerce plus récent construit nativement sur la plateforme Salesforce (Force.com) plutôt que sur l'infrastructure héritée de Demandware. Salesforce l'a qualifiée comme son offre Commerce DTC. Pour l'instant, ce n'est pas un remplacement pour Commerce Cloud B2C d'entreprise. Elle cible les cas d'usage du marché intermédiaire et les scénarios d'auto-service B2B. Si vous êtes une marque d'entreprise évaluant SFCC aujourd'hui, vous évaluez toujours la plateforme lignée Demandware. Sachez ce que vous achetez.

Nous avons implémenté SFCC chez Columbia Sportswear, l'une des plus grandes entreprises de vêtements de plein air du monde, et chez Empower Global, une plateforme construite pour élever les marques appartenant à des Noirs. Échelle différente, modèles commerciaux différents, même leçon. La plateforme livre quand vous respectez ce qu'elle est.

Voici ce que nous avons appris sur l'exploitation de SFCC à l'échelle.

La décision architecturale que vous devez bien comprendre en premier

SFCC vous offre deux chemins architecturaux fondamentaux. SFRA (Storefront Reference Architecture) est l'approche couplée traditionnelle où l'avant-plan et l'arrière-plan vivent ensemble à l'intérieur de la plateforme SFCC. Composable Storefront (construit sur PWA Kit et Managed Runtime de Salesforce) découple entièrement l'avant-plan, le livrant comme une application web progressive basée sur React connectée à SFCC via API.

Cette décision façonne tout en aval. La structure d'équipe, l'embauche de développeurs, la complexité intégration, le temps d'accès au marché, et le coût de maintenance continu remontent tous à l'architecture que vous avez choisie le premier jour.

Quand SFRA est la bonne réponse

SFRA a du sens quand l'expertise SFCC existante de votre équipe est basée cartouche, quand votre surface intégration est étroite, et quand vous devez être actif rapidement. SFRA a été éprouvé au combat sur des centaines de déploiements d'entreprise. L'écosystème cartouche tiers pour SFRA est mature. Les processeurs de paiement, les moteurs de taxes, les plateformes de fidélité, et les outils de recommandation de produits ont tous des intégrations natives SFRA. Vous ne construisez pas à partir de zéro.

Le risque avec SFRA est le plafond de performance à long terme. L'architecture couplée signifie que les améliorations d'avant-plan exigent des déploiements d'arrière-plan. L'optimisation de la vitesse de page frappe les contraintes structurelles. Alors que Composable devient la direction stratégique de la plateforme, SFRA exigera finalement de toute façon une migration.

Quand Composable est la bonne réponse

Composable Storefront a du sens quand la performance est une exigence absolue, quand votre équipe possède une forte expertise React, et quand vous avez besoin d'une flexibilité maximale pour composer des solutions meilleures de sa catégorie sur les couches de recherche, CMS, et personnalisation. Les temps de chargement de page sur une implémentation PWA Kit bien construite sont véritablement plus rapides. L'expérience de développement est moderne. L'avant-plan est entièrement portable.

Le risque avec Composable est la maturité intégration. L'écosystème tiers pour PWA Kit se développe toujours. Ce qui était une installation cartouche dans SFRA devient le développement personnalisé dans Composable. Et l'implémentation hybride de Salesforce (exécution simultanée de SFRA et Composable) résout le problème de migration en théorie mais crée une complexité d'exploitation qui s'aggrave plus longtemps vous l'exécutez.

L'architecture intégration est où échouent les projets SFCC

SFCC ne vit pas isolée. Elle se connecte à votre ERP pour l'inventaire et la tarification. Elle se connecte à votre OMS pour la gestion commandes et l'acheminement de l'exécution. Elle se connecte à votre CRM pour les données clients et la personnalisation. Elle se connecte à votre PIM pour le contenu produit. Obtenez ces intégrations mal et la plateforme qui semblait si puissante dans la démo devient un passif en production.

Chez Columbia, nous avons implémenté Order Dynamics comme l'OMS et construit une toute nouvelle couche intégration cloud basée sur les événements reliant la vitrine SFCC aux systèmes d'arrière-plan sur le marketing, la fidélité client, et l'intelligence commerciale. L'architecture intégration s'étendait sur 21 sites d'eCommerce mondiaux lancés simultanément. La complexité intégration n'était pas un obstacle au déploiement SFCC. C'était le déploiement. La vitrine était la partie facile.

Les trois erreurs d'intégration que nous voyons le plus souvent

Les intégrations synchrones sur les mauvais flux de données. Les requêtes d'inventaire en temps réel de la vitrine vers l'ERP au paiement créent de la latence et des points d'échec. La disponibilité d'inventaire devrait être repoussée vers SFCC selon un calendrier et cachée. Réservez les appels synchrones pour les moments qui les exigent réellement, spécifiquement le placement commandes et la capture de paiement.

L'OMS comme réflexion tardive. Salesforce Order Management est un OMS capable et s'intègre naturellement avec SFCC - nous l'avons implémenté chez Empower Global aux côtés de Commerce Cloud, Marketing Cloud, Service Cloud, et Loyalty Cloud. Mais même une intégration native exige toujours une configuration significative pour l'exécution multi-lieu, la logique de division-expédition, et l'acheminement des retours. Les marques qui traitent l'OMS comme une phase ultérieure et connectent SFCC directement à l'ERP pour la gestion commandes construisent une dette technique qui coûte deux à trois fois plus cher à annuler que cela n'aurait coûté de le faire correctement la première fois.

Aucune stratégie de basculement basée sur les événements. Les intégrations échouent. Votre architecture doit gérer l'arrêt ERP sans surface une expérience de paiement cassée. Conçu pour le mode dégradé dès le premier jour. Cachez ce qui peut être caché. Mettez en file ce qui doit être en temps réel. Définissez le basculement pour chaque point intégration avant le lancement en production, pas après votre premier incident de production.

L'IA Einstein est réelle. Mais elle exige des vraies données pour fonctionner.

Einstein pour Commerce est véritablement puissant. Les recommandations produits, le tri prédictif, les insights Commerce, et les dictionnaires de recherche Einstein peuvent significativement déplacer les taux de conversion, la valeur commande moyen, et les taux recherche-à-achat. Nous l'avons vu fonctionner. Nous avons aussi vu des marques dépenser six chiffres sur l'activation Einstein et ne rien voir bouger de significatif parce que les données sous-jacentes n'étaient pas prêtes.

Einstein apprend à partir des signaux comportementaux. Les clics, les vues, les ajouts au panier, les achats, les requêtes de recherche, et les séquences de session alimentent tous les modèles. Si votre catalogue est mal structuré, vos termes de recherche ne sont pas mappés, ou votre flux de données comportementales est incomplet, les sorties d'Einstein reflètent cette qualité. Garbage in, garbage out s'applique aussi précisément à la personnalisation IA qu'à tout autre système de données.

Ce dont vous avez besoin avant que Einstein livre

• ■
  Un catalogue produit propre. Chaque produit doit avoir des attributs précis, des catégories complètes, et les liaisons variant appropriées. Les modèles recommandation d'Einstein utilisent la structure du catalogue comme signal fondamental. Un catalogue plat, incohéremment attribué produit les recommandations qui semblent aléatoires parce qu'elles le sont.
• ■
  Historique comportemental suffisant. Einstein a besoin de volume pour trouver les motifs. Les vitrines nouvelles, les catalogues récemment migrés, et les segments faible-trafic ne donnent pas aux modèles assez de signal. Planifiez une période d'accumulation données de 60 à 90 jours avant que les recommandations atteignent une précision significative.
• ■
  Investissement dictionnaire de recherche. Les dictionnaires de recherche Einstein améliorent dramatiquement la pertinence de recherche en gérant les fautes de frappe, les synonymes, et la terminologie spécifique à la marque. Mais ils exigent une curation continue. Quelqu'un de votre équipe doit en être propriétaire. Personne ne le fait, et la recherche devient votre point d'abandon le plus élevé.
• ■
  Stratégie placement, pas juste l'activation. Où vous placez les recommandations a autant d'importance que les recommandations qui émergent. Le placement de la page détail produit pilote la vente croisée. Le placement de la page panier pilote la vente majorée. Le placement de la page d'accueil pilote la découverte. Chacun exige une stratégie différente et des métriques de succès différentes.

L'architecture multisite et mondiale. Planifiez-la avant de la construire.

Les capacités multisite de SFCC sont l'une de ses plus grandes forces concurrentes. Une seule instance SFCC peut alimenter des douzaines de vitrines sur des marques, régions, langues, et devises avec la gestion catalogue centralisée et les expériences clients localisées. Chez Columbia Sportswear, nous avons aidé à architector et lancer 21 sites d'eCommerce mondiaux simultanément à partir d'une fondation SFCC partagée - des sites s'étendant sur plusieurs régions avec un temps d'inactivité presque nul dès le premier jour.

Mais multisite mal fait est pire que pas de multisite du tout. Les décisions de gouvernance que vous prenez dans la première implémentation déterminent comment chaque lancement vitrine futur devient coûteux.

Les décisions de gouvernance qui s'aggravent au fil du temps

Structures catalogue partagées versus site-spécifiques. Si vous construisez un catalogue monolithique que chaque site partage sans logique de variation, vous créez des contraintes quand différentes régions ont besoin d'une tarification, contenu, ou assortiment différents. Construisez l'architecture catalogue avec la variation multisite à l'esprit dès le départ, même si vous ne lancez qu'une seule vitrine initialement.

Code partagé versus cartouches site-spécifiques. Chaque personnalisation site-spécifique ajoutée directement au chemin cartouche base crée de la dette. Construisez un modèle clair héritage cartouche le premier jour. Cartouches base pour la fonctionnalité partagée. Cartouches site pour la variation localisée. Cartouches personnalisées pour la logique spécifique à la marque. Violer ce modèle pour la vitesse dans les implémentations précoces rend les sites ultérieurs exponentiellement plus chers.

Architecture gestion contenu. Page Designer et Asset Contenu de SFCC fonctionnent bien à l'échelle site unique et deviennent maladroits à l'échelle mondiale sans modèle de gouvernance. Définissez qui peut éditer quoi, quel contenu est partagé versus localisé, et comment les approbations contenu circulent à travers les équipes avant le lancement. Adapter cela rétrospectivement est douloureux.

La migration SFRA vers Composable. Ce que Salesforce ne vous dit pas.

Salesforce a été clair que Composable Storefront est la direction stratégique de la plateforme. PWA Kit et Managed Runtime représentent où va l'investissement de SFCC. Cela signifie que si vous êtes sur SFRA, la migration n'est pas une question de si mais de quand.

Le chemin d'implémentation hybride de Salesforce vous permet d'exécuter SFRA et Composable simultanément, migrant page par page ou flux par flux. En théorie, cela minimise le risque. En pratique, l'état hybride est l'état le plus risqué à long terme.

Exécuter hybride signifie maintenir deux systèmes d'authentification simultanément. À partir de la version SFCC 25.3, cela exige l'authentification hybride pour gérer à la fois le cookie session SFRA traditionnel et le JWT Web Token JSON SLAS en synchronisation sur chaque requête. Cette synchronisation n'est pas triviale, et la fenêtre pour les bogues d'état-session qui affectent la conversion est ouverte le temps entier que vous êtes en mode hybride.

Notre recommandation est de traiter le hybride comme un état transition avec une date fin dure, pas un modèle d'exploitation. Définissez la portée de la migration Composable, fixez une date limite pour quitter le hybride, et approvisionnez en conséquence. Les marques qui laissent les implémentations hybride dériver deviennent permanemment coûteuses à exploiter.

La performance à l'échelle n'est pas automatique

SFCC gère bien le trafic de pointe. L'infrastructure Managed Runtime se met à l'échelle automatiquement. Le CDN de Salesforce gère la livraison mondiale. Mais l'infrastructure mise à l'échelle automatique ne compense pas les problèmes de performance au niveau application, et les implémentations SFCC peuvent accumuler ces problèmes silencieusement jusqu'à ce qu'un événement trafic élevé comme un lancement produit ou une période de vacances les expose tous à la fois.

Le travail de performance qui se fait avant le lancement, pas après

• ■
  Audits de performance composant Page Designer. Les pages SFCC fortement modèles construites avec plusieurs composants Page Designer peuvent générer des appels API excessifs. Auditez chaque modèle vitrine pour le volume d'appels API avant le lancement. Consolidez les appels. Cachez agressivement au niveau composant.
• ■
  Stratégie optimisation image. Les capacités imagerie dynamique de SFCC sont puissantes mais exigent une configuration délibérée. La livraison image non optimisée est l'une des causes les plus courantes de mauvais scores Core Web Vitals sur les vitrines SFCC. Définissez explicitement les présets de taille image, de format, et de qualité. Ne compter pas sur les défauts.
• ■
  Test de charge avant chaque événement de pointe. Testez votre couche intégration, pas juste la vitrine. L'infrastructure SFCC se met à l'échelle. Votre ERP, OMS, et passerelle paiement peut ne pas le faire. Un délai expiration paiement au trafic de pointe est un événement revenu. Test de charge la pile entière.
• ■
  Parité bac à sable vers production. Les bacs à sable SFCC ont des caractéristiques de performance différentes que la production. Les tests de performance dans le bac à sable vous disent sur la performance relative entre les changements de code, pas la performance absolue de production. Testez dans un environnement semblable à la production avant les versions importantes.