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

Un traider serait donc la cause de 5 Milliards de perte pour la SG…

Pour arriver à ce niveau de perte, il aurait spéculer sur 50 Milliards d’euros !

Au début, je ne pensais pas que c’était possible, je penchais donc pour une maneuvre pour charger un bouc émissaire de tous les mauvais placements… Puis mes différentes lectures (ici par exemple) m’ont fait douté : oui, il semblerait que cela soit possible !

Pourtant, la SG dépense des sommes colossales pour son système d’information, dont pas mal de millions d’euros pour la sécurité et le contrôle.

Que peut on en conclure ?

A mon sens, ce qui est marquant, c’est la non maîtrise de ces systèmes d’information.

Pour arriver à un tel résultat, il faut que le système ne soit pas compris par les personnes qui l’analysent.

Et le prix que l’on paye une armée de consultants n’est pas un outil de mesure de qualité…

D’où mon image : la pyramide est inversée, le système est gros et lourd, mais quelques grains de sable peuvent tout faire tomber.

Update de 20h35

En relisant mon billet, je me suis dit que j’étais pas assez explicite.

Petit complément donc.

Un système d’information, c’est du code qui s’exécute. Ce n’est pas une abstraction.

Pour analyser un système, il faut analyser le code. C’est donc pas un travaille ou on manipule des abstractions…

J’ai travaillé dans les banques dans ma jeunesse. Les documents d’analyses ne correspondent pas à ce que font les programmes… Quand il y a des documents d’analyse ! Je me souviens d’une très grosse banque, qui avait un programme très important, au coeur du système. Le programme avait été écrit avec PAC, un générateur de programmes Cobol. Quand je suis arrivé, le programme PAC était perdu, il n’y avait aucun document d’analyse… Donc, la seule façon de comprendre les règles métiers, c’était d’analyser le code généré par PAC… C’est une illustration de la pyramide inversée. Dans un tel contexte, tout peut arriver !

Microsoft préfère utiliser ses produits pour présenter ses évènements… et c’est bien normal.

Pour présenter les Techdays 2008, Microsoft a développé ce site :

Dans ce site, Microsoft met en avant la force de Sylverlight, à savoir la manipulation de video dans des contenus rich-media. Chaque “pola” est une video, et un clic sur l’une des image lance le petit film. On peut bien entendu déplacer, redimensionner, tourner chaque imagette en toute liberté. sympa.

Cerise sur le gateau, ça marche très très bien sur Mac (installation en deux ou trois clics, puis comportement très fluide).

C’est Brainsonic qui a développé ce petit site.

(Merci Manu pour le lien)

(re)Passons aux choses sérieuses !

Donc la question, c’est quelle est la façon d’organiser un service web… comme un site marchand par exemple.

En particulier, comment traiter le coeur du service, c’est à dire les bases de données ?

Habituellement, on sépare le service web en “deux parties” :

• Le front-office : c’est la partie visible par les clients du service. Pour un service e-commerce, c’est le site marchand lui-même.
• Le back office : c’est donc tout le reste. En fait, le back office regroupe beaucoup de modules (suivant la taille des projets) : CRM, emailing, outils de tracking (business intelligence), lien vers le système logistique, …

Chaque partie à besoin de bases de données pour travailler.

Comment faire ?

• Faire une seule base, et brancher tous les modules sur cette base centrale ?
• Mettre une base par module, et développer des logiciels de synchronisation, pour que les données des différents modules soient cohérentes ?

En fait, il n’y a pas de réponse systématique, et il faut prendre en compte beaucoup de paramètres :

• En règle général, il vaut mieux que le front office ai sa propre base de données, que cette base de données soit exclusive pour le front donc. L’idée, c’est que rien ne doit impacter le front office, qui est le moteur business.
• On développe rarement les modules “à partir de rien” : on utilise un “framework” pour le front, un module type Sugar CRM pour le CRM, … Or, ces modules ont leurs propres bases de données.
• Un autre paramètre est le nombre d’Internautes utilisant le Front. A partir d’un certain volume, on n’a plus le choix, il faut une base spécifique pour le Front.
• Le prix bien sûr, prix des licences logicielles et prix des développements.
• En particulier, si on a plusieurs bases de données, la synchronisation entre ces bases devient le point clé. Il faut développer des modules de synchronisation, avec des stratégies (quand doit on synchroniser, sur quels évènements). Il faut également penser aux évolutions : les bases de données sont faites pour évoluer. Il faut des modules de synchro pour gérer les versions des bases.

Dans tous les cas, il faut penser cette architecture des bases de données avec soin, c’est l’épine dorsale de tout le système.

Pour tout le monde, Amazon, c’est un boutique de vente en ligne.

Mais Amazon a également une offre SAAS qui s’enrichie de mois en mois.

Le SAAS, c’est l’idée, à mon avis promise à un très grand avenir, que les systèmes d’informations vont évoluer, et que ces systèmes seront de plus en plus répartis, et géré non pas par les entreprises directement, mais par des tiers.

Le leader du domaine, c’est bien entendu salesforce.com qui propose une solution CRM en mode SAAS donc.

C’est donc une approche “métier”, c’est à dire proposer un service, qui cible directement un besoin de l’entreprise (le suivi des contacts commerciaux en l’occurence).

Amazon propose une approche opposée, qui “part du bas”.

Ils ont commencé par S3 (Simple Storage Service), qui consiste à proposer du stockage en mode “service” : un client peut ainsi louer en ligne un espace de stockage.

Le prix est à l’usage, 100% dépendant des volumes :

• 0,18$ par GB et par mois ;
• 0,10$ par GB envoyé vers l’espace de stockage ;
• 0,18$ par GB sortant de l’espace de stockage ;
• 0,012$ par requête.

On paye donc tout, mais 100% au volume et sans limite basse. Un petit service va donc payer quelques $ par mois. On est à fond sur l’idée des petits ruisseaux qui font les grands fleuves.

Amazon a étendu son offre avec la mise en ligne d’une base de données, sur le même principe : Amazon Simple DB.

Le prix est calqué sur le modèle de S3, on paye au stockage, et aux requêtes.

Enfin, Amazon propose une offre de paiement en ligne, également en mode SAAS.

L’idée est clair : proposer des briques de bases, qui permettent de construire des applications en ligne, le plus simplement possible, et avec un prix complètement dépendant de l’usage : pas cher au début, plus cher ensuite, mais si il y a du trafic, on peut imaginer qu’il y a des revenus (quoi que ).

Je ne sais pas ce que cette expérience d’Amazon va devenir, mais je suis convaincu par l’approche, que ce soit mis en oeuvre par Amazon ou par d’autres.

C’est une analogie intéressante, que je vous propose de creuser (c’est le cas de le dire).

Comme je l’ai souvent dit, le e-commerce est mis en œuvre via du logiciel : Front office, back office, suivi des commandes, emailing, … Tous ces composants sont mis en musique via des lignes de code…

Le logiciel est un artisanat neuf, et c’est sain de chercher des repères par rapport à des industries plus anciennes.

Donc le bâtiment.

Pour construire une maison, il faut faire d’abord un plan.

En fait, avant de faire le plan, il vaut mieux creuser le besoin : nombre d’enfants, souhaits (avoir le soleil le matin, …), budget, délais, …

Ensuite, un architecte va faire le plan donc, et il va y avoir plusieurs aller-retours entre l’architecte et le client.

Après, il faut de la patience, tout le monde le sait : on rentre dans la partie réalisation. Un architecte ou un maître d’œuvre va diriger les opérations, et coordonner les activités de plusieurs corps de métier : terrassier, maçon, platrier, électricien, plombier, menuisier…. Pendant cette phase là, on ne peut plus tout changer, et plus le projet avance, et moins on peut changer de choses.

La réussite du projet final tient sur plusieurs critères :

• L’intelligence de l’architecte, pour réellement comprendre les besoins et envies des clients, qu’ils n’expriment parfois pas clairement ;
• Le savoir faire de l’architecte, pour trouver les artisans bien adaptés au projet, et les faire travailler au bon moment ;
• Le savoir faire individuel de chaque artisan : même si le maçon fait un très bon boulot, si le peintre « salope tout », le résultat final sera décevant ;

Par contre, plus les « couches basses » font du bon boulot, et plus on peut rattraper les erreurs : si c’est le maçon qui fait du mauvais boulot, il n’y a pas grand chose à faire…

On peut dire tout ça pour le logiciel :

• Comme pour le bâtiment, un logiciel doit être conçu, il faut faire des plans ;
• Il faut faire ces plans en discutant avec le « client » (équipe e-commerce de la grosse entreprise, patron pour la petite entreprise, …) ;
• Il faut avoir un bon architecte (vous avez mes coordonnées ) ;
• Il faut ensuite être très patient, parce que pour monter tout ça, ça prend du temps ;
• Enfin, le résultat final est dépendant de la qualité des artisans, individuellement.

Mais voilà, le logiciel, ça s’appelle également du soft : on croit que c’est mou.

De plus, le marketing de certains acteurs du logiciel nous laissent croire qu’on peut tout faire, tout demander, n’importe quand, et que le logiciel s’adaptera.

On le sait tous : le nombre de projets ne respectant aucun de ces « fondamentaux » est effarant : on démarre sans plan, on change de plan tout au long du développement, on recrute les équipes sans vraiment « challenger » les compétences par rapport aux objectifs, le tout se faisant sans architecte !

On rentre ensuite dans une spirale infernale, qui creuse l’écart entre les équipes marketing ou management et les équipes techniques. Pour les « marketeurs », la technique coûte cher, ne produit rien de bon, avec des délais incroyables ;
Pour les tecky, les marketeurs changent d’avis tous les jours, imposent des délais irréalistes, et ne reconnaissent pas la valeur du travail fait.

Il y a du pain sur la planche !