Voici comment j'ai monté une app à $100K ARR

TL;DR

Jérémy Pitault, créateur de l'application d'apprentissage du japonais Shinobi (Shinobi Japanese), partage sa méthode en 9 étapes plus 2 bonus pour créer une application mobile ou web qui marche. Son application approche les 10 000 $ de MRR, avec environ 130 000 utilisateurs créés et 50 000 utilisateurs actifs mensuels. Sa thèse : les deux premières étapes (trouver une idée à partir de ce qu'on aime et d'un problème précis, puis faire une étude de marché) comptent plus que tout le reste, car sans demande réelle tout le développement et le marketing sont perdus. La vidéo couvre aussi le choix de plateforme, la stack recommandée (JavaScript/TypeScript, Next.js, React Native, Expo, Firebase…), le MVP, le marketing, les retours utilisateurs, le service client, le pivot, les A/B tests et l'association. Public visé : développeurs et créateurs qui lancent leur première application.

Points clés

1. Les étapes 1 (idée + problème) et 2 (étude de marché) sont les plus importantes : sans elles, on risque de perdre 6 mois à développer et marketer un produit sans demande 0:00:22 0:02:46
2. Choisir l'idée à partir de ce qu'on aime et viser un problème précis dans cette niche ; ne s'aventurer sur des marchés inconnus qu'après avoir déjà réussi une application 0:00:36
3. Plateforme : B2B et outils B2C techniques en web ; applications B2C gamifiées, éducatives ou sociales en mobile, idéalement sur toutes les plateformes 0:03:03
4. La meilleure stack est celle qu'on maîtrise déjà ; à défaut : JavaScript/TypeScript, Next.js + Vercel (web), React Native + Expo (mobile), Firebase, Node.js, Sanity, PostHog, RevenueCat ou Stripe, Sentry 0:04:25
5. Le MVP doit contenir au maximum 1 à 2 fonctionnalités clés, celles qui résolvent le problème de l'audience 0:06:40
6. Workflow de développement du MVP en 4 étapes : UI/UX avec données statiques, logique (backend, API, base, auth), connexion UI et logique, retouches 0:08:09
7. Marketing : SEO/ASO, contenu organique en masse et régulier, emailing, publicité payante (dont Google Ads), influenceurs plus tard, affiliation surtout pour le web ; « être partout » 0:08:57
8. Retours utilisateurs : bouton de signalement de bug près de la fonctionnalité principale, écran de feedback (note sur 5 + champ texte) après 1 à 3 utilisations, email du support partout, communauté (Discord) 0:11:01
9. Lancer la communauté Discord avant l'application a permis de recruter des bêta-testeurs et d'éviter les mauvais avis ; Android exige 20 bêta-testeurs avant publication 0:12:27
10. Service client : répondre aux avis et aux mails en moins de 24 heures, régler le problème, offrir un geste (14 jours ou 1 mois de premium) et demander de modifier l'avis 0:13:10
11. Pivoter si les utilisateurs détournent l'usage de l'application ; sinon diagnostiquer : pas de marché (abandonner) ou mauvaise implémentation (continuer) 0:14:22
12. Diagnostic : personne ne télécharge = problème marketing ; les gens téléchargent mais ne restent pas = problème d'application 0:16:22
13. A/B tests seulement après validation de l'idée, sur les nouveaux utilisateurs, pour améliorer rétention, engagement et conversion 0:16:39
14. S'associer avec un profil complémentaire (marketing si on est développeur) : c'est ce que fait l'auteur sur tous ses produits 0:17:42

Plan de la vidéo

Contenu détaillé

0:00:00 Introduction

• L'auteur, Jérémy, a créé l'année précédente une application mobile d'apprentissage de langue appelée Shinobi 0:00:00
• Chiffres annoncés : proche de 10 000 $ de MRR, environ 130 000 utilisateurs créés, 50 000 utilisateurs actifs mensuels 0:00:00
• Le titre et la description parlent de 100 000 $ d'ARR (la description précise « application d'apprentissage de langue (japonais) ») 0:00:00
• Annonce de 9 étapes plus un bonus ; les deux premières sont présentées comme les plus importantes 0:00:22

0:00:36 Étape 1 : trouver une idée d'application

• Partir de ce qu'on aime : c'est là qu'on apporte de la valeur ajoutée 0:00:36
• Opinion : pour une première application, faire quelque chose qu'on n'aime pas est « très compliqué » ; on ne peut viser des marchés inconnus qu'après avoir déjà une application qui marche 0:00:52
• Trouver un problème à résoudre dans cette niche, sinon l'application « servira à rien » 0:00:52
• Discuter ensuite avec une IA pour préciser le produit ; il recommande Claude 0:01:07
• Opinion : Claude est « la meilleure IA » 0:01:07
• Exemple : on aime la peinture, problème = les peintres ont du mal à se rencontrer. Idée simple : réseau social pour peintres. Idée affinée avec l'IA : application pour organiser les vernissages (marché plus réduit, problème précis) 0:01:23

0:01:56 Étape 2 : étude de marché

• Objectif : repérer les acteurs principaux, les niches et les ultra-niches 0:01:55
• Exemple d'ultra-niche : application pour peintres, pour les vernissages, en particulier d'art abstrait 0:02:10
• Chercher aussi des sous-marchés émergents : exemples cités, les tags ou la peinture féminine 0:02:10

• Schéma à l'écran : trois cercles imbriqués, « Peintre » (marché), « Vernissage » (niche), « Abstrait » (ultra-niche) 0:02:13

0:02:30 Annonce : communauté Skool

• Il vient de créer une communauté Skool (« school » dans le transcript) pour développeurs et créateurs d'applications, avec vidéos et modules complets, notamment sur l'usage de l'IA pour les études de marché ; lien en description 0:02:29
• Rappel : sans les étapes 1 et 2, on peut perdre 6 mois à développer, publier et marketer un produit alors qu'il n'y a « aucune demande » 0:02:46

0:02:45 Étape 3 : choisir la ou les plateformes

• B2B (professionnels) : plutôt le web ; le mobile y est peu utile 0:03:03
• Exemple : Mobbin (« mobine » dans le transcript), outil qui montre des captures d'écran d'applications mobiles, destiné aux développeurs, designers et product managers ; il n'existe qu'en site web, car on travaille sur ordinateur, pas sur téléphone 0:03:03

• À l'écran (Mobbin) : fiche « Discord : Talk, play, hang out », Platform « iOS, Android, Web, Site », Rating 4.24 (7), Category « Social Networking, Communication », onglets Screens / UI Elements / Flows 0:03:16
• B2C technique (ex. convertisseur PNG vers JPEG, transcripteur de vidéos YouTube à partir d'un lien) : plutôt une application web 0:03:44

• À l'écran : site « Turn YouTube Videos into Transcripts Instantly », « Rated 4.6 out of 5 (Based on 15,609 reviews) », champ avec un lien youtu.be et bouton « Extract transcript », options « Extract in Bulk » et « Extract Channel ID », « Get started for free with 25 tokens », « Trusted by 1.3M+ users worldwide » (nom du site non visible) 0:03:53
• B2C gamifié, éducatif ou réseau social : le mobile est « clairement une bonne solution » ; il recommande alors de viser toutes les plateformes directement 0:04:04

0:04:26 Étape 4 : choisir la stack

• Stack = ensemble des technologies (langages, frameworks, etc.) 0:04:25
• Opinion : la meilleure stack est celle qu'on connaît déjà, pour réduire la friction ; même PHP convient si la plateforme le supporte 0:04:25
• Sans connaissance préalable, il recommande JavaScript (simple, très cross-platform, nombreux frameworks) et TypeScript 0:05:04
• Web : framework Next.js, déploiement sur Vercel (« Versel » dans le transcript) 0:05:04
• Mobile : React Native (Android, iOS et web) avec Expo pour gérer le code natif plus simplement 0:05:22
• Reste : Firebase (« tous les produits sont vraiment cool », plans gratuits) : Firebase Authentication, Firestore pour la base, Firebase Analytics (basiques mais bon début) 0:05:22
• Backend si besoin : Node.js (il le qualifie de framework JavaScript), éventuellement les Google Cloud Functions de Firebase 0:05:40
• CMS : Sanity, qu'il utilise 0:05:58
• Analytics avancées : PostHog, plan gratuit à 1 million d'événements par mois 0:05:58
• Paiements et abonnements : RevenueCat pour une application mobile (logo affiché ; « revenu 4 » dans le transcript), Stripe pour le web 0:06:19
• Logs et monitoring : Sentry (« Centri » dans le transcript, à vérifier) 0:06:19

0:06:40 Étape 5 : développement de l'application

• Il annonce oralement « la 6e étape » mais il s'agit de l'étape 5 selon les chapitres 0:06:34
• MVP (minimum viable product) : produit minimal envoyable en production, avec au maximum 1 à 2 fonctionnalités clés, celles qui résolvent le problème de l'audience 0:06:40
• Exemple Shinobi Japanese : marché éducation / apprentissage de langue, niche japonais ; problème : manque de contenu compréhensible en contexte pour des apprenants de niveau peu avancé 0:07:05
• MVP de Shinobi : petites histoires compréhensibles, avec images pour le contexte, et chaque mot cliquable pour avoir définition, exemples et prononciation 0:07:28
• Coder avec ou sans IA : question de préférence 0:07:28
• Il utilisait « Patrolia » (outil non identifié, à vérifier) jusqu'à il y a quelques mois, puis a découvert Claude Code, qu'il utilise plusieurs heures par jour 0:07:49
• Il dit devoir prendre le plan payant à 200 dollars par mois de Claude Code 0:07:49
• Masterclass Claude Code de plusieurs heures disponible dans sa communauté Skool 0:08:09
• Workflow pour coder un MVP rapidement, 4 étapes 0:08:09 :
  • 1. UI/UX : tout le design, avec des données statiques, sans base de données 0:08:28
  • 2. Logique : backend, API, base de données, voire authentification 0:08:28
  • 3. UI<=>Logique : connecter l'interface à la logique 0:08:28
  • 4. Retouches : design ajusté aux vraies données, architecture si besoin 0:08:49

0:08:57 Étape 6 : marketing

• Opinion : c'est « peut-être » l'étape la plus importante 0:08:49
• Acceptation sur Google Play Store et Apple Store : parfois des retouches pour être conforme, mais globalement simple ; aucune validation pour une application web 0:08:49
• SEO (site web) ou ASO (App Store Optimization) : mots-clés dans la page de présentation pour être trouvable 0:09:08
• Contenu organique B2C : TikTok, Instagram, Facebook, Reddit (« Crédit » dans le transcript, à vérifier), YouTube, formats shorts et longs 0:09:45
• Contenu organique B2B : LinkedIn, YouTube, blogs 0:09:45
• Objectif : contenu en masse qui apporte de la valeur ; possibilité d'une liste email qui envoie de la valeur et redirige vers l'application 0:09:45
• Publicité payante : mêmes réseaux que l'organique, plus Google Ads, intéressant en B2B et B2C 0:10:06
• Opinion : le plus important est « d'être partout », que l'utilisateur voie publicités ou contenu où qu'il aille 0:10:06
• Shinobi publie beaucoup sur Instagram, TikTok et YouTube (longs et shorts), plusieurs fois par semaine ; poster beaucoup puis s'arrêter est mauvais pour l'algorithme 0:10:23
• Influenceurs : à garder pour plus tard, il faut de la réputation pour négocier les prix 0:10:42
• Affiliation : marche très bien dès le début, mais difficile à mettre en place sur mobile ; plutôt pour le web 0:10:42

0:11:01 Étape 7 : retours utilisateurs

• Opinion : les retours utilisateurs sont « la chose la plus précieuse », focus principal au lancement 0:10:56
• Mettre dans l'application un endroit simple et intuitif pour rapporter les bugs, proche de la fonctionnalité principale ; sur Shinobi, un bouton dans les histoires 0:11:13
• Après 1, 2 ou 3 utilisations de la fonctionnalité principale, afficher un écran de feedback (avis, pas bug) : note sur 5 et petit champ texte 0:11:34
• Afficher l'adresse email du support partout : profil, settings, etc. 0:11:53
• Bonus : créer une communauté (Discord, groupe Facebook…) ; Discord marche très bien pour Shinobi 0:12:09
• Shinobi a lancé sa communauté Discord avant la mise en ligne, alimentée par le contenu organique ; des membres ont rejoint le groupe de bêta-testeurs, ce qui a évité des mauvais avis 0:12:27
• Android : il faut 20 bêta-testeurs avant de publier sur le store ; une communauté permet de les trouver vite 0:12:46

0:13:09 Étape 8 : service client

• Enjeu : la réputation, via la preuve sociale (social proof) ; des mauvais avis sur Trustpilot, l'Apple Store ou le Google Play Store et « c'est foutu » 0:13:10

• À l'écran (Trustpilot, La Banque Postale, en illustration) : note 1,3 « Mauvais », « 6 k avis », « Voir tous les avis (5 644) », comparaison « Les gens ont aussi consulté » : BoursoBank 4.5 (46 k), Crédit Agricole 2.3 (4 k), Creditmutuel 2.1 (2 k), Société Générale & Vous 1.9 (3 k) 0:13:19
• Répondre directement aux avis (stores, Trustpilot) et aux mails et retours en moins de 24 heures 0:13:27
• Causes fréquentes d'un mauvais avis : bug, application « dévente » (sens incertain, à vérifier), absence de réponse du support 0:13:27
• Régler le problème pour la personne puis pour tous les utilisateurs 0:13:44
• Offrir un geste : 14 jours ou 1 mois gratuit de la version premium 0:13:44
• Demander ensuite à l'utilisateur de modifier son avis, en expliquant que l'application est nouvelle et que les bons avis l'aident à grandir 0:14:03

0:14:33 Étape 9 : pivoter ou abandonner

• Si l'application ne marche pas mais que les retours révèlent un usage détourné : pivoter vers ce détournement, remodeler l'application selon l'usage réel 0:14:42
• Sinon, vérifier que les étapes 1 et 2 ont été bien faites (y a-t-il un marché, une demande ?) 0:15:01
• Marché et demande réels : problème d'implémentation (marketing ou application), ou barrière à l'entrée (avantage compétitif des concurrents) : chercher à la casser, ou passer à autre chose 0:15:01
• Pas de marché ni de demande (personne ne télécharge malgré un bon marketing) : passer à autre chose 0:15:35
• En cas de problème d'implémentation : continuer, se former au marketing, améliorer l'application avec les retours, appeler et parler aux utilisateurs 0:16:05
• Personne ne télécharge : problème marketing. Les gens téléchargent mais ne restent pas : problème d'application ; parler aux utilisateurs qui partent 0:16:22

0:16:40 BONUS 1 (10e point) : A/B tests

• Ajouté « parce que j'aime bien les chiffres arrondis » 0:16:39
• Pas au lancement : d'abord valider l'idée et intégrer les retours utilisateurs 0:16:39
• Nécessite une base d'utilisateurs importante et beaucoup de nouveaux entrants ; les A/B tests se font surtout sur les nouveaux utilisateurs, car la rétention sur une application n'est « pas très importante » 0:16:55
• Principe : tester deux versions d'une fonctionnalité pour voir laquelle marche le mieux 0:16:55
• Indicateurs visés (affichés à l'écran : « Rétention », « Engagement », « Conversion ») : rétention (durée d'utilisation avant abandon), engagement (nombre de sessions par utilisateur, une fois par semaine ou quatre fois par jour), conversion (gratuit vers payant) 0:17:15

0:17:42 BONUS 2 : s'associer

• Faire seul développement, marketing, A/B tests et étude de marché est compliqué ; solution : s'associer avec quelqu'un de complémentaire 0:17:37
• L'auteur maîtrise le développement et l'A/B testing ; il s'est associé sur tous ses produits avec des personnes « très très fortes en marketing » 0:17:56
• Répartition : lui sur le produit, l'itération, la conversation et les retours utilisateurs ; l'associé sur le marketing, l'image, l'étude de marché, les nouvelles idées et fonctionnalités, l'offre 0:18:13
• Communauté Skool (créateurs, développeurs, marketeurs), dont fait partie son associé : échanges avec d'autres créateurs, modules sur le développement d'applications, module de transparence sur Shinobi (MRR, nombre d'utilisateurs, A/B tests et résultats, « adminel » et « data aware », termes à vérifier, probablement panneau d'administration et entrepôt de données) 0:18:34

Procédures actionnables

Valider une idée d'application avant de coder

1. Choisir un domaine qu'on aime et qu'on connaît (surtout pour une première application) 0:00:36
2. Formuler un problème précis à résoudre dans cette niche 0:00:52
3. Affiner le produit en discutant avec une IA (il recommande Claude) 0:01:07
4. Faire l'étude de marché : acteurs principaux, niches, ultra-niches, sous-marchés émergents 0:01:55
5. Ne pas commencer le développement tant que la demande n'est pas établie 0:02:46

Choisir plateforme et stack

1. B2B ou outil B2C technique : web ; B2C gamifié, éducatif ou social : mobile sur toutes les plateformes 0:03:03
2. Prendre sa stack actuelle si elle est supportée par la plateforme 0:04:25
3. Sinon : TypeScript, Next.js + Vercel (web), React Native + Expo (mobile), Firebase Authentication + Firestore + Firebase Analytics, Node.js ou Google Cloud Functions, Sanity (CMS), PostHog (analytics), RevenueCat (mobile) ou Stripe (web), Sentry (logs) 0:05:04

Coder un MVP rapidement

1. Limiter le MVP à 1 ou 2 fonctionnalités qui résolvent le problème 0:06:40
2. UI/UX : construire tout le design avec des données statiques 0:08:28
3. Logique : backend, API, base de données, authentification 0:08:28
4. UI<=>Logique : brancher l'interface sur la logique 0:08:28
5. Retouches : ajuster le design aux vraies données et l'architecture si besoin 0:08:49

Mettre en place la boucle de feedback et le support

1. Ajouter un bouton « rapporter un bug » près de la fonctionnalité principale 0:11:13
2. Après 1 à 3 utilisations de la fonctionnalité principale, afficher un écran de feedback : note sur 5 + champ texte 0:11:34
3. Afficher l'email du support dans le profil, les settings et ailleurs 0:11:53
4. Créer une communauté Discord avant le lancement, y recruter les bêta-testeurs (20 requis pour Android) 0:12:27
5. Répondre à chaque avis et mail en moins de 24 heures, régler le problème, offrir 14 jours ou 1 mois de premium, puis demander la modification de l'avis 0:13:27

Décider de pivoter, continuer ou abandonner

1. Usage détourné observé : pivoter vers cet usage 0:14:42
2. Personne ne télécharge : travailler le marketing 0:16:22
3. Téléchargements sans rétention : améliorer l'application, interroger les utilisateurs qui partent 0:16:22
4. Barrière à l'entrée : la casser ou passer à autre chose 0:15:19
5. Pas de marché ni de demande : passer à une autre application 0:15:35

Données et chiffres

Outils, ressources et entités citées

Citations notables

« Les deux premières étapes, je le dis tout de suite, c'est les plus importantes. Donc ne les passe pas. » 0:00:22

« Si tu ne les fais pas, tu vas perdre 6 mois à développer un produit, le mettre sur le marché, faire le marketing alors qu'il y a juste aucune demande. » 0:02:46

« La meilleure stack, c'est vraiment ta stack. » 0:04:25

« Dans tous les cas, le plus important, c'est d'être partout. » 0:10:06

« Si personne télécharge l'application, on sait déjà que le problème vient du niveau marketing. Si les gens téléchargent l'application mais ne restent pas, l'application a un problème. » 0:16:22

Captures d'écran

Glossaire

• MRR : revenu récurrent mensuel (monthly recurring revenue), chiffre de Shinobi cité en introduction.
• ARR : revenu récurrent annuel (annual recurring revenue), utilisé dans le titre.
• Niche / ultra-niche : sous-marché de plus en plus précis (peintres > vernissages > art abstrait).
• B2B / B2C : application destinée aux professionnels / au grand public.
• Stack : ensemble des technologies (langages, frameworks, etc.) utilisées pour créer l'application.
• MVP : minimum viable product, produit minimal envoyable en production, avec 1 à 2 fonctionnalités clés.
• SEO : optimisation pour les moteurs de recherche (application web).
• ASO : App Store Optimization, mots-clés dans la page de présentation sur les stores.
• Social proof : preuve sociale, réputation portée par les avis.
• Pivoter : remodeler l'application vers l'usage que les utilisateurs en font réellement.
• A/B test : test de deux versions d'une fonctionnalité pour voir laquelle marche le mieux, fait surtout sur les nouveaux utilisateurs.
• Rétention : période pendant laquelle l'utilisateur utilise l'application avant de l'abandonner.
• Engagement : nombre de sessions par utilisateur (fréquence de retour).
• Conversion : passage d'un utilisateur gratuit à payant.

Limites et points à vérifier

• Transcript généré automatiquement par YouTube : plusieurs noms déformés, corrigés ici d'après le contexte ou l'écran. « revenu 4 » = RevenueCat (logo vu à l'écran), « mobine » = Mobbin (site vu à l'écran), « Versel » = Vercel, « Post Hog » = PostHog, « school » = Skool, « Lia » = l'IA, « Cloud Code » = Claude Code.
• Corrections non confirmées visuellement : « Centri » = Sentry, « Crédit » = Reddit (à vérifier).
• Termes non identifiés : « Patrolia » (outil de code utilisé avant Claude Code), « dévente » (cause d'un mauvais avis), « adminel » et « data aware » (contenu du module Skool) : à vérifier.
• Incohérence apparente entre le titre (100 000 $ d'ARR) et l'introduction (« se rapproche doucement des 10 000 dollars de MRR », soit environ 120 000 $ par an si atteint) ; les chiffres ne sont pas sourcés au-delà de la déclaration de l'auteur.
• Numérotation : il annonce oralement « la 6e étape » pour le développement (étape 5 selon les chapitres) ; le BONUS 1 des chapitres est présenté oralement comme un « 10e point ».
• Affirmation non vérifiée ici : l'exigence de 20 bêta-testeurs avant publication sur Android.
• La vidéo est majoritairement en face caméra ; les autres visuels (logos, plans d'illustration) n'apportent pas d'information supplémentaire. Le nom du site de transcription YouTube montré n'est pas visible.
• La vidéo contient plusieurs promotions de la communauté Skool payante (prix non cité) de l'auteur.