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