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

Zappos, une erreur à 1,6 million de dollars…

Cet article est écrit par Christophe Davy, dirigeant de Brand Online Commerce, qui intervient ponctuellement sur ce blog. Son contenu n’engage pas François Ziserman, qui d’ailleurs de manière générale réprouve le plus souvent ce que dit et écrit Christophe. A se demander pourquoi il l’a invité sur son blog…

Le site 6pm.com appartient à l’américain zappos.com, le n°1 de la chaussure en ligne, récemment racheté par Amazon. C’est un site de déstockage qui permet à Zappos d’écouler les fins de collections avec des discounts pouvant aller jusqu’à 70%.

Vendredi dernier, ils ont fait plus fort que 70%, suite à un bug informatique (de leur moteur de calcul des prix). En effet, tous les produits se sont retrouvés à un prix unique, 49,95 $ !

L’erreur n’a été repérée qu’au bout de 6 heures, et le site a alors été fermé le temps de rectifier les étiquettes de prix. Mais le manque à gagner s’élève à 1,6 million de dollars. Au passage, un bug à 1,6 million de dollars en seulement six heure de temps, cela laisse rêveur sur la puissance commerciale du site.

Le management de Zappos a rapidement (le jour même !) décidé d’assumer la perte, et de livrer les produits aux clients ayant eu la chance de saisir cette opportunité.

Double morale à cette histoire :

1/ Tous les e-commerçants doivent être en veille permanente sur leurs étiquettes de prix, et sans cesse valider les prix vus par les clients ; ne pas se contenter de faire confiance aux règles de gestion de leur back-office

2/ Encore une fois les américains nous donnent des leçons de réactivité et de gestion de la relation clients ; cf la boulette 3 Suisses de l’année dernière…

Entre focalisation et contrôle

Pour une entreprise, le choix est toujours difficile :

Vaut il mieux être focalisé, et « le meilleur du monde » sur son cœur de métier, ou vaut il mieux s’étendre, encore et encore, et ainsi tirer le maximum de revenus des clients, en leur proposant « la totale » ?

Cette question se pose dans des contextes très différents.

Premier exemple avec Google.

Pendant longtemps, Google nous expliquait que pour eux, moins un client restait longtemps sur leurs pages et mieux c’était : cela veut dire que l’internaute à trouvé ce qu’il cherche.

Mais Google change, et propose toujours plus de services.

Et ces services sont de plus en plus envahissants, sur les pages de Google.

Ainsi, quand on fait une recherche, ce qui est mis en avant, ce sont avant tout les services proposés par Google : voir les vidéos associées sur Youtube, voir l’actualité via le service de… Google bien sûr, ou encore cet encart, dès la home page de Google, me proposant de changer de navigateur, et d’utiliser Chrome.

Google est clairement dans une logique « d’en prendre le plus possible » et de lier au maximum les services, les uns entre les autres.

Dans le monde des éditeurs de logiciels, cette question, de la focalisation, est complètement centrale.

La tentation est extrêmement forte de tout faire pour répondre à tous les besoins des clients, principalement parce que la plupart des clients n’ont pas (ou très peu) de ressource technique. Si l’éditeur propose une réponse partielle, le client va devoir assembler plusieurs solutions, et c’est pas simple.

C’est bien comme ça que ce sont développés les solutions de type ERP : une solution qui fait tout.

Pour notre petit monde du e-commerce, cette question est bien sûr clé.

Le cœur d’une solution e-commerce, c’est quoi ?

  • Le catalogue ?
  • La gestion du compte ?
  • La gestion du processus achat et des commandes ?

Après, des solutions se proposent de compléter le moteur e-commerce :

  • Les solutions de CRM, pour gérer de manière plus cohérente l’ensemble des interactions avec les clients ;
  • Les solutions de « searchandising », pour enrichir la navigation dans le catalogue, par les catégories ou la recherche ;
  • Les solutions « CMS », pour faciliter l’édition de pages de contenus, autres que les pages directement générées par le catalogue.

Sans parler de tous les liens à faire avec les systèmes d’informations de l’entreprise : ERP, comptabilité, logistique…

Et c’est sûr que pour faire une solution basée sur l’assemblage de briques, il va falloir de la technique, et, si on n’a pas d’équipe technique interne, une société de développement informatique (intégrateur, SSII, on l’appelle comme on veut).

NGinx, l’avenir du Web ?

Discussion passionné avec Laurent ce matin.

Laurent Letourmy est le brillant patron d’Ysance.

Laurent fait parti de ces patrons qui savent de quoi ils parlent !

Bref, on parlait archi Web ce matin, à la fraiche.

J’ai ainsi appris l’émergence d’un nouveau serveur HTTP : NGinx.

C’est un serveur, qu’on peut mettre à la place d’Apache ou IIS.

D’après Laurent, qui connait très bien tout ça, NGinx est beaucoup plus efficace qu’Apache.

C’est une solution pour résoudre un point qui, à mon avis, va devenir crucial dans les années à venir : économiser la ressource serveur.

NGinx, à suivre donc.

Je ne suis pas marié avec Magento !

J’ai entendu ça plusieurs fois ces dernières semaines…

Il m’a semblé important de mettre les choses au clair :

Je ne suis pas marié avec Magento !

Je ne pense pas que Magento soit la réponse miracle, adapté à tous les cas de figures.

Je participe avec grand plaisir aux évènements Magento, mais je le fais également avec d’autres solutions : Prestashop par exemple.

Je ne suis pas marié non plus avec le PHP !

D’ailleurs, si on me demande mon avis, je pense que .Net est probablement actuellement le plus bel environnement pour développer des services Web… Mais bon, faut pouvoir se le payer…

Il y a également de très belles choses en Java, avec Eclipse, qui est également un bel environnement, et pas mal de briques, open sources ou pas.

Le métier d’Araok est d’aider ses clients à faire les meilleurs choix, dans un contexte donné :

  • Expertise technique interne
  • Budget
  • Autres applications
  • Besoin fonctionnel

En fonction de tous les paramètres, on cherche la solution la plus adaptée.

Pas de religion, pas de dogme donc !

Et le prochain qui me demande si j’ai des relations exclusives avec Magento, je lui fais le coup du « vous devriez lire mon blog 😉 ).

SAP mon amour

SAP est une boite hors norme.

C’est le leader mondial de l’ERP.

ERP, c’est un logiciel censé tout faire dans l’entreprise.

En fait, je vais révéler un secret : ça fait pas tout ;).

Bon, à mon très humble avis, l’idée même d’un logiciel qui fait tout est une très mauvaise idée

Malheureusement, c’est compliqué d’expliquer que c’est une mauvaise idée, et comme beaucoup d’entreprises n’ont pas de culture technique (exemple : pas de directeur technique / informatique au comité de direction), et bien SAP a surfé, pendant des décénies, sur une promesse simple : apporter une solution unique qui va tout faire.

Et puis SAP a réussi sur une stratégie commerciale très agressive. Aujourd’hui, il y a tellement de clients SAP que celui qui n’a pas SAP n’a pas le choix. Mettez vous à la place du DSI : tous ces collègues, dans les boites comparables, ont pris SAP. Les chefs vont lui dire : pourquoi s’embêter ? Si les autres ont pris ça, c’est que c’est bon ? Et il va ramer, notre DSI, ramer jusqu’à finalement bien souvent ne plus se battre, et faire ce qui finalement sera le plus simple pour lui : prendre SAP.

Petit détail : ce sont des secrets de polichinelles : certaines entreprises ont bien failli y passer, lors d’une migration SAP…

Il faut dire que comme ce sont des logiciels qui ont le contrôle sur le cœur de la production de l’entreprise, si ce truc là ne marche pas, l’entreprise peut se trouver complètement bloquée.

Donc, SAP c’est vendu à (presque) toutes les grandes entreprises.

Aujourd’hui SAP a un peu de mal à gérer sa croissance… Elle est leader sur le marché de l’ERP pour les grands groupes, peut se dire qu’elle va aller prospecter pour de plus petits comptes, sauf que c’est pas si facile de changer de culture commerciale.

Et puis, une stratégie qui a marché pour de très grosses boites peut ne pas marcher sur de plus petites boites.

Enfin, on peut également se dire que la culture des entreprises évolue, et que les décideurs commencent à se dire que ces solutions ne sont pas forcément les plus efficaces pour une entreprise agile !

Bon, tout ces pensées suite à la lecture de cet article :

Quelles sont les nouvelles priorités de SAP?
« Nous avons commis des erreurs. Nous devons regagner la confiance de nos clients (…). Nous devons nous concentrer sur trois priorités, qui doivent être traitées simultanément:  1-la croissance, 2–la marge et 3–la communication.

Hum, le gars dit qu’ils doivent regagner la confiance des clients, et que ce qu’il doit faire, c’est gagner plus d’argent et mieux communiquer. C’est pas gagné !!!

Système d’information : Les effets de bords d’un prix très élevé

Ce billet concerne plutôt les entreprises de taille moyenne à grande.

J’ai déjà parlé dans des billets précédents, de l’effet de bord d’un projet IT très très cher :

En général, de tels projets sont validés par la direction générale.

Et, comme par magie, le projet est « toujours » un succès.

Pourquoi ?

Parce que si ce n’était pas le cas, la direction serait « challengé ».

Donc, même si dans la pratique c’est pas si rose que ça, on va s’arranger pour dire que « tout va bien ».

Qui ira vraiment vérifier ?

Les équipes vont se débrouiller, jongler entre excel et des applications instables, la communication sera : « on track ».

Et bien parfois, un autre scénario se produit : la mort du projet.

Le scénario est le suivant :

Un projet « mastodonte » est lancé.

A un moment donné, quelques années plus tard, un dirigeant, n’ayant pas trempé dans la décision, regarde le truc, et fait une rapide analyse :

  • ça a coûté combien ?
  • ça a rapporté quoi ?

Et là, rapidement, la décision va être prise d’arrêter le projet.

le projet est donc mort d’avoir coûté trop cher, au démarrage, et donc d’avoir, les premières années, un bilan « indéfendable ».

Quelle est la différence entre les deux scénarios ?

Finalement, dans le deuxième projet, on peut se dire que la décision n’a pas été prise assez haut, et que le projet n’a pas été vendu assez cher ;).

Plus sérieusement, c’est pour moi un élément complémentaire pour pousser des solutions par étapes, avec une monté en puissance très progressive.

Il faut éviter à tout pris les projets « cathédrale », qui coute cher, sont long à faire, et ont des résultats très incertains.

Il vaut tellement mieux privilégier une approche « agile », par étapes.

Mais pour cela, les mentalités doivent énormément évoluer !

Nouvelle fonction sur Lengow pour enrichir les flux produits

Lengow est une solution (dont j’ai déjà parlé ici) qui permet de publier tout ou partie du catalogue vers différents moteurs de shopping.

Bien sûr, pour fonctionner, le moteur à besoin d’avoir le plus d’informations possibles sur les produits.

Et c’est souvent là que ça coince.

Pour régler ce problème, Lengow a ajouté un système, qui permet de récupérer les données sur les produits directement à partir de la page web du produit.

On a pas mal discuté avec Mickael (fondateur / directeur technique de Lengow) de cette fonction.

Au final, c’est un choix pragmatique, qui permet de mettre en place Lengow sans avoir à attendre d’avoir le flux qui va bien.

Mais la question que ça pose, nécessairement, c’est : pourquoi les e-marchands ne peuvent ils pas produire le flux directement ?

Et oui, si la page produit affiche des informations sur les produits, c’est bien que ces informations sont stockées dans le système d’information e-commerce du marchand.

Oui, mais voilà, bien souvent, ce système est :

  • Soit mal maîtrisé (ou pas maîtrisé du tout) ;
  • soit externalisé : et les demandes d’évolutions peuvent être chères, et longues à venir (ou ne jamais venir…) ;
  • soit l’équipe technique a d’autres priorités.

Cela donne une assez bonne idée du chemin qu’il reste à parcourir, pour fournir aux marchands un système e-commerce réellement performant…

Critère de qualité – La robustesse

Quand un site e-commerce grossit, que le site représente plusieurs millions d’euros, la qualité du site prend de plus en plus d’importance.

Ce n’est pas le cas au début, au lancement d’un site e-commerce.

Mettre la barre trop haut, au lancement d’un site n’est pas forcément une bonne idée, parce que la qualité à un prix…

Pour faire simple, au démarrage, il vaut mieux privilégier le e-marketing, et accepter de prendre certains risques au niveau de la qualité de la solution.

La qualité se mesure par plusieurs critères.

Le critère que je propose de creuser un petit peu ce soir, c’est la robustesse.

C’est quoi la robustesse ?

La robustesse, en informatique, c’est la capacité qu’à une solution informatique à se comporter le mieux possible, même quand « le monde s’écroule ».

Concrètement, cela veut dire, pour un site e-commerce, que le site doit continuer à fonctionner même si des incidents surviennent, à différents endroits (un serveur qui s’arrête, un service tiers qui ne répond plus, …).

Bien sûr, on ne peut pas demander à ce que le service continue « comme si de rien n’était » alors que des services clés ne répondent plus. Mais on peut demander à ce que la dégradation du service soit contrôlée et progressive.

Exemple : le lien avec la logistique tombe, et le site Front office n’a plus les infos de stock.

On peut tout à fait imaginer que le Front ai une sorte de cache, et qu’il puisse continuer à effectuer des ventes, en s’appuyant sur le stock géré en cache.

Autre exemple : sur pecheur.com, il y a deux systèmes de paiement CB, indépendants. C’est une solution (simple pour le coup) pour permettre de vendre à tout instant, même si l’une des plateformes de paiement tombe.

Pour un service Web, la robustesse, c’est également bien se comporter quand le site doit supporter une charge trop importante.

Exemple de stratégie : au lieu de ne plus rien répondre, le site peut s’adapter à la montée en charge, en se délestant de certaines fonctions (merchandising par exemple) pas complètement indispensables.

C’est toujours mieux que de laisser tous les clients attendre devant une page qui s’affiche à la mode des années 80.

C’est finalement assez cher de concevoir une solution vraiment robuste. Il faut doubler les serveurs, mettre en place des processus pour gérer les différents cas de panne, concevoir une architecture avec des composants assez indépendants, faire des tests, …

Mais c’est clairement indispensable et rentable pour un gros site, ou il est carrément impensable que le service s’arrête.

L’URL Rewriting est il un bon critère de choix pour une solution e-commerce ?

Bon, si je fais pas attention, mes titres de billets vont devenir de plus en plus long… Est-ce un effet Twitter ? 😉

J’ai donc écrit hier un billet ou je donne quelques pistes sur les critères, plus ou moins bon, pour choisir une solution e-commerce.

J’avais donc pris comme exemple l’URL rewriting comme mauvais critère.

Un commentaire sur ce billet m’a rappelé que toutes les solutions e-commerce n’incluent pas cette fonctionnalité.

Et je me suis dit que ça pourrait faire l’objet d’un billet ;).

En fait, c’est sûr que c’est pas si simple…

Cela dépend en grande partie de la taille du projet e-commerce.

Si vous avez un « petit » projet », c’est à dire que vous lancez une activité e-commerce, et vous cherchez une solution simple et rapide à mettre en oeuvre, il est clair qu’il faut ajouter, à la check-list des caractéristiques de la solution l’URL-Rewriting.

Au fait, pour ceux qui ne connaissent pas, l’URL Rewriting est la possibilité de gérer, depuis le back office du site, l’URL associée à chaque catégorie, à chaque produit, de manière à avoir une URL « bonne à manger » pour Google, c’est donc une fonction pour améliorer son référencement naturel.

Bon, donc pour un petit projet, ce critère est fondamental… de même que tout un tas d’autres critères… Maintenant, effectivement, une solution qui n’inclue pas l’URL rewriting doit commencer à dater sérieusement.

Pourquoi la question n’est pas la même pour un gros projet ?

Quand on est sur un site ayant de grands volumes, on ne s’intéresse plus au référencement naturel ?

Si si, bien sûr !

C’est juste qu’on doit bien évidement inclure cette fonction au site final, mais que cette fonction est tellement anecdotique, par rapport à l’ensemble des enjeux, qu’elle ne peut pas être un critère discriminent.

Au pire, si une solution correspondait à 99,9% aux besoins du gros projet, et que, par le plus grand des hasards, la solution n’incluait pas un URL Rewriting adapté au projet (toutes les solutions un brin modernes que je connais incluent ce mécanisme), et bien ça ne serait pas si compliqué que ça de l’ajouter…

Tout ça pour dire quoi ?

Et bien pour bien se rendre compte que, suivant la taille, les enjeux d’un projet, les contraintes ne sont absolument pas les mêmes. Si on devait écrire un guide des solutions e-commerce, et bien… il faudrait en écrire plusieurs, suivant les enjeux des projets ;).

Les critères de choix des solutions e-commerce… Les bonnes et les mauvaises raisons

Sur ce sujet, plus que sur d’autres, le marketing est maître…

Bon, reprenons depuis le début :

Vous montez un site, il vous faut un moteur pour propulser votre boutique.

Il existe des tas de solutions. Comment vous y retrouver ?

Au fond, pour bien choisir, il faudrait y passer pas mal de temps, pour définir une grille d’analyse, prioriser les critères, puis passer à la moulinette les différentes solutions…

Bien sûr, personne ne fait ça (sauf nous, on y bosse, mais chut…).

Donc, les décisions se prennent autrement.

Comment ?

Ah comment, bonne question !

Je vois toutes sorte de décisions.

Bien souvent, la décision est politique…

Mais, et c’est également très fréquent, on choisi avec des critères extrêmement superficiels.

Exemple : telle solution met en avant une fonction, qui, objectivement, est un point de détail ou alors n’est réellement pas discriminant… (url rewriting, j’ai entendu cet argument mis en avant par l’une des plus grosse solution du marché…).

Mais voilà, ce point de détail est mis en valeur par les commerciaux, et l’acheteur est séduit par ce « gadget » qui semble bien sympathique.

Pour prendre une analogie, c’est comme si vous deviez acheter une voiture, et que vous choisissiez en fonction du porte clé qu’on va vous offrir…

Bon, je ne peux pas m’empêcher de le dire : pour un peu de raison dans ce monde de brute, n’hésitez pas à faire appel à Araok !