Archives par mot-clé : Architecture du système d’information

L’écosystème des solutions pour un site marchand – Le CMS

Ce billet est le premier d’une série, ou je vais essayer de clarifier les choses, sur la façon de concevoir un “système marchand”.

On commence par le premier composant, le plus évident, mais pas forcément le plus simple : le CMS.

Tous les marchands vendent en ligne aujourd’hui, et la crise du Covid a mis en avant l’importance du canal digital.

Les marchands veulent se simplifier la vie. Ils aimeraient autant bâtir leur solution ecommerce avec le moins de composants possibles… Mais la réalité est qu’aujourd’hui, une plateforme complète n’existe pas. Les choses évoluent beaucoup trop vite, la couverture fonctionnelle est beaucoup trop large, les métiers trop différents… En fait, quelque soient les raisons, la réalité est là : pour avoir une solution ecommerce de qualité, il va falloir “faire du Légo”.

Alors, quels sont les composants clés pour un site marchand ?

Déjà, il faut bien voir que le marchand n’a pas attendu le digital pour développer son système informatique. Il y a donc très probablement un ERP, peut être un (ou plusieurs 😉 ) CRM, peut être un PIM, sans doute un logiciel de gestion logistique, des logiciels de caisses, des solutions pour gérer le SAV, … Bref, le système informatique du marchand est déjà un patchwork composé de dizaines de composants.

Le système ecommerce va donc devoir co-exister et surtout coopérer avec cet existant.

Mais revenons à nos moutons : quels sont les composants clés pour un site marchand : 

Le premier composant qui vient à l’esprit est un CMS. C’est l’outil qui va servir de base au site marchand. 

La plupart du temps, on part d’un CMS ecommerce, comme Salesforce Commerce Cloud, Proximis, SAP Hybris, Shopify

(Pour les plus petits marchands, il existe également plein de solutions, comme Wizishop, Prestashop, et bien d’autres)

Un tel outil va proposer les fonctions de bases pour un site : 

  • Gestion du catalogue des produits : gestion de l’arborescence des produits, gestion des pages produits, moteur de recherche ;
  • Gestion du compte client ;
  • Animation du contenu des pages (accueil, …) ;
  • Gestion du panier et du processus achat ;
  • Interface avec une solution de paiement (ou un PSP pour les intimes) ;
  • Gestion du suivi des commandes. 

Le CMS doit pouvoir gérer les différents terminaux d’accès : mobile, tablette ou ordinateur.

Pour peu que l’enseigne vende à l’international, il va falloir gérer le multi langue et le multi site (un site par pays). Rien que ce point mériterait un billet (ou un livre !) à lui tout seul.

Alors, vous allez me dire, il fait tout ce CMS, pourquoi avoir besoin d’autre chose ?

Bonne remarque 😉

En fait, pour quelqu’un créant une nouvelle marque, et souhaitant lancer le site marchand directement, il n’en faut pas plus (Qu’en pense Martin par exemple, de Slean ? 😉 )

Mais pour les marchands déjà établis, ou les marques de renom, il va faire bien plus :

Il va falloir en particulier s’interfacer ce CMS avec les composants existants : 

  • Interfacer la base de données Produits avec le site marchand ;
  • Interfacer le système de gestion des commandes du CMS avec le système existant du marchand ;
  • Interfacer la gestion des stocks, pour avoir les bonnes informations de stock, disponibles dans le site marchand ;

En général, la gestion des prix et des promotions est un sujet compliqué : le marchand a déjà ses outils, plus ou moins adaptés au digital. Là encore, il va falloir faire communiquer les solutions.

Le CMS doit faire tout cela en étant capable de gérer les pics de trafic. Il n’y a pas si longtemps, on comptait les sites hors service au début des soldes… Pendant la crise du Covid, on a encore vu quelques sites HS…. 

Le CMS doit être résilient : s’il y a un bug, les choses doivent être gérées de manière “souple” : on n’affiche pas le code de l’erreur interne au client par exemple….

Le CMS doit être robuste face aux attaques “pirates” : il ne doit pas être possible d’accéder, depuis le Web, aux infos confidentielles des clients.

Le CMS soit être “SEO friendly” : il doit être bien fait pour que Google référence bien les pages. Là encore, ce sujet mériterait un livre entier.

Il doit être relativement facile de faire des évolutions : changer les formats des pages, changer des textes, changer des menus…

Cela n’a l’air de rien, mais faire tout ce que doit faire un CMS, en gérant des centaines, voir des milliers d’appels à la seconde est un vrai challenge. C’est bien pour cette raison que les solutions SaaS on “gagné” le marché.

Alors, faut il forcément un CMS pour faire un site marchand ?

Bien sûr que non (ça serait trop simple). 

Il existe plusieurs alternatives : 

Il est possible de construire soi-même ce CMS. On a donc bien un CMS, mais ce n’est pas une solution du marché, on se le fait soi-même. Cette solution est aujourd’hui relativement rare, car cela demande une très bonne maîtrise technique Web. Il est toujours assez facile de faire une première version qui fonctionne “à peu près”. Faire une solution qui fonctionne dans la durée, avec tous les critères évoqués ci dessus (plus tous ceux que j’ai oubliés), cela représente un vrai gros travail. Si aujourd’hui pratiquement personne ne se risquerait à repartir de zéro, on peut par contre partir de frameworks, contenant les briques de base, pour monter son site.

Enfin, la solution à la mode est de faire un site marchand headless, mais ça, je vous en reparlerai !

Aujourd’hui, plus de 95% des sites marchands sont construits sur des CMS du marché.

 

 

Pourquoi n’y a-t-il pas d’Amazon Français ?

Mon humble réponse à cet article des Echos qui retrace la vie de quelques gros acteurs du ecommerce Français : Pixmania, Rueducommerce, CDiscount, Oscaro et Priceminister

L’analyse du journaliste, pour faire simple, c’est de dire que les finances n’ont pas suivies.

Peut être… Mais je pense qu’il y a une autre raison : la culture technique.

La force d’Amazon, c’est d’avoir monté un système d’information qui est une machine de guerre.

Le e-commerce, c’est du “techno-marketing”. Bien sûr, il faut savoir trouver les bons produits, savoir acheter, et savoir vendre… Il faut également s’approprier toute la culture spécifique du ecommerce, et ça fait un “gros morceau”.

Il faut intégrer les notions d’acquisition de trafic : SEO, SEM.

Il faut de plus développer une culture de la data : mettre en place les outils pour avoir de la donnée, et faire de l’analyse.

Mais il faut également avoir une vrai vision de l’urbanisme de son système d’information ecommerce…

C’est sur ce dernier point que, je pense, on pêche le plus.

La difficulté, c’est le passage à l’échelle.

Bien sûr, quand on démarre, il ne s’agit pas d’urbanisme. On prend des outils open source, quelques développeurs, et zou, on a un site en ligne.

Mais quand on doit traiter 100, 1000 commandes par jour, c’est une autre histoire.

Et si on veut de la croissance et de l’agilité, sans urbanisme, on est mort. Le système d’information devient une pieuvre incontrôlable, qui tient par “miracle” et que personne n’ose bouger.

ça coute de plus en plus cher à maintenir, les pannes sont de plus en plus fréquentes, et difficile à corriger…

Le problème ? Pas de vision ambitieuse de la plate forme. On bricole ce qui marche, à cout réduit. Ce qui a fait la réussite des débuts donne l’assurance qu’il faut continuer comme ça…

Alors oui, ça a bien un rapport avec les moyens financiers, mais pas uniquement.

 

Fin d’un mythe : pas de PMD universelle

Je dois le dire : je n’aime pas les promesses bidons.

La “DMP universelle” en est une.

La DMP universelle, c’est une “boite” qui va contenir, monsieur le client, toutes les données sur vos clients et prospects.

En stockant tout, vous pourrez tout faire !

Génial :

Vous allez stocker le parcours des visiteurs sur vos sites, stocker les données CRM, les données issues des magasins, des call centers…

Un peu d’algo par dessus, et vous pourrez “créer de la valeur” en proposant des scénarios futuristes…

Je n’y crois pas, car en fait, c’est justement au niveau des scénarios que ça coince :

Avec les technologies actuelles, on doit au contraire constuire la DMP en fonction de ce qu’on veut en faire.

Je prends un exemple qui concerne Target2Sell : la recommandation temps réel de produits :

On a bien une DMP pour faire ça, avec des données extrêmement variées : Web, magasin, CRM, …

Mais toute la DMP est conçue par rapport à une contrainte très forte : faire des recommandations spécialisées pour chaque visiteur, en 50 ms !

Et je peux vous dire que c’est pas une mince affaire ! 50 ms, c’est pas beaucoup… Alors on doit mettre en oeuvre tout un tas de technologies permettant de gagner du temps.

Résultat, ça marche, plutôt bien même, mais c’est pas universel.

Il ne serait juste pas possible de faire des recommandations de produits personnalisés en temps réel, en s’appuyant sur une DMP… pas conçue pour ça.

Du monobloc au légo

Quand on est une entreprise, chargé de vendre des produits par exemple, l’informatique apparait comme un outil, pas une fin en soi.

On cherche donc le moyen de simplifier les choses, d’optimiser les investissements.

Quand un éditeur vient vous promettre que sa solution fait tout, c’est cool 😉

Pas besoin d’assemblage, de nombreux appels d’offres. Un seul paquet et hop, tout marche avec tout. C’est la promesse de l’ERP, le graal du DSI.

Ce schéma est en fait un fantasme.

Dans la pratique, un seul logiciel ne peut pas couvrir tous les besoins de l’entreprise :

  • Les disparités entre les entreprises sont trop importantes
  • Les besoins, les rythmes sont trop divergeant, entre les différents services

L’ERP, le mythe des année 80, à eu la peau dure. Il en a fallu des projets, à plusieurs dizaines de millions d’euros, voir plusieurs centaines, jetés à la poubelle. Il en a fallu des entreprises tellement meurtries après un tel projet qu’elles peuvent tout juste se refaire une beauté pour se faire racheté, incapable de la moindre flexibilité.

Alors, si la solution “tout en un” ne marche pas, que faut il faire ?

La solution est en train de se dessiner sous nos yeux : du mashup basé sur des composants SaaS.

Chaque problématique doit être traité par une solution adaptée. On se retrouve donc avec un ensemble de composants.

Il s’agit donc de brancher ensemble un ensemble de briques.

L’architecture globale est très importante : il ne s’agit surement pas de brancher n’importe quoi avec n’importe quoi, on arriverait à un “plat de nouille”. Il faut “urbaniser” l’ensemble.

 

On commence à voir apparaitre des solutions qui permettent justement d’industrialiser ces assemblages. C’est dans cette direction que s’engage Lengow, avec sa nouvelle offre, permettant aux différents éditeurs de se brancher sur le “hub” proposé par Lengow.

Je suis convaincu que cette direction est la bonne. Il reste du chemin 😉

Peut on (encore) lancer une solution e-commerce ?

Combien y-a-t-il de solutions e-commerce sur le marché ? Une bonne centaine… Peut-on encore se lancer ? Bonne question. Je pense que oui, parce que peu de solutions sont réellement bien faites. Si je devais m’y lancer (je vous rassure, je suis sur autre chose), voici en vrac ce que je ferais :

  • Je mettrais les API au coeur de la solution
  • Je ne chercherais donc pas à tout faire, mais plutôt à proposer une brique, facile à brancher avec les autres éléments du puzzle (CRM, ERP, Search, …)
  • La solution serait légère, très très rapide, et permettrait donc des temps de réponses très courts
  • Le coeur de la réflexion, ça serait sans doute le catalogue, qui est, je pense, la partie la plus délicate d’une bonne solution e-commerce (déclinés, attributs variables, …). A voir le succès d’Hybris, solution qui n’est pas e-commerce à la base (c’est un PIM à la base, avant le rachat plutôt récent d’icongo).
  • Je ferais des choses simples  sur le multi site, multi langue, parce que de toute façon, c’est un sujet tellement compliqué qu’il vaut mieux proposer une base simple et évolutive plutôt que chercher à tout faire…
  • Je ferais un back-office bien fait, simple, évolutif, entièrement basé sur des API
  • La solution serait très modulaire. On pourrait ainsi n’utiliser que le front, et l’interfacer avec d’autres systèmes
  • Je serais très prudent sur les fonctions de moteurs de promos, avec là encore plutôt une logique d’API
  • Elle serait adapté au cloud, et serait nativement construite pour être répartie sur plusieurs serveurs
  • Elle serait très probablement en grande partie basée sur du NoSQL

Sur ce mini cahier des charges, on voit bien qu’on peut encore y aller… Mais quels sont les clients qui seraient intéressées par un tel produit ? Il faudrait faire un gros travail pour mettre en avant les avantages métiers qu’apporterait une telle solution…. Et vous, elle serait comment l’architecture de votre solution e-commerce de vos rêves ?

Des couches avec des API pour avoir une vie plus douce

ça c’est du titre, non ? 😉

Un système d’information e-commerce pour un site ayant de gros volumes gère des sujets très variés : relation client, site e-commerce, logistique, processus de commande, gestion des stocks, comptabilité…

Il n’est pas question de tout mettre dans un seul paquet. ça, ça marche en mode “garage”, quand on démarre.

On va donc avoir plusieurs modules, chacun chargé de géré en ensemble “cohérent” de fonctions.

La bonne approche consiste à définir des API métiers pour échanger les informations entre les modules.
Il faut bien voir qu’une API, c’est bien plus riche qu’une base de données.
Une API, c’est un ensemble de fonctions, qui, ensembles, donne une vue sur un module donné.

L’interface API ne doit pas être un mapping direct de la base de données (sinon, ça ne sert à rien, autant se brancher sur la base).
Il faut faire un vrai travail “métier” pour définir la vue… métier justement.

Il faut faire des ateliers, avec quelques interlocuteurs internes métiers, pour définir cette vue (pas trop de monde non plus, sinon, on rentre en “réunionite”)

De mon expérience, il est important de définir cette vue non pas à partir de ce que fait le programme, mais à partir d’une vue idéale sur un sujet donné.

Si, par exemple, on cherche a définir la vue Client, on va se poser toutes les questions sur ce qu’est un client, vu du SAV, du service avant vente, vu comme un client pour un magasin ou un client vu du site e-commerce, vu de l’équipe chargé des programmes de fidélité, …

Ensuite, bien sûr, il faut faire le mapping entre l’API et ce qu’on a “en magasin”. On peut bien sûr avoir des cas ou on demande plus que ce qu’on peut faire. L’API n’est pas forcément réalisable a court terme, avec les modules actuels.

Je pense que c’est normal d’être dans cette situation, et c’est même relativement sain. Cela donne une vision “moyen terme” de ce qu’il faut construire.

L’API doit quand même être utilisable rapidement, et pour ça, on se débrouille : certaines fonctions ne sont pas implémentées (“not yet implemented”).

Mais la plupart du temps, on trouve un moyen pour collecter les données, quitte à aller chercher les informations sources dans plusieurs modules.

Voilà, c’est tout pour aujourd’hui. Il est tard (et oui, les billets sont écrit le soir et programmés, merci WordPress 😉 ). Mais il y aura bien sûr d’autres billets sur ce thème, parce que c’est un sujet majeur, sur lequel il y a beaucoup à faire de mon point de vue 😉

Je me rends compte que le billet ne répond pas vraiment au titre : on ne voit pas vraiment pourquoi on va avoir une vie plus douce ;). ça sera donc l’occasion de faire une suite !