Archives par mot-clé : Software

Quel pricing pour les offres SAAS ?

Le SAAS est l’avenir de nos systèmes informatiques, en particulier pour le e-commerce.

Pour que cette mutation se fasse, il faut que les offres matures voient le jour, avec des prix adaptés.

Le modèle Salesforce

La star du SAAS, c’est Salesforce.com (solution qui permet de gérer les données liées à la prospection commerciale et au suivi de la relation avec les clients).

Le prix est principalement basé sur le nombre d’utilisateurs. Le prix d’appel est de 20$ par utilisateur et par mois.

Le modèle de prix est excellent : pour une petite boite, avec par exemple 2 ou 3 comptes, le prix est très bas.

Et puis, les revenus d’une boite sont toujours liés aux nombres de commerciaux. Le prix de la solution s’adapte donc très bien aux petites boites et aux gros groupes.

A l’autre bout de la chaîne, l’exemple d’Amazon

Amazon propose également des solutions SAAS, mais en « partant du bas ».

Amazon propose, avec S3, une solution de stockage et d’hébergement de services en lignes.

Voici la grille de prix proposé par Amazon :

Storage
$0.18 per GB-Month of storage used

Data Transfer
$0.10 per GB – all data transfer in

$0.18 per GB – first 10 TB / month data transfer out
$0.16 per GB – next 40 TB / month data transfer out
$0.13 per GB – data transfer out / month over 50 TB

Requests
$0.012 per 1,000 PUT or LIST requests
$0.012 per 10,000 GET and all other requests*

Comme vous pouvez le voir, le prix est 100% basé sur l’usage. On paye le stockage et les flux, entrants et sortants.

L’avantage de ce modèle est qu’il est lié aux coûts d’Amazon (qui doit acheter des disques pour stocker les données, et acheter de la bande passante).

Ce modèle présente à mon avis deux inconvénients :

  • Il n’est pas forcément évident, pour l’utilisateur, d’anticiper le prix de la solution ;
  • Le prix n’est pas dépendant des revenus. Cette solution sera très avantageuse pour certains, et très cher pour d’autres.

Les exemples liés au e-commerce

Plusieurs éditeurs de logiciels proposent dès aujourd’hui des solutions de type SAAS. Je pense en particulier à des solutions de moteur de recherche, à intégrer dans les sites marchands.

A mon sens, les solutions ne sont pas très matures (en tout cas au niveau du « packaging », de l’offre. Un signe qui ne trompe pas : impossible d’avoir une grille de prix. On est en fait sur du « sur mesure ».

Autre point : ces solutions visent plutôt les gros acteurs. On comprend la logique : il vaut mieux vendre une solution chère à un petit nombre d’acteurs que diluer son effort commercial, avec des petits revenus pour chaque vente.

C’est vrai, mais :

  • La concurrence est très rude : tout le monde cible les « gros poissons » ;
  • Le principe même du SAAS, c’est qu’on peut cibler tout le monde, y compris les petits acteurs, et qu’on y gagne de l’argent, avec un modèle du type ‘les petits ruisseaux font les gros fleuves ».

Autre élément : ces solutions sont aujourd’hui assez « technique » à mettre en œuvre. On est loin du « plug & play ».

Quel avenir ?

Les solutions doivent donc s’améliorer, avec une mise en œuvre plus rapide, et donc une interface plus simple, mieux travaillée (marrant, ça fait référence, sans que ce soit prémédité, à mon billet précédent).

On doit trouver un prix acceptable pour les petites boites et dans le même temps un prix qui rapporte suffisamment pour permettre à l’éditeur de vivre, en faisant évoluer la solution (investissement R&D).

Prenons l’exemple d’un moteur de gestion de catalogue, en SAAS donc.

Quels peuvent être les éléments de pricing :

  • Eléments « physiques » :
    • Nombre de produits ;
    • Espace physique occupé (un peu comme S3) ;
    • Nombre de visites ;
  • Autres critères :
    • Nombre de produits vendues par mois ;
    • Chiffre d’affaires ;
    • …

Le chiffre d’affaire est un critère qui peut sembler intéressant pour l’éditeur, mais il est délicat à faire accepter par les clients en général et par le e-commerçant en particulier.

Les critères physiques ont l’avantage de l’objectivité, mais cela ne me semble pas parfait non plus : un commerçant peut démarrer avec beaucoup de produits, sans pour autant avoir des revenus importants… Un peu comme si Salesforce.com nous faisait payer au nombre de contacts.

Vous le voyez, il reste du travail…

Autres articles sur le sujet :

L’art de l’abstraction

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.

Les couches logicielles

Couches, du hard vers l'applicatif

Donc, à la base, il y a du matériel.

Pour donner vie à ce matériel, on rajoute un système d’exploitation.

Par dessus ce système, on ajoute des applications.

Une application bien particulière est le navigateur Internet.

Ensuite, nos services Internet peuvent prendre vie, soit directement dans le navigateur, soit via une extension, Flash ou Java.

Chaque flèche indique un endroit pour développer une application.

Live from OnAir

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

CRM / SugarCRM – Partie 2

Voici donc la suite de mon billet sur le CRM et SugarCRM.

SugarCRM donc.

L’application permet, à la base, de gérer les données suivantes : Contact, Compte (regroupe plusieurs contacte), Affaire (associée à un Compte), Evènement (appel téléphonique, mail)…

Mais le modèle est particulièrement évolutif. Fondamentalement, le système permet de gérer… des données ayant des relations entre elles (on peut difficilement faire plus générique !). C’est pourquoi SugarCRM peut être utilisé pour des applications très variées, bien loin du modèle initial.

Autre sujet intéressant : comment brancher un site marchand sur le système de CRM ?

2 approches : on peut avoir les deux systèmes séparés, chacun ayant sa propre base de données.

Avantage : c’est propre, et les activités « back » ne viennent pas impacter ce qui se passe au niveau du Front.

Le problème est qu’il faut alors synchroniser les bases. Cette synchronisation va nécessiter un développement spécifique, qu’il faudra faire évoluer en permanence, pour des évolutions sur le front ou sur le back.

Autre solution : tout construire sur SugarCRM. Un client d’Ysance l’a fait, et ça marche très bien.

L’avantage est évident : un seul modèle de données, rien à synchroniser.

Problème ? Il faut être attentif à ce que les opérations du back n’impactent pas trop les performances du site. Cela va bien pour un site ayant un trafic « raisonnable ». C’est une bonne solution pour commencer, il sera toujours temps de faire évoluer le modèle.

CRM / SugarCRM – Partie 1

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 !

Avancer vite, ou sécuriser ?

Dans notre secteur, le e-commerce, une part importante des investissements est affectée au développement du système informatique : front-office et back office.

C’est un investissement important parce qu’il y a beaucoup de choses à développer : front, administration du front, gestion du processus de livraison, lien avec les systèmes des transporteurs, CRM, emailing, moteur de recherche, lien avec les plate-formes d’affiliation et moteurs de shopping, système de gestion du SAV, gestion du stock, …

Il n’existe pas de solution clé en main, couvrant tous les besoins. Il faut donc construire le système, à partir de différents composants, et réaliser les développements pour adapter ces composants au contexte de l’entreprise, et pour faire l’intégration entre les composants. De plus, l’activité e-commerce vient bien souvent compléter un système d’information déjà en partie construit : on arrive rarement en terrain vierge !

Comment font les entreprises pour développer leur système informatique ?

Plusieurs cas de figures bien entendu. Les grosses entreprises, ayant un gros système informatique, peuvent confier la mission de la mise en ligne d’un site marchand à l’équipe informatique. Dans ce scénario, on arrivera sans doute à un processus technique assez classique, avec cahier des charges, appel d’offre, …

Mais bien souvent, dans les petites structures, les moyens mis en œuvres seront beaucoup plus artisanaux : un développeur, et hop, le site est en ligne, avec bien souvent développement 100% maison.

Si le développeur est bon, le système peut marcher, et tenir quelques années : 2, 3, … 5 ?

C’est clairement le moyen le plus économique pour mettre en ligne un site marchand.

Le problème, c’est que tout l’édifice repose alors sur le savoir faire un peu magique d’un seul homme.

L’autre problème, c’est que l’entreprise aura une vision des développements très « particulière », puisque « la toute petite équipe technique » fonctionne sur un mode complètement informel, et que le développeur peut ainsi faire des modifications très très rapidement.

Plus tard, quand les revenus deviennent important, d’autres aspects surgissent : la fiabilité, la sécurité, …

Il faut alors changer de méthode, mettre en place de la redondance, à tous les niveaux (hard, humain). Tout cela est infiniment moins rapide qu’avant !

Ah là là, que la qualité coûte cher !

Abstraction or not abstraction

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 !

Le futur des applications en ligne / Lancement d’AIR demain

Demain soir a lieu le lancement officiel d’AIR d’Adobe (vous y serez ? Moi, oui !).

L’occasion de se reposer la question : quel est l’avenir des applications en ligne ?

On peut utiliser une application qui va se jouer dans le navigateur (un service Internet quoi).

Avantages :

  • L’utilisateur n’a rien à installer, donc un accès rapide à l’application, un accès depuis n’importe quel ordinateur, et pas de problème de mise à jour ;
  • On bénéficie de facto de toute les fonctions autour des URL (bookmark, copier / coller, et les effets viraux, en avec la transmission très facile de l’adresse du site) ;
  • L’utilisateur est (normalement) en sécurité, l’application en ligne ne peut pas accéder aux ressources locales de l’ordinateur : ni les fichiers sur le disque dur, ni les périphériques (micro, caméra, …). Rien excepté la zone graphique contenu dans la fenêtre du navigateur, la souris et le clavier pour entrer des données ;
  • L’interface est assez bien balisée (là aussi, normalement 😉 ), et l’utilisateur a des repères, il sait ce que c’est qu’un formulaire, qu’un lien, une page, …
  • L’application est la même, quelque soit l’ordinateur, le système d’exploitation, le navigateur (ok, je simplifie 😉 ).

Inconvénients :

  • Avec les applications évoluées, le navigateur est « décalé » : le bouton back est inutilisable, l’application a besoin d’accéder à plus de ressources (caméra, …) et l’interface est un peu limité ;
  • L’application n’est accessible que quand il y a une connexion Internet (a modérer, avec les propositions de Google).

C’est donc pour donner « plus d’air » aux applications en ligne qu’Adobe a développé son AIR.

L’idée est d’avoir le beurre et l’argent du beurre.

En fait, c’est évidement pas si simple :

  • L’utilisateur doit installer l’application AIR (ok, très peu de clics) ;
  • Les mises à jour sont pratiquement transparentes : comme il y a une application locale, il faut bien mettre à jour l’application. Mais cette mise à jour est automatisée (comme la plupart des applications, aujourd’hui) ;
  • L’interface n’est plus du tout banalisée. Ce n’est pas une critique, puisque justement c’est le but, de sortir des limites du navigateur. Le résultat sera dépendant de ce que feront les éditeurs… On verra le meilleur et le pire !
  • L’application est bien la même, quelque soit la plate-forme, c’est ce qu’apporte le moteur AIR.
  • L’application peut fonctionner en mode off-line, cela dépend de l’application (l’application eBay en mode off-line n’est pas opérationnelle) ;
  • On peut bien sûr se passer l’url qui pointe vers la page d’installation de l’application, mais il est certain qu’on n’aura pas le même niveau de viralité par rapport aux URL…
  • La sécurité : ah, je suis impatient d’en savoir plus demain. Adobe devait y travailler, c’est évidement un sujet clé.

Dans une application AIR, le runtime AIR n’est pas visible, seule l’application apparait sur le bureau de l’ordinateur.

La gestion des applications est donc laissée au gestionnaire de fichier de l’ordinateur.

C’est là que je reviens avec mon idée, d’un navigateur sans bord de fenêtre… C’est peut être un compromis plus intéressant : garder la notion de navigateur, d’URL, mais avec certaines applications en ligne, qui prendraient la main sur la fenêtre du navigateur.

Pourquoi ?

  • Pour garder justement la notion d’URL et tous les avantages associés ;
  • Pour avoir le double mode : service Internet ou service « application » ;
  • Pour simplifier encore plus les processus d’installation ;

Mais voilà, Adobe ne me demande pas mon avis pour spécifier ses produits. Microsoft non plus remarquez !

La troisième voie pour le logiciel

Au début, c’était simple.

Le logiciel est édité par des éditeurs, qui vendent leur logiciel le prix qu’ils veulent.

Microsoft, Oracle, SAP…

Tous ces acteurs se sont ainsi « goinfrés » avec des prix sans rapport avec les coûts de fabrication, et des abus de tous ordres, comme une maintenance soit disant évolutive, pratiquement obligatoire et cher (en général 20% du prix d’achat), qui n’a d’évolutive que le nom, car l’éditeur ne se gênait pas pour sortir une nouvelle version du logiciel, non couverte par la maintenance (obligé de tout repayer donc si on veut la dernière version)….

Ces abus ont ouvert la voie au logiciel libre.

Des « étudiants chevelus » se sont associés pour travailler ensemble sur des logiciels, qui marchent, qui sont gratuits, et qui sont livrés avec le code source, modifiable donc par les utilisateurs.

Je pense que ce modèle est très bien dans certains cas, mais ne peut pas être généralisé. A mon sens, c’est réducteur. Pourquoi une entreprise qui investi dans du logiciel ne pourrait elle pas en vivre, en vendant son logiciel ?

Je sais que cette discussion peut générer des passions, l’open-source, c’est parfois une religion 😉

Pourquoi l’entreprise qui a développé un logiciel devrait elle obligatoirement livrer son code source, alors qu’elle a éventuellement déployé de gros efforts pour avoir un système innovant, plus performant pour l’utilisateur.

Aujourd’hui, on navigue entre les deux modèles, la licence d’un côté et le libre de l’autre.

Je pense donc que les éditeurs de logiciels payent pour leurs « parents abusifs ».

Je pense qu’il existe une troisième voie. Je cherche un nom, j’appelle ça le « logiciel éthique » (un amis me disait que ça collait pas, parce que éthique fait référence à d’autres valeurs, …).

Bref, cette troisième voie, c’est une voie ou on fait du logiciel, pas open-source, pas gratuit, mais avec des garanties pour le client.

La principale garantie, c’est de tout mettre en œuvre pour que le client ne soit pas bloqué avec une solution unique, qu’il puisse changer de fournisseur si un fournisseur fait défaut, ou abuse de sa position.

Un logiciel, c’est un programme qui « discute » avec son entourage.

L’idée serait donc de définir très précisément les interfaces des logiciels.

Cette idée est parfaitement en phase avec ma conviction que l’avenir (ok moyen/long terme) du logiciel passe par le SAAS.

Des Composants SAAS discutent avec d’autres composants via des web services. Normaliser les échanges, c’est donc normaliser les services web des composants…

Les dernières news sur Microsoft me semblent aller dans ce sens là, mais on ne change pas de culture comme ça !