Capstone : du prototype au produit

Six semaines plus tard

Faisons les comptes. Six semaines après la première ligne de prompt, l'app de Tom est utilisée par trois classes dans deux collèges. Le prof de maths a payé sa version « classe » via le Payment Link. Lina affiche un streak de 34 jours. Et Tom a reçu cette semaine quatre messages : deux idées de fonctionnalités, une question, un bug mineur. C'est le moment charnière que connaissent tous les créateurs : l'app fonctionne — mais une app qui fonctionne n'est pas encore un produit. Un produit, c'est une app plus une boucle : on mesure, on écoute, on décide, on itère. Ce chapitre installe cette boucle, puis t'envoie vers ton prochain projet.

Mesurer : des chiffres sans espionner

Première question d'un responsable produit : « qui utilise quoi, vraiment ? ». Les impressions mentent — les chiffres, moins. Mais attention au réflexe « Google Analytics » : pour une petite app, surtout utilisée par des mineurs, tu veux un outil d'analytics respectueux de la vie privée comme Plausible ou Umami : pas de cookies, pas de profilage, pas de bandeau de consentement à rallonge, juste des compteurs anonymes. L'intégration tient en une ligne que l'IA ajoutera en trente secondes, et le tableau de bord te dit l'essentiel : combien de visites, quelles pages, quels jours.

Le piège suivant, c'est de regarder les mauvais chiffres. Le nombre de visites flatte l'ego mais ne dit rien d'utile : on appelle ça une métrique de vanité. Tom se choisit une métrique nord — LE chiffre qui dit si l'app remplit sa mission : « combien d'élèves cochent au moins une habitude trois jours par semaine ? ». Tout le reste (visites, comptes créés, pages vues) n'est que du décor autour de cette question. Choisis la tienne avec le même critère : si ce chiffre monte, ton app rend objectivement plus service.

Écouter : organiser le feedback

Les messages éparpillés de Tom — un SMS, deux mails, un mot à la récré — sont le symptôme d'un produit sans canal de feedback. La solution est dans l'app elle-même : un petit bouton « une idée ? un souci ? », un mini-formulaire, et chaque envoi rangé dans une table de la base. Tu as toutes les compétences pour le construire — c'est même un excellent exercice de synthèse des chapitres 6 à 9 : un formulaire (entrées validées !), une table Supabase (avec RLS !), une limite d'envois (chapitre 9 !) :

Ajoute un module de feedback à mon app de suivi d'habitudes.
Ce que je veux :
1. un petit bouton discret « une idée ? un souci ? » en bas de la page principale
2. au clic : un mini-formulaire avec un champ texte de 500 caractères max et un choix « bug / idée / autre »
3. chaque envoi est enregistré dans une table feedback de Supabase avec le user_id, la catégorie et la date — avec la Row Level Security activée
4. limites : 5 envois par utilisateur et par jour, validation du contenu côté serveur, message de remerciement après envoi
5. crée aussi une page /admin accessible uniquement à mon compte, qui liste les feedbacks du plus récent au plus ancien avec un compteur par catégorie
Une étape à la fois, je teste avant de continuer.

Une fois le module en place, la règle d'interprétation : les demandes ne sont pas des besoins. Quand trois élèves demandent « un mode sombre », le besoin réel est peut-être « l'app m'éblouit le soir dans le dortoir ». Avant d'ajouter ce qu'on te demande, remonte au problème : « qu'est-ce qui te gêne, concrètement, à quel moment ? ». Parfois la bonne réponse est la fonctionnalité demandée ; souvent, c'est une solution plus simple que personne n'avait formulée.

Prioriser : la matrice du solo-bâtisseur

Avec les analytics d'un côté et le feedback de l'autre, ta liste « plus tard » va gonfler vite. Le tri se fait avec quatre questions, dans cet ordre : combien d'utilisateurs sont concernés ? (un irritant cité cinq fois bat une idée brillante citée une fois), est-ce aligné avec ta métrique nord ? (une fonctionnalité qui n'aide pas la mission attendra), quel effort ? (demande à l'IA d'estimer : petit, moyen, gros chantier), et est-ce réversible ? (une expérimentation qu'on peut retirer se tente plus librement qu'un engagement définitif).

• Beaucoup d'utilisateurs + aligné + petit effort : fais-le cette semaine.
• Aligné mais gros effort : découpe-le en mini-PRD (chapitre 3) et étale-le.
• Peu d'utilisateurs concernés : laisse mûrir — si ça revient trois fois, ça montera tout seul.
• Pas aligné avec la mission : refuse poliment, même si c'est une bonne idée. Surtout si c'est une bonne idée.

Le dernier point est le plus dur et le plus important : dire non. Chaque fonctionnalité ajoutée est une surface à maintenir, déboguer et sécuriser pour toujours. Les meilleurs produits ne sont pas ceux qui font le plus de choses, ce sont ceux dont chaque chose sert la mission. Tom refuse ainsi un « chat entre élèves » — excellente idée, mauvais produit : sa mission, c'est les habitudes, pas la messagerie.

Monétiser sans se trahir

Le Payment Link du chapitre 8 a transformé l'app de Tom en activité qui rapporte — modestement, mais réellement. Le moment est venu d'y réfléchir posément. Les modèles adaptés à une petite app : le freemium (le cœur gratuit, des conforts payants — le choix de Tom : gratuit pour les élèves, version « classe » avec tableau de bord pour les profs), le paiement unique (simple et honnête, adapté aux outils), le don (viable pour un outil aimé d'une communauté), et l'abonnement (réservé à une valeur récurrente évidente — ne l'inflige pas à un outil qu'on utilise deux fois par mois).

Deux principes au moment de fixer le prix. D'abord, la cohérence avec la mission : Tom ne fera jamais payer un élève — la mission est pédagogique, ce sont les établissements et les profs qui financent. Ensuite, la simplicité : un seul plan payant, un prix rond, une page qui l'explique en trois bénéfices. Tu pourras complexifier quand tu auras cent clients ; à cinq clients, chaque heure passée sur la grille tarifaire est une heure volée au produit.

Faire connaître : montrer le problème, pas la technique

Le bouche-à-oreille a amené trois classes à Tom ; pour aller plus loin, il lui faut une vraie page d'accueil — celle qu'un prof découvre en cliquant sur le lien partagé en salle des profs. Règle d'or du débutant : on ne vend pas la technique, on montre le problème résolu. Personne ne s'inscrit pour « une app Supabase avec RLS » ; on s'inscrit pour « aider vos élèves à tenir leurs routines de travail ». Tom la fait générer avec tout son savoir-faire de prompt :

Crée une page d'accueil marketing pour mon app de suivi d'habitudes, sur la route /accueil.
Audience : des professeurs de collège qui découvrent l'app via un collègue — pas des développeurs.
Structure :
1. un titre qui parle du problème résolu : aider les élèves à tenir leurs routines de travail
2. trois bénéfices concrets en trois cartes, sans aucun jargon technique
3. une capture d'écran de l'app au centre, propre, sur fond clair
4. un court témoignage de prof — je te fournirai le texte exact
5. deux boutons : « essayer gratuitement » vers l'inscription, et « version classe » vers la page de paiement
Style : cohérent avec l'app, épuré, accent vert, rassurant, lisible sur téléphone.
La page doit se charger vite : pas d'animations lourdes, pas de bibliothèques inutiles.

Le rythme durable : itérer sans s’épuiser

Dernier ingrédient du produit : le rythme. L'erreur classique post-lancement est le sprint permanent — trois fonctionnalités par semaine pendant un mois, puis l'abandon complet. Le rythme durable du solo-bâtisseur ressemble plutôt à ceci : une amélioration par semaine, choisie par la matrice de priorisation, livrée selon la méthode des chapitres 3-4 (mini-PRD si c'est gros, construire-tester-committer toujours), plus un quart d'heure d'hygiène hebdomadaire : un œil sur les analytics, le tri des feedbacks, un coup d'œil aux pages de statut et au plafond de dépense IA.

Et accepte une idée contre-intuitive : un produit peut être fini. Si la métrique nord est bonne, que les feedbacks se tarissent et que l'app rend exactement le service prévu, tu as le droit de la laisser tourner en mode maintenance et de passer à autre chose. « Terminé et utile » est un état glorieux, pas un échec d'ambition. Toutes les apps n'ont pas vocation à devenir des empires — celle de Tom fait précisément ce qu'elle doit faire, et c'est sa plus grande qualité.

Ton parcours — et le projet suivant

Prends une seconde pour mesurer le chemin, parce qu'il est considérable. En dix chapitres, tu as appris à cadrer une idée (mini-PRD), choisir des outils, construire en itérant, déboguer méthodiquement, déployer, authentifier des utilisateurs, centraliser des données en sécurité, brancher des services externes, sécuriser l'ensemble, et piloter un produit avec des chiffres et du feedback. Ce ne sont pas des connaissances de « vibe codeur débutant » : c'est, très exactement, le cycle de vie complet d'un produit logiciel — celui que suivent les équipes professionnelles, que tu sais maintenant dérouler en dialoguant avec une IA.

La suite s'écrit d'elle-même : choisis un deuxième projet, un cran plus ambitieux, et redéroule le cycle entier. Tu iras trois fois plus vite — non parce que l'IA aura progressé, mais parce que toi tu sauras quoi demander, quoi exiger, quoi tester et quand dire non. C'était l'objectif secret de ce cours depuis la première page : pas t'apprendre à faire une app, t'apprendre à en faire autant que tu veux. Tom a déjà son idée suivante — un carnet de lecture pour le club du CDI. Et toi ?