Archives par mot-clé : API

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 !