Le Saas (Software As A Service) est une discipline récente qui correspond bien à l'esprit du temps. Vous louez une application plutôt que de l'acheter, ou pire, de la faire développer.
Disponibilité rapide de services (il suffit d'ouvrir un compte), mutualisation des développements entre plusieurs clients, procédure simple pour arrêter le service lorsqu'on en a plus besoin.
Cela n'est toutefois pas sans poser de problèmes.
Le premier d'entre eux, toujours avancé par les DSI, concerne la sécurité. Quel est le niveau de garantie proposé par l'hébergeur de l'application, notamment en ce qui concerne la confidentialité des données de son client sur son instance mais également en ce qui concerne la reprise ou la récupération de ces données ? Il convient que l'éditeur proposant un service Saas présente toutes les garanties en la matière. Après tout, il suffit de se dire que les finances (qui sont pourtant un actif stratégique pour une entreprise) sont hébergées chez les banquiers, et non en interne...
Le deuxième problème, et non des moindres, concerne le mode de financement. Jusqu'à présent, les éditeurs de Saas que je connais proposent un système de tarification au nombre d'utilisateurs. Dans un modèle où il s'agissait de distribution de licence de logiciel, c'était assez logique. Dans un modèloe d'utilisation, cela me semble moins pertinent. Au bout du compte, cela peut représenter beaucoup d'argent et il est assez simple en ce cas pour des directions internes de tordre les chiffres pour "prouver" qu'au bout de x mois, le retour sur investissement d'un développement spécifique est plus profitable (toujours fausses ces démonstrations, car oubliant nombre de paramètres, mais tellement rassurantes...).
Il me semble que les éditeurs de Saas auraient tout intérêt à réfléchir et proposer des offres tarifaires reposant sur l'usage réel du service : l'espace occupé et le trafic. Peu importe après tout qu'il y ait 1 ou 10.000 utilisateurs. Ce qui est important, c'est la valeur créée. Et cette valeur se matérialise par l'espace disque occupé et la bande passante utilisée.
Cela permettrait certainement de simplifier la prise de décisions en proposant une offre tarifaire très concurrentielle.
D'accord avec toi sur ce nouveau modèle. Le point qui resterait à travailler alors est la formulation du prix afin que l'acheteur puisse budgéter ses dépenses, qu'il y ait un plafond.
Rédigé par: Youssef Rahoui | 15 juin 2009 à 20:16
@Youssef : Je pense qu'une piste sur le modèle de la téléphonie pourrait être envisagé. Au début, c'était facturé à la consommation. Avec le temps, on peut établir des forfaits, dépassements de forfaits...etc.
Rédigé par: jbp | 16 juin 2009 à 10:27
Complètement d'accord avec toi car c'est juste logique. Dans le monde off line les cotisations se calculent en fonction du CA, les remises en fonction du volume, etc, etc...
En plus, cela aurait l'avantage induit de récompenser l'interface la plus ergonomique, la plus fluide, la plus sympa, celle qui donne envie qu'on l'utilise....
Rédigé par: martialm | 17 juin 2009 à 07:12
@Youssef; d'accord avec toi.
Pour fixer le plafond, on peut se baser sur le nombre de comptes créés (plus éventuellement une estimation du nombre de comptes à créer durant le mois)
Pour la facturation, on se base sur le nombre d'utilisateurs actifs, c-a-d ceux qui ont accédé à la plate-forme dans le mois ...
L'entreprise sait donc combien elle pourrait payer au maximum, mais ne paie que pour l'usage effectif.
Rédigé par: Xavier B | 17 juin 2009 à 08:40
Interessant mais avec les appli 2.0 certaines peuvent aussi avoir un meilleur ROI en interne.
quoiqu'il en soit ce que tu dit est tellement vrai que certains éditeurs de suite 2.0 en SAS ont déjà largement fait évoluer leur mode de facturation pour éviter les blocages que tu mentionnes :-)
Rédigé par: Vincent | 17 juin 2009 à 11:25
Oui, la piste du mobile est intéressante. Le client pourrait automatiquement, selon sa consommation, passer d'un forfait à un plus avantageux (à l'unité mais plus coûteux sur le montant de la facture) mais il pourrait plafonner sa dépense (forfait bloqué !).
Rédigé par: Youssef Rahoui | 17 juin 2009 à 20:29
Jean-Baptiste, très intéressante analyse.
Tu sais que c'est un sujet qui me passionne. Un des principaux avantages que trouve dans le modèle SaaS est de permettre au client de se focaliser sur le développement des usages plutôt que sur une mise en place d'un outil technique/technologique.
D'une manière générale, les utilisateurs sont ravis car en SaaS la solution à laquelle ils s'abonnent est (souvent) immédiatement disponible. Pas besoin de mise en place, de déploiement, ou pire de développement (comme tu l'indiques).
Les financiers ne sont pas non plus mécontents du SaaS : ils passent d'un modèle CapEx à un modèle OpEx. Pas d'investissement en Capital que des charges opérationnelles.
Ce point est très important. En effet, dans tout lancement de projet, les bénéfices ont tendance à s'accroitre dans le temps. En tout état de cause, il y a rarement beaucoup de bénéfices au lancement.
Ce n'est qu'après un certain temps que les bénéfices surviennent. Or dans un modèle CaPex (achat de logiciel classique = Licence + Maintenance) les coûts de la solution sont très élevés avant même le lancement ! Si on résume, en CaPex : tu payes beaucoup au début avant même de commencer à envisager des bénéfices.
En mode SaaS (OpEx), de manière générale tu payes en fonction du nombre d'utilisateurs et dans le cas des réseaux sociaux (dans lequel j'évolue) cela revêt beaucoup de sens : plus il y a de monde, plus il y a de valeur créée, plus effectivement cela coûte mais surtout plus cela rapporte = gagnant-gagnant-gagnant !
Tu cites un dernier point important : la tarification à l'usage. C'est une approche très cohérente avec les points cités ci-dessus. Tu ne payes que si tu utilises réellement.
Cependant, il faut que tu saches que dans ce cas les opposants sont les services achat des grands comptes (français). Ils ont l'impression de ne pas pouvoir maitriser quel sera le coût au final de l'utilisation d'une solution SaaS quand bien même cela serait plus juste et lié à l'usage ! J'ai même entendu des sociétés me dirent "nous préférons payer plus cher, y compris pour des comptes inactifs, que ne pas être certains de ce que cela pourrait coûter" (sic)
Une évolution des mentalités est en cours et doit continuer...
Sur les premiers points je te conseille la lecture de l'excellente analyse de Julien le Nestour sur le modèle "utility pricing" ( http://www.scribd.com/doc/11984571/How-to-price-Enterprise-Social-Computing-offerings )
Rédigé par: Laurent Pantanacce | 07 juil 2009 à 17:33
Salut Laurent,
Je te rassure, je suis également un fervent convaincu de ce modèle et je pense que ça va dans le sens de l'histoire. Il va tout de même falloir du temps pour que les opérationnels qui ont un budget comprennent les notions d'OPEX et CAPEX qui doivent être un peu ésotériques pour elles. L'approche budget d'investissement, budget de maintenance (en oubliant évidemment les budgets évolutions...) paraît souvent moins douloureuse sur le papier.
Je me dis simplement que la tarification au nombre d'utilisateurs ne me paraît pas forcément la bonne solution. Tu prends pour hypothèse (optimiste) que l'ensemble des ayant droits sont actifs... Or, tu sais comme mois qu'il y a beaucoup plus de lecteurs que de contributeurs.
Je pense qu'il y a une vraie réflexion à avoir par rapport à ce qui se pratique dans la téléphonie par exemple qui me semble un des secteurs les plus proches de cette notion d'utilisateurs / usages / paiements au volume.
Rédigé par: jbp | 07 juil 2009 à 18:48