Commerce mobile avec SAP Commerce Cloud (anciennement Hybris) : fonctionnalités, performance et PWA

Dans la plupart des boutiques en ligne, la majorité des sessions commencent sur un smartphone. Les capacités mobiles d’une plateforme de commerce déterminent donc si vos clients peuvent acheter chez vous, et non si la boutique a l’air moderne.

Beaucoup d’entreprises traitent encore le mobile comme une version réduite du site desktop. C’est l’inverse qu’il faut faire : concevoir d’abord pour le téléphone, puis étendre la mise en page au grand écran.

SAP Commerce Cloud, le produit autrefois appelé SAP Hybris, gère le mobile sur trois couches : le SAP Composable Storefront responsive (anciennement Spartacus), les fonctions de Progressive Web App (PWA) et les API REST OCC que tout frontend ou toute application native peut appeler. Voici ce que fait chaque couche et où se situent ses limites.

En bref : SAP Commerce Cloud sert les clients mobiles grâce au Composable Storefront responsive basé sur Angular, à des fonctions PWA comme la mise en cache et l’ajout à l’écran d’accueil, et aux API OCC qui alimentent aussi les applications natives. Pour la plupart des boutiques B2C et B2B, une PWA bien construite suffit ; une application native se justifie pour la lecture de codes-barres, la réalité augmentée ou un usage hors ligne intensif. Les plus grands gains mobiles viennent généralement du travail de performance sur les images, le JavaScript et la mise en cache.

Comment SAP Commerce Cloud gère-t-il le mobile ?

Le support mobile de Commerce Cloud s’organise en trois couches.

Couche 1 : le storefront responsive. SAP Composable Storefront est une application Angular dont les composants s’adaptent à la taille de l’écran : les grilles se replient, la navigation passe dans un menu, les zones tactiles sont dimensionnées pour les doigts. Les bases, bien faites. Nous avons un jour repris une boutique dont l’implémentation précédente utilisait sur mobile des zones tactiles de 32 pixels, et les clients touchaient sans cesse le mauvais élément. Les valeurs par défaut du Composable Storefront sont raisonnables sur ce point. (Si vous êtes encore sur l’ancien storefront Accelerator, notre guide de migration vers le Composable Storefront décrit la démarche.)

Couche 2 : Progressive Web App. Le Composable Storefront intègre le support PWA : un service worker pour la mise en cache et une application web installable avec ajout à l’écran d’accueil. Pas d’App Store, pas de processus de validation, pas de cycle de publication séparé. SAP indique que les fonctions PWA sont encore en cours d’extension (SAP Help : Progressive Web Application Support) ; les notifications push et un fonctionnement hors ligne plus poussé demandent donc en général un travail de projet.

Couche 3 : les API OCC. Les API REST Omni Commerce Connect renvoient du JSON structuré, et les réponses peuvent être allégées par des jeux de champs pour limiter le volume de données sur les réseaux mobiles. Cela compte avec une connexion faible au fond d’une vallée, et c’est la même API qu’utiliserait une application native.

Avez-vous besoin d’une application native ?

Pour la plupart des cas d’usage commerciaux, non. Une PWA couvre la mise en cache des contenus déjà consultés, l’ajout à l’écran d’accueil et une navigation proche d’une application, et avec un peu de travail de projet les notifications push. Cela suffit pour la grande majorité des scénarios B2C et B2B.

Une application native se justifie si vous avez besoin de visualisation produit en réalité augmentée, du matériel de l’appareil comme la lecture de codes-barres ou le GPS, de fonctions hors ligne importantes (pour la vente itinérante, par exemple) ou d’applications métier B2B dédiées. Ce que nous déconseillons : développer une application native surtout pour que la marque ait une icône dans l’App Store. Le développement et la maintenance ont un coût réel et, sans cas d’usage que le web ne couvre pas, les téléchargements restent faibles.

Si vous optez pour le natif, les API OCC servent l’application exactement comme le storefront web. Même backend, frontend différent. Savoir si le Composable Storefront ou un frontend React ou Next.js convient mieux à votre équipe est une autre question, que nous traitons dans SAP Composable Storefront ou React et Next.js.

Quel travail de performance compte le plus sur mobile ?

Un storefront mobile lent perd des clients à chaque interaction. Les Core Web Vitals de Google sont l’étalon pratique :

• LCP (Largest Contentful Paint) : l’image principale en moins de 2,5 secondes sur mobile, grâce aux images responsives, au chargement différé et à un CDN.
• INP (Interaction to Next Paint) : réduire le volume de JavaScript par chargement différé et découpage du code.
• CLS (Cumulative Layout Shift) : définir explicitement largeur et hauteur des images et réserver l’espace des contenus dynamiques.

Optimisations propres à Commerce Cloud :

• Compression des images et diffusion au format WebP
• Mise en cache CDN des ressources statiques et des réponses d’API adaptées
• Rendu côté serveur (SSR) dans le Composable Storefront pour afficher plus vite les premiers contenus
• Chargement différé des images produits sous la ligne de flottaison
• Réponses allégées de l’API de recherche pour les fiches produits mobiles

Rien de tout cela n’est spectaculaire, mais c’est la différence entre une boutique mobile qui vend et une boutique qui perd des clients à chaque page. Pour un regard extérieur sur votre storefront, parlez à notre équipe Commerce ou lisez notre comparaison des partenaires SAP Commerce Cloud en Suisse. La plateforme elle-même est présentée sur notre page SAP Commerce Cloud.

Questions fréquentes

SAP Commerce Cloud prend-il en charge Apple Pay et Google Pay ?

Oui, via le prestataire de paiement intégré, par exemple Adyen, Stripe ou un prestataire suisse. Les portefeuilles sont activés et configurés chez le prestataire de paiement, pas dans Commerce Cloud.

Comment le storefront gère-t-il une mauvaise connexion ?

Le service worker de la PWA met en cache les ressources statiques et les contenus déjà consultés, si bien que la navigation reste possible avec un réseau faible. Les transactions exigent toujours une connexion : le checkout ne peut pas se terminer hors ligne.

Peut-on avoir des mises en page différentes sur mobile et sur desktop ?

Oui. Le CSS responsive adapte automatiquement les composants. Si vous avez besoin d’un contenu différent et pas seulement d’une autre disposition, SmartEdit permet de personnaliser ou de restreindre des composants pour des publics précis.

Comment fonctionne la recherche sur mobile ?

Le même moteur de recherche (Solr dans la configuration standard) sert les deux canaux. Le storefront adapte l’interface : recherche en plein écran, filtres et panneaux de facettes adaptés au tactile.

Et la lecture de codes-barres en B2B ?

Commerce Cloud n’intègre pas de lecture de codes-barres. Il faut une application native ou une PWA qui utilise l’accès à la caméra du navigateur ; plusieurs composants de partenaires ajoutent cette fonction.