De l'idée aux premiers utilisateurs payants : comment nous avons lancé un SaaS B2B

Elle est arrivée avec un tableur, une intuition et une échéance que le congrès de son secteur lui avait fixée sans la consulter. Dans quatre mois, elle serait sur une petite scène devant environ deux cents personnes qui dirigeaient exactement le type d'entreprise que son idée était censée servir. Elle voulait pouvoir leur montrer quelque chose de réel : pas des diapositives, pas une maquette, mais un produit dans lequel un inconnu pourrait se connecter et payer. C'est par cette conversation que commence cette étude de cas, et le plus utile à son sujet, c'est à quel point le point de départ était ordinaire.

Nous avons modifié les détails permettant d'identifier la personne à dessein. La fondatrice est réelle, le produit est en ligne, et les chiffres sont proches de la vérité mais arrondis et adoucis pour que personne ne puisse remonter jusqu'à elle. Ce qui compte, ce n'est pas la niche précise, c'est la forme du parcours, car cette forme se répète presque chaque fois qu'un fondateur non technique tente de transformer une bonne idée en logiciel qui fonctionne. Si vous vous trouvez à peu près au début de ce chemin, voilà à quoi peuvent ressembler les prochains mois lorsque cela se passe bien.

La version courte : un secteur qu'elle connaissait intimement, un processus manuel pénible que tout le monde y tolérait, un tableur avec lequel elle le faisait discrètement mieux que ses pairs, et zéro bagage technique. Onze semaines de travail concentré plus tard, les premiers utilisateurs payants étaient là. Voici comment, et, plus honnêtement, voici où nous avons trébuché.

La situation : un tableur qui fait un vrai travail

La fondatrice dirigeait un petit cabinet de conseil dans un domaine réglementé et chargé de documents. Ses clients étaient d'autres petites entreprises, et chacune d'elles se débattait avec la même corvée récurrente : rassembler une pile de formulaires, vérifier qu'ils soient complets, courir après les éléments manquants et produire une synthèse propre avant une échéance. La plupart de ses concurrents faisaient cela avec des e-mails, des appels et un dossier de modèles Word. Elle, elle le faisait avec un tableur qu'elle avait construit et affiné pendant quatre ans, et ses clients l'adoraient en silence pour cela.

Ce tableur était toute la révélation. Ce n'était ni un business plan ni une étude de marché : c'était une preuve. Des gens s'appuyaient déjà sur son outil, lui demandaient de le faire tourner pour des entreprises qu'elle ne conseillait même pas, proposaient de payer rien que pour y accéder. Quand des clients tentent d'acheter quelque chose avant que vous ne l'ayez construit, vous pouvez cesser de deviner s'il existe une demande. La question n'a jamais été cela vaut-il la peine d'être fait. La question était cela peut-il devenir un logiciel qu'une autre personne peut utiliser sans qu'elle soit assise à côté.

Ses contraintes étaient tout aussi réelles. Un budget fixe issu de ses propres économies, pas d'un fonds. L'échéance du congrès. Et une règle stricte sur laquelle nous nous sommes accordés tôt : cela ne pouvait pas devenir un projet qui exigeait son attention chaque jour, car elle avait toujours un cabinet à diriger. Quoi que nous construisions, cela devait être achevable, abordable et ennuyeux à exploiter. Ces trois mots ont façonné chacune des décisions qui ont suivi.

Le premier travail a été de décider ce qu'il ne fallait PAS construire

Quand les fondateurs décrivent leur produit de rêve, la liste de fonctionnalités est toujours énorme, parce qu'ils l'imaginent depuis des années. La sienne remplissait deux pages : tableaux de bord, permissions d'équipe, piste d'audit, rappels automatiques, portail client, facturation, analyses, intégrations avec trois outils que ses clients utilisaient, et — bien sûr — « un peu d'IA quelque part là-dedans ». Chaque point était raisonnable. Les construire tous avant le lancement aurait été un désastre.

Nous avons donc fait l'exercice que nous faisons avec tout le monde : pour chaque fonctionnalité, nous avons posé une seule question sans détour. Si elle manquait le jour du lancement, un client refuserait-il de payer ? Pas « serait-ce plus agréable avec », mais la vente mourrait-elle vraiment. La plupart des fonctionnalités échouent à ce test, et c'est tout l'intérêt. Celles qui survivent sont votre véritable produit. Tout le reste est une feuille de route, ce qui est une belle chose à avoir, mais pas ce que l'on construit en premier.

Ce qui a survécu était presque gênant tant c'était réduit. Un utilisateur pouvait créer un compte, mettre en place un dossier, inviter son client à téléverser les documents requis et récupérer la même synthèse propre et vérifiée que produisait son tableur — sauf automatiquement, et sans elle dans la boucle. C'était tout. Pas de tableaux de bord. Pas de rôles d'équipe. Pas d'IA, pas encore. Quatre fonctionnalités, un travail clair, fait correctement.

Ce que nous avons réellement construit en onze semaines

Nous travaillons par cycles courts et visibles, plutôt que de disparaître trois mois pour revenir avec une surprise. Environ chaque semaine, la fondatrice recevait un lien vers quelque chose qu'elle pouvait cliquer, même quand c'était laid et à moitié branché. Ce rythme compte plus qu'il n'y paraît : il maintenait ses décisions petites et fréquentes plutôt que de les laisser s'empiler en une seule revue terrifiante à la fin.

Semaines 1–3 : la colonne vertébrale

Nous avons d'abord construit le cœur sans gloire — les comptes, une façon sécurisée de stocker les documents et le modèle de données sous le flux des dossiers. Rien de cela n'est visible pour un client, et tout cela est la partie coûteuse à corriger plus tard si on la bâcle. Comme le produit traitait les documents sensibles d'autres entreprises, nous avons traité le contrôle d'accès et la séparation des données comme une exigence de lancement, pas comme une amélioration ultérieure. C'est l'un des rares endroits où nous avons refusé de couper.

Semaines 4–7 : le vrai travail

Puis la partie qui justifiait de payer : transformer la logique de son tableur en moteur qui vérifie que les documents sont complets et produit la synthèse. C'était le cœur du produit et nous lui avons consacré le plus de temps. Nous nous sommes assis avec elle et avons décortiqué pourquoi chaque règle de son tableur existait — et plusieurs se sont révélées être des habitudes plutôt que des exigences, ce qui nous a permis de simplifier. À la fin de la semaine sept, on pouvait dérouler un vrai dossier du début à la fin.

Semaines 8–11 : le rendre sûr pour le faire payer

La dernière ligne droite a fait la différence entre une démo et un produit. Le paiement, pour que les gens puissent réellement s'abonner. Une inscription propre qui ne nécessitait pas de manuel. La douzaine de petits états d'erreur qui décident si un inconnu fait confiance à votre logiciel ou s'en va. Et les tests — ennuyeux, répétitifs — avec la fondatrice et deux clients bienveillants qui ont accepté de le casser exprès avant que des inconnus ne le fassent. Ce dernier groupe a largement mérité sa remise d'accès anticipé.

La question du « mets-y un peu d'IA », répondue honnêtement

Sa liste de souhaits comportait de l'IA, comme la plupart des listes aujourd'hui. Nous avons objecté, et il vaut la peine d'expliquer pourquoi, car c'est le même conseil que nous donnons à presque tout le monde. Le travail que la version un devait accomplir — vérifier un ensemble connu de documents par rapport à un ensemble connu de règles — est un travail que les règles font mieux que l'IA. Il est prévisible, il est auditable, et quand un client réglementé demande « pourquoi le système a-t-il signalé cela », vous voulez une réponse claire, pas un haussement d'épaules.

Cela ne veut pas dire que l'IA n'avait pas sa place. Il y avait un problème véritablement désordonné, de nature linguistique, caché dans le flux : les clients téléversaient souvent des documents presque corrects mais mal étiquetés, ou collaient des informations en texte libre au lieu de remplir le formulaire. Lire ce fouillis et le trier, c'est exactement ce dans quoi l'IA moderne excelle. Nous l'avons donc noté soigneusement — puis laissé pour la version deux. L'ajouter avant le lancement aurait retardé l'échéance pour peaufiner une fonctionnalité que personne n'avait encore demandé à payer.

Obtenir les premiers utilisateurs payants

Voici la partie qui inquiète le plus les fondateurs et pour laquelle ils se préparent le moins. Un produit que personne ne peut trouver n'est pas une entreprise, c'est un passe-temps. Mais cette fondatrice avait un atout valant plus que n'importe quel budget marketing : elle avait déjà un public qui lui faisait confiance, et certains d'entre eux avaient demandé à payer avant que le logiciel n'existe. Le plan de lancement s'est entièrement appuyé là-dessus, et le vôtre devrait aussi si vous en disposez.

Plutôt qu'un lancement public tapageur, nous avons fait l'inverse — un lancement discret et délibéré. Deux semaines avant le congrès, elle a écrit à la poignée de clients qui avaient déjà demandé, leur a proposé un tarif de membre fondateur et les a intégrés à la main, observant lors d'un appel vidéo comment ils l'utilisaient. Chaque confusion devenait une correction. Lorsqu'elle est montée sur cette scène, elle ne vendait pas une idée ; elle décrivait un logiciel que ses pairs payaient déjà, et elle pouvait le dire honnêtement.

1. 1
   Commencez par ceux qui demandent déjà

   Sa première prise de contact n'est allée qu'aux clients qui avaient auparavant proposé de payer. La demande chaude convertit avant même que la demande froide ne réponde.
2. 2
   Intégrez les premiers à la main

   Pas d'exploits en libre-service au début. Elle a accompagné en direct chaque premier utilisateur, transformant chaque point de confusion en correction concrète.
3. 3
   Un tarif pour fondateurs, pas pour toujours

   Les premiers utilisateurs ont eu un tarif fondateur clairement limité dans le temps. Il récompensait leur risque et donnait aux clients suivants une raison à la hausse des prix.
4. 4
   Utilisez l'échéance comme lancement

   Le congrès n'était pas un coup marketing greffé après coup — c'était la contrainte forçante qui a maintenu le périmètre honnête tout du long.

Le résultat — et ce qu'il signifie vraiment

À la fin du mois de lancement, le produit avait ses premiers abonnés payants — un petit nombre, du genre qu'on peut encore compter sur deux mains, chacun étant une vraie entreprise payant un vrai abonnement mensuel. Cela paraît modeste, et ça l'est. C'est aussi le jalon le plus difficile de toute la vie d'un produit logiciel. Passer de zéro client payant à quelques-uns est bien plus dur que de passer de quelques-uns à beaucoup, car c'est le moment où l'idée cesse d'être la vôtre pour devenir celle du marché.

Les chiffres ci-dessous sont indicatifs et arrondis, mais ils sont fidèles à la forme de ce qui s'est passé. Ce que nous voulons que vous en reteniez, ce ne sont pas les chiffres — ce sont les proportions. Une première version étroitement cadrée, un petit budget concentré, un délai court et un lancement visant la demande chaude plutôt qu'internet tout entier.

Là où nous nous sommes trompés

Une étude de cas qui ne liste que des réussites est une publicité, alors voici la partie honnête. Nous avons commis deux erreurs qui méritent d'être nommées, car vous serez tenté par les mêmes.

D'abord, nous avons sous-estimé l'accueil. Nous avions cadré le produit avec soin, mais traité les cinq premières minutes de l'expérience d'un nouvel utilisateur comme un détail, quelque chose à ranger à la fin. Cela s'est révélé être le moment décisif, et nous avons passé une semaine non prévue à reconstruire l'inscription et le premier écran vide pour qu'un inconnu puisse comprendre quoi faire sans qu'on le lui dise. La prochaine fois, l'expérience de première utilisation est une fonctionnalité dès le premier jour, pas à la semaine dix.

Ensuite, nous avons laissé une « petite » règle du moteur de vérification enfler. La fondatrice a mentionné un cas limite presque en passant, nous avons convenu que c'était facile, et il a discrètement consommé trois jours parce que les données du monde réel étaient plus désordonnées que son tableur impeccable ne l'avait jamais révélé. La leçon n'était pas « évitez les cas limites » — c'était que son tableur effectuait en silence un nettoyage manuel qu'elle avait oublié faire. Le logiciel doit rendre ce travail invisible visible, et cela coûte toujours plus que quiconque ne s'y attend.

Si vous êtes là où elle était

Ce qui a fait que cela a marché n'était ni une architecture astucieuse ni un outil à la mode. C'était de la discipline sur le périmètre et de l'honnêteté sur la demande. Elle avait la preuve que les gens le voulaient avant que nous n'écrivions une ligne de code, et nous avons été impitoyables pour construire la plus petite version pour laquelle quelqu'un paierait quand même. Aucune de ces choses n'exige un bagage technique. Ce sont toutes deux des choses que vous pouvez commencer cette semaine, par vous-même.

Si vous avez un tableur que les gens vous demandent sans cesse de faire tourner, ou un processus manuel pour lequel vos clients vous remercient, vous êtes peut-être plus proche d'un produit que vous ne le pensez. Le geste dangereux est d'imaginer la version finie, complète en fonctionnalités, et de se figer devant son ampleur. Ne le faites pas. Trouvez le seul travail qu'elle doit absolument accomplir, ne construisez que cela et mettez-le devant ceux qui demandent déjà. La feuille de route peut attendre. Le premier utilisateur payant, non.

Questions fréquentes