Chapitre 9.2 — Trouver l’idée

⏱️ TL;DR — Une bonne idée de SaaS ne commence pas par « et si je faisais un truc avec l’IA ? » (solution-first). Elle commence par une douleur réelle et récurrente (problem-first). Ton super-pouvoir de dev-freelance : tu as vu de tes yeux les douleurs répétées de tes clients — c’est une mine d’or que le fondateur non-technique n’a pas. Mais la vraie question n’est pas « est-ce un bon problème ? », c’est « est-ce que je peux ATTEINDRE les gens qui l’ont ? ». Une idée géniale mais inatteignable est une mauvaise idée. Niche étroite > marché large. Et tu valides avant de coder.

🎯 Objectifs

• Passer du réflexe solution-first au réflexe problem-first.
• Exploiter ton avantage de dev-freelance : les douleurs vues sur le terrain.
• Faire de la distribution le premier filtre d’une idée, pas le dernier.
• Choisir une niche étroite plutôt qu’un marché large et flou.
• Valider une idée avant d’écrire une ligne de code.

Problem-first, pas solution-first

Le piège du dev, c’est de tomber amoureux d’une solution : « je veux utiliser l’IA / le temps réel / cette API cool ». Puis de chercher un problème à lui coller. Ça donne des produits techniquement impressionnants que personne n’achète.

Inverse le sens. Pars d’un problème : quelque chose qui fait perdre du temps, de l’argent ou des nerfs à des gens identifiables, de façon répétée. La solution vient après — et souvent, elle est ennuyeuse techniquement. Tant mieux : les problèmes ennuyeux sont ceux que les gens paient pour faire disparaître.

Une bonne douleur coche trois cases :

• Fréquente — elle revient chaque semaine, pas une fois par an.
• Coûteuse — elle brûle du temps ou de l’argent mesurable.
• Consciente — les gens savent qu’ils l’ont et cherchent déjà à la régler (ils bricolent un tableur, achètent un outil médiocre, paient un freelance).

Si les gens paient déjà pour un pansement bancal, c’est le meilleur signal du monde : le marché a validé qu’il veut une solution.

Scratch your own itch

Le point de départ le plus fiable : ta propre douleur. Un truc qui *t’*énerve, que tu bricoles à la main chaque semaine. Avantage énorme : tu es ton premier utilisateur, tu comprends le problème dans ses détails, et tu sais quand la solution est bonne sans avoir à interviewer qui que ce soit.

La limite : ta douleur n’est un marché que si d’autres la partagent et sont atteignables. « Ça m’énerve » est un point de départ, pas une validation. Le itch te donne l’idée ; la suite du chapitre te dit si elle tient.

Ton avantage de dev-freelance : la mine d’or

Voici ce que ce cours veut vraiment que tu entendes : en tant que dev-freelance, tu es assis sur un gisement d’idées que 90 % des makers n’ont pas.

À chaque mission, tu vois de l’intérieur comment une vraie boîte travaille. Et tu vois les mêmes douleurs revenir de client en client :

• « On exporte ce rapport à la main tous les lundis. »
• « On recopie les données de l’outil A vers l’outil B. »
• « On n’a aucun outil pour ça, on se débrouille dans un Google Sheet monstrueux. »
• « On paie une agence 2 000 €/mois pour un truc semi-automatisable. »

Chacune de ces phrases est une idée de micro-SaaS pré-validée par le terrain. Tu connais le problème, tu connais le vocabulaire du métier, tu connais le budget, et surtout — tu connais où trouver d’autres boîtes qui ont exactement la même douleur. C’est ça, l’avantage décisif : pas seulement l’idée, mais le canal pour la vendre.

💡 Réflexe — Tiens un fichier « douleurs ». À chaque mission, chaque fois qu’un client dit « c’est chiant, on fait ça à la main » ou « il n’existe pas d’outil pour… », note-le, avec le métier et une estimation du temps perdu. En 6 mois, tu auras une liste d’idées ancrées dans le réel — infiniment plus précieuse qu’une séance de brainstorming devant une page blanche.

Distribution d’abord : « puis-je les atteindre ? »

Voici le filtre qui trie les idées viables des fantasmes. Avant même de juger si le problème est bon, demande :

Est-ce que je peux ATTEINDRE les gens qui ont ce problème ?

Une idée géniale pour un public que tu ne sais pas toucher est une mauvaise idée — parce que la distribution est la cause d’échec n°1 (rappel : 9.1). « Un outil pour les dentistes » peut être excellent ; si tu n’as aucun moyen d’atteindre les dentistes, il ne vaut rien pour toi.

Un public est atteignable s’il se rassemble quelque part que tu peux toucher : un subreddit actif, un hashtag, un forum métier, des groupes Slack/Discord, une conférence, une liste d’entreprises que tu peux contacter en direct. Si tu ne sais pas nommer où vivent tes futurs clients, tu n’as pas encore d’idée — tu as un vœu.

Niche étroite > marché large

L’instinct dit « plus le marché est grand, mieux c’est ». Faux pour un solo. Un marché large veut dire : concurrents établis, message générique, distribution impossible (tu ne peux pas « atteindre tout le monde »).

Une niche étroite gagne parce que :

• Ton message devient précis : « le CRM pour les ostéopathes » parle mille fois plus fort que « un CRM ».
• La distribution devient possible : une niche se rassemble dans des endroits identifiables.
• La concurrence est plus faible : les gros ne descendent pas si bas, les solos n’y sont pas encore.
• Tu peux facturer plus cher : un outil taillé pour leur métier vaut plus qu’un outil générique.

« Trop petit » est rarement le problème d’un débutant. Commence absurdement étroit ; tu élargiras plus tard si ça marche. Un marché de 500 boîtes que tu sais atteindre bat un marché d’un million que tu ne touches pas.

⚠️ Piège — « Le marché est énorme, donc même 1 % suffit. » C’est le raisonnement qui tue le plus de SaaS solo. Ce 1 % est inatteignable sans budget marketing : tu es noyé dans le bruit, en face de concurrents financés. La vraie question n’est jamais « quelle taille de marché ? » mais « quelle fraction puis-je réellement toucher seul, ce mois-ci ? ».

Valider avant de construire

Tu as un problème, un public atteignable, une niche. Ne code rien encore. Valide, avec deux outils :

1. The Mom Test. Parle à 5–10 personnes de la niche. Règle d’or : ne demande jamais « est-ce que tu utiliserais mon outil ? » (tout le monde ment pour être gentil — même ta mère). Demande le passé et le concret : « raconte-moi la dernière fois que tu as géré ça », « ça t’a pris combien de temps ? », « tu utilises quoi aujourd’hui ? », « combien tu paies pour le régler ? ». Les faits ne mentent pas, les compliments si.
2. La pré-vente. Le seul test qui ne ment jamais : est-ce qu’ils sortent la carte bleue avant que le produit existe ? Une landing page avec un vrai bouton de paiement (ou un « je te réserve une place à tarif fondateur, 50 % maintenant »), et tu comptes les conversions. Une pré-commande vaut mille « super idée ! ».

Si tu ne trouves personne à qui parler, ou personne ne veut payer d’avance : c’est le signal. Tu viens d’économiser 3 mois de build sur une idée morte. C’est une victoire, pas un échec.

🚀 Sur ton plan 12 mois — Ton dev Next.js n’invente pas son idée en salle blanche : il relit son fichier « douleurs » accumulé pendant ses missions freelance. Il en sort une douleur récurrente vue chez trois clients d’un même secteur — un public qu’il sait déjà atteindre. Sur 12 mois, l’étape « idée » ne prend pas des semaines de brainstorming : elle prend quelques appels de validation avec un réseau qu’il a déjà construit. C’est tout l’intérêt de poser le SaaS après le freelance.

✏️ Exercices

Exercice 1 — Le test « où vivent-ils ? ». Prends ta meilleure idée de SaaS actuelle. En une phrase, nomme l’endroit précis où se rassemblent tes clients potentiels (subreddit, groupe, forum, liste d’entreprises…). Si tu n’y arrives pas, l’idée n’est pas prête.

Exercice 2 — Reformule à la Mom Test. Tu veux valider une idée d’outil de facturation pour freelances. Écris trois questions qui respectent le Mom Test (sur le passé et le concret), et repère la question piège à ne PAS poser.

🧠 Quiz de révision

Chapitre suivant : Construire vite avec l’IA — transformer l’idée validée en MVP en quelques semaines, sans sur-construire.