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

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 !