Du monolithe au composable : comment réussir le move to cloud de son site e-commerce sans perdre les développements spécifiques ?

Toutefois, la plupart des solutions SaaS actuelles limitées par des API normées, n’autorisent plus l'ajout de personnalisations. 
Comment réussir ce move to cloud sans sacrifier les spécificités clés qui font la valeur d’une entreprise ? Voici les étapes pour relever ce défi.

Développements spécifiques en SaaS : quelles contraintes ?

Quels sont les développements spécifiques les plus courants ?

Les développements spécifiques les plus couramment déployés incluent :

• L’intégration de solutions tierces offrant de meilleures fonctionnalités que la solution nativement présente dans le monolithe (en premier lieu, bien souvent, un nouveau moteur de recherche et de recommandation produit).
• L’implémentation de règles de gestion spécifiques embarquées dans les interfaces d’import / exports de données, ou de la réconciliation de données produit post intégration.
• La création de reportings de données personnalisés.
• Le développement de fonctionnalités pour scénariser des spécificités business, telles que des offres packagées, des scénarisations spécifiques d’accès aux produits (aide au choix, configurateurs de produits, etc.), des règles de gestion de pricing ou de fidélité... 
• Et bien d’autres encore !

Quels défis posent ces développements spécifiques ?

En optant pour un replatforming vers une architecture de Commerce Composable, les entreprises rencontrent ainsi plusieurs défis majeurs :

1. Les solutions SaaS actuelles des éditeurs n’autorisent pas l’intégration de développements spécifiques au cœur des plateformes. Elles fournissent uniquement la configuration et l’implémentation d’un habillage aux couleurs des enseignes. Elles offrent bien souvent une forte complétude fonctionnelle par rapport aux besoins métier, mais n’hébergeront pas les développements spécifiques et les fonctionnalités additionnelles auparavant proposées aux clients ou aux collaborateurs : elles obligent à se conformer à un certain standard.
2. Ces solutions SaaS s’interfacent désormais au travers d’API normées. À leur appel, les API fournissent ou intègrent un schéma de données préétabli. Il n’est plus possible de développer ses flux sur le serveur e-commerce, de transformer des fichiers d’entrées en données attendues par la base de données, de réconcilier des fichiers de sources différentes : ces plateformes attendent ce travail, prémâché, d’une source externe.
3. Les API d’interfaces nécessitent généralement d’être appelées pour répondre et fournir ou intégrer la donnée demandée : bien souvent, elles ne prendront pas l’initiative… d’exporter une commande passée. Un autre système doit « donner l’ordre » aux API d’effectuer un travail.

Compte tenu des contraintes imposées par ces nouvelles normes, les étapes suivantes représentent une solution pour réaliser un move to cloud sans accroc de votre ancien site e-commerce monolithique vers une solution SaaS.

Move to cloud | Étape 1 : Construire une architecture cible autour d’une solution Middleware

Les architectures e-commerce SaaS, qui plus est MACH (Microservices, API-first, Cloud-native, Headless), éclatent les domaines fonctionnels en composants qu’il nécessite de faire communiquer.

▲ Eclatement des platefomes e-commerce en composants dans les architectures de Commerce Composable

Ces composants interagissant majoritairement au travers d’appels API. Ainsi, veillez à posséder un middleware : en agissant comme un chef d’orchestre, il fournira ses instructions à chaque composant et récoltera les réponses.

Assurez-vous de disposer d’un middleware capable :

• d’orchestrer les flux et les appels API de chaque composant
• de consolider et de mapper les données de diverses sources vers les formats attendus par les destinataires.
• de créer des bases de données « tampon », consolidant les différentes informations pour les fournir ensuite, complètes, aux différents destinataires comme le site e-commerce.

Les API orientées Front seront, quant à elles, directement appelées par le Front Headless pour présenter les données.

Move to cloud | Étape 2 : Rompre avec les développements spécifiques au sein des sites e-commerce

L’approche headless propose de déployer des expériences utilisateurs très variées. Elle offre une grande liberté en matière d’identité de marque et de scénarisation des fonctionnalités.

Le cœur des solutions SaaS, en revanche, ne tolère que peu – voire pas - de développements spécifiques « métier » : des développements impliquant une logique, des règles de gestion et des données hors du périmètre natif.

La question essentielle à vous poser désormais est : « comment gérer notre héritage de développements spécifiques ? ».

Plusieurs réponses seront envisageables en fonction des cas particuliers, et une méthode d’analyse consiste à catégoriser les fonctionnalités par domaines applicatifs :

• CMS (Content Management System) où produire et publier les contenus éditoriaux et d’animation marketing
• PIM (Product Information Management) où gérer le référentiel des produits, les enrichir et les publier sur les canaux comme le e-commerce
• OMS (Order Management System) où gérer la vue consolidée des stocks et leur localisation ainsi que le dispatch des commandes e-commerce à traiter
• Search (moteur de recherche) où gérer les listes de produits, résultats de recherche, dictionnaires de synonymes, boost and bury des produits dans les résultats naturels, etc.
• Pricing
• Promotions
• CRM (Customer Relationship Management), compte client et programme de fidélité
• Fonctionnalités « maison » différenciantes par rapport à la concurrence
• Front End (le site e-commerce présenté au client) où les scénarisations et mises en avant de contenus, produits et promotions

La méthodologie à suivre est la suivante :  

1. Recenser et classifier les développements spécifiques réalisés

2. Mesurer leur valeur business (exemple : amélioration du référencement et du nombre de visites, hausse de la valeur du panier moyen, hausse du taux de mise au panier, hausse du taux de transformation, baisse du nombre de retours, simplification du travail des collaborateurs, simplification du pilotage de l’activité commerciale, etc.)

3. Arbitrer sur le devenir de ces développements qui prendront l’un des chemins suivants :

• Le décommissionnement 

Beaucoup de ces développements représentent des héritages du passé, des méthodes obsolètes qui constituent aujourd’hui une dette technique à éliminer. De plus, veillez à repenser les processus métier afin de vous passer de certains de ces développements.

• La réorientation vers le bon outil, dans un meilleur respect des zones de responsabilité applicatives des composants du système d’informations

Certains développements spécifiques avaient été réalisés sur la plateforme e-commerce dans le but de pallier des manques du système d’informations. Par exemple, un développement assurant le groupement des produits en offres packagées est en réalité du ressort d’une solution PIM, devenue incontournable, ou encore, un workflow lourd de gestion de stock est du ressort d’un OMS.

• La transposition d’une scénarisation purement Front dans le Front Headless, prévu à cet effet

Les développements spécifiquement liés à l’expérience utilisateur de votre enseigne sont transposables dans le Front Headless, sans aucune difficulté, tant qu’il ne s’agit que du comportement des pages en fonction du contexte de navigation (qui est le visiteur ? quel est son comportement sur le site ? etc.)

• La sanctuarisation de développements « Business Critical », représentant un savoir-faire spécifique ou apportant une valeur d’expertise faisant partie des différenciateurs de l’enseigne.

Certains développements spécifiques n’entrent dans aucune des catégories précédentes. Prenons un exemple emblématique de fonctionnalité en ligne qui illustre parfaitement l’expertise d’une enseigne : le configurateur de solution technique pour les sports de glisse, s’assurant de la compatibilité des skis avec les fixations, prenant en compte la taille, le poids et le niveau technique du client. Ce type de développements est essentiel à préserver : il constitue l’ADN même de l’enseigne.

La bonne approche consiste à sanctuariser cette fonctionnalité : 

• L’extraire du site e-commerce
• La porter en application autonome au sein du système d’information et l’exposer par API au travers du middleware
• La consommer au travers du site e-commerce… mais aussi en boutique, à l’atelier… cette fonctionnalité étant alors devenue fondamentalement omnicanale ! 

Move to cloud | Étape 3 : Planifier et mettre en œuvre

La transformation profonde de l’architecture, imposée par les nouveaux standards des plateformes e-commerce, nécessite ainsi un travail de mise à jour d’une grande partie du Système d’Informations en lui-même. Il devient ainsi nécessaire de construire une roadmap IT dont la complexité variera selon le niveau de maturité de l’architecture du SI, d’effectuer les choix technologiques associés, puis de procéder à sa mise en œuvre. 

L’activité e-commerce étant devenue aujourd’hui incontournable pour la plupart des enseignes, les approches « big bang » sont souvent proscrites. Une approche pas à pas des décommissions et des relocalisations de fonctionnalités, par petits groupes, en les réimplémentant sur la solution existante est une approche sécurisante vous assurant :

• De tester peu à peu le déport des fonctionnalités et la robustesse de la nouvelle architecture au travers de l’A/B testing
• De décharger progressivement la plateforme existante de son code source spécifique et améliorer sa performance plus rapidement
• De tester la nouvelle architecture et les nouveaux services exposés sur d’autres canaux (ex : application pour les vendeurs) avant de les déployer sur le site e-commerce

La clé de la réussite du move to cloud de votre nouvelle plateforme e-commerce SaaS est donc d’adopter une approche de Commerce Composable, autour de services exposés par un middleware. 

Cette direction SaaS se généralise parmi les éditeurs. Elle concerne le e-Commerce comme nous avons pu l’évoquer dans un premier article, mais également de plus en plus de domaines fonctionnels dans votre système d’informations - Product Information Management (PIM), Order Management System (OMS), Warehouse Management System (WMS), Middleware, Entreprise Ressource Planner (ERP), Marketing Automation, Customer Relationship Management (CRM), etc. – accélérant la transformation digitale vers des systèmes d’informations composables et orientés services.