Décrire ton app (mini-PRD)

Pourquoi décrire avant de générer

La tentation est grande d'ouvrir l'outil et de taper « fais-moi une app de suivi d'habitudes ». Essaie, et tu verras le problème : l'IA va combler tous les vides avec ses propres choix. Elle décidera des couleurs, des fonctionnalités, de la structure — et il y a peu de chances que ses choix correspondent à ce que tu avais en tête. Tu passeras ensuite dix messages à détricoter ce que tu aurais pu éviter avec deux minutes de réflexion.

C'est tout l'intérêt du mini-PRD. PRD signifie « Product Requirements Document », le cahier des charges qu'écrivent les équipes produit professionnelles. La version « mini » tient en une dizaine de lignes et répond à cinq questions : à quoi sert l'app, qui l'utilise, que fait-elle exactement, à quoi elle ressemble, et sur quelle base technique. Avec ça, l'IA produit du premier coup quelque chose de proche de ta vision.

Il y a un bénéfice caché : écrire le mini-PRD te force à clarifier ta propre pensée. Beaucoup d'idées d'apps semblent limpides dans la tête et se révèlent floues sur le papier. « Une app pour aider les élèves » — d'accord, mais à faire quoi, concrètement ? Le mini-PRD est ton premier outil de chef de projet, avant même le premier prompt.

Le mini-PRD en cinq blocs

• But : une phrase. « Une app web pour suivre ses habitudes de travail quotidiennes. »
• Utilisateurs : qui s'en sert et dans quel contexte. « Des élèves de collège, sur leur téléphone, le soir. »
• Fonctionnalités : 3 à 5 actions concrètes, numérotées. Pas plus pour une v1.
• Style : 3-4 adjectifs et une contrainte. « Épuré, mobile-first, accent vert, gros boutons. »
• Technique : reste simple. « HTML/CSS/JS simple, stockage local, pas de compte utilisateur. »

L'ordre a son importance : on part de l'intention (le but) pour finir par l'implémentation (la technique). Si tu ne sais pas quoi mettre dans le bloc technique, écris simplement « le plus simple possible, sans base de données ni compte utilisateur » — l'IA comprendra et choisira pour toi une base saine.

Le mini-PRD de Tom, complet

Je veux construire une app web : un suivi d'habitudes.
Utilisateurs : élèves de collège qui veulent tenir des routines de travail, surtout sur téléphone.
Fonctions :
1. ajouter / supprimer une habitude
2. cocher chaque jour si l'habitude est faite
3. voir une série (streak) de jours consécutifs réussis
4. voir un mini-calendrier du mois avec les jours cochés
Style : épuré, mobile-first, accent vert, gros boutons faciles à toucher.
Technique : HTML/CSS/JS simple, stockage local (localStorage), pas de compte utilisateur.
Construis d'abord UNIQUEMENT les fonctions 1 et 2. On ajoutera la suite après mes tests.

Observe la dernière ligne : Tom donne la vision complète, mais demande explicitement de ne construire que les fonctions 1 et 2. C'est la combinaison gagnante — l'IA connaît la destination (elle fera des choix cohérents avec la suite), mais le premier livrable reste petit et testable. Tu valides la base, puis tu demandes « ajoute maintenant la fonction 3 » dans un message suivant.

Les mots qui changent tout

Certains termes de ton mini-PRD ont un effet démesuré sur le résultat. « Mobile-first » dit à l'IA de concevoir d'abord pour un petit écran — crucial si tes utilisateurs sont sur téléphone. « Stockage local » évite toute la complexité des comptes et serveurs. « Épuré » oriente vers un design sobre plutôt que surchargé. Ces mots-clés sont des raccourcis vers des décisions techniques entières.

À l'inverse, certains mots déclenchent une complexité que tu ne soupçonnes pas. « Compte utilisateur » implique inscription, connexion, mots de passe, récupération — des heures de travail. « Notifications » implique des autorisations et des services externes. « Temps réel » (voir les changements des autres instantanément) implique un serveur permanent. Si l'un de ces mots se glisse dans ta v1, demande-toi sérieusement s'il peut attendre la v2.

Décrire le style sans être designer

Tu n'as pas besoin de vocabulaire de designer pour obtenir une belle app. Trois techniques simples : donne des adjectifs (épuré, chaleureux, professionnel, ludique), cite une référence connue (« dans l'esprit de l'app Notes d'Apple », « sobre comme un site de la presse »), et précise une couleur d'accent (« accent vert », « tons bleu nuit »). L'IA traduira ces indications en choix typographiques et visuels cohérents.

Si le premier rendu ne te plaît pas, affine par comparaison plutôt que par jargon : « plus aéré », « les boutons sont trop petits pour un pouce », « trop de couleurs, garde uniquement le vert et le gris ». Ce sont des retours que n'importe qui peut formuler, et l'IA les comprend parfaitement.

Prioriser : v1 ou plus tard ?

Distingue le « indispensable v1 » du « ce serait bien plus tard ». Le test est simple : sans cette fonction, l'app rend-elle encore service ? Si oui, c'est du « plus tard ». Tom applique le test : sans l'ajout d'habitudes, l'app est vide — v1. Sans le cochage quotidien, elle ne sert à rien — v1. Sans les notifications, elle marche très bien — plus tard. Sans le partage entre élèves, aussi — plus tard.

flowchart TD
  I["Idée de fonctionnalité"] --> Q["Sans elle, l'app rend-elle service ?"]
  Q -->|"Non, elle est inutilisable"| V1["Indispensable v1"]
  Q -->|"Oui, elle marche quand même"| V2["Liste « plus tard »"]
  V1 --> P["Dans le mini-PRD"]
  V2 --> L["Notée pour la v2"]

Garde ta liste « plus tard » bien au chaud dans un fichier ou une note : ce n'est pas une poubelle, c'est ta feuille de route. Au chapitre 5, une fois l'app déployée, c'est dans cette liste que tu piocheras tes prochaines améliorations — guidé par les retours de tes premiers utilisateurs.

Mini-glossaire du chapitre

• PRD : Product Requirements Document, le cahier des charges d'un produit.
• localStorage : un petit espace de stockage dans le navigateur, où une app peut sauvegarder des données sans serveur.
• Mobile-first : concevoir d'abord pour téléphone, puis adapter aux grands écrans.
• v1 / v2 : première version utilisable / version améliorée suivante.
• Streak : série de jours consécutifs de réussite (terme courant dans les apps d'habitudes).