Archives par mot-clé : Système d’information e-commerce

Keynote RBS Change

Je vous ai parlé la semaine dernière, RBS est un éditeur de solution e-commerce.

Aujourd’hui, RBS a organisé une présentation, avec pas mal d’actualité.

Voici quelques notes :

Le produit existe depuis 7 ans, 200 clients
Le produit cible des sites « moyen à grand », B2B & B2C
Cross canal, International
Avec des besoins CMS
Le modèle, c’est un coeur gratuit, et des extensions payantes : 20 extensions payantes, de 500 à 8000 € l’extension, plus une maintenance de 20% par an
Les partenaires : NBS en particulier, hébergeur spécialisé dans le e-commerce, avec une offre Magento, Prestashop et RBS Change donc
Références : Aubert, Phox, Rossignol, Manfield, …
Une offre packagée pour les partenaires, avec formation, accès au help-desk, 20% de commission sur les licences : 8995 €
Partenaires intégrateurs : Smile, Synolia, Bysoft, …
Focus sur Smile justement : Smile met en avant la rapidité de l’outil, la qualité (modularité en particulier) : 10 développeurs formés, 2 projets menés à terme et un en cours (Solaris, Ma boutique Régime Dukan)

Annonce de la V4 !

Objectif : devenir leader mondial d’ici fin 2015 sur son segment de marché
Core : 30% plus compact
Respect des nouveaux standards du marché (PSR-0 et 1)
Mise à jour des designs patterns
API simplifiée
PHP 5.3 – 5.4
Basé sur Zend Framework 2 !!!
Disponible sur Github
Qualité vérifiée via Travis-ci
Documentation en anglais
Ouvert aux contributions externes
Le Back office de la V3 est sur XUL (propriétaire Firefox), le nouveau back office est en HTML5
Avec une interface responsive, qui permet de gérer le back depuis une tablette

Copie d’écran du nouveau back office :

Fonctions avancées pour l’international : instances pilotées (super 🙂 )

Date de sortie : Q2/Q3 2013 (un peu de patience 😉 )
Garantie du support éditeur de la 3.6 jusqu’en 2015

Et voilà, c’est la fin de cette présentation !

RBS Change – Solution e-commerce open source évoluée

La brique e-commerce est évidemment un élément clé du système d’information e-commerce !

Vous ne connaissez peut être pas RBS Change, et c’est une erreur 😉

RBS Change est une solution e-commerce, open source, portée par un éditeur français.

La solution est intéressante parce que construite par une équipe expérimentée.

A la base (2005), RBS avait de l’expérience dans le CMS, et la solution a donc ces éléments là dans ses gènes.

Un CMS avancé, cela permet, outre bien sûr l’édition de pages, de gérer des notions avancées comme des droits d’accès au back office, du workflow, de la gestion de version…

Le workflow par exemple est une fonction très importante dès qu’on sort du mode garage :

L’idée c’est de définir des rôles pour les personnes qui vont animer le site. Ensuite, on peut définir, justement via le gestionnaire de workflow, des étapes, permettant d’aller de la création à la mise en ligne d’un élément du site.

Exemple : une personne A crée un contenu, et c’est une personne B qui doit valider ce qui a été fait et qui a la responsabilité d’appuyer sur le bouton GO.

A partir de ce CMS, RBS change a fait évoluer les choses en prenant le virage du e-commerce (2007).

Par la suite, la solution a encore pas mal évoluée, avec la réécriture du coeur pour avoir une solution plus efficace, puis enfin le changement de modèle, avec un coeur en open-source et une vrai stratégie d’éditeur.

Petit détail qui a son importance : la solution possède un module SOLR qui permet d’enrichir le moteur avec les fonctions de navigation à facette et la recherche avancée, tout cela parfaitement intégrée dans la solution.

Aujourd’hui, la solution en est à la version 3.6.2.

Vous pouvez la tester directement sur le site de RBS.

Cette solution est plutôt stable, et motorise de beaux sites e-commerce.

Le modèle de licence est de ne rien payer pour le coeur de la solution et de payer pour les modules périphériques.

Tout cela est déjà très bien… Mais en plus, RBS va faire des annonces mardi prochain.

Que va proposer RBS ? Une nouvelle release ? Des innovations technologiques ? Stay tuned 😉

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 !

Prestashop a sorti la nouvelle version 1.5 !

Prestashop édite une solution e-commerce open source.

PrestaShop 1.5

Cela faisait plusieurs mois qu’on attendait ça : la sortie de la nouvelle version 1.5.

Et bien c’est fait, la version est disponible au téléchargement, ici.

Quelques nouveautés, parmi une liste bien pus longue :

Le multi boutique
L’intégration de thèmes mobiles
Un back office entièrement redessinée
Gestion des commandes partielles
…

Un enjeu important sera la migration des modules de la 1.4 vers la 1.5, modules qui font la richesse de la solution.

Bravo à Prestashop en tout cas, j’ai hâte de tester ça 🙂

Et vous pouvez également passer les voir au salon e-commerce :).

L’actualité riche de Wizishop

Wizishop est une solution e-commerce en mode SAAS.

La solution permet de faire de bonnes boutiques en lignes, avec un bon rapport qualité prix.

Wizishop a sorti plusieurs évolutions intéressantes :

Processus de paiement en une étape : Smart Check-Out
Une solution de gestion de campagnes SMS
La refonte des sites pour les mobiles

Le processus de paiement est intéressant, très riche fonctionnellement (paypal access, Facebook registration, traitement « intelligent » des erreurs du formulaire, …)

Le plus simple est de l’essayer sur la boutique de démo : http://www.demo-wizishop.com

Vous pouvez bien sûr aller les voir au salon e-commerce, je suis sûr qu’ils seront très content de vous montrer tout ça 🙂

Assistons nous à un changement d’ère au niveau du e-commerce ?

Je lis ici et là que le e-commerce est en train de changer, de muter.
On passerait sur un mode « industriel » à mettre en opposition du mode des pionniers, des explorateurs.

Alors, c’est vrai, le e-commerce est sur certains points de vue mature. Le fait que des millions de personnes achètent en ligne en est le signe le plus visible, le plus évident. Le e-commerce génère des milliards d’euros de chiffre d’affaires, et on prévoit 1000 milliard € de chiffre d’affaires en 2013 !

Donc, de ce point de vue là, on est effectivement sur un marché mature.

Marché mature qui va poursuivre sa croissance, il suffit de voir les leviers permettant d’assurer la croissance pour les années à venir :

Part de marché des gens connectés ;
Part de marché des clients, il reste de la marge,
Habitudes des clients (nombre de commandes annuelles),
Sans parler de l’évolution des usages, avec les mobiles, les tablettes.
Largeur de l’offre : 100 000 sites en france, 200 000 en Angleterre….

Donc, même dans un contexte particulièrement tendu, le e-commerce va encore croitre.

Maintenant, on est toujours sur un terrain très mouvant ; les choses évoluent très très vite :

Au niveau technique :

Le web évolue toujours très vite, tiré par les innovations proposées par les éditeurs de navigateurs (Google, Microsoft, Apple, Mozilla).
Les terminaux pour accéder au web sont également en évolution, dopée aux hormones de croissances, avec la compétition mondiale et féroce que se livrent les grands fabricants : Google, Apple, Amazon, Samsung.
Les technologies serveurs : il suffit de voir à quelle vitesse se développe une offre, au niveau mondial, pour bien prendre conscience de l’immaturité des offres. Un bon développeur peut sortir un produit bien fait en quelques mois, et le diffuser au niveau mondial… Sans parler de l’évolution accélérée des socles de développements. Aujourd’hui, on demande aux développeurs de faire à la main le codage de l’ensemble des couches, logique métier, présentation, sans environnement de production au niveau de ce qu’on faisait il y a quelques années… Si on est en régression sur ce sujet, c’est que les choses bougent trop vites.

Au niveau des usages : avec le développement d’acteurs comme Facebook, Pinterest, Twitter, qui, en quelques mois deviennent des acteurs mondiaux et changent les usages des internautes.

Donc, les choses changent vites, tant au niveau technologie qu’au niveau des usages.

Le e-commerce doit donc répondre à une situation paradoxale :

Il s’agit de mettre en place un système d’information e-commerce industriel, capable de :

Supporter des gros volumes, des pics de trafics,
Gérer un volume important de transactions, de manière fiable et 100% sécurisé
Gérer des catalogues complexes, riches
Gérer un système d’information e-commerce en lien avec une constellation d’autres briques métiers : gestion des stocks, logistique, transport, relation client, …

Et dans le même temps, ce même système d’information doit être souple, doit permettre des mises à jours faciles et rapides, de manière à suivre les évolutions des usages et techniques.

Ce paradoxe est réellement complexe à gérer. Dans tous les cas, il ne peut pas être traité à la légère il demande de la part des gros acteurs une maturité sur ce qu’est un système d’information e-commerce, maturité qui n’est pas très répandue (architecture SOA, méthodes « réellement » agiles, …)

En fait, je pense que la plupart des boites qui veulent réellement réussir, à long terme, sur le e-commerce, doivent intégrer dans leurs gènes que le système d’information e-commerce n’est pas une charge qu’on subie mais plutôt un actif à construire et cultiver.

Les boites doivent apprendre à gérer et capitaliser sur les équipes techniques : à recruter les meilleurs, les payer à la hauteur de leurs responsabilités, les manager de manière adéquate. La meilleure façon de faire du logiciel, c’est l’hyper responsabilisation de chacun. C’est le contraire du Taylorisme…

Les boites doivent définir une stratégie claire, ou l’on défini ce qu’on fait en interne et ce qu’on externalise. Le SAAS va jouer à l’évidence un rôle clé dans les années à venir…

Bref, il s’agit d’une véritable révolution, qui, parce qu’elle touche à l’humain et à l’ADN des boites, prendra du temps.

Les différents niveaux des interfaces back office

Vous voulez qu’une fonction soit paramétrable, qu’on puisse la modifier, simplement.

Il y a plusieurs niveaux d’interfaces.

Le niveau le plus haut, celui que vous avez sans doute en tête, c’est une vrai interface : une page, avec des champs pour éditer les différents paramètres, et des boutons, pour valider, tester, annuler.

Le deuxième niveau, c’est une interface technique : cela ressemble, mais l’interface n’est pas clean : elle a été faite rapidement, peut être même automatiquement. Elle permet bien de paramétrer la fonction, mais la prise en main de l’interface est moins intuitive.

Le troisième niveau, c’est une interface via un fichier de configuration. Un fichier, XML par exemple, permet de régler des variables. C’est très efficace, mais il faut comprendre la syntaxe du fichier de paramétrage. Pour peu que sa structure soit peu intuitive, et c’est pas si simple que ça.

Le niveau suivant, c’est de modifier le code… Si la fonction est bien codée, c’est pas forcément si compliqué, mais il faut savoir coder.

On a donc quatre niveau d’interface.

C’est important de bien comprendre tout ça, et, a chaque fois qu’on veut que quelque chose soit paramétrable, de se demander quel est le niveau qui doit être défini. Tout n’a pas besoin d’être au niveau le plus haut. Exemple : définir le nombre de produits affichés sur une page liste. Cette contrainte évoluera peu, peut être même jamais. Mettre une telle info dans un fichier de paramètre est sans doute une bonne idée.

La page produit, c’est simple…

Rien de plus simple qu’une page produit !

Pourquoi se « faire des noeuds » pour rien ?

C’est :

Un nom de produit
Un texte de description
Quelques photos

Le produit est rangé quelque part, dans une catégories.

Voilà, fin du débat.

Heu, c’est un peu court…

Un produit peut être déclinable, en taille, en couleur, et en tout un tas d’autres choses (motif par exemple).

A-t-on une fiche produit par déclinaison ou est-ce la même fiche produit pour toutes les déclinaisons ?

Au fait, le stock, c’est pour une déclinaison…

Et puis pendant qu’on y est, le prix, il peut varier en fonction de certains critères.

Ah, ok.

Et c’est pas fini : a-t-on une seule page pour toutes les déclinaisons ?

La question est simple mais pas la réponse.

Cela dépend des cas.

En général, on a bien une seule fiche produit pour la déclinaison en taille. Pourquoi ? Parce qu’il s’agit d’une variable « technique », qui n’a pas de valeur sur les pages listes par exemple.

Mais ce n’est pas forcément le cas pour d’autres critères, comme une déclinaison par couleur. Suivant les cas, il peut être intéressant d’avoir une fiche produit spécifique par couleur, avec une URL et donc un référencement spécifique. Si le client cherche un pull rouge, c’est pas mal que cette page remonte chez google, non ?

Oui mais si on a 30 couleurs de pull, vous imaginez la tête des pages listes, qui vont être remplies de toutes les déclinaisons de couleur ?

Sur cet exemple, on voit bien que cette simple question a des réponses riches, pour un même site.

Et je n’ai pas parlé du moteur de recherche interne au site, qui doit permettre d’aller directement sur la bonne fiche si l’internaute cherche « pull rouge ».

Et si je reviens sur les tailles, on peut aussi bien améiorer l’expérience client, en permettant des filtres sur les tailles dès les pages listes. Exemple : je ne cherche que des chaussures en 43. ça serait pas mal que, quand je clique sur la chaussure qui me plait, j’arrive directement sur la chaussure en 43, non ?

bon, j’arrête là, parce que, normalement, vous avez compris mon idée : une page produit n’est pas simple du tout ! C’est même réellement un « objet » complexe.

Et je n’ai pas parlé de personnalisation, d’attributs variables, de comparaison de produits, …

Bref, le produit, c’est un monde… un monde modélisé d’ailleurs par des logiciels, qu’on appellent des PIM : Product Information Management. Si je devais concevoir un système e-commerce, je commencerais par là ;).

Prestashop optimise la version 1.4 et prépare la suite…

Prestashop vient de sortir une toute dernière version de la solution e-commerce.

Ce n’est pas une release majeure, on sait tous que la prochaine version importante, c’est la 1.5, qui est en préparation…

Cette version semble tout à fait intéressante, en ce sens qu’elle apporterait un gain de performance tout à fait significatif.

Quand on sait l’importance d’avoir des boutiques qui répondent vite, ce graphique donne envie d’essayer, non ?

Voir l’article complet sur le blog de prestashop, avec la liste des améliorations, et pleins d’autres infos, en particulier sur la procédure pour migrer vers cette version.

Infographie – API et e-commerce

Les API, c’est un élément majeur d’évolution, en interne pour les systèmes d’informations, et en externe, pour brancher les sites et les services entre eux.

Voici une infographie pour avoir quelques repères sur ce thème :

Via Get Elastic Ecommerce Blog