Je suis tombé sur une vidéo expliquant très simplement le concept du SaaS :

Utile pour comprendre ce qui se cache derrière cet acronyme barbare ;).

L’expérience montre que la plupart des éditeurs SaaS se préoccupent du sujet pricing sur le tard. C’est pourtant une problématique clé qui impacte l’application elle-même et son architecture.

Plusieurs raisons peuvent expliquer cette faiblesse : Vision à long terme défaillante, tâtonnements dans l’élaboration du business model, priorité axée sur une mise en ligne le plus rapidement possible du service, difficultés techniques à surmonter.  En reportant ce sujet, on s’expose à des difficultés difficilement surmontables par la suite.

Est-ce raisonnable de risquer une situation de blocage à un moment clé de l’expansion d’un projet ? Lorsque un produit atteint un niveau de maturité intéressant pouvant séduire de nouveaux profils, on découvrirait ce nouveau sujet devenu absurdement complexe ? à savoir :

1) Quel modèle de prix mettre en place ?

2) comment l’intégrer à l’application existante ?

Concernant le point 1), la plupart des éditeurs ont (espérons-le) une expérience solide de l’élaboration de modèles de prix. Cependant, difficile de passer sans douleur d’un modèle archaïque (1 transaction ponctuelle) à un modèle s’inspirant des opérateurs télécoms, où la grande valeur de l’éditeur réside dans la capacité de fidélisation de ses clients.

Pas facile non plus de trouver l’unité de comptage la plus pertinente. Sur ce point, mieux vaut rechercher la plus simple, même si elle est imparfaite (Basecamp - tarification au nombre de projets, Message Business - tarification au nombre d’emails envoyés…)

Pour le point 2) Une fois esquissés les contours de ce modèle de prix de type abonnement, vient la problématique - ardue - de l’intégration du système de facturation. Les impacts sur l’application elle-même sont nombreux, des incohérences de fond pouvant alors émerger. Je pense notamment à un cloisonnement des données absent ou au contraire trop important qui donnerait du fil à retordre aux traitement de facturation. En définissant en amont les informations clés liées à la facturation, on gagne grandement en souplesse par la suite - on évite en prime quelques casses-têtes et maux de têtes… -.

Le mieux reste de mettre en place toute l’infrastructure de son système de facturation dès la version beta de son service. Plus facile à dire qu’à faire, étant donné que cette période est riche de problématique techniques à résoudre. D’OÙ l’intérêt de systèmes out-sourcés, qui peuvent se plugger sur un service SaaS, solution que j’évoquais il y a quelques semaines.

Cyrille

J’ai manqué de réactivité sur le coup, mais mieux vaut tard que jamais. Je souhaitais faire un retour sur la dernière annonce de google, le lancement de Google App Engine.

A la manière de Salesforce via Force.com, Google va proposer une offre PaaS (Platform-as-a-Service). Google App Engine permettra de développer puis d’héberger en SaaS des sites dynamiques.

Les limitations sont pour le moment très structurantes :
- le langage supporté est obligatoirement Python.
- un accès un compte gratuit (limité à 500 MB de stockage et 5 millions de pages vues) maximum par mois.

Je n’ai que peu d’infos sur le sujets, mais Google App Engine parait bien placé pour séduire les porteurs de projets persos ou startups.
En ce sens, Google parait mieux positionné que Salesforce. Le peu d’attrait de la plateforme Salesforce pour les startups a par ailleurs été récemment soulevée, et l’appétence pour Force.com est plutôt à chercher du côté des grandes DSI.

Amazon reste de son côté axé sur l’hébergement à la demande.
Les 3 géants du SaaS - Salesforce, Amazon et Google - ne s’affrontent donc pas encore frontalement (pour combien de temps ?).

Pour en savoir plus, des questions réponses sur Google App Engine (en anglais) :
http://redmonk.com/sogrady/2008/04/09/clouds-rolling-in-the-google-app-engine-qa/

En mars a eu lieu la conférence SaaScon à Santa Clara (Californie). Saugatuck y a présenté les résultats d’une enquête mondiale concernant le SaaS.
Le compte-rendu de cette enquête dégage les toutes dernières tendances du secteur. Merci a Hervé Gonay de Smartline Systems qui m’a transmis ce lien.

Les résultat sont classés selon en 7 points :
1) Le taux de pénétration et d’adoption du SaaS continue de progresser pour toutes les entreprises, de toutes tailles confondues. L’adoption est d’ailleurs de plus en plus acceptée pour des projets coeur-business.

2) Le SaaS est mondial : En europe, le décalage est d’environ 12 mois par rapport aux USA. Le taux d’adoption est donc sur le point d’exploser, sous l’impulsion de la GBR, du bénélux et des pays nordiques.
La France et l’Allemagne suivent ensuite avec l’Asie. le décalage est alors de l’ordre de 18 à 24 mois, mais la courbe de croissance est pressentie comme étant identique.

3) 84% des responsables IT sont satisfaits ou très satisfaits des solutions SaaS. Ce niveau de satisfaction client est exceptionnellement élevé.
Tout particulièrement pour les besoins correspondants à la première génération de logiciels SaaS (voir schéma ci-dessous ‘Wave I’). Les points forts du SaaS en théorie se vérifient alors dans la pratique : fonctionnalités, temps de réponse, disponibilité, prix.
Concernant les besoins de la 2ème et 3ème vagues de croissance du SaaS, qui demandent plus d’interopérabilité, du workflow personnalisé, des intégrations de process et de doonnées, les solutions SaaS ne sont pas encore au même niveau (voir schéma ci-dessous ‘Wave II’ et ‘Wave III’).

4) Les logiciels SaaS stand-alone dans la première vague gagnent en capacité d’intégration avec les architectures des entreprises, que ce soit par l’intérmédiaire des services Web (vague 2) puis par l’intégration et le management des process (vagues 3 et 4).

5) Le nombre de plateformes SaaS explosent. Leur niveau de robustesse et d’ouverture se renforce rapidement.

6) Les revendeurs migrent en masse vers le SaaS. Mouvement peu évident pour beaucoup, car ils doivent s’adapter à de nouveaux modes de travail, de nouvelles technologies et une culture différente.

7) Le nombre de fusions-acquisitions augmentera certainement.

En somme que du bon ! (et l’océan n’est pas encore rougeoyant ;) )

Cyrille

Pour mieux comprendre comment les fonctionnalités de type réseau social peuvent s’intégrer dans les logiciels d’entreprise, j’ai évoqué en premier lieu comment ces fonctionnalités s’intègrent aux services Web2.0. Seconde étape, j’applique à présent la même démarche aux services professionnels. Certains d’entre eux sont des pionniers dans l’intégration de fonctionnalités sociales :

My Quire (gestion de projet) :
- Goupes : Créer à chaud une organisation matricielle transverse, pour s’adapter au changement.
- Networks - friends : Identifier les réseaux mixtes pro-perso.
- Profil : Visibilité accrue des contributeurs pour mise en relation avec vie réelle et numérique.

BlueKiwi (Enterprise Social Software) :
- Gérer des communautés : Créer à chaud une organisation matricielle transverse, pour s’adapter au changement.
- Réseau social automatiquement représenté sous forme de nuages de tags (pas déclaratif) : Connaître le réseau interne d’un collaborateur. Identifier des personnes clés.
- Collaborateurs les plus impliqués sur un sujet : Identifier les experts et leaders d’opinion dans l’entreprise. Identifier des personnes clés.

Feedback 2.0 (Dans une position intermédiaire pro/grand public, Feedback2.0 propose une plateforme de feedback impliquant les communautés d’utilisateurs/clients) : 
- meilleurs contributeurs : Valorisation de l’utilisation intensive du service. Valorisation de la valeur ajoutée apportée par les contributeurs.  Permet d’identifier les experts d’une thématique.
- profil des contributeurs : Visibilité accrue des contributeurs pour mise en relation avec vie réelle et numérique.

Deux remarques principales, les fonctionnalités de réseau social intégrées à des logiciels pros permettent de :

1) Créer manuellement ou automatiquement une communauté autour d’une thématique ou d’un projet donné.

2) Identifier les experts et leaders d’opinion pour une thématique.

Si on compare l’intégration de fonctionnalités sociales dans les services web2.0 grand public et dans les logiciels d’entreprises, on note :

- une multiplicité de moyens d’échanges informels qui reste plus variée dans les services web2.0.

- un structuration plus forte des communautés pour les services destinés aux professionnels, qui répond principalement à un besoin de confidentialité.

Voici un résumé sous forme de mapping, qui met en avant les 2 points précédents, en classant les services web étudiés selon la variété des échanges entre utilisateurs (ordonnée) et la capacité à structurer de communautés au fil de l’eau (abscisses). Vous pouvez cliquer sur l’image pour l’agrandir.

Les logiciels d’entreprise gagneraient à augmenter le niveau d’échanges entre utilisateurs pour fidéliser et dynamiser les communautés.

De son côté, Feedback 2.0 a une position atypique car traite un usage très concis à la manière des services web2.0 grand public. Il a su également s’en inspirer en travaillant sur l’implication des utilisateurs.

Dans tous les cas, la notion d’entreprise étendue (entreprise + partenaires, fournisseurs, consultants, clients…) est peu présente. Il est certes possible de la traiter dans certains outils, mais elle n’est ni explicite ni gérée finement (prérequis pour traiter les problématiques de confidentialité et sécurité).

Cyrille