Comment valider une idée SaaS avant d'écrire une ligne de code

La plupart des produits SaaS échoués n'ont pas échoué parce que le code était mauvais. Ils ont échoué parce que personne ne voulait payer pour ce que les fondateurs avaient construit. La validation est le travail que vous faites avant d'écrire une ligne de code pour vous assurer que vous n'allez pas passer six mois sur un produit magnifiquement conçu qui résout un problème trop petit, trop rare ou trop bon marché pour soutenir une entreprise.

La bonne nouvelle, c'est qu'une idée de SaaS peut être validée en trois à cinq semaines pour moins de trois cents dollars. La mauvaise nouvelle, c'est que la plupart des fondateurs sautent cette étape parce que construire donne l'impression d'avancer et parler à des inconnus donne l'impression de traîner. L'ordre compte — chaque semaine de validation économise environ un mois de travail inutile plus tard.

Commencez par une phrase, pas par une liste de fonctionnalités

Avant toute chose, écrivez une phrase sous cette forme : 'J'aide [rôle précis] dans [type précis d'entreprise] à [tâche précise] afin qu'ils puissent [résultat précis].' Mauvaise version : 'J'aide les petites entreprises à gagner du temps sur les opérations.' Bonne version : 'J'aide les responsables des opérations d'agences de trois à vingt personnes à rapprocher le suivi du temps avec les factures clients afin qu'ils puissent facturer chaque semaine plutôt que chaque mois.'

Si vous ne pouvez pas écrire cette phrase, vous n'êtes pas prêt à valider — vous avez une idée de catégorie, pas une idée de client. Plus la phrase est étroite, plus chaque étape suivante devient facile : vous saurez exactement qui interviewer, exactement quels forums lire et exactement quelle audience cibler avec vos annonces.

Faites dix à quinze entretiens sur le problème

Trouvez dix à quinze personnes qui correspondent à cette phrase et interrogez-les sur le problème, pas sur votre solution. L'objectif est de comprendre comment elles décrivent la douleur, ce pour quoi elles paient déjà et ce qu'elles ont essayé. Trois questions font l'essentiel du travail : 'Racontez-moi la dernière fois que vous avez fait cette tâche. Qu'avez-vous utilisé ? Qu'est-ce qui était agaçant ?' Soyez attentif aux dépenses. Si la personne paie déjà pour des tableurs, des freelances ou un outil maladroit, le problème est réel. Si elle hausse les épaules, il ne l'est pas.

Obtenir ces entretiens est en soi un signal de validation. Si vous n'arrivez pas à décrocher quinze rendez-vous à partir de cent messages LinkedIn ou e-mails froids ciblés, votre client est difficile à atteindre — et une activité SaaS est en grande partie une activité d'acquisition client. C'est un enseignement qui vaut plus que les entretiens eux-mêmes.

Construisez une landing page, pas un produit

Décrivez le produit sur une seule page comme s'il existait déjà. Montrez le résultat, indiquez un prix et ajoutez un bouton disant 'Obtenir un accès anticipé' ou 'Commencer l'essai gratuit'. Utilisez un outil que vous connaissez déjà — Carrd, Framer, Webflow ou une simple page Next.js. La page devrait prendre une journée, pas une semaine.

Dépensez cent à deux cents dollars en publicités très ciblées — LinkedIn pour les rôles B2B, Reddit ou des newsletters de niche pour les audiences prosumers, Google Search pour les mots-clés à forte intention comme 'reconcile time tracking with invoices'. Envoyez le trafic vers votre page et mesurez deux choses : le taux de clic vers l'appel à l'action et le pourcentage de visiteurs qui laissent leur e-mail.

• En dessous de 1 % de capture d'e-mails sur un trafic très ciblé : le message ou l'audience est incorrect.
• Deux à cinq pour cent : un vrai signal — continuez à itérer sur le texte et l'audience.
• Au-delà de cinq pour cent sur plus d’une centaine de visiteurs : signal fort, passez à un pilote payant.
• Incluez toujours un prix ou une fourchette de prix — un tarif vague gonfle les inscriptions et détruit le signal.

Lancez un pilote concierge ou Wizard-of-Oz

Prenez les cinq ou dix premières personnes inscrites et proposez-leur le résultat à un vrai prix — cinquante à deux cents dollars par mois, c’est très bien —, mais délivrez-le manuellement en coulisses. Utilisez des tableurs, Zapier et vos propres mains pour produire le résultat. Le client ne voit jamais les coutures ; vous découvrez précisément ce que le produit doit faire, et vous encaissez de vrais revenus.

Si cinq inconnus ne paient pas, même une petite somme, pour une version du résultat livrée manuellement, aucun logiciel sophistiqué n’y changera quoi que ce soit. S’ils paient, vous avez désormais des clients payants, un flux de travail enregistré et un cahier des charges bien meilleur que n’importe quel document que vous auriez pu écrire à l’avance.

Des chiffres qui signifient 'go', 'maybe' et 'no'

La validation se juge sur des tendances, pas sur un point de donnée isolé. Après trois à cinq semaines de travail, regardez l’ensemble : la facilité avec laquelle vous avez pu programmer des entretiens, la clarté avec laquelle les gens ont décrit la douleur avec leurs propres mots, la force de conversion de la page d’accueil et le nombre de personnes ayant payé pour le pilote manuel. Comparez les preuves à l’un des trois résultats et agissez en conséquence — refuser de décider, c’est déjà décider de continuer à brûler du temps.

• Go : les entretiens ont été faciles, trois personnes ou plus ont prépayé ou signé des lettres d’intention, et la conversion était forte.
• Maybe : l’intérêt existe mais aucun argent n’a circulé — resserrez la cible, augmentez le prix ou affinez le résultat, puis testez à nouveau.
• No : difficile de trouver le client, douleur floue, aucun paiement malgré plusieurs demandes. Arrêtez et choisissez un problème plus précis.

Quand vous êtes enfin prêt à construire

Vous êtes prêt à écrire du code lorsque la seule question qui reste est de savoir si vous pouvez bien construire le produit — et non plus si quelqu’un en veut. À ce stade, vous devez connaître exactement la tâche à accomplir, le prix accepté par le client, le canal qui l’amène et le flux de travail que vous comptez automatiser. Construisez la plus petite version qui délivre le résultat promis aux dix premiers clients payants, et continuez à livrer le reste manuellement jusqu’à ce que le produit rattrape le besoin.

La validation n’élimine pas le risque ; elle le déplace de 'est-ce que quelqu’un s’en souciera ?' — la question qui tue la plupart des sociétés SaaS — vers 'peut-on exécuter ?' — la question à laquelle les fondateurs sont généralement mieux armés pour répondre. Cet échange est tout l’intérêt du travail effectué avant d’écrire la moindre ligne de code.