Développement pour éditeurs SaaS B2B : dix clients qui l’utilisent valent mieux que mille inscrits

C’est la différence structurante avec un produit grand public, et elle change tout le cadrage. Le dirigeant qui signe cherche un gain mesurable et une réduction de risque. L’équipe qui utilisera l’outil cherche à ne pas travailler plus qu’avant. Une première version qui ne convainc que l’un des deux ne se déploie jamais : il est acheté et pas utilisé, ou utilisé et jamais renouvelé.

La conséquence pratique est qu’on ne cherche pas du volume d’inscription. On cherche trois à cinq entreprises qui acceptent de travailler avec vous pendant le développement, d’utiliser le produit sur des données réelles, et de vous dire ce qui ne va pas. Ce sont des partenaires de conception, pas des testeurs.

En quatre mois, vous avez un produit utilisé dans de vraies organisations, et la réponse à la question qui compte : est-ce que ça change assez leur façon de travailler pour qu’ils paient l’année suivante.

C’est l’étape qui décide du sort du projet, et c’est celle qu’on repousse le plus volontiers parce qu’elle est inconfortable.

Pourquoi trois, et pas trente

Trois entreprises qui utilisent le produit chaque semaine sur leurs vraies données apprennent davantage que trois cents inscriptions issues d’une campagne. Le volume rassure et n’informe pas : des inscrits qui n’ont pas de problème à résoudre ne reviennent pas, et leur silence ne vous dit rien.

Trois permet aussi de distinguer un besoin partagé d’une demande particulière. Avec un seul partenaire, on construit son outil interne. Avec trois, on voit ce qui revient.

Ce qu’on leur demande, explicitement

• D’utiliser le produit sur des cas réels, pas de le regarder.
• Une conversation d’une demi-heure toutes les deux semaines, avec la personne qui l’utilise vraiment.
• Le droit de voir leurs données d’usage, ce qui suppose de le dire clairement dès le départ.

Ce qu’on ne leur demande pas : de payer tout de suite. Le paiement se teste plus tard, sur un volume plus large, et le mélanger à la phase de conception fausse les retours.

Où on les trouve

Presque toujours dans le réseau du fondateur, et c’est un signal en soi : un fondateur qui ne connaît pas trois entreprises ayant ce problème n’a probablement pas encore le bon problème. Cette difficulté vaut mieux découverte au mois un qu’au mois dix.

Le risque à connaître

Un partenaire trop enthousiaste et trop proche dira oui à tout. Nous cherchons donc au moins un profil critique, quitte à ce que les séances soient désagréables. Un produit validé par des gens polis n’est pas validé.

C’est la différence technique la plus lourde entre un produit grand public et un produit B2B, et c’est le seul élément qu’on ne peut pas corriger sans tout reprendre.

La structure minimale d’un produit B2B

Une entreprise cliente, plusieurs utilisateurs rattachés, des droits qui diffèrent selon la fonction, et une séparation stricte entre les données de deux clients. Ces quatre points forment le socle, et ils se posent avant le premier écran.

La tentation, au stade de la première version, est de simplifier : un utilisateur égale un compte, on verra plus tard pour les équipes. C’est le raccourci qui coûte le plus cher, parce qu’ajouter la notion d’organisation après coup oblige à reprendre le modèle de données entier.

Les droits se gèrent au niveau de la donnée

Masquer un bouton n’est pas une protection. Si la règle n’est pas appliquée là où la donnée est lue, elle n’est pas appliquée. C’est vrai sur mesure comme ailleurs, et c’est la première chose qu’un client un peu sérieux vous demandera de démontrer.

Ce que vos prospects vont exiger, plus tôt que vous ne le pensez

Dès qu’une entreprise d’une certaine taille envisage de vous acheter quelque chose, un questionnaire de sécurité arrive. Où sont hébergées les données, qui y accède, que se passe-t-il en cas de départ d’un salarié, comment récupère-t-on ses données en sortant.

Une première version ne peut pas tout couvrir, et ce n’est pas attendu. Ce qui est attendu, c’est de savoir répondre honnêtement, et d’avoir des réponses cohérentes. Nous préparons donc ce document pendant le projet plutôt qu’en urgence au premier vrai prospect.

La réversibilité, qui est un argument de vente

Pouvoir montrer qu’un client récupère ses données dans un format lisible lève une objection qui bloque beaucoup d’achats B2B. C’est peu coûteux à construire tôt et pénible à rajouter tard.

C’est la deuxième cause d’abandon d’un produit B2B, après l’absence de besoin réel. Un outil qui exige une double saisie perd ses utilisateurs au bout de quelques semaines, quelle que soit sa qualité.

La règle simple

Chaque information que l’utilisateur doit ressaisir alors qu’elle existe déjà ailleurs est une raison de ne pas revenir. Le calcul se fait au cadrage : d’où vient chaque donnée, et peut-elle entrer autrement qu’à la main ?

Les trois branchements qui rendent le plus

• L’entrée par la messagerie. Beaucoup de processus B2B commencent par un courriel. Capter là où l’information arrive vraiment évite l’essentiel de la saisie.
• La connexion au suivi commercial. Si votre produit touche à la relation client, il doit dialoguer avec l’outil qui la porte déjà, sans quoi deux vérités coexistent.
• L’export, sous une forme utilisable. Le tableur reste l’outil universel du B2B. Un export propre supprime des demandes de fonctionnalités que vous n’aurez pas à construire.

Ce qu’on ne construit pas au stade de la première version

Une connexion pour chaque outil du marché. On en fait une, celle que les trois partenaires de conception utilisent, et on regarde si elle change quelque chose à leur usage. Si oui, on en fait une deuxième. Ces flux passent par les mêmes plateformes que nos autres chantiers, décrites sur la page automatisation des processus.

Et l’identification unique

La connexion par le compte d’entreprise est demandée par les organisations d’une certaine taille et rarement par les petites. Au stade de la première version, elle attend, sauf si vos partenaires de conception sont précisément de grosses structures. C’est un arbitrage à écrire, pas à trancher par défaut.

Les indicateurs d’un produit B2B ne ressemblent pas à ceux d’un produit grand public, et se tromper d’indicateur conduit à célébrer un échec.

Les quatre chiffres qui comptent au stade de la première version

• La répétition d’usage par organisation, pas par utilisateur. Une entreprise où trois personnes se connectent chaque semaine vaut mieux que dix entreprises où une seule personne est venue une fois.
• La profondeur d’usage. Est-ce que le produit sert sur le vrai flux de travail, ou seulement sur un cas de démonstration ? La réponse se lit dans le volume de données réelles saisies.
• Le nombre de personnes invitées par le client lui-même. C’est le meilleur signal disponible : quelqu’un ne fait pas venir un collègue sur un outil qui ne sert pas.
• Ce qu’ils font quand le produit ne marche pas. Ils écrivent, ou ils reviennent à leur ancienne méthode ? Le premier cas dit que le besoin est réel.

Les chiffres qui trompent

Le nombre d’inscriptions, presque toujours issu du réseau du fondateur. Le temps passé sur l’outil, qui peut signaler une interface confuse autant qu’un usage intense. Et le taux de satisfaction déclaré, qui mesure la politesse.

Le seuil de décision, écrit avant de commencer

Nous écrivons dès le cadrage ce qui vaudra réponse positive : par exemple, deux organisations sur trois qui utilisent le produit chaque semaine sur des données réelles au bout de six semaines. Un seuil posé après coup s’ajuste toujours à ce qu’on a obtenu.

C’est la question qui inquiète le plus les fondateurs, souvent avant même de commencer. Elle se pose plus tard qu’on ne le croit, et elle se prépare dès le départ.

Le plafond arrive au succès, pas au démarrage

Quatre signaux l’annoncent : les temps d’affichage se dégradent sur les écrans qui manipulent beaucoup de lignes, une exigence de conformité dépasse ce que la plateforme permet, le coût indexé sur l’usage devient comparable à celui d’une équipe technique, ou la logique métier devient assez spécifique pour qu’on passe plus de temps à contourner l’outil qu’à s’en servir.

Aucun n’arrive pendant une première version. C’est une bonne nouvelle : le plafond de nos socles de développement est un problème de croissance.

Ce qui se transfère, et qui vaut cher

Pas le code. Le modèle de données validé par l’usage, les parcours éprouvés par de vraies organisations, les règles métier écrites, et la connaissance de ce qui ne sert à rien. Une équipe technique qui démarre avec cela ne construit pas la même chose qu’une équipe qui démarre avec un cahier des charges.

C’est là que la première version prend sa valeur économique réelle : il ne remplace pas le développement, il en réduit fortement le risque.

Ce que nous faisons dès le début pour limiter la dépendance

Vérifier que les données sont exportables dans un format lisible, et le tester plutôt que le supposer. Documenter la logique métier en français, en dehors de l’outil, pour qu’elle survive à la plateforme. Et tenir une nomenclature, pour que la reprise ne soit pas une enquête.

Le détail de la démarche et l’arbitrage entre plateformes sont sur la page développement d’applications, et la comparaison des outils dans cet article.

C’est la question qui revient dès le premier échange, et la réponse est presque toujours la même : pas maintenant.

Pourquoi le prix ne se valide pas sur une première version

Vos trois à cinq partenaires de conception viennent de votre réseau. Ils acceptent de payer parce qu’ils vous connaissent, ou refusent pour des raisons qui ne disent rien du marché. Dans les deux cas, le signal est faussé par la relation.

Il y a un second effet, plus pernicieux : introduire le paiement pendant la conception change la nature des retours. Un client qui paie devient exigeant sur des détails, un client partenaire vous dit ce qui manque. Vous avez besoin du second à ce stade.

Ce qui se teste, en revanche

• La disposition à payer, en principe. La question « si cet outil faisait X, combien vaudrait-il pour vous par mois ? » posée à froid donne un ordre de grandeur exploitable.
• Le budget d’où sortirait la dépense. C’est plus informatif que le montant : un outil payé sur un budget existant se vend, un outil qui demande de créer une ligne budgétaire prend un an de plus.
• Qui signe. Si votre utilisateur enthousiaste n’a pas de pouvoir d’achat, votre cycle de vente sera plus long que prévu.

L’unité de facturation, qui se décide tôt

Par utilisateur, par organisation, ou à l’usage : ce choix a des conséquences sur le modèle de données, donc il ne se repousse pas indéfiniment. Facturer à l’usage suppose de compter quelque chose dès le départ, et ajouter ce comptage après coup est douloureux.

Nous posons donc la question au cadrage, sans exiger de réponse définitive : il suffit de savoir ce qu’il faut mesurer pour ne pas se fermer une porte.

Un devis de première version se compare mal, parce que le mot recouvre aussi bien un prototype de démonstration qu’un produit utilisable en production.

Ce qui est toujours compris

• Le cadrage, c’est-à-dire l’écriture de la question à démontrer, du seuil de décision et du périmètre.
• La conception des parcours et des écrans, qui est le vrai poste de travail.
• La construction, le modèle de données, les rôles et les droits au niveau de la donnée.
• La mise en ligne, la préparation des séances avec les partenaires de conception, et le transfert à votre équipe.

Ce qui se chiffre à part

Les abonnements aux plateformes, qui sont à votre nom et dépendent de votre volume. L’acquisition au delà des partenaires de conception, qui est un métier distinct. Et les connexions aux outils de vos clients, au delà de la première, parce que chacune est un projet en soi.

Le lot suivant

Il se décide sur les données d’usage, pas sur la liste d’envies du départ. Nous préférons un lot court chiffré sur un périmètre écrit à un forfait mensuel qui installe une dépendance sans engager sur un résultat.