Comment unifier l’expérience client grâce à un E-business orienté services ?

Une architecture orientée services dans un système d’informations (SI) est un concept mettant en relation différents applicatifs sous forme de relations fournisseurs / consommateurs. D’un point de vue E-Business le concept consiste, pour son site Magento, soit à consommer des informations issues du SI du client ou d’un SI Tiers, soit à exposer une partie de son fonctionnel.

1) Enjeux d’une architecture orientée services

Penser son architecture e-commerce en l’orientant services est un concept très en vogue.
Que ce soit des services entrant ou sortant, l’idée du concept est de pouvoir aller chercher chez l’autre ce dont il nous sera difficile (voir impossible) de récupérer soi-même. Dans cette optique, on pourra constater un impact sur les facteurs ci-dessous :

Voici un exemple d’architecture orientée services qu’un client pourrait choisir pour répondre à son besoin :

2) Magento et l’orienté services

Magento 2 a nativement renforcé ses possibilités en termes d’échanges externes d’informations. En effet, il est désormais possible, via les contrats de services, d’exposer tout ou partie des fonctionnalités de la plateforme par le biais de webservices ou d’API.

Dans ces termes, notre plateforme Magento 2 jouit d’une emprunte forte de la partie E-Business de l’entreprise et permet, désormais, de partager cette puissance avec d’autres entités externes.

Depuis longtemps, les plateformes e-commerce s’appuient sur des informations externes pour proposer l’ensemble de leurs services. En effet, de nombreux modules Magento 2 permettent d’accéder, par le biais de services tiers, à des fonctionnalités dont les données ne sont pas stockées directement sur la plateforme. Néanmoins, la tendance actuelle va plus loin et vise désormais à exposer une partie des fonctionnalités de la plateforme e-commerce.

3) Une architecture orientée services… Mais dans quels cas ?

Il y a donc 2 sens d’utilisation des services que nous allons appeler : services entrants exposés par un tiers et consommés par Magento 2 et services sortants, c’est-à-dire les services exposés par la plateforme e-commerce.

Comme évoqué précédemment, il est déjà très courant de rencontrer des consommations de services sur notre plateforme Magento 2. Les cas sont évidemment très variables en fonction des besoins du site mais il est très facile d’extirper quelques exemples significatifs comme :

Dans d’autres cas, des choix stratégiques peuvent amener la plateforme à décentraliser une partie de ses fonctionnalités à des tiers.

Par exemple :

• Le besoin d’un moteur de recherches personnalisée

Même si Magento 2 propose déjà un panel de fonctionnalités bien au dessus de la moyenne, le client peut avoir un besoin fort en matière de marketing et dans ce cas, il est susceptible de coupler sa plateforme e-commerce à un outil en mode Saas comme Fredhopper ou encore PigData.

• Un catalogue volumineux

Si le volume du catalogue client ne permet par une absorption et/ou une mise à jour de celui-ci de manière suffisamment fréquente, il sera possible d’opter pour l’externalisation de tout ou partie du catalogue. Cela permettra ainsi d’interroger un service externe pour récupérer les informations produit en fonction des besoins du site e-commerce.

• Un fonctionnel complexe à intégrer dans Magento

Un algorithme complexe pour générer un calcul précis (de prix ou de stock par exemple) pourrait contraindre Magento à aller puiser le fonctionnel directement sur le SI du client et ainsi à appeler des Webservices plutôt que d’afficher ses données stockées.

De manière globale et par souci de fiabilité des données présentées au client, il est déconseillé de dupliquer du fonctionnel complexe du client sur son site e-commerce.

Remarques : les cas de figure précédents incitent à se poser la question de la cohérence d’un ETL (Extract-Transform-Load) ou d’un ESB (Enterprise Service Bus) dans le système.

• Authentification unique (ou SSO : Single Sign On)

Dans le but de renforcer la sécurité, certain RSI font le choix de centraliser leurs informations utilisateurs sur leur seul système, dans ce cas et par le biais d’un protocole sécurisé (type SAML) le SI client (identity provider) fournira les informations d’authentification utilisateur à Magento (service provider)

Informations :
Identity provider : a pour rôle d’authentifier l’utilisateur et de fournir les données utilisateurs.
Service provider : a pour rôle de sécuriser l’accès à une application par le biais de l’identity provider.




Et l’utilisation de Magento comme fournisseur de services alors ?

Il est possible de se servir des données de son site Magento comme référence pour d’autres outils :

• Le catalogue

Les fabriquants de produits livrent, en général, des informations brutes. Sans la présence d’un PIM, la BDD e-commerce est parfois le seul endroit où l’on trouve des informations “retravaillées”. Il est utile, dans ce cas, de mettre à disposition une API REST permettant à d’autres outils (l’E-Catalogue, bornes, appli mobile, site mobile…) de venir consulter tout ou partie du catalogue Magento.

• L’état de la commande

Les outils de tracking étant généralement partiellement liés à des facteurs externes (transporteur, magasin, paiement…), l’idée d’exposer l’état d’une commande depuis la plateforme e-commerce permet d’avoir une vision complète de son état (depuis la création jusqu’à la remise au client).

• Commande / facturation

Pour le SI client et en subsitution aux traditionnels flux, il sera possible d’exposer pour le service comptabilité une méthode fournissant les commandes d’un certain statut.

Par le biais de ces exemples, on se rend compte qu’en fonction du besoin du client, une multitude de cas rendrait la mise à disposition d’une partie du fonctionnel Magento pertinent.

4) Point d’attention

Si ils ne sont pas maîtrisés, 2 points pourraient venir noircir le tableau d’une architecture orientée services.

La sécurité

Qui dit ouverture de méthodes à l’extérieur dit sécurisation obligatoire d’une extrémité à l’autre.

La performance

Le deuxième point de vigilance est incontestablement la performance. En effet, le concept de l’orienté services étant la mutualisation des services, il est essentiel de s’assurer, pour un service :

• qu’il sera en capacité d’absorber la charge supplémentaire qui sera générée par les nouveaux consommateurs
• qu’il peut fournir un SLA (service-level agreement) satisfaisant

Dans les deux cas, il sera essentiel de se poser les questions en amont du projet puisque, que ce soit d’un point de vue trafic ou qualité de service, le niveau d’exigence des différents consommateurs peut varier. Dans tous les cas, il faudra très certainement accompagner le projet d’une phase d’analyse sur les besoins et capacités de chacun (tests de montées en charge) et, dans la foulée, d’un réajustement de l’infrastructure.

Conclusion

Chaque entité de la sphère du système d’informations dispose de sa spécialisation, son expertise, son savoir faire… en d’autre termes, son fonctionnel. Le fait d’inclure le e-commerce dans cette sphère prouve désormais son importance au sein de la stratégie de l’entreprise. La mise en place d’un site e-commerce étant un investissement lourd et les informations dont il dispose, précieuses, il devient essentiel de capitaliser sur cet investissement pour ainsi optimiser son ROI.