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

Prestashop 1.6

Petit teasing sur Prestashop 1.6 :

ça a l’air bien sympa tout ça 🙂

Bon, je ne peux pas m’empêcher de vous rappeler que Target2Sell est très facile à installer sur toutes les boutiques prestashop, et que ça permet de gagner en performance commerciale (taux de transfo, montant du panier…). Déjà plus de 20 boutiques en ligne 🙂

Question clé : le passage de la 1.5 à la 1.6 pourra-t-il se faire sans douleur ? A suivre !

Du mille feuille au « one stop shop »

Quand on veut bâtir une solution e-commerce, on a finalement le choix entre deux extrémités :

  • Soit on cherche un acteur polyvalent, qui va vous proposer du « all in one », c’est également ce qu’on appelle le « one stop shop ». Si on prend l’analogie avec le bâtiment, c’est le constructeur de maison. Pas besoin d’architecte, pas besoin d’aller chercher des artisans. Un seul acteur fait tout.
  • Soit on fait soit même sa « liste de course », et on choisi, item par item, les bons composants.

Si on n’a pas de temps, qu’on n’y connait pas grand chose, le « one stop shop » est bien sûr très tentant.

construction-maison-laon

La photo est attrayante, il y a tout ce qu’il faut, et pas besoin de s’embêter avec tous les détails…

Mais si on veut « the best of bread », il faut faire son marché !

bread-534x356

Bien sûr, ça prend plus de temps, il faut comprendre comment les différentes briques interagissent entre elles, les fonctions de chacune, les différents fournisseurs, …

Comprendre les différence entre ce que proposent les fournisseurs est difficile… et prend du temps. Mais c’est le prix de l’excellence !

Autre sujet important : en composant son « mille feuille », il faut bien valider que le prix total est bien raisonnable et bien compatible avec son activité.

Il ne faut donc pas se tromper de brique !

Bon courage 🙂

 

Pré production et data stagging

Sur un site un peu pro, on a deux versions (au moins) :

Une version en production (le site en ligne) et une version en préparation, appelée pré-production.

La version de pré production permet de tester les évolutions qu’on fait sur le site.

Vous demandez une nouvelle fonction, l’équipe technique réalise l’évolution, et envoie ça sur la pré production.

Cela permet de voir ce que ça donne et de valider que ça fonctionne bien.

Pour bien faire ça, il faut que la pré production tourne sur une configuration pratiquement équivalente à celle de production.

L’une des grande difficulté est d’avoir un environnement et des données équivalentes entre les deux environnements. Sans entrer dans les détails, cela coute cher et c’est compliqué à faire…

Bon, ça, c’est pour la partie logicielle, applicative.

Maintenant, on a besoin d’autre chose pour bien travailler, c’est le data stagging.

Le data stagging, c’est un peu la même idée que la pré-production : pouvoir tester en condition quasi réelles des modifications, mais ici, il ne s’agit pas de modifications faites sur les programmes mais sur les données.

Exemples : vous préparez le catalogue de la rentrée, vous mettez à jour les éléments marketing du site, vous préparez des éléments de merchandising (promotions, bannières, …).
Le data staging permet de tester tout ça dans un environnement équivalent à celui de la production, mais sans prendre le risque d’impacter le site en ligne.

Il y a plusieurs façon de faire du data stagging. On peut faire du data stagging logique : tout se fait sur le site en ligne, mais les données sont « dupliquées » entre les deux environnements : la production et le data stagging.
L’autre approche est physique : on crée physiquement deux versions du site, avec des mécanismes de synchronisation entre les sites.

Sans data staging, on est en « direct live » : on fait des modifications, et on regarde sur le site ce que ça donne.

Enfin, une autre solution est de faire ce que fait Apple : fermer le rideau.

apple-store-down

C’est une alternative intéressante, car elle évite la mis en place du data stagging, et permet de tester une mise en ligne avant de la proposer aux internautes.

Finalement, les meilleures solutions sont rarement les plus compliquées 😉

Prestashop : Go Go Go !

J’ai entendu, ou plutôt lu, par ci par là, des critiques plutôt sévères à l’égard de Prestashop.

Je ne me sens pas en phase avec ça !

Bien sûr, Prestashop n’est pas parfait, et la direction n’a pas toujours pris les bonnes décisions.

Et oui, c’est vrai, la nouvelle direction a décidé de réduire les effectifs.

Mais, quand vous connaissez les choses de près, le revers du décors, vous en connaissez beaucoup de boites ou tout est parfait ?

L’entrepreneuriat, c’est fait d’essais / erreurs. Après, certains font croire qu’ils avaient tout calculé… La vie d’une entreprise n’est jamais un long fleuve tranquille.

Par exemple si on parlait de Magento, on pourrait en dire des choses, sur la non focalisation, ou d’autres histoires pas toujours claires.

Donc Prestashop :

C’est une très bonne solution, plutôt bien faite, plutôt bien adapté pour mettre en ligne des boutiques, plutôt souple pour correspondre à pas mal de cas.

Pour de petites boutiques, la solution est très bien, facile et légère a installer.

Pour de plus grosses boutiques, Prestashop peut se brancher par dessus un système d’information interne, et ça tourne très bien.

La boite avance, et qu’ils aient décidé de simplifier le contour fonctionnel de la solution est de mon point de vue un très bon signe.

Si vous me lisez, vous savez que l’un de mes motos est : focalisation.

Donc, Prestashop : GO GO GO

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 🙂