• Qui est (vraiment) le client ?

  16 juillet 2009

  Pendant longtemps, le jeu était un peu biaisé au niveau des mobiles.

  Les vrais clients pour les constructeurs de mobiles étaient les opérateurs.

  Vous, moi, nous n’étions que de simples utilisateurs.

  Bien sûr, j’exagère : les constructeurs ont toujours communiqué directement auprès des utilisateurs, pour “générer l’envie”.

  C’est Apple qui a clairement changé la donne, avec son iPhone.

  Apple a su ne pas faire de concession, et rester “focus” sur un seul type de client : l’utilisateur.

  L’opérateur est clairement dans le paysage, mais Apple a su recréer un lien beaucoup plus fort entre lui : le constructeur, et l’utilisateur.

  C’est comme ça qu’on a sur l’iPhone la liberté d’installer les applications que l’on veut, y compris sur la première page (et non les applications imposées par l’opérateur mobile).

  En fait, non, on ne fait pas exactement ce que l’on veut, c’est vrai : on ne peux installer que les applications autorisées par Apple…

  Réagir et/ou lire les commentaires

• Superman

  15 juillet 2009

  

  J’ai rencontré Superman.

  Il s’appelle Luc Michalski et, tout seul, le soir, après son travail, il développe un moteur de recherche…

  Le moteur tourne : il a “avalé” près de 5 millions de sites web, scanné plus de 100 millions de pages web…

  Luc ne fera sans doute pas concurrence à Google, mais il a forcément énormément appris en réalisant ce tour de force, qui est en ligne.

  En occurrence, Luc a du développer les éléments fondateur de tout moteur de recherche : le robot qui scanne les sites, le moteur qui analyse les pages pour alimenter l’index et le moteur qui navigue dans l’index.

  que la force soit avec toi, Luc (euh, c’est pas superman ça, je m’embrouille ).

  Réagir et/ou lire les commentaires

• La révolution Internet est-elle une révolution comme les autres ?

  14 juillet 2009

  L’humanité a pas mal évolué, depuis l’âge des cavernes (je suis peut être remonté un peu loin…).

  Donc, pas mal de ruptures dans notre histoire. Exemples : la maîtrise du feu, des outils, de l’agriculture, des métaux, …

  L’écriture, l’imprimerie, …

  La révolution industrielle…

  Et puis, enfin, la révolution actuelle, numérique.

  Je me posais la question : la révolution actuelle est-elle de même nature que les révolutions précédentes ?

  Au niveau de la force de l’impact, je pense qu’il n’y a pas débat : le “tout numérique” est a mon sens au niveau des plus grands bouleversements.

  La ou je me pose une question, c’est sur la possible fragilité de cette révolution.

  Prenons l’invention de l’imprimerie.

  Grosse rupture, qui a changé nos vies.

  Et bien, il me semble que cette rupture là ne souffre d’aucune fragilité. Une fois qu’on a compris comment imprimer, on peut le refaire assez facilement.

  Pour notre rupture numérique, c’est très différent : tout “tient debout” grâce à une sacrée infrastructure : réseaux, routeurs, …

  Cette infrastructure me semble être une “fragilité” : sans ce réseau, il ne resterait pas grand chose de notre monde numérique.

  Fragile le réseau ?

  Oui et non.

  Non parce que justement, ce qui en fait sa force, c’est la souplesse du système. Un point du réseau tombe, pas de problème, les données vont passer par d’autres chemins. Notre réseau numérique semble robuste donc.

  Robuste… Peut être, mais cela reste un édifice assez complexe, avec, n’en doutons pas, quelques SPOF (Single Point Of Fealure).

  Et puis, s’il le falait vraiment, ne croyez vous pas que quelques gouvernements pourraient “débrancher” le machin ?

  Je n’ai pas d’infos secrètes, mais il me semble assez réaliste d’imaginer que le gouvernement américain, par exemple, a des équipes spécialisées pour “tout débrancher”…

  Réagir et/ou lire les commentaires

• Envoyer les colis avec la Poste

  10 juillet 2009

  Notre bonne vielle poste a créé une entité, toute dédiée à l’expédition de nos joyeux colis : Géopost.

  Géopost est (pour faire simple) découpé en deux entités : ColiPoste et Chronopost.

  Gros avantages : ces sociétés bénéficient des infrastructures de La poste : maillage pour le transport et surtout points de livraison avec les bureaux de postes et les facteurs.

  ColiPoste

  C’est la livraison “J+2″, en France et à l’international.
  97% des livraisons sont effectuées effectivement à J+2 !

  Plusieurs options : soit le colis est simplement remis dans la boite aux lettres, soit le colis est remis avec signature du client.

  Si vous vous lancez, vous pouvez démarrer avec Colipost très simplement, avec une interface WEB extranet, pour créer les étiquettes.

  Si vous avez suffisemment de volume (1500 € à l’année de frais de livraisons), vous pouvez utiliser un logiciel (Windows) qui permettra d’imprimer les étiquettes de manière plus pro.

  Chronopost

  C’est la livraison “J+1″,  en France et à l’international, réussie dans 98% des cas !

  Plusieurs options pour la livraison : Garantie avant 8h, 9h, 10h ou 13h (c’est la dernière option la plus courante).

  Pour les étiquettes de transport, c’est un peu le même système qu’avec ColiPoste.

  Pour aller plus loin…

  Vous pouvez interfacer votre système e-commerce avec les logiciels de La Poste.

  Avantage : pas besoin de ressaisie manuelle des informations de livraison.

  Mais ça, c’est une autre histoire !

  Réagir et/ou lire les commentaires

• Cohérence de l’interface

  9 juillet 2009

  Cela fait quelque temps que j’ai en tête un billet, sur la cohérence de l’interface d’un site.

  Mais j’ai du mal à l’écrire : j’ai des idées qui me semblent trop théoriques, …

  Et puis, miracle, je suis tombé sur ce site…

  Premier bouton pour acheter :

  

  Deuxième bouton, sur la page suivante donc :

  

  Troisième bouton :

  

  Et enfin dernier (probablement le plus réussi) :

  

  Voila. rien ne vaut un bon exemple…

  Donc, pour faire simple, la cohérence, c’est “pas ça”.

  Réagir et/ou lire les commentaires

• Fusion / Acquisition : 1 + 1 = 3 ou… 1 ?

  8 juillet 2009

  Les boites se rachètent les unes les autres.

  C’est la vie des entreprises : les petits se font manger par les gros.

  Et là dessus, c’est un peu comme les poupées russes : il y a “pratiquement toujours” un plus gros que vous…

  Autre modèle : deux boites de taille similaire fusionnent pour être plus fort.

  On peut regrouper deux boites pour plusieurs raisons : complémentarité des offres : technique, géographique, marketing…

  On peut aussi racheter un concurrent, pas du tout complémentaire donc, juste pour “dégager le terrain”.

  La question qui me semble intéressante est : comment faire pour que la nouvelle entreprise, désormais mélange des deux “parents”, crée un maximum de valeur ?

  C’est une excellente question, merci.

  Idéalement, la valeur résultante doit être supérieure à la valeur de chaque “parent” (d’où le titre : 1 + 1 = 3) ?

  Dans bien des cas, la réalité n’est pas super drôle… Le racheteur se comporte en maître, et le racheté se retrouve réduit au status peu enviable “d’esclave”.
  Le maître veut rationnaliser : les offres, les équipes, les équipements…

  Alors on casse tout, on ne prend pas vraiment le temps de comprendre ce qui marche, ce qui ne marche pas… C’est l’opération “tracto-pelle”.
  Le résultat est en général un vrai massacre. Les équipes qui fonctionnaient ne fonctionnent plus, les meilleurs sont parti depuis longtemps…

  Alors, comment faire mieux ?

  A mon avis, la meilleure solution consiste à faire vivre les différentes entités, comme de vrais entités business, relativement indépendantes.

  Chacune est responsable de son P&L (Profit & Lost : bilans financiers quoi).

  Dans un tel schéma, chacun est donc respecté, en tant qu’entrepreneur pour le “top management” et en tant qu’équipe motivée, pour les équipes.

  Certains savent faire cela, mais ça demande une vrai humilité : l’humilité d’écouter, de comprendre, de chercher la valeur chez l’autre…

  Réagir et/ou lire les commentaires

• Ne pas aller trop vite sur des nouvelles techno…

  7 juillet 2009

  Je vous avais parlé de l’option de GMail, qui permet de lire ses mails en mode off-line.

  Et bien ce qui marchait hier ne marche plus aujourd’hui :

  Avec la mise à jour presque simultanée sur Mac de Firefox 3.5 et Safari 4, Google Gears, le coeur de la technologie pour rendre un service off-line, n’est plus à jour.

  

  Imaginez : vous êtes e-marchand. Vous vous dites que la fonction offerte par Google Gears est bien sympathique et vous décidez d’adapter votre site avec cette technologie… quelques mois plus tard, patatra, ça ne marche plus !

  A mon sens, il faut en titer plusieurs leçons :

  Avant d’adopter une techno, il est très important de s’assurer de sa pérennité. A chaque fois qu’on part sur une techno trop jeune, on prend le risque que ça soit instable.

  Il faut prévoir des plans B : sur GMail en l’occurrence, le mode off-line n’est plus actif, mais ce mode est désactivé automatiquement si Google Gears n’est pas installé.

  Enfin, j’aimerais bien savoir pourquoi Google ne tient pas le rythme des mises à jours pour un produit aussi central que Google Gears…

  Dernière remarque : le Web est un environnement qui est très “mouvant” : chaque mise à jour d’un navigateur doit être suivie de près par les e-marchands, pour s’assurer que le service est toujours nickel, sur un parc le plus large possible.

  Réagir et/ou lire les commentaires

• Séparer le back du front

  7 juillet 2009

  La plupart des systèmes e-commerce regroupent, sur un même serveur, le Front office et le back office.

  Bon, quand on se lance, il est complètement normal de tout mettre sur un seul serveur : on n’a pas l’argent pour se payer plusieurs machines. Et puis le trafic des premiers mois ne pose pas vraiment de problème…

  Par la suite, c’est une autre histoire.

  Le site e-commerce représente un chiffre d’affaire concéquent… Et la moindre interruption de service met en danger l’équilibre de “la petite entreprise e-commerce”.

  Le Front office doit donc être en ligne 24h sur 24, 7 jours sur 7.

  Pour garantir ce résultat, il faut isoler le Front au maximum.

  C’est le meilleur moyen de garantir que le front est “centré” sur sa mission : répondre, dans un temps très court, aux requêtes des internautes.

  Le back office n’entre pas dans cette mission… Il doit donc être découplé du Front.

  Une première étape peut être de monter une architecture à trois niveaux :

  • Le Front office, composé d’un ou plusieurs serveurs Web
  • La base de données, hébergée sur son propre serveur
  • Le Back office, hébergé sur un autre serveur

  C’est une bonne solution, qui a l’avantage de pouvoir être mise en oeuvre pratiquement sans modifier les solutions e-commerce du marché.

  Avantages :
  Les programmes back office ne pénalisent plus le Front.

  Limites majeures :
  Si une page du back sollicite beaucoup la base de données, les temps de réponses du front seront bien impactés par l’utilisation du back…
  Autre limite : toute bêtise sur le back sera instantannément visible sur le Front.

  Et puis, pour un site plus pro, on souhaite un découplage plus fort :
  On veut, par exemple, mettre à jour le catalogue, et pouvoir “recetter” les modifications, avant qu’elles soient en ligne.

  L’étape d’après consiste donc à avoir un ensemble front complet, composé de serveurs front, avec une base de données dédiée.

  Le back office est complètement séparé, avec sa propre base de données.

  Si on part d’une solution e-commerce toute faite, on peut arriver à ce résultat assez facilement…

  Toute la question, sur un tel système, c’est : comment synchroniser les données entre les bases du Front et du Back.

  Là, pas de solution magique : il va faloir développer une couche de synchronisation.

  Et ça, ça sera l’occasion de pleins d’autres billets…

  Réagir et/ou lire les commentaires

• Regrouper les images pour un site e-commerce plus rapide

  3 juillet 2009

  Avoir un site qui répond rapidement, c’est fondamental.

  Le problème, c’est que faire un site qui réponde rapidement, c’est pas si simple que ça.

  Beaucoup de facteurs entrent en compte :

  • La qualité du système serveur, logiciel et matériel
  • L’architecture des serveurs
  • La bande passante, achetée chez l’hébergeur
  • La bande passante, chez le client
  • Les caches, qui interviennent à différents niveau (de la base de données au cache réseau type Akamai)
  • La structure et le contenu de la page web

  Quand le navigateur doit afficher une page, il doit en fait faire plusieurs requêtes pour aller chercher les différents éléments de la page.

  Si la page est composé de 30 images, le navigateur va faire 30 requêtes, une par image.

  D’ou la solution, de regrouper les images, pour diminuer très fortement le nombre d’images à charger.

  Ensuite, c’est au niveau du CSS qu’on défini la zone de la grande image qu’on veut afficher.

  Typiquement, on utilise cette méthode pour les images du ‘template’ (bordures, boutons, …).

  Autre avantage très important pour cette méthode : elle permet de gérer les différents états d’un bouton très proprement, puisque ces différents états sont pré-chargés à l’affichage de la page. Quand le bouton doit changer d’état (clic souris par exemple), l’affichage de la nouvelle image est instantanné, parce qu’il n’y a pas de requête pour aller chercher une nouvelle image.

  Qui utilise ce type de technique ? Amazon par exemple…

  Réagir et/ou lire les commentaires

• Regrouper les images pour un site e-commerce plus rapide

  3 juillet 2009

  Avoir un site qui répond rapidement, c’est fondamental.

  Le problème, c’est que faire un site qui réponde rapidement, c’est pas si simple que ça.

  Beaucoup de facteurs entrent en compte :

  • La qualité du système serveur, logiciel et matériel
  • L’architecture des serveurs
  • La bande passante, achetée chez l’hébergeur
  • La bande passante, chez le client
  • Les caches, qui interviennent à différents niveau (de la base de données au cache réseau type Akamai)
  • La structure et le contenu de la page web

  Quand le navigateur doit afficher une page, il doit en fait faire plusieurs requêtes pour aller chercher les différents éléments de la page.

  Si la page est composé de 30 images, le navigateur va faire 30 requêtes, une par image.

  D’ou la solution, de regrouper les images, pour diminuer très fortement le nombre d’images à charger.

  Ensuite, c’est au niveau du CSS qu’on défini la zone de la grande image qu’on veut afficher.

  Typiquement, on utilise cette méthode pour les images du ‘template’ (bordures, boutons, …).

  Autre avantage très important pour cette méthode : elle permet de gérer les différents états d’un bouton très proprement, puisque ces différents états sont pré-chargés à l’affichage de la page. Quand le bouton doit changer d’état (clic souris par exemple), l’affichage de la nouvelle image est instantanné, parce qu’il n’y a pas de requête pour aller chercher une nouvelle image.

  Qui utilise ce type de technique ? Amazon par exemple…

  Réagir et/ou lire les commentaires

Articles en provenance du blog ziserman.com