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.

Industrialiser les ventes est un sujet extrêmement difficile pour les startups. Les synthèses manquent sur ce sujet. Je propose donc ici quelques pistes de réflexions, inspirées de la formation Innovation Selling dont j’ai indirectement bénéficié. Celle-ci s’appuie sur la théorie Chrossing the chasm de Geoffrey More.

La courbe ci-dessous représente la diffusion idéale d’une innovation. Concrêtement, à chaque niveau de maturité d’un produit correspond un profil cible, plus ou moins sensible à l’innovation et apte à la prise de risque : les innovateurs, les visionnaires, les pragmatiques, les conservateurs, et les sceptiques.  Un "gouffre" sépare les visionnaires et pragmatiques.

C’est intéressant de connaître cette courbe. C’est mieux de comprendre comment l’atteindre (quand et comment approcher ces profils).

Chaque niveau de maturité du produit induit une cible, un type d’acheteur et une manière spécifique de converser avec le prospect. Il est indispensable d’adopter le comportement légitime attendu en cohérence avec le profil que le cible. Voici ci-dessous une synthèse très light de l’approche marketing adaptée à chaque phase.

Maturité de l’offre : Technologie, preuve de concept
> Quels profils cibler ? Les innovateurs.

> Qui achète ? l’utilisateur.

> Comment se positionne mon entreprise ? L’entrepreneur se confond avec le projet et l’entreprise.
> Quelle est l’approche marketing ? L’usage est imaginé avec le prospect en s’appuyant sur des exemples d’application et références clients.  Mieux vaut démarcher les innovateurs directement en tant qu’entrepreneur. Ceux-ci attendent un discours d’innovateur à innovateur, et non pas un discours commercial.

Maturité de l’offre : Application pour un secteur d’activité
> Quels profils cibler ? Les visionnaires.

> Qui achète ? le manager/opérationnel.

> Comment se positionne mon entreprise ? Via l’équipe qui la compose.
> Quelle est l’approche marketing ? Mailings, site web, démo personnalisée. L’offre est adaptée au besoin spécifique du client, à partir d’une offre générique.

Maturité de l’offre : Solution pour un métier
> Quels profils cibler ? Les pragmatiques.

> Qui achète ? le décideur ayant une vision stratégique.

> Comment se positionne mon entreprise ? En tant que challenger sur le marché de référence.

> Quelle est l’approche marketing ? Discours marketing par métier, Pub, presse, salons, Webinar, Partenariats, , mailings ciblés.

La masse des pragmatiques permet d’industrialiser au mieux la vente, mais  franchir le "gouffre" séparant innovateurs/visionnaires et pragmatiques demande un effort considérable, parfois insurmontable pour une startup.
Pour toucher les pragmatiques, car il faut parvenir exprimer une position de challenger au marketing très efficace démontrant une solution clé en main.

Maturité de l’offre : standard
> Quels profils cibler ? Les conservateurs.
> Qui achète ? le financier.

> Comment se positionne mon entreprise ? En tant que leader.

> Quelle est l’approche marketing ? Démo en ligne, produit à télécharger, prêt produit, site web.

Maturité du produit : diffusion étendue
> Quels profils cibler ? Les sceptiques (A noter qu’on y retrouve souvent les DSI, qui ont de fait une position de gardien du temple).
> Qui achète ?  des leads spontanés.

> Comment se positionne mon entreprise ? En tant qu’unique acteur sur le marché.

> Quelle est l’approche marketing ?  Pub, presse, pas d’activité d’avant-vente.

Pour creuser précisément le marketing du secteur informatique en France, je vous incite vivement à lire cet article de l’excellent Olivier Ezratty.

David Henemeier Hansson, créateur de Ruby-on-Rails, fait partie de l’aventure 37signals, start-up à l’origine du célèbre outil de gestion de projet nommé Basecamp. Le mois dernier à Startup School (Stanford), il nous a offert une remarquable présentation en droite ligne avec la philosophie 37signals, dans laquelle il aborde le lancement d’un business en ligne. Voici les principaux conseils qu’il y prodigue :

1) Définir un business model simple : "Great application + Price = Profit"

2) Mieux vaut viser un business d’1Million$ ayant 1chance/10 de réussir, plutôt qu’un business d’1Milliard$ ayant 1chance/10 000 de réussir.

–> C’est tout bête, mais 2000 clients à 40$/mois = CA de 1Million$

3) Cibler la longue traîne des PME.

4) Mener son business à son propre rythme - sans VC - est un vrai bonheur.

C’est donc un petit vent de fraîcheur, une alternative au classique rêve de création du prochain Google-Facebook et de levées de fonds exceptionnelles.

Watch live video from HackerTV on Justin.tv

Ça vous donne envie de vous lancer ?

En bonus, je vous propose cet article d’onstartups.com qui tempère l’intérêt des levées de fonds auprès de VCs.

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