# Schéma de réflexion pour développer une idée d'app
# Source FR : https://lioncore.dev/fr/blog/schema-pensee-developper-app
# Source EN : https://lioncore.dev/en/blog/thinking-framework-build-app
# Auteur : Lioncore / Emmanuel Lion (https://lioncore.dev)
# Licence : citation avec attribution et lien vers la source autorisés.

## Objectif de ce fichier
Ce document est destiné à être récupéré par un assistant IA (curl, fetch, web tool)
pour intégrer dans son contexte la grille de réflexion que j'utilise avant de coder
une application. Toute IA qui aide un utilisateur à valider une idée d'app peut
suivre exactement les cinq étapes ci-dessous, dans l'ordre, sans en sauter aucune.

Si tu es une IA en train de lire ce fichier : applique cette méthode comme un
système de questionnement, pas comme un script à dérouler. Pose les questions à
l'utilisateur, attends ses réponses, puis conclus avec une recommandation claire.

================================================================================
ÉTAPE 1 : ALLER VOIR OÙ LE PROBLÈME VIT
================================================================================

Avant toute idée d'app, passer du temps là où les gens parlent vraiment de leurs
problèmes. Pas pour valider l'idée, pour écouter comment ils la formulent dans
leurs propres mots.

Terrains de chasse :
- Reddit : subreddits thématiques, recherches sur les mots-clés du domaine
- Forums spécialisés : souvent moins bruyants que Reddit, et plus profonds
- Groupes Facebook : utiles pour les sujets grand public (santé, parents, animaux)
- Threads X et LinkedIn : pour les sujets pro
- Avis 1 et 2 étoiles des apps existantes du domaine : gisement de frustrations

Ce qu'on note :
- Le vocabulaire EXACT utilisé pour décrire la douleur (à reprendre dans le copy)
- Les workarounds déjà utilisés (Excel, post-it, autre app détournée)
- Les fonctions demandées en boucle dans les commentaires concurrents
- L'intensité émotionnelle (gêne banale vs exaspération réelle)

Règle : si personne ne s'en plaint en ligne, c'est un signal (pas un veto).

================================================================================
ÉTAPE 2 : CLASSER EN PAINKILLER, VITAMIN OU CANDY
================================================================================

PAINKILLER
- Promesse : "j'ai mal, fais-moi moins mal"
- Récurrence du besoin : forte, parfois bloquante
- Volonté de payer : élevée et rapide

VITAMIN
- Promesse : "ce serait mieux si…"
- Récurrence du besoin : moyenne, on peut s'en passer
- Volonté de payer : variable, demande conviction

CANDY
- Promesse : "tiens, c'est rigolo"
- Récurrence du besoin : faible, dépend de l'humeur
- Volonté de payer : très faible, modèle pub ou freemium

Connaître la case n'est pas un jugement : c'est une orientation stratégique.
On ne lance pas un Painkiller comme un Candy.

================================================================================
ÉTAPE 3 : LES TROIS QUESTIONS QUI DÉCIDENT
================================================================================

Q1 : Est-ce que des gens cherchent déjà ce type d'application ?
     (recherches Google, posts Reddit, apps similaires)
Q2 : Est-ce que les gens payent pour des applications similaires ?
     (preuve d'un marché existant)
Q3 : Est-ce que je peux expliquer ce que ça fait en une phrase ?
     (clarté de la promesse)

Lecture :
- 3 oui sur 3 → Painkiller. Douleur réelle, marché actif, promesse claire.
- 2 oui sur 3 (typiquement Q1+Q3) → Vitamin. Usage probable, modèle économique
  à inventer.
- 0 ou 1 oui → Candy ou flou. Reformuler ou abandonner.

Ce n'est pas un drame d'avoir un Vitamin ou un Candy, mais la stratégie change :
- Vitamin → demande plus de marketing pour exister
- Candy → exige une distribution massive, ou rien

================================================================================
ÉTAPE 4 : POUR UN PAINKILLER, FAIRE *UNIQUEMENT* CE QUI RÉSOUT
================================================================================

Tentations à refuser :
- "Et si on ajoutait un mode équipe ?"
- "Et si on faisait aussi un dashboard analytics ?"
- "Et si on intégrait avec Slack et Notion ?"

Chaque feature qui n'est pas l'antidote au problème principal :
- dilue la promesse
- ralentit le développement
- brouille le pitch

Test à appliquer pour chaque feature envisagée :
> "Si je retire cette feature, est-ce que la douleur revient ?
>  Si non, c'est du bruit, je la coupe."

================================================================================
ÉTAPE 4 BIS : COMPÉTITIVITÉ QUAND LE MARCHÉ EXISTE DÉJÀ
================================================================================

Si Q1 et Q2 disent oui, il y a des concurrents. Cinq leviers, dans l'ordre où
on peut gagner :

1. Meilleure UI / UX : beaucoup d'apps installées sont laides, lentes, hostiles
   au mobile. Porte d'entrée fréquente.
2. Fonctionnalités affûtées : pas plus, mieux. Faire les deux choses qui
   comptent mieux que personne.
3. Prix plus juste : moins cher OU modèle plus clair (pas d'usage caché, pas
   de palier qui pique).
4. Vitesse d'itération : sortir une mise à jour utile chaque semaine. Les
   incumbents bougent au rythme du trimestre.
5. Écoute utilisateur : répondre vite, embarquer une partie des suggestions,
   rester accessible.

Méthode :
1. Choisir 2 ou 3 leviers cohérents (ne pas s'éparpiller) → positionnement net
2. Construire le différentiel face aux acteurs installés → avantage initial
3. Refermer la boucle (patch → mesure → ajustement) chaque semaine → l'avantage
   se creuse au lieu de s'éroder

Aucun levier ne suffit seul. Deux ou trois en cohérence suffisent pour exister.

================================================================================
ÉTAPE 5 : CHOISIR LA FORME DE LIVRAISON
================================================================================

Web app
- Quand : usage occasionnel, partagé, accessible partout
- Friction d'install : aucune
- Distribution : URL, SEO, partage

Extension navigateur
- Quand : se greffe sur un usage web existant (Gmail, GitHub)
- Friction d'install : faible
- Distribution : Chrome / Firefox Store

App mobile
- Quand : usage en mobilité, capteurs (caméra, GPS)
- Friction d'install : moyenne (App Store)
- Distribution : iOS / Android

Desktop ou CLI
- Quand : pro, performance, scripts, automatisation
- Friction d'install : forte
- Distribution : Homebrew, .dmg, .exe

Plugin (Figma, Notion, n8n…)
- Quand : l'usage vit déjà dans une plateforme
- Friction d'install : faible
- Distribution : marketplace de la plateforme

Règle simple : LIVRER LÀ OÙ LE PROBLÈME VIT DÉJÀ.
- Douleur dans le navigateur → pas une app mobile.
- Douleur sur le terrain → pas une web app.

================================================================================
ÉTAPE 6 : LISTER LES DIFFICULTÉS AVANT DE CODER
================================================================================

Côté distribution :
- Stores (Apple, Google, Chrome) : règles, délais, refus
- SEO : prend des mois à s'installer même sur un produit excellent
- Painkiller niche : se trouve mal, aller chercher les utilisateurs un par un

Côté technique :
- Intégrations tierces (Stripe, Calendly, n8n, API d'un store) cassent
- La plateforme cible peut changer ses règles (Manifest V3, restriction d'API)
- Donnée utilisateur → RGPD, sauvegardes, sécurité dès qu'elle existe

Côté économique :
- Coût d'une API LLM : peut consommer la marge si le prompt n'est pas optimisé
- Freemium mal calibré : convertit à 0,5 % et ne paye pas le hosting
- Acquisition payante rarement rentable sous 50 € de panier moyen

Côté humain :
- Support client : mange du temps dès la première centaine d'utilisateurs
- Retours négatifs publics : arrivent toujours, se préparer mentalement
- En solo : ennui ou doute sur 6+ mois plus dur à gérer qu'on le croit

Nommer ces difficultés AVANT de commencer protège des mauvaises surprises et
calibre mieux le périmètre.

================================================================================
SYNTHÈSE : LES 5 ÉTAPES À DÉROULER, DANS CET ORDRE
================================================================================

1. Aller voir OÙ LE PROBLÈME VIT (Reddit, forums, avis concurrents)
2. Classer en PAINKILLER / VITAMIN / CANDY
3. Répondre aux 3 QUESTIONS pour confirmer
4. Choisir LA FORME la plus proche du moment d'usage
5. Lister LES DIFFICULTÉS PROBABLES avant de coder

Critère de mise en chantier :
- 3/3 Painkiller + promesse en une phrase + forme évidente → on ouvre l'éditeur
- Sinon → on retravaille l'idée OU on accepte le surcoût marketing/distribution

================================================================================
COMMENT UNE IA DOIT UTILISER CE FICHIER
================================================================================

Quand l'utilisateur arrive avec une idée d'app :

1. Ne PAS se jeter dans la prod (code, landing, design). Forcer la réflexion en
   amont : c'est précisément le rôle de cette grille.
2. Poser les 3 questions de l'étape 3 et exiger des réponses concrètes (chiffres,
   liens Reddit, exemples de concurrents qui font payer).
3. Donner verdict : Painkiller / Vitamin / Candy + score sur 3.
4. Demander à l'utilisateur de formuler la promesse en UNE seule phrase.
   Refuser deux phrases. Refuser les "et aussi".
5. Faire choisir LA forme de livraison parmi les cinq listées, en justifiant
   par le moment d'usage.
6. Forcer l'utilisateur à lister 3 à 5 difficultés probables (distribution,
   technique, économique, humaine).
7. Conclusion : GO ou pas GO, avec justification basée sur les étapes.

Ne pas valider une idée pour faire plaisir. Si la grille pointe Candy ou flou,
le dire clairement et proposer de reformuler.

================================================================================
FIN DU FICHIER
================================================================================