Salesforce Commerce Cloud.
Ce que personne ne vous dit
avant de signer.

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 réalité commence bien avant le lancement. Certaines équipes n'y arrivent jamais. SFCC exige des développeurs logiciels chevronné habitant 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 réalité que la plupart des gens ne disent pas ouvertement. Vous travaillez sur Demandware. Salesforce a acquis Demandware en 2016 pour 2,8 milliards de dollars et l'a renommée 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 massivement 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 habité cet écosystème sous-estiment régulièrement la courbe d'apprentissage.

Salesforce élabore aussi quelque chose appelé Commerce on Core, son produit commerce plus récent élaboré nativement sur la plateforme Salesforce (Force.com) plutôt que sur l'infrastructure héritée de Demandware. Salesforce la qualifie 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 la plateforme lignée Demandware. Sachez ce que vous achetez.

Nous avons livré SFCC chez Columbia Sportswear, l'une des plus grandes entreprises de vêtements de plein air du monde, et chez Empower Global, une plateforme élaborée 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 où frontend et backend vivent ensemble dans SFCC. Composable Storefront (élaborée sur PWA Kit et Managed Runtime de Salesforce) découple entièrement le frontend, le livrant comme application web progressive React connectée à SFCC via API.

Cette décision façonne tout en aval. Structure d'équipe, embauche de développeurs, complexité d'intégration, temps d'accès au marché, et coûts de maintenance continus remontent tous à l'architecture 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 d'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 produit ont tous des intégrations natives SFRA. Vous ne partez pas de zéro.

Le risque avec SFRA est le plafond de performance à long terme. L'architecture couplée signifie que les améliorations frontend exigent des déploiements backend. L'optimisation de la vitesse page frappe les contraintes structurelles. À mesure que Composable devient la direction stratégique de la plateforme, SFRA exigera finalement une migration.

Quand Composable est la bonne réponse

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

Le risque avec Composable est la maturité d'intégration. L'écosystème tiers pour PWA Kit se développe toujours. Ce qui était une installation cartouche dans SFRA devient 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.

L'architecture d'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 de 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 OMS et élaboré une toute nouvelle couche d'intégration cloud basée sur les événements reliant la vitrine SFCC aux systèmes d'arrière-plan couvrant le marketing, la fidélité client, et l'intelligence commerciale. L'architecture d'intégration s'étendait sur 21 sites d'eCommerce mondiaux lancés simultanément. La complexité d'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

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

OMS traité comme réflexion tardive. Salesforce Order Management est un OMS capable et s'intègre naturellement avec SFCC - nous l'avons livré 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 une configuration significative pour l'exécution multi-localisation, la logique de scission-expédition, et l'acheminement des retours. Les marques traitant l'OMS comme phase ultérieure et reliant SFCC directement à l'ERP pour la gestion de commandes élaborent une dette technique coûtant deux à trois fois plus à débobiner que cela n'aurait coûté de le faire correctement la première fois.

Absence de stratégie de basculement basée sur les événements. Les intégrations échouent. Votre architecture doit gérer l'indisponibilité ERP sans exposer une expérience de paiement cassée. Concevez pour le mode dégradé dès le premier jour. Mettez en cache ce qui peut l'être. Mettez en file ce qui doit être temps réel. Définissez le basculement pour chaque point d'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 for 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 de commande moyenne, et les taux de 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 de variantes appropriées. Les modèles de 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 de 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 responsable. Personne ne l'est, et la recherche devient votre point d'abandon le plus élevé.
• ■
  Stratégie de placement, pas juste l'activation. Où vous placez les recommandations a autant d'importance que ce qui émerge. Le placement de page détail produit pilote la vente croisée. Le placement de page panier pilote la vente majorée. Le placement de 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 concevoir.

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é quasi zéro dès le premier jour.

Mais multisite mal conçu 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 de 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 élaborez 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. Concevez 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 de base crée de la dette. Concevez un modèle clair d'héritage cartouche le premier jour. Cartouches de 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 de gestion de contenu. Page Designer et les assets de 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 de 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 le mode 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 JSON Web Token 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 mode hybride comme un état de transition avec une date fin stricte, 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 automatiquement 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 de composant Page Designer. Les pages SFCC fortement modèles élaborées avec plusieurs composants Page Designer peuvent générer des appels API excessifs. Auditez chaque modèle de vitrine pour le volume d'appels API avant le lancement. Consolidez les appels. Mettez en cache agressivement au niveau composant.
• ■
  Stratégie d'optimisation d'image. Les capacités d'imagerie dynamique de SFCC sont puissantes mais exigent une configuration délibérée. La livraison d'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 comptez pas sur les défauts.
• ■
  Test de charge avant chaque événement de pointe. Testez votre couche d'intégration, pas juste la vitrine. L'infrastructure SFCC se met à l'échelle. Votre ERP, OMS, et passerelle de paiement peuvent ne pas le faire. Un délai d'expiration de paiement au trafic de pointe est un événement revenue. 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.