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

L’inévitable changement de stratégie de Magento ?

Magento a commencé par être une solution 100% open source.

Puis une première licence payante est arrivée (Magento enterprise).

Une deuxième licence payante à suivie (Magento professional).

Magento a réalisé une grosse levée de fonds… On imagine bien que les investisseurs demandent à ce que les revenus rentrent… rapidement.

De la à imaginer que la version gratuite soit délaissée progressivement, il n’y a qu’un pas.

Un des experts Magento, avec qui nous avons échangé sur le sujet, me disait que c’était un avenir plus que plausible…

Dans ce cas, on pourrait imaginer une branche open source, gérée par la communauté.

Hum, un produit aussi riche et complexe que magento peut il bien évoluer sans le support d’un éditeur ?

A suivre en tout cas. Peut être plus d’info lors du prochain bargento, le 8 Novembre ?

Sans moi pour le coup, je serais « dans le sud 😉 ».

Demandware en France

demandware a donc ouvert en France.

Ils réalisent déjà une bonne part de leur chiffre d’affaires hors des US (pls de 30%), mais principalement en Allemagne et en Angleterre. Il était donc temps de corriger le tir.

La stratégie de Demandware est de venir en direct. Il y a donc une société Demandware SA, dirigée par William Tamaloust.

Cette entreprise aura sa propre force de vente, avant vente, et support après vente.

Demandware est une solution à suivre de très près : c’est une solution réellement innovante, qui a fait ses preuves auprès de très belles références.

La solution est étonnante, je ne connais pas d’équivalent.

D’abord, elle est « full SAAS ».

C’est donc Demandware qui héberge la solution, et garantit tant les opérations quotidiennes que les mises à jours.

Mais, et c’est là la véritable innovation, la solution est complètement personnalisable !

Je ne parle pas d’un simple paramétrage, via un back office. Demandware propose nativement des API complètes et un studio (dérivé d’Eclipse), pour étendre et adapter Demandware à tous les besoins spécifiques.

Inspiré par Salesforce, la solution peut également être étendue, via ses mêmes API, par des éditeurs tiers (place de marché de composants complémentaires).

J’ai passé un bon bout de temps avec les équipes, et j’ai pu jouer avec tout ça : réellement bluffant !

A suivre, je vous dit !

Autres articles sur le sujet :

Lengow bouge vite et publie sur Facebook !

Lengow a besoin d’une vue sur le catalogue du site, et, à partir de cette vue, aide à publier les bons produits sur les moteurs de shopping.

Mais, une fois qu’on a le catalogue, et si on est agile, on peut enrichir la solution rapidement, et augmenter assez vite la couverture fonctionnelle, et donc la valeur ajoutée du service pour le client…

C’est ce que fait Lengow, en ajoutant (encore !) une fonctionnalité : la possibilité de publier tout partie du catalogue vers Facebook :

Bravo à Lengow pour son dynamisme.

Recherche temps réel

Sur un article lu récemment, j’ai appris que Google serait en train de tester une nouvelle fonction, permettant d’afficher les résultats de recherche au fil de la saisie de l’Internaute :

Intéressant. Et on voit bien que cette fonction est bien complémentaire de l’autre fonction temps réel, visant à proposer les mots à chercher, à partir de ce que tape l’Internaute.

Cela concerne bien évidement le e-commerce, d’abord parce que toute modification faite par Google impacte l’acquisition de trafic.

L’autre impact pour le e-commerce, c’est bien sûr la mise en oeuvre de ce type de fonction pour le moteur de recherche interne au site.

Je suis prêt à parier que l’impact serait positif en terme de taux de transformation.

Problème intéressant : quelle techno permet de mettre en oeuvre facilement cette fonction ? Fredhopper ? Antidot ? Endeca ?

(info trouvée sur 01.net)

Présentation d’Avail Intelligence, par son président

Avail Intelligence est une solution qui crée des liens entre les produits, pour faire, automatiquement, du cross selling.

Le mieux est de laisser son CEO en parler :

Référence notable en France : La Redoute.

Magento / Prestashop : quelques chiffres

C’est une assez bonne façon de comparer les solutions : comparer quelques éléments de volumétrie.

	Magento	Prestashop
Nombre de tables en base de données	229	135
Nombre de fichiers PHP	5 840	977
Volume des fichiers PHP	44,4 Mo	7,9 Mo
Fichiers de configurations XML	773	0
Volume des fichiers XML	14 Mo	0
Nombre de fichiers de templates	0	155

Cela confirme bien que Prestashop est bien plus léger que Magento.

Au niveau des tables, la différence n’est pas énorme (moins d’un facteur 2).

Par contre, au niveau du code, il n’y a pas photo, avec plus de 5 fois plus de code pour Magento.

Cela veut dire plus de source d’erreurs, besoin de plus de ressources pour exécuter Magento, plus de temps, plus de complexité.

Alors ?

Alors, pour choisir, il faut prendre le temps de bien analyser la situation du projet.

Quand le projet le justifie, Magento est une très bonne solution.

Mais si vous avez peu de moyens, si vous n’avez pas une forte maîtrise technique, alors oubliez Magento et faites une belle boutique, avec Prestashop.

Heu, d’ailleurs, si vous n’avez pas de ressource technique, les solutions type Oxatis, Powerboutique, 42Stores, RentAShop sans oublier Wizishop… sont de très bonnes solutions pour démarrer sans perdre trop d’argent au lancement.

Modifier la commande… Après sa validation ?

Vos clients passent commande sur le site.

Tout va bien… Sauf que les clients sont joueurs ;).

Un premier voudra modifier son adresse de livraison, après avoir passé la commande.

Un deuxième voudrait bien supprimer l’un des produits commandé.

Un troisième souhaitera ajouter un produit complémentaire…

Ces inocentes demandes doivent trouver des réponses (ou pas), et cela va impacter le site, mais également le système d’information sous jacent.

Commençons par le site.

Comment le client va-t-il pouvoir modifier sa commande ?

La solution la plus simple est de lui proposer un moyen de contacter le service client, mail ou téléphone, et de laisser ce service régler, avec le client, la modification de la commande. Dans ce cas, la modification doit pouvoir au moins être faite dans le back office.

L’autre solution, c’est de proposer la modification de commande en ligne. C’est ce que fait Amazon :

Au passage, je vous laisse apprécier mes derniers achats 😉

Bon, revenons à notre sujet.

Cet écran est intéressant. En fonction de l’état de traitement de la commande, les options proposées sont différentes.

Si la commande est en cours de préparation, on ne peut plus rien modifier :

Sinon, on dispose de tout un tas d’options :

Amazon propose donc de :

Changer le mode de paiement
Supprimer des articles
Changer le mode de livraison ou l’adresse de livraison

L’idée proposée par Amazon est finalement assez simple :

Soit la commande n’est pas descendue dans le système logistique, et elle peut être modifiée, soit elle est dans le système logistique, et dans ce cas, elle ne peut plus être modifiée.

Quelques mots sur cette interface web de modification de commande :

Cette fonction n’est pas très simple à mettre en oeuvre, mon conseil est de ne pas se précipiter dessus… Surtout pour un site ayant de faible volumes. Le contact, mail ou téléphone est une solution qui a fait ses preuves ;).

Cette fonction en ligne prend tout son sens pour les gros sites, puisque c’est un moyen d’apporter un service de meilleur qualité, sans faire exploser la taille de l’équipe relation client.

Autre point intéressant :

Quand fait on descendre la commande dans le système logistique ?

Ce qui est certain, c’est que, si on n’a pas tous les produits en stock, cela ne sert à rien de descendre la commande.

Maintenant, dans le cas ou on dispose de tous les produits, quelle est la meilleure option ? Descendre la commande le plus tôt possible ou temporiser un peu, de manière à laisser au client le temps d’éventuellement modifier sa commande ?

A voir, au cas par cas, en fonction de vos produits, de votre système logistique.

On est en effet dans le domaine du compromis : vaut il mieux laisser au client le temps de changer d’avis, ou vaut il mieux envoyer la commande le plus rapidement possible ?

Je pense que, dans bien des cas, la priorité doit être à la vitesse de livraison.

Les gros projets qui font plouf !

Pourquoi les très gros projets Internet sont souvent des échecs ?

On entend régulièrement parler de projets, ou le prix était de plusieurs millions d’euros, et qui se sont mal terminés… très mal pour certains.

Dernier exemple en date : France.fr.

Comment est-ce possible ?

Ou est le « bug » ?

Si on compare avec le bâtiment, cela ne se passe pratiquement jamais comme ça.

Bien sûr, dans le bâtiment, les délais dérapent, les prix aussi… Mais le truc se monte, et bon, on arrive à un bâtiment qui souvent correspond à peu près à ce qui était demandé initialement.

Alors, pourquoi n’en est-il pas de même avec le software ?

Je pense que le coeur de la réponse, c’est la jeunesse de cette industrie, et donc les erreurs de jeunesses, de la part de … plus ou moins tous les acteurs impliqués.

Le client :
Il ne connait pas forcément la différence entre une demande raisonnable et une demande extrêmement complexe. Alors que, pour reprendre notre analogie avec le batiment, certaines demandent seraient balayées dès leur expression (« je veux une piramide à l’envers : heu, non ! »)
Il n’a pas non plus forcément conscience qu’on ne peut pas faire évoluer les demandes au fil de l’eau, pendant les développements.
Enfin, il ne va pas forcément s’adresser à la bonne adresse. Il va s’adresser aux plus gros cabinets de conseils, ou aux très grosses SSII.
Ces sociétés ne sont pas spécialisés sur Internet, et finalement, n’ont pas réellement l’expertise technique nécessaire.

La société en charge du projet :
Comme je l’ai dit plus haut, c’est bien souvent une très grosse boite, de conseil ou d’informatique.
Elle n’est pas particulièrement spécialisée sur les architectures Internet.
Elle va donc appliquer des méthodes inadaptées.
Et le problème avec l’informatique, c’est que les erreurs de conceptions, on les voient bien souvent à la fin du projet…

Et voila, c’est simple finalement :
Le client et le prestataire appliquent des recettes inadaptées.

Le web est neuf, il faut travailler avec des boites pointues, des spécialistes.

Mais bon, aucune chance que cet article change les choses, puisque de tels décideurs ne sont pas lecteurs de ce type de blogs.

Et les rares à lire ces lignes savent déjà ce que je viens de dire 😉

Apprendre à utiliser Prestashop, pas à pas

Je viens de parcourir un bouquin :

C’est une bonne solution pour prendre en main Prestashop, de l’installation jusqu’à l’ouverture de la boutique.

Ce livre permet de passer en revue les principales options proposées par Prestashop.

Comme son titre l’indique, il ne s’agit pas d’un livre pour les programmeurs…

Bonne lecture !

2 ans avec Magento, l’expérience Brand Online Commerce

Cet article est écrit par Christophe Davy, dirigeant de Brand Online Commerce, qui est « l’invité permanent » de François sur ce blog.

La plateforme e-commerce Magento est un véritable phénomène (de mode ?) sur le marché, tout le monde en veut, tout le monde en fait.

J’entends le mot « magento » dans la bouche de tout le monde, y compris parfois chez des dirigeants qui ne sont pas censés en connaître l’existence. Toutes proportions gardées, je trouve des similitudes avec la façon dont est vu SAP dans les entreprises. Pour plagier l’ami Seguela, « si tu ne diriges pas une entreprise utilisant SAP avant 50 ans, c’est que tu as raté ta vie ». Et maintenant, « si tu n’as pas mis en place un e-commerce avec Magento avant 50 ans, c’est que tu as raté ta vie ».

J’ai donc voulu apporter un témoignage concret et issu d’un vécu quotidien, en l’occurrence celui de mon entreprise Brand Online Commerce. Brand Online Commerce est sur le marché du e-commerce délégué, elle opère la chaîne de valeur du e-commerce pour le compte de marques haut-de-gamme (beauté, mode, luxe). Des sites comme narscosmetics.co.uk, sequoiaparis-usa.com, sergelutens.com ont été créés et sont gérés au quotidien par Brand Online Commerce.

Tous nos sites ont un point commun, ils tournent sous Magento.

Nous avons choisi Magento à l’été 2008, à la création de l’entreprise. Ce choix, que je considère comme très judicieux, a été réalisé avec l’ami François (le taulier du blog sur lequel vous êtes en train de me lire).

Pourquoi judicieux ? Parce que nous avons systématiquement une problématique internationale dans tous nos contrats. Nous gérons ainsi 3 boutiques en Europe pour les cosmétiques Nars avec 2 langues et 2 devises, 5 boutiques pour Sequoia Paris (4 langues et 1 devise en Europe, 1 langue et 1 devise aux US), etc…, etc…

Dans un tel contexte, Magento répond efficacement à notre besoin. Une fois le set-up technique bien fait, on peut facilement (oui, le set-up est « long », mais après la maintenance est « facile ») gérer le catalogue produit en lui appliquant toutes les contraintes inhérentes à un e-commerce international, et notamment :
– une gestion de prix différents pour un même produit par langue et/ou par pays,
– dans une ou plusieurs devises,
– une gestion de l’affichage du catalogue par langue et/ou par pays (tel produit disponible au UK ne l’est pas en France),
– des listes de best-sellers différentes par langue et/ou par pays,
– des règles de discount, gift with purchase, free shipping différentes selon des critères classiques (liste de SKU, seuil de commande, offre ciblée sur une référence,…) croisés avec les langues et/ou les pays (free shipping à 80£ sur telle boutique, et à 100 € sur telle autre, et pas de free shipping sur une troisième).

A titre d’illustration, on retrouve une partie de ces contraintes exprimées dans les blocs promotionnels actuellement en place sur les site Nars Cosmetics en Europe :

Ma comparaison avec SAP, encore une fois toutes proportions gardées, vaut aussi sur un autre point : un programmeur met beaucoup de temps à faire le tour de Magento, et il lui faut plusieurs mois (mois, pas semaines) pour être vraiment opérationnel. Magento est tellement complet et paramétrable, que la montée en puissance d’un programmeur se fait nécessairement module par module. Je ne parle pas du simple fait d’apprendre comment cela marche en théorie, mais d’être compétent jusque dans la maintenance et dans le fonctionnement au day-to-day des différentes mécaniques techniques.

Par exemple, la maîtrise des règles de gestion des promotions est en soi déjà une compétence longue à acquérir. Il ne m’étonnerait donc pas de voir, avec la montée en maturité de l’écosystème Magento, les programmeurs Magento se spécialiser sur tels ou tels modules de Magento. Exactement comme pour SAP, où les experts sont toujours spécialisés sur des modules, jamais sur la totalité de la solution.

Quant à « l’Apple Store » de Magento, Magento Connect, il contient aujourd’hui 2500 applications… Qui peut dire « je les ai toutes auditées, et je sais ce dont j’ai besoin » ? Chez Brand Online Commerce, comme je pense chez tout le monde, on ne passe pas assez de temps à regarder ce qui est proposé sur Magento Connect. Là aussi, je me demande si l’on ne verra pas émerger prochainement un nouveau type d’acteur dans l’écosystème Magento, le consultant-programmeur chargé d’auditer les besoins et de repérer les modules Magento déjà disponibles pour ce besoin ; ses honoraires étant plus que financés par la réduction de la charge de développement technique de la solution.