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 !

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedIn

2 commentaires

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *