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

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).

J’étais invité, l’autre jour, à une présentation de SugarCRM, organisée par Ysance (bravo Samuel).

Ysance connait très bien ce logiciel, pour l’avoir mis en œuvre dans de nombreux contextes.

CRM donc…

L’idée de base du CRM, c’est qu’il est plus rentable de cultiver les clients existants que de travailler à en ramener des nouveaux. Evidemment, il ne faut pas appliquer cette doctrine à la lettre : il est toujours bien d’aller chercher des nouveaux clients, mais celà nous rappelle qu’on peut travailler sur la base installée.

Travailler la base installée, cela veut nécessairement dire mieux travailler la relation avec ces clients.

La relation avec les clients, c’est :

• La relation avant la vente, la relation durant la prospection donc ;
• La relation pendant la vente ;
• La relation après la vente, y compris le service après vente.

Une solution CRM, c’est une solution qui doit permettre de gérer l’ensemble des données et des processus liés à la relation entre l’entreprise et les clients.

SugarCRM est l’un des acteurs clé de ce marché, et le leader des solutions open-source.

SugarCRM commercialise différentes version de sa solution, et la version de base, déjà très complète, est gratuite. Les versions plus complètes sont payantes avec des prix somme toute raisonnables (de 275 $ à 450 $ par utilisateur et par ans).

Avoir une solution open source est important dans ce genre d’application. Par définition, cette application est au coeur du système d’information, et c’est donc important pour l’entreprise d’avoir la main sur le code source.

OpenSugar est une application écrite en PHP 5, utilisant une base de donnée (souvent MySQL, mais OpenSugar supporte d’autres bases).

Pour le e-commerce, le CRM est tout simplement vital !

La suite au prochain épisode !

Le fondement même de la qualité, en matière de logiciel, passe par l’abstraction.

Si on veut écrire un logiciel apte à évoluer, on doit le concevoir sous la forme de modules.

Un module, c’est un ensemble de programmes, qui doivent résoudre un problème bien défini.

L’abstraction, c’est l’idée qu’on peut définir et programmer un module, sans aller voir dans les modules voisins : ceux avec qui les programmes discutes, a côté donc mais également en dessous.

Ainsi, quand on développe une application Windows par exemple, on a besoin de connaitre les API de Windows. Pas son fonctionnement intime.

Et bien actuellement, il me semble que cette idée est bien mise à mal. Quand on développe un service Internet, il est difficile de se positionner dans cette posture. Tout est incroyablement entre-mêlé.

Ainsi, pour mettre en ligne un service, qui va devoir supporter de grosses montée en charges, on doit tout prendre en compte, et avoir une culture qui mêle base de données, réseau, serveur Internet, …

C’est bien entendu une situation temporaire, qui met en avant la fragilité des architectures actuelles, et de la non maturité des solutions mises en oeuvre.

Ceci étant dit, il faut bien avancer et on doit faire avec !