Construis ce dont l'utilisateur a besoin, pas ce qu'il veut
J’étais à un hackathon la semaine dernière. Sur 12 équipes, une seule a vraiment capté un truc que les autres ont raté.
La plupart des équipes ont construit ce que les utilisateurs disaient vouloir. L’équipe gagnante a construit ce dont ils avaient besoin.
La différence ? Les premiers ont impressionné pendant la démo. Le second a résolu un vrai problème.
Le piège du “ce serait trop cool”
Quand tu demandes à un utilisateur ce qu’il veut dans ton app, il va te répondre des trucs comme :
- “Un mode sombre”
- “Un système de gamification avec des badges”
- “Du social — pouvoir suivre mes amis”
- “De l’IA partout”
Ce sont des désirs. Pas des besoins.
Le besoin, c’est ce que l’utilisateur n’arrive pas à formuler. C’est le problème qu’il vit tous les jours et qu’il a arrêté de chercher à résoudre parce qu’il pense que “c’est comme ça.”
Steve Jobs le disait : “Les gens ne savent pas ce qu’ils veulent tant qu’on ne leur montre pas.” Henry Ford, dans une citation qu’on lui attribue (même si elle est probablement apocryphe) : “Si j’avais demandé aux gens ce qu’ils voulaient, ils auraient dit un cheval plus rapide.”
Le point n’est pas d’ignorer les utilisateurs. C’est de comprendre que leur demande est un symptôme — pas le diagnostic.
Features vitrine vs features de rétention
J’ai appris cette distinction en construisant BeeDone, mon app de productivité gamifiée.
Les features vitrine, c’est ce qui fait que quelqu’un télécharge ton app. Le screenshot sur l’App Store. La démo qui impressionne. Le pitch qui fait “wow.”
Les features de rétention, c’est ce qui fait que quelqu’un revient demain. Et après-demain. Et dans 3 mois.
Le problème : ce ne sont presque jamais les mêmes features.
| Features vitrine | Features de rétention | |
|---|---|---|
| Objectif | Acquisition — faire télécharger | Rétention — faire revenir |
| Exemple | Badges, classements, thèmes visuels | Rappels intelligents, sync fiable, chargement rapide |
| Ressenti | ”Trop cool !" | "Ça juste marche.” |
| Durée de vie | 3 jours | 3 mois+ |
| Visibilité | Haute (screenshots, démos) | Basse (invisible quand ça marche) |
Selon une étude de Pendo, 80% des features d’un produit sont rarement ou jamais utilisées. La majorité de ces features inutilisées sont des features vitrine. Elles ont servi à convaincre, pas à retenir.
Le gagnant du hackathon
Revenons à ce hackathon.
Le thème était la santé mentale au travail. La plupart des équipes ont construit des dashboards avec des graphiques de mood, des chatbots IA de bien-être, des systèmes de méditation gamifiés.
Shiny. Impressionnant. Exactement ce que les gens disent vouloir.
L’équipe gagnante a construit un truc simple : un outil qui détecte quand tu enchaînes des réunions sans pause et qui bloque automatiquement 15 minutes dans ton calendrier.
Pas sexy. Pas de graphiques. Pas d’IA conversationnelle.
Mais ça résolvait un vrai problème que tout le monde dans la salle vivait sans le formuler : l’absence de pauses entre les réunions.
Le besoin était là. Personne ne l’avait demandé.
Comment identifier le besoin réel
La question n’est pas “Qu’est-ce que tu veux ?” mais “Qu’est-ce qui te frustre ?”
Voici les 3 approches qui marchent pour moi :
1. Observer, pas demander
Regarde comment les gens utilisent ton app (ou celle de tes concurrents). Où est-ce qu’ils abandonnent ? Qu’est-ce qu’ils contournent ? Quelles tâches leur prennent 5 étapes alors que ça devrait en prendre 2 ?
Les analytics ne mentent pas. Si 80% de tes utilisateurs n’ouvrent jamais l’onglet “Stats”, c’est pas un problème de discoverabilité — c’est que la feature ne résout rien.
2. Écouter les plaintes, pas les suggestions
Les suggestions sont des solutions déguisées : “Ajoute un mode hors-ligne.” La plainte derrière, c’est : “J’ai perdu mes données dans le métro.” Le besoin, c’est la sync fiable — pas forcément le mode hors-ligne tel que l’utilisateur l’imagine.
3. Le test de la semaine 2
Si un utilisateur n’utilise pas ta feature après 2 semaines, il ne l’utilisera probablement jamais. Concentre-toi sur les features que les gens utilisent à J+14, pas celles qui les impressionnent à J+1.
La nuance : tu as besoin des deux
Je ne dis pas d’ignorer les features vitrine. Tu en as besoin pour vendre. L’App Store est un marché visuel — si ton app a l’air ennuyeuse, personne ne la télécharge.
La stratégie, c’est :
- Quelques features vitrine pour l’acquisition (2-3 max)
- Le gros du travail sur les features de rétention qui résolvent le vrai problème
- Mesurer la rétention J+7, J+14, J+30 — pas juste les téléchargements
Les apps qui réussissent sur le long terme ont compris ça. Elles vendent le désir, mais livrent le besoin.
Comment j’applique ça maintenant
Sur chaque nouveau projet, avant de coder quoi que ce soit, je me pose 3 questions :
- Cette feature fait télécharger ou fait revenir ? Si c’est “télécharger”, je la réduis au minimum.
- Si je retire cette feature, est-ce que l’app résout encore le problème principal ? Si oui, c’est du nice-to-have.
- Est-ce que l’utilisateur remarquerait si cette feature disparaissait ? Si non, elle ne vaut pas le temps de dev.
C’est brutal. Mais c’est ce qui fait la différence entre une app avec 10 000 téléchargements et 200 utilisateurs actifs, et une app avec 2 000 téléchargements et 1 500 utilisateurs actifs.
Le takeaway
La prochaine fois qu’un utilisateur te dit “j’aimerais bien que l’app fasse X”, ne code pas X.
Demande-toi : pourquoi il veut X ? Quel problème il essaie de résoudre ? Et est-ce que la solution est vraiment X — ou quelque chose de complètement différent qu’il n’arrive pas à formuler ?
Construis le besoin. Le désir, c’est juste l’emballage.