Note : Ce contenu a été créé avant que Fabernovel ne fasse partie du groupe EY, le 5 juillet 2022.

‍

Si les livraisons en un jour ouvré et les notifications de commande sont devenues monnaie courante dans l’expérience d’achat en-ligne moderne, elles requièrent en “back office” non seulement une transformation technique, mais aussi culturelle de l’organisation. Satnur Kumas, consultant en architecture web, nous éclaire dans cet épisode sur les technos et les enjeux d’une telle transformation.

D : Bonjour Satnur, bienvenue ! Ce sujet semble passionnant. De quoi s’agit-il ?

S : Il s'agit d'une transformation. Au départ, les applications qui ont été conçues et développées il y a 10 ans, voir même plus sont conçues de manière isolée. Par exemple, on fessait une application pour gestion du stock, une application pour la vente de produit et ensuite on procédait au déploiement en magasin et on développait une autre application pour le disposition sur le web. Donc chacune application avaient son propre référentiel, l'ensemble de ses données et le soir il fallait propager les modifications qui ont été faites sur les modifications du stock, les commandes qui ont été faites dans la journée. On avait une synchronisation qui a été faite le soir ou pendant la nuit et tout le monde exportaient les données modifiées et importaient les données modifiées des autres. Donc il n'y avait que la nuit où les donnés reflétaient l'état exacte des choses. Et du coup on peut avoir des collisions entre ces données. Typiquement, si on prend l'exemple dans le retail, le stock dans l'entrepôt - vous recevez une commande de 100 pièces d'un produit et vous faites une promotion la dessous, les magasins en commandent 50 et sur le canal web aussi se déchaînent et profitent de la promo et en commandent 60. Vu du magasin, il y a 100 produits en stock, donc tout va bien, ils vendent les 50. Vu que sur le canal web il y a 100 produits en stock, donc s'ils vendent les 60 il n'y a aucun problème. Et c'est le soir qu'on se rend compte, qu'on a dépassé la quantité commandée. Donc chacun fonctionne de manière isolée, a sa propre vision des données, mais personne n'a cette vision globale et cohérente des données modifiées durant la journée. Alors comment on satisfait les clients qui ont commandé, mais ne pourront pas être livrés. Justement, les gens du retail ont fait une révolution pour pouvoir s'adapter à ces modifications en quasi temps réel. Avec ça ils ont permis ce qu'on appelle aujourd'hui “click&collect". Donc on commande dans la journée et on reçoit le lendemain, c'est quelques chose qui est devenu la norme aujourd'hui. Cela veut dire qu'il faut casser tous ces synchronisations des données la nuit et passer en temps réel. C'est different de relancer les mêmes traitements la nuit, car c'est une fasse bonne idée. Il faut basculer sur les architectures événementielles avec ou sans APIs et essayer de casser ces grosses applications qui ont cette vision partielle et fissurée de ces données. L'idée principale est de réduire le périmètre de chacune de ces applications là et d'avoir un seul composant qui gère une seule chose : le composant qui gère le client, le composant qui gère la commande, celui qui gère le panier, celui qui gère le stock, etc.

Ensuite, quand nous avons ces composants de base on fait des applications qui les agrègent, donc on fait les appels à ces composants là.

...

Écoutez le podcast pour découvrir ce sujet en entier.