L'architecture MACH dans SAP Commerce Cloud : ce qu'elle signifie en pratique

MACH signifie Microservices, API-first, Cloud-native et Headless. Sur un transparent, ce sont quatre cases. Dans un projet, ce sont des choix concrets, et SAP Commerce Cloud traite chacun de ces quatre principes différemment. Savoir où passe la limite évite de prendre des décisions d’architecture sur la foi des présentations des éditeurs.

En résumé : Commerce Cloud est un hybride. Trois principes sont intégrés, le quatrième passe par des extensions.

En bref : SAP Commerce Cloud respecte l’approche API-first (API REST OCC), le cloud-native (une plateforme que SAP exploite pour vous) et le headless (Composable Storefront ou tout front-end sur mesure). Son back-end est une seule application Java ; il ne repose donc pas sur des microservices, et SAP recommande de développer toute nouvelle logique sur mesure sous forme d’extensions side-by-side sur SAP BTP. Pour la plupart des projets B2B, cet hybride suffit. Misez sur l’API-first et le headless, considérez le cloud-native comme acquis et n’ajoutez des microservices que là où une exigence précise le demande.

Que signifie MACH ?

MACH regroupe quatre principes défendus par la MACH Alliance :

• Microservices : logique métier découpée en petits services déployables indépendamment
• API-first : chaque fonction exposée par des API bien définies avant toute interface utilisateur
• Cloud-native : conçu pour une exploitation dans le cloud, avec mise à l’échelle automatique, résilience et services gérés
• Headless : front-end découplé du back-end, communication uniquement par API

Ce n’est pas tout ou rien. Une plateforme peut être forte sur certains principes et plus faible sur d’autres. La combinaison dont vous avez besoin compte davantage que n’importe quel label affiché sur le site d’un éditeur. Pour la question métier de savoir quand assembler des services spécialisés, lisez notre guide sur le commerce composable en B2B.

M comme microservices : un hybride

Le back-end de Commerce Cloud est une seule application Java. Panier, checkout, calcul des prix, recherche et gestion des commandes tournent dans le même processus, et la plateforme se déploie comme un tout, pas module par module.

Les microservices apparaissent autour :

• Extensions side-by-side sur SAP BTP. C’est l’approche recommandée par SAP pour toute nouvelle logique sur mesure : la développer comme service autonome sur SAP BTP (runtime Kyma ou Cloud Foundry) et l’appeler par API, plutôt que d’étendre le cœur.
• Services tiers. Paiement, fiscalité, recherche ou personnalisation tournent comme services indépendants appelés par Commerce Cloud.

En pratique, vous ne pouvez pas déployer les modules commerce séparément, mais vous gagnez en extensibilité grâce aux services externes. Pour la plupart des mises en œuvre B2B, cela suffit, et le cœur unique a un avantage : prix contractuels, promotions et flux de commande restent cohérents au même endroit. Là où le cœur a vraiment limité un projet, notre réponse a toujours été la même : développer cette fonction précise sur BTP, à côté de Commerce Cloud.

A comme API-first : le principe le plus solide

Les API REST OCC (Omni Commerce Connect) exposent produits, catégories, paniers, checkout, commandes, clients, recherche et contenus CMS. Composable Storefront communique avec Commerce Cloud exclusivement par ces API, la meilleure preuve qu’elles sont assez complètes pour faire tourner une boutique entière. SAP documente l’architecture OCC à base d’extensions sur SAP Help.

Ce qui rend cette couche exploitable en projet :

• une large couverture des opérations commerce, B2B compris
• extensible : vos propres extensions ajoutent des points de terminaison
• des spécifications OpenAPI et une authentification OAuth 2.0
• toute technologie front-end peut l’utiliser

Une réserve : certaines tâches d’administration et de configuration passent encore par le Backoffice. Les API sont conçues pour le commerce, pas pour l’administration complète du système.

C comme cloud-native : exploité par SAP

SAP Commerce Cloud tourne sur une infrastructure que SAP exploite pour vous. Concrètement :

• mise à l’échelle automatique selon le trafic
• un CDN intégré pour les contenus statiques et les médias
• des déploiements via le Cloud Portal, sans accès direct aux serveurs
• des environnements provisionnés séparément et des artefacts de build immuables
• journaux et métriques dans le portail
• correctifs de sécurité et versions de mise à jour cumulatives fournis par SAP

La contrepartie, c’est le contrôle. Vous ne pouvez ni choisir le moteur de base de données, ni régler la JVM au-delà de ce que SAP autorise, ni utiliser des régions que SAP ne propose pas. Pour la plupart des charges commerce, cela n’a aucune importance ; pour quelques cas particuliers, si. Depuis la fin de la maintenance standard du produit on-premise le 31 juillet 2026 (SAP Help), l’avenir de SAP Commerce passe par le cloud ; notre article sur ce qu’il faut faire maintenant que le support on-premise a pris fin présente les options.

H comme headless : intégré

Composable Storefront (anciennement Spartacus) est le front-end headless de SAP, basé sur Angular (SAP Help). Il ne communique avec Commerce Cloud que via OCC, et vitrine et back-end se déploient indépendamment : vous livrez une mise à jour Angular sans toucher au back-end Java.

Ce que le headless permet :

• n’importe quel framework front-end (Angular, React, Vue, Next.js)
• les mêmes API pour le web, les applications mobiles, les bornes et les portails partenaires
• des mises en production de la vitrine indépendantes de celles du back-end
• le rendu côté serveur, pour la vitesse et les moteurs de recherche

Souvent oublié : même en mode headless, SmartEdit continue de gérer la composition des pages. Les responsables de contenu créent pages, emplacements et composants dans SmartEdit, et Composable Storefront les affiche. Le marketing modifie les mises en page sans développeur. Si vous préférez React ou Next.js, notre comparaison Composable Storefront ou React/Next.js explique les compromis. Distrelec est une référence pour la voie headless : après le découplage de son front-end, le délai de mise sur le marché des changements front-end a baissé de 70 %.

Faut-il adopter MACH entièrement ?

Pas forcément. MACH est un ensemble de principes, pas une religion. La question utile est de savoir quels principes résolvent vos problèmes concrets.

API-first et headless valent presque toujours la peine. Ils vous donnent de la liberté côté front-end et une stratégie d’intégration propre, y compris vers l’ERP.

Le cloud-native est désormais acquis pour SAP Commerce.

Les microservices sont le domaine où le pragmatisme compte le plus. Le back-end unique fonctionne bien pour la plupart des mises en œuvre. Si une fonction exige un déploiement indépendant ou des stockages de données séparés, développez-la sur BTP à côté de Commerce Cloud. N’essayez pas de démonter la plateforme elle-même.

Si vous comparez avec d’autres plateformes, notre comparaison SAP, Salesforce et Adobe Commerce met les architectures côte à côte. Ou parlez de votre configuration à nos architectes commerce.

Questions fréquentes

SAP Commerce Cloud est-il une plateforme MACH ?

En partie. Il respecte bien trois des quatre principes : API-first grâce aux API REST OCC, cloud-native en tant que plateforme exploitée par SAP, et headless grâce à Composable Storefront ou à tout front-end sur mesure. Le back-end est une seule application Java et ne respecte donc pas le principe des microservices ; la réponse de SAP, ce sont les extensions side-by-side sur SAP BTP.

Quelle est la différence entre MACH et commerce composable ?

MACH décrit la façon dont la technologie est construite : microservices, API d’abord, exploitation cloud-native, front-end découplé. Le commerce composable est la stratégie qui consiste à assembler des services spécialisés en une plateforme commerce. Il faut des briques de type MACH pour composer, mais les utiliser ne rend pas automatiquement composable.

Peut-on construire un front-end sans Angular sur SAP Commerce Cloud ?

Oui. Les API OCC sont des points de terminaison REST indépendants de la technologie : React, Vue, Next.js ou Svelte fonctionnent aussi bien que Composable Storefront, la vitrine Angular de SAP. Vous renoncez aux composants de vitrine préconstruits de SAP et gagnez le contrôle total du front-end, maintenance comprise.

L’architecture MACH améliore-t-elle les performances ?

Elle le peut. Un front-end headless permet le rendu côté serveur et la mise en cache en périphérie, et une plateforme cloud gérée s’adapte au trafic. Le risque est une décomposition excessive : de nombreux services qui s’appellent mutuellement ajoutent une latence qu’une plateforme unique bien réglée évite. Mesurez les parcours d’achat importants avant et après chaque changement.

Passer à MACH change-t-il le coût de SAP Commerce Cloud ?

La licence de la plateforme ne dépend pas de l’architecture choisie. Les coûts de mise en œuvre et d’exploitation, si : des services propres sur SAP BTP ou un front-end sur mesure ajoutent du travail de développement et de maintenance. Pour beaucoup de projets, la plateforme standard avec Composable Storefront est le démarrage le plus économique.