Frontend Sana Commerce pour SAP/Dynamics : un storefront sans build React sur mesure

Sana Commerce résout un problème qui fait échouer de nombreux projets SAP et Dynamics depuis des années : la rupture entre les données ERP et le storefront. Les prix, les stocks, les conditions client et l'historique des commandes proviennent directement de SAP S/4HANA ou de Microsoft Dynamics 365, sans couche intermédiaire, sans base de données séparée, sans décalage de synchronisation. C'est le cœur de la promesse de Sana, et cet article n'y change rien. La question posée ici se situe strictement une couche plus haut : le frontend par lequel les clients voient réellement ces données.

Pourquoi les équipes construisent un frontend React sur mesure sur Sana Commerce

Sana fournit des modèles de storefront et des API REST permettant d'étendre l'interface. Pour les équipes ayant des ambitions de design élevées ou des besoins B2B particuliers, configurateurs personnalisés, workflows d'approbation spécifiques, affichage de logiques de prix particulières, la couche de modèles ne suffit souvent pas. La réponse naturelle : un frontend React entièrement sur mesure qui dialogue directement avec l'API Sana et offre une liberté de design complète. Techniquement, cela fonctionne, les API sont conçues pour cela, et la première version fonctionne généralement très bien.

Le piège : la compatibilité de mise à jour avec le cycle de release de Sana

Le point qui manque souvent de place dans la planification de projet : Sana Commerce Cloud évolue en permanence, nouvelles versions d'API, flux de checkout modifiés, nouvelles fonctionnalités de plateforme, tout selon le rythme de release propre à Sana. Un frontend React construit sur mesure se trouve en dehors de ce cycle. Il ne reçoit rien automatiquement, chaque changement Sana doit être suivi et appliqué manuellement, sinon la logique de storefront personnalisée finit par s'écarter de la structure d'API officielle.

En pratique, cela se traduit par :

• Les montées de version de l'API Sana déclenchent des revues de changements cassants dans votre propre code React
• Les nouvelles fonctionnalités de checkout ou d'approbation issues de la roadmap Sana doivent être reconstruites à la main, au lieu d'arriver automatiquement
• Chaque nouvelle page de campagne ou d'univers produit nécessite un sprint de développement, pas d'autonomie marketing
• Les mises à jour de React, Node et des dépendances atterrissent dans votre propre backlog, pas chez Sana
• Chaque mois sans maintenance élargit l'écart entre le frontend sur mesure et l'état actuel de l'API Sana

Ce n'est pas un problème propre à Sana, cela concerne tout build sur mesure construit sur une plateforme commerce intégrée à un ERP avec son propre rythme de release. Cela vaut néanmoins la peine de chiffrer honnêtement cette charge de maintenance dès le départ.

Ce qui reste inchangé au niveau de l'ERP

Point important pour bien situer le sujet : Sana reste dans ce schéma la source de vérité pour les prix, les stocks, les conditions client et les données de commande, lues directement depuis SAP S/4HANA ou Dynamics 365. Rien ne change à cette connexion, quel que soit le frontend qui affiche finalement les données. Le problème de compatibilité de mise à jour se situe entièrement au niveau de la couche de présentation, là où vivent les composants React, pas dans l'intégration des données entre Sana et l'ERP.

Laioutr, la réponse gérée : une couche FMP au-dessus de l'API Sana

Laioutr intervient précisément à ce niveau de présentation, sans toucher à la connexion entre Sana et l'ERP. Notre Composable Headless Frontend se connecte à l'API Sana via notre couche de données Orchestr et mappe les données produit, prix, stock et client sur notre schéma de composants unifié, les mêmes données qu'interrogerait un frontend sur mesure, mais maintenues de façon centralisée plutôt que dans votre propre dépôt. Parce que cette connexion fonctionne comme un composant de plateforme, Laioutr suit les évolutions de l'API Sana de manière centralisée, sans que chaque projet client ait à les reconstruire séparément.

Le résultat est un Frontend as a Service : mises à jour de framework, correctifs de sécurité, CI/CD et suivi du cycle de release de Sana relèvent de la plateforme, pas du sprint de votre équipe. Les développeurs et développeuses conservent un accès complet à la couche composants pour la logique B2B spécifique, sans la charge permanente de maintien de la compatibilité.

Comment fonctionne la connexion technique

La couche Orchestr dialogue avec l'API Sana Commerce, récupère les données produit, les prix spécifiques au client, les disponibilités et le statut des commandes, puis les normalise sur notre schéma de composants. Les composants de fiche produit, de liste produits et de checkout dans le frontend attendent la même structure de données, que ce soit Sana, SAP Commerce Cloud ou un autre backend intégré à un ERP derrière. Pour les champs spécifiques B2B de Sana, paliers de prix personnalisés, workflows d'approbation, catalogues par groupe de clients, une équipe d'ingénierie connecte une seule fois un résolveur personnalisé dans la couche Orchestr, plutôt que de les reconstruire dans un fork React sur mesure.

Qui fait quoi : ingénierie et marketing

Les équipes d'ingénierie définissent les composants et enrichissent la bibliothèque avec les données spécifiques à Sana, logique de prix B2B, groupes de clients, processus d'approbation. Le marketing travaille en parallèle dans l'éditeur Studio, compose des univers produits, change des pages de campagne, sans pull request et sans attendre une fenêtre de déploiement. Avec un build React entièrement sur mesure, cette séparation n'existe pas, chaque changement passe par le code, qu'il soit éditorial ou structurel.

Grille de décision : build sur mesure, modèles Sana ou FMP géré

Trois situations, trois réponses pertinentes. Vous disposez d'une équipe frontend importante et permanente et voulez un contrôle total sur chaque composant, sans couche de plateforme intermédiaire : le build React sur mesure reste une option valable, avec la maintenance de compatibilité comme compromis assumé. Les modèles standards de Sana vous suffisent, et l'individualité du design est secondaire : la couche de modèles reste la voie la plus rapide. Vous voulez une logique frontend B2B personnalisée, mais sans travail permanent de compatibilité avec le cycle de release de Sana : une couche frontend gérée comme Laioutr au-dessus de l'API Sana est la voie directe. Plus de détails sur la connexion sur notre page Sana Commerce.

Un schéma similaire se retrouve sur d'autres plateformes intégrées à un ERP, par exemple dans API OCC de SAP Commerce Cloud et Laioutr : comment le frontend se connecte, où la même séparation entre connexion ERP et exploitation du frontend s'applique. Pour une vision plus large des coûts d'un build sur mesure, voir Le coût caché des frontends sur mesure dans l'ecommerce entreprise.

En résumé

Sana Commerce résout le problème ERP-frontend côté données, de façon fiable et sans couche intermédiaire. Construire par-dessus un frontend React entièrement sur mesure revient à s'engager à maintenir en permanence ce frontend au rythme du cycle de release de Sana. Laioutr prend en charge exactement cette responsabilité comme travail de plateforme : votre connexion SAP ou Dynamics via Sana reste inchangée, et la couche frontend fonctionne comme une Frontend Management Platform, maintenue, à jour, et toujours extensible. La première étape est généralement un appel de découverte technique, où nous identifions ensemble les données Sana dont votre storefront a réellement besoin aujourd'hui.