Painkiller, Vitamin ou Candy : la grille que j'utilise avant de coder une app

D'abord, aller voir où le problème vit

Avant toute idée d'app, je passe quelques heures dans les endroits où les gens parlent vraiment de leurs problèmes. Pas pour valider mon idée, pour écouter comment ils la formulent dans leurs propres mots.

Mes 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, moins pour la vie quotidienne
• Avis 1 et 2 étoiles des apps existantes du domaine : un gisement d'or pour les frustrations

Ce que je note pendant cette phase :

• Le vocabulaire exact utilisé pour décrire la douleur, à reprendre dans le copy
• Les workarounds que les gens utilisent déjà (Excel, post-it, autre app détournée)
• Les fonctions demandées en boucle dans les commentaires des concurrents
• L'intensité émotionnelle du problème (gêne banale ou exaspération réelle)

Si je ne trouve personne en train de s'en plaindre, c'est un signal. Pas un veto, mais un signal.

La grille Painkiller, Vitamin, Candy

Toutes les apps n'ont pas le même rapport au besoin. J'utilise trois cases pour me situer :

Type	Promesse	Récurrence du besoin	Volonté de payer
Painkiller	"j'ai mal, fais-moi moins mal"	Forte, parfois bloquante	Élevée et rapide
Vitamin	"ce serait mieux si…"	Moyenne, on peut s'en passer	Variable, demande conviction
Candy	"tiens, c'est rigolo"	Faible, dépend de l'humeur	Très faible, modèle pub ou freemium

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

Les trois questions qui décident

Pour savoir dans quelle case on est, je me pose trois questions :

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

Le scoring se lit dans une grille :

Profil	Q1 — recherché	Q2 — payant	Q3 — phrase claire	Score	Lecture
Painkiller	✓	✓	✓	3/3	Douleur réelle, marché actif, promesse claire
Vitamin	✓	✗	✓	2/3	Usage probable, modèle économique à inventer
Candy ou flou	✗	✗	✗	0/3	Ni douleur, ni marché — à reformuler ou abandonner

Trois oui, c'est un Painkiller. Moins, c'est un Vitamin ou un Candy. Pas un drame, mais ça change la stratégie : un Vitamin demande plus de marketing pour exister, un Candy exige une distribution massive ou rien.

Pour un Painkiller : ne faire QUE la chose qui résout

Quand on tient un vrai Painkiller, la plus grosse erreur c'est de l'enrichir. La tentation est forte :

• "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 et brouille le pitch. Le client est venu pour qu'on lui retire la douleur. Tout ce qui n'y contribue pas est du bruit.

Si je retire cette feature, est-ce que la douleur revient ? Non, alors c'est du bruit, je la coupe.

Comment être compétitif quand le marché existe déjà

Si Q1 et Q2 disent oui, ça signifie aussi qu'il y a déjà des concurrents. Cinq leviers à passer en revue, dans l'ordre où on peut gagner :

1. Meilleure UI / UX : beaucoup d'apps installées sont laides, lentes, hostiles au mobile. C'est une porte d'entrée fréquente.
2. Fonctionnalités affûtées : pas plus, mieux. Une app qui fait les deux choses qui comptent mieux que personne, c'est gagnant.
3. Prix plus juste : soit moins cher, soit un 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 fait une différence visible. Les concurrents installés bougent souvent au rythme du trimestre.
5. Écoute utilisateur : répondre rapidement, embarquer une partie des suggestions, rester accessible. Les gros acteurs ne le font plus.

Comment ces leviers s'articulent :

Étape	Action	Résultat
1. Choisir	2 ou 3 leviers cohérents (ne pas s'éparpiller)	Une promesse de positionnement nette
2. Construire	Livrer ce différentiel face aux acteurs installés	Un avantage initial mesurable
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, c'est suffisant pour exister.

Sous quelle forme livrer ?

Le choix de la forme dépend du moment d'usage et de la friction acceptable. Mon arbre de décision :

Forme	Quand l'envisager	Friction d'install	Distribution
Web app	Usage occasionnel, partagé, accessible partout	Aucune	URL, SEO, partage
Extension navigateur	Greffe sur un usage web existant (Gmail, GitHub)	Faible	Chrome / Firefox Store
App mobile	Usage en mobilité, capteurs (caméra, GPS)	Moyenne (App Store)	iOS / Android
Desktop ou CLI	Pro, performance, scripts, automatisation	Forte	Homebrew, .dmg, .exe
Plugin (Figma, Notion, n8n…)	L'usage vit déjà dans une plateforme	Faible	Marketplace de la plateforme

Règle simple : livrer là où le problème vit déjà. Si la douleur arrive dans le navigateur, ne fais pas une app mobile. Si elle arrive sur le terrain, ne fais pas une web app.

Inconvénients et difficultés à anticiper

Avant d'écrire la première ligne, je liste honnêtement ce qui peut coincer. Quatre catégories :

Côté distribution

• Les stores (Apple, Google, Chrome) ont leurs règles, leurs délais, leurs refus
• Le SEO prend des mois à s'installer, même sur un produit excellent
• Un Painkiller niche se trouve mal, il faut aller chercher les utilisateurs un par un au début

Côté technique

• Une intégration tierce (Stripe, Calendly, n8n, l'API d'un store) peut casser à tout moment
• La plateforme cible peut changer ses règles (Manifest V3, restriction d'API)
• La donnée utilisateur, dès qu'elle existe, déclenche RGPD, sauvegardes et sécurité

Côté économique

• Le coût d'une API LLM peut consommer la marge si on n'optimise pas le prompt
• Un freemium mal calibré convertit à 0,5 % et ne paye jamais le hosting
• L'acquisition payante est rarement rentable sous les 50 € de panier moyen

Côté humain

• Le support client mange du temps dès la première centaine d'utilisateurs
• Les retours négatifs publics arrivent toujours, il faut s'y préparer mentalement
• En solo, l'ennui ou le doute sur un projet de 6 mois ou plus est plus dur à gérer qu'on le croit

Si je peux nommer ces difficultés AVANT de commencer, je me protège des mauvaises surprises et je calibre mieux le périmètre.

Synthèse

Mon schéma se résume en cinq étapes :

1. Aller voir où le problème vit (Reddit, forums, avis sur les concurrents)
2. Classer dans Painkiller, Vitamin ou Candy
3. Répondre aux trois questions pour confirmer
4. Choisir la forme la plus proche du moment d'usage
5. Lister les difficultés probables avant de coder

Si à l'issue je tiens un 3/3 Painkiller avec une promesse en une phrase et une forme évidente, alors j'ouvre l'éditeur. Pas avant.