Bon le SaaS, tout le monde en parle, mais même chez les éditeurs, sa définition fait débat…

Dans le cadre de ma thèse qui je le rappelle a pour sujet “les nouveaux leviers marketing des éditeurs de logiciels BtoB loués en ligne“, je m’efforce de mettre un peu d’ordre dans tout ça. Voici ce que ça donne :

Pour définir le SaaS (Software as a Service), je me suis appuyé sur des valeurs sûres, en reprenant la définition proposée par l’IDC, que j’ai confrontée à celles des vénérables unreasonable men, Bob Warfield et Ben Kepes :

Caractéristiques d’une application SaaS :
- l’application est située directement sur Internet ou un réseau privé. L’accès à l’application se fait par le réseau pour son utilisation et son administration

- la gestion du service et de la tarification est centralisée

- Tous les clients utilisent la même instance (le même logiciel), etl’architecture est multitenant ( un tenant = un compte client/plusieurs utilisateurs). les données clients sont cloisonnées de manière virtuelle par tenant, pour assurer la confidentialité et une gestion individualisée. l’architecture multi-tenant simplifie donc la gestion de l’application pour l’éditeur car une seule instance doit être administrée par l’hébergeur. L’expérience montre qu’un seul client ne peut pas alourdir excessivement la plateforme, la qualité de service reste donc généralement stable. Des milliers de clients et utilisateurs peuvent utiliser une seule instance.

- Les mises à jour sont disponibles instantanément pour toute la plateforme car elles sont centralisées. Ces mises à jour ne nécessitent donc aucun patch à télécharger côté client : la configuration sur site client est minimale ou nulle.

- tarification par abonnement souvent basée sur le nombre d’utilisateurs, accompagnée de suppléments correspondants généralement à une qualité de service et une capacité de stockage supérieure.

Les revenus sont souvent plus faibles, mais récurrents, ce qui leur permet d’être plus prévisibles, à la manière des forfaits de maintenance pour les logiciels classiques

Cette définition exclut les software appliances et permet de différencier l’ASP (à voir dans un prochain post ;) )

Cyrille

Chaque semaine, je présente un post qui m’a marqué. Cette fois-ci, Bob Warfield livre sur Smoothspan sa vision des coûts supportés par les éditeurs SaaS.

Une des problématiques les plus complexes à relever pour les éditeurs SaaS concerne la livraison du service à faible coût.

Le tableau ci-dessous relève les dépenses engagées par certains des principaux fournisseurs de services en lignes :

Le pourcentage coût est calculé en fonction des revenus, ce qui explique de grandes variations, entre autres dûes aux différences de business model : gratuit pour google, payant aux alentours de 100$/user pour Salesforce.

En moyenne, le coût de délivrance du service est de 26%. Evidemment, les jeunes sociétés SaaS ne peuvent pas atteindre immédiatement un pourcentage si bas, mais l’essentiel est de rester concentré sur une baisse continue des coûts, grâce à un programme d’amélioration continue.

Si on se place du point de vue client, il est généralement considéré qu’un contrat annuel SaaS est en gros égal à la licence d’un logiciel hébergé sur le SI interne. Or les coûts de fonctionnement d’un logiciel en interne seraient 4x le prix de la licence, chaque année (Timothy Chou, Oracle). En reprenant les 26% précédent, on trouve 4/0.25 =16 : le coût de fonctionnement d’un logiciel SaaS est 16x moins cher que pour un logiciel hébergé en interne! On saisit d’autant plus l’intérêt du multi-tenant avec ce calcul…

Pour lire l’article (en anglais)

Cyrille

Chaque semaine, je présente un post qui m’a marqué. Cette semaine, Bob Warfield exprime les manques qui freinent la croissance du SaaS, et plus précisément du PaaS.

Le grand débat de la semaine, à l’initiative de SaaSWeek, puis repris par Unreasonable men, a concerné la viabilité du modèle PaaS.

Pour rappel, le PaaS est l’acronyme de Platform as a Service. Il s’agit d’offrir une plate-forme en ligne permettant le développement d’une application, le stockage de données et tous les outils nécessaires pour faire tourner une application multi-tenants évolutive. Ce sont donc généralement les killer apps SaaS qui, en ouvrant ensuite leur plateforme s’orientent vers une démarche PaaS.

Le débat met en lumière la difficulté de construire des applications SaaS, qui réside en grande partie dans l’élaboration à moindre coût d’une plateforme multitenant évolutive et facile à exploiter. C’est pourtant un prérequis au développement d’une offre PaaS

Bob Warfield, dans un excellent post décrit les écueils à surmonter pour construire une plateforme :

- Securité et IT

De nombreuses choses sont à bâtir, qui n’apportent pas de différenciation au produit, mais qui sont indispensables pour que l’étude de la solution puisse simplement être envisagée : sécurité, intégration au SI/intranet…

- Plateforme multi-tenant et contrôle des versions (évolutivité)

L’objectif est de mutualiser un maximum de services sur un minimum de ressource. Il faut pouvoir gérer les montées de versions, les correctifs, dans une démarche incrémentale.

- Montée en charge et gestion des bases de données

Dans un monde multi-tenant, la capacité à supporter les montées en charge parfois soudaines est primordiale. Lorsqu’on y joint le sujet des bases de données (les limites de MySQL et le coût des BDD Oracle), le problème devient corsé…

- Personnalisation et configuration

Ceci concerne à la fois la capacité à adapter la présentation (Interface utilisateur), les processus (Workflow), les objets existants, ou même ajouter des briques de code supplémentaire.

- Diminuer le coût de livraison du service

C’est un point crucial pour toute application SaaS, lorsque l’on sait que ces coûts représentent au minimum 25% des revenus pour les acteurs du SaaS (et les plus performants…). L’enjeu est donc d’automatiser tout ce qui permettra de diminuer ce coût, grâce à la croissance de la plateforme.

- Open Source + ecosystème favorable + PaaS

Une orientation Open Source (par les API notamment) crée un écosystème favorable ayant pour objectif de développer une approche PaaS. Nous avions vu dans deux précédents posts, comment une plateforme émerge puis est adoptée. Lorsque c’est le cas, les économies d’échelles décisives dans un monde multi-tenant sont très significatives.

Pour lire l’article (en anglais)

Cyrille

Chaque semaine, je présente un post qui m’a marqué. Cette fois-ci, c’est un de post de Bob Warfield, sur son blog Smoothspan que j’ai remarqué

Comment les plateformes SaaS parviennent à être adoptées et fédérer une communauté de développeurs ?

Bob Warfield souligne 3 points clés, valables pour de nombreux produits, mais qui prennent une importance considérable lorsqu’il s’agit pour une entreprise d’investir sur une plateforme, pour laquelle l’effet communautaire est un argument de poids dans sa décision:

1. Une plateforme doit avoir un aspect novateur remarquable, pour attirer une population d’early adopters
2. Elle doit répondre à un problème non résolu. D’autant plus lorsque le côté remarquable d’une plateforme, immediatement visible à son lancement n’est plus perçu, elle se doit de séduire les pragmatiques par une réduction des coûts liés à son utilisation
3. Entrer dans un cercle vertueux, où des personnes souhaitent profiter de la visibilité de la plateforme. Facebook est l’exemple le plus frappant de ces derniers mois, de nouvelles applications tierces fleurissent tous les jours, chacune espérant bénéficier de la croissance de la plateforme pour former rapidement une communauté d’utilisateurs.

Pour être pérenne, une plateforme doit atteindre une taille critique. C’est là une difficulté à surmonter. D’aucuns estiment par exemple que Ning, avec 100 000 réseaux sociaux créés, n’a pas encore atteint cette taille critique. En effet, tant qu’aucun service/réseau à succès ne se développe en se basant sur la plateforme, la preuve de concept n’est pas validée.

Pour lire l’article (en anglais)

Cyrille

Je commence aujourd’hui une nouvelle rubrique, dans laquelle j’exposerais chaque semaine un post qui m’a marqué. C’est parti !

Pour débuter, cette semaine, je vous propose Bob Warfield, sur son blog Smoothspan qui livre un article éclairant sur l’émergence des plateformes sur le Web.

A travers SalesForce, ou maintenant Facebook se dessinent des plateformes, cadres de travail (frameworks) sur lesquels peuvent se développer des applications complémentaires au coeur du service. Plus de 650 applications gravitent autour de SalesForce Automation sur la plateforme appexchange de Salesforce, la grande majorité ayant été dévelopée par des tiers. De même, Facebook compte sur sa plateforme plus de 10 000 applications réalisées par des tiers!

Il expose le cheminement de ces killer apps du web pour devenir des plateformes : en soulignant plusieurs points :

- il faut avoir la vision de cette plateforme dès le départ

- Il faut développer une killer app (plus facile à dire qu’à faire :) )

- Mieux vaut garder pour soit le côté plateforme de son service et attendre que la killer app fédère une communauté. Dévoiler ensuite la capacité de la plateforme à la communauté permettra un bien meilleur accueil et l’implication des tiers sera d’autant plus enthousiaste.

- il faut donner un maximum de moyens au tiers pour leur permettre de réussir leur intégration à la plateforme et de générer du revenu.

- c’est l’investissement engagé par des tiers sur la plateforme qui les fidélise, autant que les revenus qu’ils en tirent

Pour aller plus loin, voici son article

A très bientôt!

Cyrille