Je vais commencer par quelque chose qu'on dit rarement dans ce genre d'article.
Moi, j'ai souvent lancé sur intuition. PrimoCV, mon premier SaaS, utilisé par plus d'un million de personnes, je l'ai lancé parce que je faisais des CV design pour mes propres candidatures et que j'avais l'intuition que rendre cette compétence accessible aux gens qui n'avaient pas le bagage design pourrait marcher. Pas après des mois d'interviews utilisateurs. Sur une intuition. Et ça a marché.
Alors pourquoi vous parler de validation ? Parce que l'intuition fonctionne parfois, mais les principes du lean startup améliorent les chances à chaque fois. Et entre les deux, il y a de la place pour être pragmatique. Dans cet article, je vous partage ce que ça veut dire concrètement de valider son idée, comment le faire sans écrire une seule ligne de code, et dans quels cas vous pouvez vous en passer.
🎬 Vous préférez la version vidéo ?
Cet article existe aussi en vidéo sur la chaîne YouTube Joliweb Studio. Voir sur YouTube →
Pourquoi valider reste une bonne idée, même si peu de gens le font vraiment
Si vous demandez à des fondateurs comment ils ont lancé leur produit, beaucoup vous diront qu'ils ont suivi leur instinct. Et certains ont eu raison : l'intuition compte, connaître un secteur de l'intérieur ou vivre soi-même le problème qu'on veut résoudre est déjà une forme de validation. C'est même souvent la meilleure.
Mais il y a une différence entre "je connais ce problème parce que je le vis" et "je pense que ce problème existe parce que ça me semble logique". La deuxième situation est risquée, parce qu'on a tous tendance à surestimer l'universalité de nos propres problèmes. Ce qui nous gêne profondément ne gêne pas forcément les autres au point de les faire sortir leur carte bleue.
L'approche lean startup répond exactement à ça, avec une idée simple : tester le plus tôt possible, avec le moins de ressources possible, si ce qu'on pense être vrai l'est vraiment. Ce n'est pas une méthode rigide à appliquer à la lettre, c'est un état d'esprit, qui coûtera toujours moins cher que de découvrir après douze mois de développement que personne ne voulait ce que vous avez construit. C'est d'ailleurs l'une des raisons pour lesquelles la majorité des SaaS échouent avant leur premier client payant.
Les trois choses concrètes à faire avant de coder
Voilà trois actions accessibles, réalisables en quelques semaines, sans écrire une ligne de code.
🗣️ Parler à des gens qui ont le problème
Pas à vos amis, pas à votre famille : à des inconnus qui seraient vos utilisateurs potentiels. L'objectif n'est pas de leur vendre quoi que ce soit, c'est d'écouter comment ils décrivent le problème, avec quels mots, à quel point ça les gêne vraiment, et ce qu'ils font aujourd'hui pour le contourner.
Ce dernier point est clé. Si les gens ont déjà bricolé une solution, même imparfaite, même pénible, cela veut dire que le problème est suffisamment douloureux pour qu'ils aient investi du temps ou de l'argent à le résoudre. C'est un bon signe. S'ils vous disent plutôt "ouais c'est un peu galère mais bon, ça va", c'est un signal faible, pas forcément rédhibitoire mais à prendre en compte. Il n'y a pas de nombre magique d'interviews : dix à quinze conversations sérieuses avec des personnes qui correspondent vraiment à votre profil cible donnent déjà des informations très utiles.
👀 Observer si le problème existe déjà dans leur façon de travailler
C'est ce que j'ai observé sur un des projets que j'ai accompagnés. Le porteur de projet voulait créer une plateforme pour un secteur qu'il connaissait très bien, et ce qu'il voulait automatiser ou centraliser, les gens du secteur le faisaient déjà, mais manuellement, avec des fichiers Excel bricolés et des échanges par email.
Cette réalité-là, c'est de la validation. Pas besoin de grands sondages : les gens ont déjà adopté un comportement qui prouve que le besoin existe, et votre produit vient juste le rendre moins douloureux. Quand vous pouvez observer ça, vous partez avec beaucoup moins d'incertitude.
💳 Vérifier que des gens paient déjà pour une solution approximative
C'est peut-être le signal le plus fort. Si des concurrents existent, même imparfaits, même chers, même mal conçus, cela veut dire que le marché paie déjà pour résoudre ce problème. Beaucoup de fondateurs voient la concurrence comme un problème, alors que c'est souvent l'inverse. Un marché sans aucune concurrence peut vouloir dire deux choses : soit vous avez trouvé une opportunité que personne n'a vue, soit personne n'a voulu s'y aventurer parce qu'il n'y a pas de business viable. La deuxième hypothèse est statistiquement plus fréquente. Avant de coder, cherchez si des solutions existent déjà, si des gens les achètent, et ce que vous apportez de différent ou de mieux.
Les cas où la validation est moins critique
Il y a des situations où le niveau de validation nécessaire avant de lancer est naturellement plus bas, et c'est important de le dire.
Vous construisez pour vous-même. C'est mon cas avec Zendaboo, mon propre SaaS : je construis le produit que je rêve d'utiliser depuis des années. Je n'ai pas fait d'interviews utilisateurs en amont, et ça ne m'inquiète pas vraiment, parce que je suis moi-même l'utilisateur cible. Ce n'est pas la même logique que de construire pour quelqu'un d'autre.
Vous connaissez le secteur de l'intérieur. Si vous avez travaillé des années dans un secteur et que vous en connaissez les pratiques et les frustrations, vous avez une longueur d'avance sur n'importe quelle étude de marché. Ce qui ne veut pas dire qu'il ne faut rien vérifier, mais le niveau d'incertitude de départ est beaucoup plus faible.
Le marché existe déjà et vous avez une approche différente. Si vous arrivez sur un marché où des solutions existent et que vous avez une conviction claire sur ce que vous faites mieux ou différemment, la question n'est plus "est-ce que le problème existe" mais "est-ce que mon approche est meilleure". C'est une question différente, qui se teste souvent plus vite.
Dans tous les autres cas, prendre quelques semaines pour parler à des gens, observer le terrain et regarder ce qui existe déjà est du temps très bien investi. Ce n'est pas de la procrastination, c'est éviter de passer douze mois à construire quelque chose que personne ne voulait.
Ce qu'il faut retenir
La validation n'est pas un passage obligé gravé dans la pierre, c'est un outil, et comme tout outil il s'utilise selon le contexte. Quand ce contexte ne vous donne pas de certitudes naturelles, parler à des gens, observer le terrain et vérifier que quelqu'un paie déjà pour résoudre ce problème sont trois actions réalisables en quelques semaines, gratuitement, qui peuvent vous éviter des erreurs coûteuses.
Questions fréquentes
Combien d'interviews utilisateurs faut-il pour valider une idée de SaaS ?
Il n'y a pas de nombre magique, mais dix à quinze conversations sérieuses avec des personnes qui correspondent vraiment à votre profil cible donnent déjà des informations très utiles, surtout si vous cherchez comment elles décrivent le problème et ce qu'elles font déjà pour le contourner.
Faut-il toujours valider son idée avant de développer un SaaS ?
Pas dans tous les cas. Si vous construisez pour vous-même, si vous connaissez le secteur de l'intérieur, ou si vous arrivez sur un marché existant avec une approche clairement différente, le niveau de validation nécessaire est plus bas. Dans les autres situations, valider avant de coder reste le meilleur moyen d'éviter de construire quelque chose que personne ne voulait.
Comment savoir si un problème est assez douloureux pour justifier un SaaS payant ?
Le meilleur signal est de vérifier si les gens ont déjà bricolé une solution, même imparfaite, pour contourner ce problème. Cela prouve qu'ils ont investi du temps ou de l'argent dessus, ce qui est un indicateur bien plus fiable qu'un simple intérêt exprimé en discussion.