je sais que tu as vu les agents de tout le monde créer des applis mobiles sur X.
littéralement tous les jours, quelqu’un poste : « lancé sur l’App Store iOS en 24h », puis deux semaines plus tard : « j’ai atteint 4k$ de MRR ». et les réponses sont toujours les mêmes :
« t’as utilisé quoi pour le coder ? » « t’as trouvé tes utilisateurs comment ? » « lâche la sauce »
à force d’en voir passer, tu finis forcément par te demander :
« est-ce que je devrais aussi me lancer dans les applis mobiles ? »
réponse courte : PUTAIN OUI.
surtout si tu as passé ces dernières années à construire du SaaS.
et encore plus si tu t’es convaincu que les applis grand public n’étaient pas pour toi parce que tu es un « profil b2b ».
parce qu’il y a de fortes chances que tu vendes déjà à des particuliers depuis des années. tu t’es juste contenté de leur coller un dashboard SaaS sous le nez.
voilà pourquoi cette distinction compte, et exactement comment je passerais de zéro à une appli mobile prête à être publiée, le plus vite possible.
tu fais peut-être déjà du b2c
il y a un conseil startup ultra classique qu’on répète partout :
- vends aux entreprises
- les entreprises ont de l’argent
- les clients b2b restent plus longtemps
- les consommateurs ne veulent pas payer
ça paraît logique.
jusqu’à ce que ton « SaaS b2b » soit un outil d’analytics à 19$/mois vendu à des solopreneurs.
tu n’as pas échappé au b2c.
tu as juste choisi l’une des cibles de consommateurs les plus difficiles qui soient.
les indie hackers et les petits fondateurs sont extrêmement sensibles au prix. ils comprennent comment fonctionne un logiciel, ils comparent tout, et ils passeront volontiers trois heures à chercher une alternative open-source pour éviter de te filer 20$/mois.
et la moitié d’entre eux se disent :
« je pourrais sûrement le coder moi-même. »
coller un abonnement Stripe sur un truc n’en fait pas magiquement du b2b.
la distinction vraiment utile, c’est pourquoi quelqu’un achète.
une entreprise achète généralement un logiciel pour une raison économique. ça fait gagner du temps aux employés, ça réduit les coûts, ça augmente le chiffre d’affaires, ça remplace un autre outil ou ça simplifie un process.
les consommateurs achètent pour des raisons totalement différentes.
ils veulent mieux dormir.
être plus beaux.
économiser plus.
arrêter de perdre leur temps.
devenir plus forts.
mieux manger.
se sentir plus organisés.
apprendre quelque chose.
arrêter quelque chose.
être moins anxieux.
gagner en confiance.
ou simplement avoir l’impression d’avancer.
et ces problèmes sont immenses, parce que littéralement tout le monde les a.
en plus, tu n’as pas besoin de convaincre un service achats, de t’intégrer dans une stack de 14 outils ni d’expliquer ton ROI pendant un call commercial.
tu dois juste faire en sorte qu’une personne regarde ton produit et se dise :
« attends, je le veux. »
c’est un terrain de jeu complètement différent.
et aujourd’hui, les applis mobiles sont l’un des moyens les plus simples d’y jouer.
pourquoi le mobile redevient soudainement intéressant
plusieurs choses se passent exactement en même temps.
1. l’ia a détruit une énorme partie de la barrière technique
avant, créer une appli mobile correcte signifiait apprendre Swift ou Kotlin, comprendre un écosystème radicalement différent, se battre avec Xcode, réfléchir à l’architecture de l’app et probablement passer des mois avant d’avoir un truc montrable.
ça change à une vitesse folle.
une appli grand public bien ciblée peut désormais passer d’une idée dans ta tête à un produit utilisable en une journée.
le goulot d’étranglement n’est plus tellement :
« est-ce que je peux le construire ? »
c’est plutôt :
« est-ce que je devrais le construire ? »
ce qui est un problème beaucoup plus intéressant.
2. la distribution grand public est partout
TikTok, Reels et Shorts peuvent placer un produit totalement inconnu devant des millions de personnes, sans que l’entreprise ait la moindre audience existante.
tu n’as pas forcément besoin de SEO.
tu n’as pas forcément besoin de pubs payantes.
tu n’as pas forcément besoin de 50 000 abonnés sur Twitter.
un seul bon contenu peut générer les quelques centaines ou milliers d’utilisateurs nécessaires pour comprendre s’il y a un vrai potentiel.
3. le mobile s’intègre parfaitement à cette distribution
voir la vidéo.
comprendre le problème.
télécharger l’appli.
tester le produit.
tout ce parcours peut se faire en quelques minutes, sur le même appareil.
il n’y a presque aucun changement de contexte.
4. tu peux tester des idées à une vitesse dingue
c’est peut-être le plus gros changement.
si construire un MVP prend trois mois, le choix de l’idée semble crucial.
si construire un MVP prend un jour ou deux, toute l’économie du projet change.
tu n’as pas besoin de trouver l’idée ultime.
tu dois trouver un concept assez intéressant à tester, construire la version la plus petite possible qui prouve le comportement central, le mettre entre les mains des gens et voir ce qui se passe.
si personne n’en a rien à faire, tu as appris un truc.
si les gens l’utilisent une fois mais ne reviennent jamais, tu as appris autre chose.
si 100 personnes le téléchargent et que 25 l’ouvrent encore une semaine plus tard, là, ça devient intéressant.
voilà donc exactement comment je m’y prendrais.
PREMIÈRE ÉTAPE
1) trouve la demande avant de trouver l’idée
n’ouvre pas une page Notion vierge pour brainstormer des « idées de startup ».
tu vas surtout trouver des solutions à des problèmes qui n’existent que dans ta tête.
à la place, commence par observer les gens.
pour les produits grand public, l’un des meilleurs endroits pour faire ça, c’est TikTok.
télécharge l’appli.
passe 5 à 10 min/jour à chercher délibérément des schémas répétitifs.
pas des vidéos virales au hasard. des comportements humains.
cherche :
- les trucs dont les gens se plaignent constamment
- les habitudes qu’ils essaient d’arrêter
- leurs complexes
- ce dont ils se vantent
- ce qu’ils trackent de manière obsessionnelle
- les nouvelles esthétiques et identités
- les challenges que tout le monde se met soudain à faire
- les domaines où ils aimeraient s’améliorer
- les routines qu’ils partagent en boucle
- les choses pour lesquelles ils demandent sans cesse de l’aide
- les comportements qui nécessitent déjà un bidouillage pénible
en gros, tu cherches des problèmes humains cachés sous des tendances.
par exemple :
il y a une tendance appelée « underconsumption core ».
en surface, la tendance, c’est des gens qui achètent moins de trucs.
la réaction évidente d’un cerveau de fondateur serait :
« créons une appli d’underconsumption. »
ne fais pas ça.
demande-toi plutôt pourquoi des millions de personnes s’y reconnaissent.
les vrais problèmes sont peut-être :
« j’achète sur un coup de tête quand je suis stressé. »
« j’arrête pas d’acheter des trucs dont j’ai pas besoin. »
« économiser de l’argent, c’est ennuyeux. »
« je n’ai aucune idée de ce que devient mon argent chaque mois. »
« je veux me sentir récompensé quand je n’achète pas quelque chose. »
ça, c’est beaucoup plus intéressant.
maintenant, tu peux commencer à imaginer de vraies boucles produit.
peut-être qu’à chaque fois que tu résistes à un achat, tu l’ajoutes dans l’appli et ton compteur d’« argent économisé » augmente.
peut-être que tu prends en photo un truc que tu t’apprêtes à acheter et que l’appli t’oblige à attendre 24 heures.
peut-être que tes amis font un concours pour voir qui a évité le plus d’achats inutiles ce mois-ci.
la tendance t’a donné le signal.
le comportement sous-jacent te donne le produit.
les 3 formats d’applis grand public auxquels je reviens toujours
tu n’as pas non plus besoin d’inventer une catégorie totalement nouvelle.
la plupart des applis grand public intéressantes reposent sur quelques structures de base.
le tracker
transforme un comportement invisible en chiffres.
dépenses. temps d’écran. sommeil. habitudes. humeur. alimentation. concentration. entraînements. sobriété. lecture. révisions.
les gens adorent se voir quantifiés, parce qu’un truc abstrait devient soudain un progrès visible.
« je me concentre mieux ces derniers temps », c’est vague.
« mon temps de concentration moyen est passé de 41 à 76 minutes », ça paraît réel.
le coach
aide quelqu’un à devenir une version légèrement différente de lui-même.
missions quotidiennes. défis. plans. rappels. recommandations personnalisées. feedback.
souvent, les gens n’ont pas besoin d’un énième outil compliqué avec 40 boutons.
ils ont besoin d’un truc qui comprend leur objectif et qui leur dit :
« fais ça maintenant. »
le produit prend de la valeur parce qu’il supprime des décisions.
l’utilitaire simple
prends un truc pénible et rends-le agréable.
timers. listes. journaux. notes. widgets. planificateurs. calculatrices. scanners.
la fonctionnalité peut être ridiculement simple si l’expérience est suffisamment bonne.
un produit n’a pas besoin de 25 fonctions pour mériter sa place sur l’écran d’accueil de quelqu’un.
parfois, une seule fonction utilisée tous les jours est bien plus puissante.
pique des idées dans les commentaires
une dernière astuce :
quand tu trouves une tendance, cherche des mots comme « appli » dans les commentaires.
les gens écrivent littéralement :
« il faudrait vraiment que quelqu’un fasse une appli pour ça »
ou :
« est-ce qu’il existe une appli qui fait ça ? »
ou :
« j’aimerais tellement qu’un truc suive ça automatiquement. »
c’est de la recherche produit gratuite.
et c’est beaucoup plus utile que de demander aux gens :
« tu utiliserais une appli qui fait X ? »
parce qu’ils expriment déjà le problème sans que tu leur aies mis l’idée dans la tête.
2) définis la boucle avant de coder quoi que ce soit
avant de toucher au code, réponds à une question simple :
qu’est-ce que quelqu’un va faire de façon répétée dans cette appli ?
pas quelles sont ses fonctionnalités.
quelle est la boucle ?
pour une appli de gestion des dépenses, ça pourrait être :
faillir acheter un truc → l’enregistrer → résister à l’achat → voir l’argent économisé → ressentir un progrès → recommencer
pour une appli de fitness :
ouvrir l’appli → recevoir l’entraînement du jour → le terminer → voir ses progrès → revenir demain
pour une appli de concentration :
choisir une tâche → lancer le timer → finir la session → allonger sa série → recommencer
si tu ne peux pas expliquer la boucle centrale en une phrase, ton appli est probablement encore trop compliquée.
pose-toi ensuite quatre autres questions :
qu’est-ce qui pousse quelqu’un à la télécharger ?
il doit y avoir une promesse très claire.
qu’est-ce qui permet de la comprendre en 10 secondes ?
la valeur ne devrait pas nécessiter de tutoriel.
qu’est-ce qui leur offre leur première victoire ?
amène-les-y le plus vite possible.
qu’est-ce qui leur donnera envie de l’ouvrir demain ?
c’est celle-là que les fondateurs oublient souvent.
les téléchargements, c’est bien.
la rétention, c’est le produit.
tu n’as pas besoin de réponses parfaites pour l’instant. juste d’assez de clarté pour ne pas demander à une IA d’inventer tout ton business pendant qu’elle écrit le code.
3) emprunte les schémas, pas les pixels
une fois que tu as une idée et une boucle de base, ne designe pas tout à partir de zéro.
tu n’es probablement pas product designer.
moi non plus.
trouve plutôt 5 à 10 applis à succès autour du même problème ou du même comportement utilisateur.
elles n’ont même pas besoin d’être des concurrentes directes.
si tu crées une appli d’épargne, peut-être qu’une appli a un onboarding incroyable, qu’une autre a un super système de séries, qu’une autre a un écran de progression hyper satisfaisant et qu’une dernière a un paywall que tu aimes bien.
télécharge-les.
utilise-les pour de vrai.
puis fais des captures d’écran de tout :
- premier lancement
- inscription
- onboarding
- écran d’accueil
- navigation
- action principale
- états vides
- écrans de progression
- séries (streaks)
- notifications
- incitations à passer en premium
- paywall
- paramètres
ce qui est utile, ce ne sont pas les couleurs ou les coins arrondis.
ce sont les décisions qu’il y a derrière.
où posent-ils des questions ?
combien y a-t-il d’écrans d’onboarding ?
à quel moment montrent-ils le vrai produit ?
quand demandent-ils l’autorisation d’envoyer des notifications ?
quand demandent-ils de l’argent ?
à quelle vitesse obtiens-tu ta première victoire ?
quelles informations restent visibles en permanence ?
qu’est-ce qui est caché ?
qu’est-ce qui te donne envie de revenir demain ?
ces boîtes ont déjà testé des milliers de micro-décisions sur lesquelles tu serais sinon obligé de tâtonner.
alors n’invente pas chaque interaction à partir de zéro.
étudie ce qui marche, comprends pourquoi ça marche, combine les meilleurs schémas et ajoute ta touche personnelle.
pour un public jeune et grand public, j’aime généralement :
- une action évidente par écran
- une typographie énorme
- très peu de texte
- des progrès visibles
- des séries
- des paliers
- des chiffres satisfaisants
- de la personnalisation dès le début
- un feedback très clair quand une action est terminée
en gros :
rends le progrès impossible à rater.
si quelqu’un accomplit quelque chose, célèbre-le.
s’il utilise l’appli depuis sept jours, montre-le-lui.
s’il s’est amélioré de 18 %, montre-le-lui.
s’il a économisé 143 $, fais en sorte que ce chiffre soit impossible à ignorer.
l’utilisateur doit constamment se dire :
« ça marche. »
4) transforme les références en vraie appli
c’est là que le développement devient ridiculement facile.
j’ai testé la plupart des outils utilisés pour coder avec l’ia.
mais si je veux passer rapidement d’une idée à une vraie appli mobile, j’utilise Shipper.
à ce stade, tu devrais déjà avoir :
- ton idée d’appli
- ton utilisateur cible
- le résultat que tu promets
- ta boucle produit principale
- des captures d’écran d’applis qui résolvent bien des problèmes similaires
prends tout ça et donne-le d’abord à ChatGPT, Claude ou Grok.
ne dis pas :
« crée-moi une appli de budget. »
tu ne donnes quasiment rien au modèle pour travailler.
donne-lui plutôt un vrai brief :
« je développe une appli mobile qui aide {utilisateur} à atteindre {résultat}. analyse les références jointes et décortique les schémas ux, la hiérarchie visuelle, l’onboarding, la navigation et les interactions qu’elles utilisent. adapte ces schémas à mon produit. définis chaque écran du mvp, ce qui s’y passe, tout le parcours d’onboarding, la navigation principale, la boucle utilisateur centrale et un mécanisme qui donne aux utilisateurs une raison de revenir régulièrement. supprime tout ce qui n’est pas indispensable pour la première version. enfin, transforme tout ça en un prompt de développement détaillé. »
tu as maintenant quelque chose qui ressemble beaucoup plus à un cahier des charges qu’à un prompt jeté au hasard.
lis-le.
vire les trucs débiles.
ajoute ce qui manque.
ensuite, prends ce résultat, joins tes captures d’écran et mets le tout dans Shipper.
dis-lui exactement ce que tu veux.
les écrans.
les interactions.
le flux.
la logique.
les moindres détails.
puis continue à lui parler comme tu le ferais avec un développeur assis à côté de toi :
« simplifie cet écran. »
« déplace le paywall après que l’utilisateur a obtenu son premier résultat. »
« ajoute une série de 7 jours ici. »
« cet onboarding est trop long. coupe-le en deux. »
« sauvegarde cet état quand l’utilisateur ferme l’appli. »
« rends cette interaction plus native pour iOS. »
« il y a trop de choix sur cet écran. mets une action en avant. »
c’est là que les gens se trompent avec les builders IA.
tu n’as pas besoin de connaître Swift.
tu n’as pas besoin de créer chaque composant à la main.
tu n’as pas besoin de configurer une usine à gaz de dev juste pour savoir si quelqu’un veut de ton idée.
mais il te faut toujours du goût.
et tu dois toujours prendre des décisions.
en gros, tu réalises le produit pendant que Shipper le construit.
et la qualité du résultat dépend énormément de la qualité de ces décisions.
la plus grande différence, c’est la façon dont tu parles à l’ia.
ne lui dis pas juste de « faire une appli ».
force-la constamment à penser à l’utilisateur :
- que voit-il en premier ?
- que doit-il comprendre ici ?
- quelle est l’action la plus importante ?
- à quelle vitesse ressent-il le bénéfice principal ?
- où pourrait-il se perdre ?
- quelles informations peut-on supprimer ?
- qu’est-ce qui rend ça satisfaisant ?
- qu’est-ce qui lui donne une raison de l’ouvrir demain ?
ça donne généralement un résultat bien meilleur que de demander sans fin de nouvelles fonctionnalités.
5) rends la première version assez bonne pour être payante
une fois que l’expérience principale fonctionne, arrête d’ajouter des trucs au hasard.
concentre-toi sur trois choses.
l’onboarding
traite l’onboarding comme un produit à part entière.
parce que pour la plupart des utilisateurs, c’en est un.
ils n’ont pas encore testé ton produit. ils ne te doivent aucune loyauté. ils peuvent fermer l’appli en deux secondes et ne plus jamais y penser.
trouve de bons parcours d’onboarding, capture-les et reproduis le même processus de référence.
ton objectif est simple :
l’utilisateur doit comprendre pourquoi il a téléchargé l’appli et en tirer de la valeur en moins de 30 secondes.
chaque écran d’onboarding doit justifier son existence.
si tu poses une question, utilise la réponse.
si tu demandes une permission, explique pourquoi.
si un truc peut attendre, repousse-le à plus tard.
et si tu as huit écrans d’onboarding juste parce que toutes les autres applis grand public en ont huit, tu fais fausse route.
donne ensuite ces références à Shipper et itère jusqu’à ce que tout paraisse évident.
la monétisation
une fois que le produit tourne, ajoute ton abonnement et ton paywall.
ne perds pas trois jours à hésiter entre 27,99 $ et 31,99 $ pour ton plan annuel.
tu n’as aucune donnée pour l’instant.
un point de départ tout à fait normal pourrait être :
- 4,99 $/semaine
- 29,99 $/an
tu pourras tester tes prix plus tard.
ce qui compte le plus au début, c’est quand tu demandes de l’argent.
si possible, laisse d’abord l’utilisateur comprendre la valeur.
laisse-le créer quelque chose.
voir un résultat.
terminer sa première session.
recevoir son premier plan personnalisé.
place ensuite le paywall sur le chemin de la poursuite de cette valeur.
tu veux que l’utilisateur se dise :
« j’en veux plus. »
et non :
« c’est quoi ce truc que je suis censé payer ? »
les finitions
ensuite, utilise ton appli.
beaucoup.
ne te contente pas de fixer l’écran d’accueil en décidant que ça a l’air terminé.
comporte-toi vraiment comme un utilisateur.
pars d’un compte neuf.
clique sur les trucs dans un ordre bizarre.
refuse les permissions.
ferme l’appli en plein milieu de l’onboarding.
rouvre-la.
laisse des champs vides.
entre des données absurdes.
reviens le lendemain matin.
donne-la à des amis sans rien expliquer et regarde où ils bloquent.
tu vas découvrir un nombre hallucinant de petits détails qui te semblaient parfaitement logiques parce que c’est toi qui les as codés.
chaque interaction confuse que tu supprimes rend le produit plus fiable.
et dès qu’un truc cloche, retourne dans Shipper et décris exactement ce que tu veux modifier.
tu ne cherches pas à rendre la première version parfaite.
tu cherches à t’assurer que la boucle centrale semble aboutie.
6) lance avant de te sentir prêt
dès que la boucle principale fonctionne :
LANCE-LA.
ne perds pas un mois de plus à ajouter des fonctions sociales, des succès, des assistants IA, des thèmes personnalisés et 14 réglages juste parce que publier te fait peur.
la première version n’est pas censée prouver que tu es un génie.
elle doit répondre à une seule question :
est-ce que quelqu’un veut vraiment de ça ?
publie-la.
crée du contenu autour du problème.
envoie des gens dessus.
observe ce qu’ils font.
lis les avis.
regarde où ils décrochent pendant l’onboarding.
regarde combien atteignent vraiment l’action principale.
regarde combien reviennent le lendemain.
regarde combien reviennent une semaine plus tard.
regarde qui paie.
puis corrige ce qui coince et relance.
personnellement, je commencerais par iOS et je ne me soucierais d’Android qu’une fois que l’idée aurait justifié ce travail supplémentaire.
et je garderais une première version concentrée de manière presque douloureuse.
une audience.
un problème.
une promesse.
une boucle centrale.
tu pourras toujours étoffer l’appli une fois que les gens y tiendront.
réduire un produit après avoir codé 30 fonctionnalités est beaucoup plus dur.
le truc étrange quand on crée des applis grand public aujourd’hui, c’est que la barrière technique qui nous en empêchait presque tous a pratiquement disparu.
avant, tu dépensais la majeure partie de ton énergie à comprendre comment construire le truc.
maintenant, tu peux consacrer beaucoup plus de temps à ce qui fait vraiment marcher le truc :
trouver un vrai comportement.
le transformer en un produit que les gens comprennent immédiatement.
leur donner une raison de revenir.
comprendre la distribution.
tu peux découvrir ce que les gens veulent sur TikTok, étudier les applis qui captent déjà leur attention, transformer ces schémas en un vrai cahier des charges et laisser Shipper construire le tout.
puis le mettre entre les mains de vraies personnes.
tu n’as pas besoin de savoir si c’est une appli à 10k$/mois avant de commencer.
tu dois juste mettre la version 1 entre les mains de quelqu’un.
de préférence avant que le chrono de 18 heures ne soit écoulé.
