blog e-commerce, François Ziserman
e-commerce, marketing des sites marchands, technologies 2.0, entrepreneuriat,...

Vous l’avez surement lu : Nokia rachète Symbian.

Symbian, c’est un OS plutôt orienté pour les mobiles. Pour la petite histoire, Symbian, à l’origine, c’est l’OS des Psion (si je me laisse aller, je vais vous parler de mon Psion 5mx : que c’est énervant que cette boite ait loupé le virage de la convergeance PDA / Mobile…).

Ce que je lis, c’est que Nokia aurait racheté Symbian pour réagir à Android.

Peut être…

Moi, aujourd’hui, celui qui m’impressionne, ce n’est pas Android mais Apple avec son iPhone.

J’entends déjà les objections :

• Tu es un inconditionnel d’Apple,
• L’iPhone est un truc de Geek, réservé à une poigné de parisiens branchés,
• …

Sur le premier point, c’est un procès d’intention ( ).

Sur le deuxième point, on verra, on verra… Quand les centaines d’applications vont débarquées sur l’iPhone, ça va faire mal… J’en fait le pari (qui veut jouer ?).

Android ? android n’est pas encore installé dans un mobile… et l’histoire à montré que c’était complètement différent, de faire un OS indépendamment du hard ou de faire un OS spécialisé pour un matériel donné.

C’est là toute la force d’Apple : ils maîtrise la chaîne complète (hard + soft), et peuvent ainsi avoir un OS plus léger et plus performant, parce que l’OS sait sur quoi il tourne : il ne doit pas avoir dix mille configurations…

Voilà, elle est là mon analyse :

Je pense que Nokia a (enfin) compris que pour augmenter la valeur de ses terminaux, il doit investir plus et mieux dans le logiciel.

Dans ce milieu, le logiciel, c’est le maillon faible, et depuis longtemps.

Motorola gère par exemple plusieurs OS (des terminaux linux, Windows Mobile, Symbian, plus, je crois, un système maison, et se disperse.

Les terminaux de Nokia ont une richesse fonctionnelle incroyable, mais la navigation dans les applications est très loin derrière “l’expérience iPhone”.

Maintenant, être capable de faire ce qu’à fait Apple, au niveau de la qualité de l’interface, ça va demander vraiment du temps à Nokia (et aux autres) : très probablement plus d’un an. Si pendant ce temps apple avance bien, ils peuvent vraiment bousculer ce marché.

Et oui, cette maîtrise du logiciel, à ce niveau de complexité, de richesse, c’est pas un travail qui se fait en 5 minutes.

Nokia a compris ? Peut être. D’autres acteurs devraient également se poser des questions et comprendre : l’avenir passe par la maîtrise du logiciel !

J’étais ce matin à une présentation de sociétés, ayant en commun d’être sur le créneau du SAAS (organisé par innov-it).

Le SAAS, c’est le nouveau nom pour l’ASP. En un mot, c’est utiliser un service en ligne, sans installation chez vous donc.

On est tous des utilisateurs aujourd’hui de solutions SAAS, via gmail par exemple.

J’y suis allé pour plusieurs raisons : pour faire de la veille, et voir s’il n’y avait pas dans le lot quelques belles innovations en préparation pour notre domaine préféré : le e-commerce. L’autre raison, vous le savez, c’est que je suis convaincu qu’à moyen terme, le SAAS va se développer énormément.

J’ai ainsi appris qu’on avait un club en France sur l’ASP : l’ASP Forum. Hum, pas très glamour ce site ;).

J’ai pu voir défiler une vingtaine de boites, venues présenter leur projet, soit pour rechercher des partenaires, soit pour chercher des sous.

J’y ai vu quelques boites intéressantes et liées au e-commerce, dont je vous parlerais bien vite (dont une solution pour automatiser la saisie des formulaires, concurrent de spoonkey donc, ou autres solutions pour réaliser des sites 3D… concurrent de VB2S donc).

Un regret : personne n’a parlé des enjeux à venir pour le SAAS. On n’a pas parlé, par exemple, de la problématique de mashup, pourtant fondamentalement liée au modèle SAAS : comment brancher plusieurs solutions SAAS entre elles ?

Tous les articles de ce blog sur le SAAS.

Quand on se lance dans un projet e-commerce, on peut se retrouver dans la situation ou l’on doit choisir un langage de programmation, et plus largement, un environnement technique (OS, serveur, langage, base).

La question est importante, parce qu’elle a beaucoup de conséquences, sur les équipes, l’architecture, et les composants, qu’on pourra plus ou moins facilement ajouter.

Quels sont les grands éléments de cet environnement ?

• Langage de programmation
• Serveur
• Base de données
• Environnement de programmation
• Système d’exploitation

On peut commencer par parler des langages de programmation.

D’abord, il faut dire que tous les langages ont une couverture fonctionnelle identique : il n’y a pas de langage qui permet de faire quelque chose, qu’on ne peut pas faire avec un autre langage.

Comment choisir alors ?

Voici quelques critères :

• Compétences des équipes : Si les équipes maîtrisent un langage (Java par exemple), cela prendra du temps de les former à un nouveau langage. Ce n’est pas forcément rédhibitoire, surtout si on a du temps, mais, existe-t-il des projets ou on a du temps ?
• Budget : Certains langages sont gratuits (Java, PHP, Ruby On Rails), et certains sont payants (.NET).
• Délais. Certains langages, associés à des librairies, permettent de gagner du temps, de développer les services plus vite.
• Environnement existant : Vous avez déjà tout un environnement, basé sur une technologie. C’est sans doute une bonne idée de faire un développement cohérent par rapport à cet existant.
• Contour fonctionnel : avec le langage on choisi “de facto” les librairies sur lesquelles on pourra s’appuyer. Si par exemple on doit intégrer un module de CRM, PHP permet de faire ça assez facilement, avec des modules comme SugarCRM.
• Robustesse de l’application : il est beaucoup plus facile de faire du code robuste en Java ou .NET qu’en PHP. PHP, pour rester sur cet exemple, est tolérant par rapport aux erreurs. La concéquence est qu’il est beaucoup plus difficile d’écrire une application 100% bug free en PHP qu’en Java. Bon, ce point doit être modéré, parce que la qualité finale dépend de tout un tas de facteurs : librairies utilisées, compétences des équipes, …

Je ne mets pas la performance comme critère, parce qu’on peut faire des services performants avec tous les langages (on peut également faire des systèmes qui rament avec tous les langages, c’est même assez facile ). A chaque fois, il convient “simplement” d’ajuster l’architecture.

Bon, vous me direz peut être que tout ça ne vous guide pas vraiment !

Prenons les trois langages les plus utilisés aujourd’hui : PHP, Java et C#.

PHP

Avantages

• Gratuit ;
• Très bien intégré dans la couche LAMP (Linux / Apache / MySQL / PHP) ;
• Grosse communauté d’utilisateurs, et donc beaucoup de librairies disponibles ;
• On trouve (relativement) facilement des ressources, soit pour recruter, soit en prestation ;

Inconvénients

• Trop tolérant aux erreurs (pas de typage, …), et donc cela augmente “mécaniquement” le risque d’avoir un service buggé ;
• Environnement de développement assez pauvre (pas de débugger encore bien stable).

Java

Avantages

• Gratuit, mais attention, il faut ajouter un serveur d’application qui n’est pas forcément gratuit. Le serveur d’application est une couche, qui s’intercale entre Apache (le serveur Web) et le langage Java.
• Très bon environnement de développement, gratuit (Eclipse) ;
• Grosse communauté, on trouve beaucoup de composants libres ou pas sur le marché ;
• Langage de très bonne qualité, qui permet, plus facilement qu’en PHP, de faire des programmes robustes et fiables.

Inconvénients

• On trouve un peu moins de ressources qu’en PHP.
• Les développements sont souvent un peu plus long qu’avec PHP. C’est la concéquence, le prix à payer ;
• Comme il y a moins de développeurs Java que PHP, les prix sont un peu plus élevés. La facture est donc un peu plus lourde qu’avec du PHP.

C#

Avantages

• Au niveau qualité du langage, on est au même niveau qu’avec le Java, mais l’intégration entre le langage et l’environnement de développement (Visual Studio) est plus forte. Au final, le développeur a entre les mains un outils de développement de très grande qualité ;
• On bénéficie du support d’un grand éditeur ;
• On peut gagner plus de temps, par rapport au Java, grâce aux nombreuses librairies fournies par Microsoft.

Inconvénients

• Solution la plus chère, à tous les niveaux : licences, ressources.
• Ce choix est très structurant, et le choix Microsoft a tendance à “se répandre” : on prend .NET, puis SqlServer, puis IIS, puis Windows Server, puis… On fini rapidement par avoir l’ensemble des logiciels Microsoft, et on revient sur le premier point : attention à la facture !

Au final

Pas simple, pas de réponse universelle.

Autre point important : un projet a une durée de vie limitée, une période d’amortissement. Un site qui vit 3 à 5 ans, c’est bien. Aller au delà n’est pas forcément très raisonnable.

encore un autre point : le choix n’est pas forcément unique : on peut faire le front en PHP, le back en Java, … Avec les Web Services, les différents langages savent dialoguer. Mais : c’est des développements complémentaires et il faut dans ce cas avoir les deux compétences.

N’hésitez pas à commenter ce billet : j’ai essayé d’être synthétique, mais j’ai sans doute oublié des points !

bien programmer est un art, où tout au moins un artisanat, un peu comme un ébéniste.

Par programmation, j’entends l’ensemble des activités, permettant de passer de l’expression d’un besoin à un système informatique. Cela regroupe donc ce qu’on appelle l’analyse, la conception, la programmation, les tests, …

Bien sûr, les grosses boites vous parlent de processus industriels.
Ils ne vont pas vous dire le contraire, quand on allonge une facture de plusieurs centaines de milliers d’euros…
Ce sont les mêmes qui réalisent les systèmes informatiques des grosses banques… Vous me suivez ?

Mais la réalité est aujourd’hui plus simple, toute nue : la qualité de votre système informatique, quel qu’il soit, dépend de la qualité des artisans qui le construisent.

Une des qualités fondamentale pour bien programmer, c’est l’art de l’abstraction.

Pourquoi ? (j’aurais pas du regarder Sarkozy l’autre soir moi, j’ai une rechute)

Quand on doit réaliser une application, la base de la programmation, c’est de découper le problème, dans deux sens : verticalement et horizontalement.

Verticalement : on sépare le problème, fonction par fonction (pour un front office, on parlera par exemple du processus achat, du catalogue produit…)

Horizontalement : on sépare le problème en couche (toujours pour notre front, on pourra faire une couche pour les données, une couche pour les objets métiers et enfin une couche présentation).

Ce découpage à pour but de définir des modules, entité informatique ayant d’une part une complexité maîtrisable et d’autre part une certaine homogénéité.

Pourquoi ?

1. Un module doit être plus simple à programmer parce que le problème qu’on cherche à régler est une partie du problème global.
2. Le module est plus homogène parce qu’il ne résoud qu’un type de problème (les données pour le processus achat par exemple).

Le programmeur, notre artisan, doit donc être capable de faire abstraction des autres problèmes (voisins de gauche et de droite et du dessous) pour se concentrer sur son “morceau” du problème.

ça encore, c’est pas le plus dur.

Le plus dur, c’est qu’il doit à son tour donner une interface à son module ayant le bon niveau d’abstraction.

Il doit bien faire la différence entre “sa cuisine interne” et la vue qu’il donne sur son module.

Concevoir l’interface d’un module est réellement une partie passionnante. On se retrouve dans la situation de définir le “panneau de contrôle”, donnant donc une vision la plus simple et la plus abstraite du problème qu’on doit résoudre.

Je m’étais inscrit à la journée OnAir de Paris.Le monde est tout petit, c’est l’occasion de croiser Fred, Olivier Ezratty, Christophe Lauer…

La présentation était réalisée par toute l’équipe d’évangélistes Adobe : Mike Chambers, Rayan Stewart, …

AIR, c’est la solution d’Adobe, pour “sortir du navigateur” et avoir des applications qui tournent directement sur le bureau de nos ordinateurs, avec une vrai logique multi-cible (PC, Mac, Linux).

Bon, faut le dire, cette journée est “terriblement” technique !

J’en parlais avec Christophe Lauer, évangéliste microsoft sur les technos Sylverlight, c’est marrant comment Microsoft qui a un background technique fait tout pour draguer les designer, en faisant des présentations ou la programmation est plutôt caché, alors qu’Adobe, qui vient plus du monde des designers, fait des présentations super techniques (on a vu des lignes de commandes ).

Autre point vraiment intéressant : les logos des premiers utilisateurs : Salesforce.com, SAP, …

Comme évoqué dans ce billet sur RichCommerce, la logique AIR prend tout son sens pour certains éditeurs, c’est un retour de balancier après une période “full web”.

L’approche AIR est une vrai alternative, pour développer plutôt simplement une application ayant une interface nickel, qui tournera sur toutes les machines, et qui sera assez simple à déployer.

A ce titre, Adobe joue relativement seul sur ce terrain : Java n’est pas aussi simple et Microsoft n’a pas d’alternative (WPF n’est pas multi-OS et Sylverlight ne sort pas du navigateur).