Dans le cadre très agréable du quai Grenelle à Paris s’est déroulé hier la conférence sur le SaaS organisée conjointement par MySaaS (Global SP) et Smartline Systems.

 

 

 

 

Jean-Christophe taunay-bucalo (en photo ci-dessus), responsable marketing de MySaaS a brillament joué le maitre de cérémonie et introduit les présentations de la matinée. Voici un résumé de mes notes, dans l’ordre de passage des intervenants :

 

Marc Tretiakow, responsable d’exploitation chez Global SP

Global SP est spécialiste de l’infogérence externalisée, notamment pour les applications SaaS. L’offre destinée aux éditeurs SaaS est packagée sous la marque MySaaS.

 

Marc Tretiakow a insisté sur le changement de paradigme suivant : l’enjeu technique d’une solution SaaS est de passer d’une garantie de moyens à engagement de résultat.

Le client n’a plus la responsabilité ni de l’hébergement ni de l’exploitation de son logiciel. Il a donc des exigences en termes de qualité de service et de niveau de disponibilité auxquelles il faut répondre.

 

Cette responsabilité est assumée de manière conjointe par l’hébergeur et par l’éditeur. Le périmètre de responsabilité de chacun doit être précisément défini, notamment pour la partie exploitation généralement assumée par l’hébergeur, mais que l’éditeur impacte parfois via des requêtes sur les bases de données.

 

D’autre part, le processus de mise en production est critique, étant donné qu’un dysfonctionnement éventuel du logiciel impacte TOUS les clients.

 

 

Henri-Michel Rozenblum, président de l’ASP forum

Henri-Michel Rozenblum a proposé une mise en perspective stratégique de l’ASP et du SaaS. La différenciation ASP et SaaS était masquée dans le discours, ce qui a malheureusement aboutit à un certain flou par moments. 

 

Le contexte stratégique :

- le TCO du SaaS est plus élevé que pour les logiciels en mode intranet.

- En 2008, 39% des sociétés de 500 à 999 opteront pour un ERP en SaaS.

- CA mondial du SaaS de 3,5md€ en 2007 et 7,5md€ en 2011 (Gartner).

- Croissance annuelle de 25% pour les logiciels SaaS en France.

- Les applications phares sont de type CRM, collaboratif, stockage et erp.

- Tous les poids lourds du logiciel se mettent au SaaS (parfois plutôt SoSaaS*…)

- Les marchés les plus ouverts au SaaS sont : 1 technologie, 2 finance, 3 media.

 

Les enjeux stratégiques :

- Passer de l’ASP au SaaS est critique lorsqu’on a vise de nombreux clients de taille réduite (cibler la longue traîne n’est pas réaliste en mode ASP/dédié).

- L’ASP/SaaS lève un vrai frein pour le développement international.

- Différence du SaaS par rapport à un éditeur traditionnel :

       > imputation des coûts d’hébergement à prendre en compte en SaaS

       > support moins cher en SaaS

       > frais de R&D plus faibles en SaaS, car moins de spécifique.

 

La profitabilité des éditeurs SaaS :

- 25% pour éditeurs traditionnels contre 15 % pour éditeurs SaaS, mais webex, leader sur marché le plus mature du SaaS, est à 25%. 

- A noter que les éditeurs SaaS vendent moins de consulting que les éditeurs traditionnels. Pas étonnant étant donné les délais de déploiement en mode intranet…

 

Les facteurs clés de succès :

- Une excellente organisation du support niveau 1

- 0 bug car chaque release affecte tous les clients

- Garantir un TCO < à TCO d’un éditeur traditionnel

- Peaufiner son argumentaire auprès des DSI : “ce n’est pas coeur business de développer, mettre en ligne et exploiter des services avec garantie de taux d’accessibilité.”

 

 

Interview de christine O’meara, product manager Microsoft Dynamics CRM

 

Jean-Christophe Taunay-Bucalo : Qu’a changé dans l’application pour la V4 et qui permet de dire que c’est du SaaS ? […]

Christine O’meara : […]On faisait de l’intranet ou asp. On ne savait pas mutualiser le service applicatif. […] Ca avait un impact sur le modèle économique de nos clients […]

 

JCTB : As-tu un retour d’expérience sur un client étant passé en mode SaaS ?

CO : […] Au lieu de parler d’un client en particulier, je vais plutot parler pour la globalité de nos clients […] La demande n’est pas très forte chez microsoft Dynamics pour les PME. […] Plutôt pour les grands comptes pour un département en particulier. […] Il y a une volonté des clients d’être rapidement dans l’utilisation du produit, quitte à effectuer des améliorations par la suite. […]

 

JCTB : Le mode SaaS est-il un épiphénomène chez Microsoft Dynamics ?[…]

CO : […]Le mode SaaS est une alternative de déploiement pour nos applications. Chez Microsoft on veut proposer toute la palette des options à nos clients. C’est aussi ce qui nous différencie de certains des acteurs du marché […](ndlr : salesforce par exemple)

 

Questions-réponses avec l’assistance :

 

Q1 : Avez-vous une solution paas ?

CO : Nous proposons un accompagnement pour les partenaires afin qu’il développent leur offre SaaS avec Microsoft (ndlr : donc pas réellement du PaaS).

 

Q2 : Quelle est votre différenciation par rapport aux grands acteurs du marché ? (oracle, sap…)

CO : La commission de la revente en mode SaaS est relativement faible. Ceci permet à nos revendeurs d’avoir des marges satisfaisantes.

Microsoft essaie de se différencier par un haut niveau de connaissance du client et de ses outils.

 

 

 

Arnaud Tessalonikos - Abaque avocat

Le passage d’une garantie de moyens à un engagement de résultat impacte directement les contrats qui lient un éditeur à ses clients et à ses fournisseurs.

Lors de cette présentation, il s’agissait donc de parcourir les spécificité d’un contrat SaaS.

 

L’architecture contractuelle doit aborder les points suivants :

- Prestataire saas, Fournisseur hardware, Editeurs, Autres frais infrastructure, Utilisateurs, Sécurité (par exemple, les recommandations de la CNIL pour les mots de passe), solution de backup, FAI ,Réglementation.

- Poser le curseur : à partir de quand le client est son propre assureur - définir seuil acceptable par le client

 

Etude de cas : Si un problème de performance lié au temps de latence apparaît, comment définir les responsabilités ?

Pour savoir prouver la mise en cause de telle ou telle partie prenante, il faut définir lors du contrat initial comment administrer la preuve de bon fonctionnement de chacun des tenants/partenaires délivrant le service.

 

Autres recommandations :

- Ne pas transférer plus de droits qu’on en détient.

- Les clauses sont importantes dans le cas d’une exécution imparfaite du contrat.

- Je suis responsable de ce que je fais mais que ce que je fais, pas ce que font les autres.

- Travailler sur les discussions juriste - technique pour qualifier le régime juridique du service.

- Définir les clauses pour enjeux majeurs/spécifiques de la profession du client : clause de secret, politique sécurité, sauvegardes, perquisitions, responsabilités (définir matrice de responsabilité, également pour le client).

 

 

Hervé Gonay - président Smartline Systems

Le métier de Smartline Systems consiste à aider les éditeurs SaaS à avoir un gotomarket plus rapide. Smartline Systems intervient donc sur les aspects marketing et commerciaux.

 

Hervé Gonay a présenté la courbe d’adoption du SaaS pour replacer le contexte. Les Etats Unis se situent juste après le point d’inflexion (ou tipping point). La France a environ 2 années de retard. 

 

 

 

En s’appuyant sur l’expérience de Smartline Systems, Hervé Gonay a ensuite présenté une liste des best practices marketing à suivre pour un éditeur SaaS :

 

- Sponsoring/Adwords

- WOM (être en relation avec blogueurs, écrire un blog).

- BDD marketing.

- Online : exploiter au maximum son site web.

- Evenementiel.

- Télémarketing : 80% du cycle de vente peut s’effectuer via se canal.

- Site Web :

        > Se concentrer sur 3 axes : description produit, démo, call to action

        > communiquer sur le TCO, la rapidité de mise en oeuvre et le SLA

        > SEO : 5% des visiteurs effectuent une demande de contact

- Présence online :

        > réseaux sociaux : avantage de proximité dans la relation avec le client.

        > places de marchés.

 

2ème thématique abordée, la génération de leads :

 

Via l’achat direct de leads :

- Site spécialisés.

- Apporteur d’affaires (commission entre 10 et 20%).

 

Via l’emailing :

- Trouver la BDD (jamais facile…), idéalement acheter la base. Le ROI n’atteint pas des sommets, mais ça reste efficace. Pour l’optimiser, il faut effectuer du tracking (par exemple avec la solution Euclead)

 

Via les salons :

- Coût entre 3000 et 4000 euros.

- Entre 30 et 50 leads par jour de salon, peut aller jusqu’à 100 avec techniques optimisées. Hervé a cité un exemple d’éditeur SaaS générant 3000 leads par an par ce canal.

- Door opener pour rappeler.

 

Via le tracking :

- Webleads, nouvelle offre proposée par Smartline Systems, vise à identifier les visiteurs les plus actifs de son site web pour les transformer en leads.

 

Via le télémarketing :

- Viser 3 telemarketeurs pour 1 vendeur physique. Y mettre des séniors pour pouvoir gérer 80% du cycle de vente en telemarketing.

 

3ème thématique, les facteurs clés commerciaux et marketing :

 

- La vente Grands comptes : La + grande partie de la négociation est généralement passée sur le Service Level Agreement. Si on reprend la courbe d’adoption du SaaS, en vague 1 les DSI peuvent être évités car les solutions SaaS sont verticales et stand alone, mais ils sont inévitablement mis dans la boucle en vague 2, où l’éditeur doit démontrer que la solution est intégrable avec le SI existant.

- Le support : Une réactivité très forte indispensable.

- Les modèles de vente directe ou indirecte : Salesforce fonctionne en vente directe et tente une approche indirecte (donne au revendeur uniquement le CA généré par l’intégration), Ines est en full indirecte (partage avec le revendeur la marge et le CA à l’intégration), netsuite est en full indirecte.

Offre smartline systems : approcher des éditeurs pour intégration commerciale à d’autres offres

 

Pour conclure, Hervé a évoqué les perspectives d’évolution de la deuxième vague (cf courbe d’adoption ci-dessus). En voici 2 principales :

- Être prêt à s’intégrer à une plateforme d’intégration. Chez ondemand solutions, intégration par l’intermédiaire de runmyprocess

- Etre référencé sur les places de marché. En France, www.ondemand-solutions.com propose un référencement gratuit.

 

Questions-réponses avec l’assistance :

 

Q1 : quel est le coût de génération d’un lead ?

Hervé Gonay : […] CRM est très cher : Sur Google, le clic coûte entre 5 et 10$ […]. Il faut savoir de quoi parle-t-on ? […] Si on définit un lead = opportunité de contact, […] alors pour des fonctionnels, le coût au lead est d’environ 40€. Entre 450 et 800 € pour un projet qualifié. […] Avec Webleads, le coût d’un lead […] (nom de la société + quelques infos) est de 25€. […]

 

 

Ceci n’est qu’un résumé rapide et certainement incomplet, n’hésitez donc pas à l’enrichir de vos remarques ou corrections. Bravo encore à Smartline Systems et MySaaS pour le succès de cette conférence la qualité de l’organisation !

CODA, leader européen des systèmes financier, a lancé Coda2Go, premier système comptable d’entreprise entièrement développé et exécuté sur la plate-forme Force.com de salesforce.com.

 

Cette décision d’utiliser Force.com est extrêmement intéressante, car il s’agit du projet le plus ambitieux développé jusqu’à présent sur la Plateforme-as-a-Service PaaS (PaaS) de Salesforce. Aucun leader ne s’y était encore aventuré.

 

 

Pour quelles raisons Coda a-t-il choisit Salesforce ?

 

1) CODA s’appuie historiquement sur d’autres plateformes :
CODA est un habitué des migrations vers les plateformes les plus en pointe du moment. Dès la fin des années 1970, CODA écrivait ses applications pour l’HP 3000. Puis, dans les années 1980, CODA migrait vers la plateforme VAX, avant de choisir l’AS/400, et finalement l’architecture client/serveur dans les années 1990. Les années ont passé, Salesforce a révolutionné le logiciel, et c’est donc logiquement que CODA a considéré une migration vers (Sales)Force.com.

 

2) CODA était client de Salesforce, et pouvait donc apprécier les qualités et le potentiel de la solution.

 

3) Avec Force.com, CODA diminue drastiquement le temps de création de son offre : CODA a construit de A à Z sa nouvelle version SaaS grâce aux outils de développement Salesforce, sans se préoccuper de l’architecture technique sous-jacente (plusieurs années de mise au point nécessaires)

Grâce à cet accélérateur, CODA dispose en un temps record d’une avance considérable sur la concurrence : CODA est la première solution SaaS de gestion financière pouvant justifier une qualité maximale.

 

4) Coda2go sera rentable rapidement : 

Salesforce dépenserait 14% de son CA pour le fonctionnement de son infrastructure SaaS (Source  Bob Warfield).
CODA, ayant une tarification débutant à 125$/utilisateur/mois hors options consacrerait moins de 30% du revenu d’un utilisateur à la mise à disposition du produit, ce dès la première année. Un objectif qui aurait été inateignable en construisant de zéro une nouvelle plateforme .

 

5) Salesforce va générer des leads pour CODA :
Coda propose une intégration très fluide avec Salesforce : Une opportunité transformée dans Salesforce déclenche en un seul clic la génération de la facture et l’imputation de la transaction en comptabilité. Dans un seul outil intégré, l’entreprise balaye l’ensemble du processus marketing et commercial, jusqu’à la signature de l’affaire et la collecte du règlement.
Cette promesse de simplicité séduira certainement des clients habitués à Salesforce.

 

Quoiqu’il en soit, Coda2go sera un test déterminant pour le succès de la plateforme Salesforce, car CODA pourrait ouvrir la voie à d’autres éditeurs de poids.

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/