Les cinq questions à poser avant de développer une fonctionnalité mobile

En février 2018, un tweet de Kylie Jenner accompagne une chute de 6 % du cours de Snap : 1,3 milliard de dollars de capitalisation effacés en une journée (Bloomberg, 22 fév. 2018). Huit mots publiés depuis son téléphone.

Kylie Jenner

@KylieJenner · 21 février 2018

sooo does anyone else not open Snapchat anymore? Or is it just me… ugh this is so sad.

↳ Time, 22 fév. 2018

Le tweet n’a pas créé le problème. Il a rendu visible, dans un contexte boursier déjà tendu, le rejet d’un redesign lancé quelques mois plus tôt. Snap comptait 191 millions d’utilisateurs quotidiens au Q1 2018 (Snap Inc. — Q1 2018 Results), puis 188 millions au Q2 2018 (Snap Inc. — Q2 2018 Results).

Une pétition Change.org contre le redesign a atteint 1,2 million de signatures avant que Snap fasse un rollback partiel (TechCrunch, 7 août 2018).

Impossible de savoir, de l’extérieur, comment Snap avait cadré cette décision. Mais l’épisode rappelle une règle simple : avant de coder, une équipe devrait pouvoir répondre à cinq questions.

Ce n’est pas un cas isolé. La même erreur se répète sur des features mobiles chaque semaine — juste sans le retentissement médiatique. Un bouton en plus, un écran, une notification, une intégration. Trois mois plus tard, la « petite fonctionnalité » a produit ses tickets bug, mobilisé un designer sur deux itérations, changé la structure d’un module central, et personne ne peut dire si elle a amélioré quoi que ce soit.

Ce n’est pas la faute de l’équipe engineering. Ce n’est pas non plus la faute du product manager. C’est ce qui arrive quand on saute la partie ennuyeuse. Les questions ci-dessous ne sont pas magiques. Elles interdisent simplement de construire une chose dont personne ne peut expliquer la raison d’être.

Question 1 — Quel problème résolvons-nous ?

C’est la plus simple à poser, la plus difficile à répondre honnêtement.

La difficulté vient d’un piège fréquent : on décrit une solution en croyant décrire un problème. « Il faut ajouter un chat dans l’application » n’est pas un problème. C’est une solution. Le problème, c’est peut-être : « les utilisateurs ne trouvent pas comment nous joindre quand ils sont bloqués sur l’étape 3 », ou peut-être : « le support reçoit 40 % de questions identiques que la documentation ne couvre pas ». Ce sont deux problèmes différents qui appelleraient deux solutions différentes.

Le test que j’applique est simple : je force la formulation à commencer par une observation, pas par une intention.

Une astuce héritée de Toyota s’applique : cinq fois de suite, demander « pourquoi ? ». Un utilisateur oublie de saisir. Pourquoi ? Parce qu’il le fait le soir au bureau. Pourquoi ? Parce que l’app est trop lente sur le terrain. Pourquoi ? Parce qu’elle attend le réseau pour chaque action. Pourquoi ? Parce que l’offline n’a pas été pensé au départ. Pourquoi ? Parce que le brief initial disait « écran de saisie » au lieu de « journée du commercial ». Au bout des cinq pourquoi, le problème n’est plus celui qu’on croyait.

Question 2 — Pour quel utilisateur, exactement ?

La deuxième question sert à éviter que la réponse à la première dérive vers « tout le monde ».

Le mot « utilisateur », quand on ne le précise pas, absorbe silencieusement des personnes très différentes. Sur une application B2B typique, il y a au moins trois catégories qui ne partagent presque rien : celui qui utilise le produit tous les jours, celui qui le consulte occasionnellement pour une décision, et celui qui paie mais ne l’utilise pas du tout. Une fonctionnalité qui ravit le troisième et complique la vie du premier finit avec 2 étoiles sur le store.

Il faut aussi renoncer à la démographie creuse et décrire des contraintes physiques réelles.

Une bonne description de persona ressemble plutôt à ceci :

« L’utilisateur a 5 minutes dans les transports, tient son téléphone d’une seule main, et peut être interrompu à tout moment. »

Ces contraintes ne disent pas qui est la personne — elles disent dans quelles conditions elle utilisera le produit. Et ce sont ces conditions qui contraignent les décisions.

Ces contraintes physiques déterminent ensuite des choix produit très concrets : durée d’une session, capacité à reprendre où on s’est arrêté, sauvegarde automatique, taille des cibles tactiles. Un persona démographique creux (« Marie, 32 ans, cadre parisienne, aime le yoga ») ne suggère aucun de ces choix.

Question 3 — Quel comportement doit changer ?

Cette question est celle qui distingue le plus une équipe produit mature d’une feature factory.

Une roadmap immature liste ce qu’on va construire : « chat, notifications push, mode sombre ». Une roadmap mature liste les comportements qu’on veut voir apparaître, disparaître ou augmenter chez l’utilisateur.

Le modèle le plus utile pour comprendre pourquoi un comportement se produit est celui de BJ Fogg (Behavior Design Lab, Stanford). Sa formulation actuelle est B = MAP : Motivation × Ability × Prompt = Behavior (behaviormodel.org). Fogg a officiellement remplacé « Trigger » par « Prompt » fin 2017 — on croise encore l’ancienne notation B = MAT dans beaucoup de supports.

Si l’un des trois manque, le comportement ne se produit pas. Cette grille change immédiatement la question. Au lieu de demander « faut-il ajouter cette fonctionnalité ? », on demande : cette fonctionnalité augmente-t-elle la motivation, la capacité d’action, ou fournit-elle un prompt — et lequel des trois est le facteur limitant actuel ?

Cette lecture Fogg change la conversation dans une équipe. Plutôt que « faut-il refaire l’onboarding ? », on demande : « les nouveaux ont-ils assez de M, A ou T pour atteindre le premier moment de valeur ? Lequel manque le plus ? »

Question 4 — Comment mesurer que ça marche ?

La quatrième question a un rôle particulier : elle transforme la conversation d’opinion en conversation de décision.

Une équipe sans métrique préétablie interprétera toujours les données a posteriori pour justifier ce qu’elle a déjà décidé. C’est un biais de confirmation classique. Une équipe qui a défini son critère avant l’implémentation peut avoir tort — et le voir.

La distinction la plus utile est celle qu’Eric Ries formalise dans The Lean Startup : vanity metric contre actionable metric.

L’exemple canonique du secteur mobile, c’est Facebook en 2007. Chamath Palihapitiya vient de rejoindre l’équipe growth. Il cherche ce qui distingue les utilisateurs qui restent actifs à vie des utilisateurs qui décrochent après quelques jours. En comparant les cohortes actives et inactives, son équipe identifie une seule différence structurante : les utilisateurs actifs à vie ont tous ajouté 7 amis dans leurs 10 premiers jours (Chamath Palihapitiya, Startup Grind, 2013).

Cette métrique a alors dirigé toute la stratégie growth de Facebook. Pas le nombre total d’inscriptions. Pas le temps moyen passé sur le site. Une seule métrique — le pourcentage de nouveaux qui atteignent 7 amis en 10 jours — a orienté toutes les décisions produit qui ont mené le réseau au milliard d’utilisateurs.

Il y a aussi la distinction entre leading indicator et lagging indicator, très utile en mobile où les cycles sont longs. Le revenu, le churn annuel, le NPS sont des lagging indicators : quand ils bougent, il est trop tard pour agir. L’usage au deuxième jour, le nombre d’actions dans les sept premiers jours, le taux de complétion d’onboarding sont des leading indicators : ils prédisent le lagging avec plusieurs semaines d’avance.

Question 5 — Quels cas d’échec devons-nous prévoir ?

La dernière question est la plus mal aimée. Elle donne l’impression de vouloir plomber l’ambiance juste avant de démarrer. En pratique, c’est celle qui économise le plus de sprints — et le type d’exercice qui aurait pu réduire le risque du redesign Snapchat 2018.

Gary Klein, chercheur en prise de décision, a proposé en septembre 2007 dans la Harvard Business Review un exercice qu’il appelle pré-mortem (Klein, HBR, sept. 2007). Avant de démarrer, imaginer que six mois ont passé et que le projet est un échec cuisant. Écrire le récit de cet échec.

L’exercice contourne un biais robuste : les gens sont bien meilleurs pour identifier des risques quand ils les visualisent comme déjà survenus, plutôt que comme des probabilités abstraites.

Il y a aussi une règle simple pour ne rien oublier au niveau écran, empruntée à Scott Hurff (Designing Products People Love) (scotthurff.com). Cinq états d’interface doivent toujours être designés :

• Ideal state — tout va bien, données présentes.
• Empty state — pas encore de données.
• Error state — quelque chose a échoué.
• Partial state — données incomplètes.
• Loading state — en attente.

Une feature qui ne designe que le happy path est incomplète, et ça se voit dès la V1.

Enfin, une règle de résilience en trois questions à appliquer systématiquement avant de coder :

Ces trois questions couvrent la majorité des bugs terrain sur mobile. Chaque « je ne sais pas » laissé sans réponse a une bonne chance de ressurgir en bug de production après la release.

La grille en pratique — un exemple complet

Prenons un cas concret. Supposons une application de vente terrain (SFA) utilisée par une centaine de commerciaux itinérants. Feature envisagée : un bouton « enregistrer visite client » sur l’écran principal.

Q1 — Problème. Un audit interne montre que les commerciaux ressaisissent leurs visites le soir au bureau. 20 % des visites sont oubliées, 40 % restent incomplètes. Ce n’est pas un problème d’ergonomie de l’écran de saisie — c’est un problème de moment de saisie.

Q2 — Utilisateur. Commercial itinérant, souvent debout, dans un magasin bruyant, une main occupée par un carton d’échantillons. Il n’a jamais 5 minutes disponibles entre deux visites. Il ne relit rien plus tard.

Q3 — Comportement. Passer de « saisie différée au bureau » à « saisie immédiate sur le terrain ». Le facteur limitant est la capacité d’action (Fogg : le A de MAT). Solution qui vise juste : baisser drastiquement le coût de saisie via un enregistrement vocal en un tap, avec géoloc automatique comme trigger contextuel.

Q4 — Mesure. Métrique : pourcentage de visites saisies dans les 30 minutes suivant la géoloc du client. Cible : passer de 15 % à 60 % en 3 mois. Décision : si la métrique n’atteint pas 40 % à J+45, on repense l’approche plutôt que d’itérer sur les détails.

Q5 — Échecs. Réseau absent (queue offline), micro coupé (fallback texte), utilisateur ferme l’app (auto-save immédiat), double-clic accidentel (idempotence côté serveur), géoloc inactive (bouton manuel de secours).

Cette grille tient sur une page. Elle prend 45 minutes à remplir sérieusement en équipe. Ces 45 minutes peuvent éviter plusieurs semaines de développement mal orienté.

Pourquoi c’est un marqueur de séniorité

L’un des enseignements les plus robustes que produit l’expérience du développement mobile, c’est que la séniorité ne se limite pas à la maîtrise technique. Elle inclut la capacité à ralentir le début.

Un ingénieur intermédiaire dit oui à la feature demandée et attaque le code. Un ingénieur senior dit : « avant qu’on démarre, on prend 45 minutes pour dérouler ces cinq questions. »

Cette capacité à retarder poliment mais fermement le début d’un travail — sans passer pour un obstacle — est un signal que beaucoup de CTO et engineering managers apprécient chez leurs recrues seniors. Pas parce qu’ils veulent des gens qui freinent. Parce qu’ils savent que le coût d’une feature mal cadrée dépasse largement le coût des 45 minutes de cadrage.

La grille distille des idées beaucoup plus anciennes — Marty Cagan (Inspired, 2017), Teresa Torres (Continuous Discovery Habits, 2021), Eric Ries, BJ Fogg, Gary Klein, Alan Cooper. Sa valeur n’est pas dans son originalité. Elle est dans le fait qu’elle rend explicite ce que les meilleures équipes font intuitivement.

Sources — vue d’ensemble

Toutes les sources sont citées en ligne dans le texte. Vue synthétique pour vérification rapide :

• Snapchat 2017-2018 : Bloomberg (22 fév. 2018) · TechCrunch (7 août 2018) · Time (22 fév. 2018) · Pétition Change.org : 1,2 M signatures.
• Duolingo & Fogg : Duolingo Blog — How Streaks Keep Learners Committed · Deconstructor of Fun · BJ Fogg, Tiny Habits (Houghton Mifflin, 2019) · behaviormodel.org.
• Facebook 7 amis en 10 jours : Chamath Palihapitiya — Startup Grind 2013.
• Frameworks cités : Marty Cagan, Inspired (Wiley, 2ᵉ éd. 2017). Teresa Torres, Continuous Discovery Habits (Product Talk LLC, 2021). Eric Ries, The Lean Startup (Crown Business, 2011). Alan Cooper, The Inmates Are Running the Asylum (Sams, 1998). Gary Klein, Performing a Project Premortem, HBR, septembre 2007. Scott Hurff, Designing Products People Love (O’Reilly, 2015).
• Eric Meyer sur les edge cases : Inadvertent Algorithmic Cruelty — A List Apart, 2014.
• Vérification : chiffres et dates vérifiés en août 2026 via les sources primaires ci-dessus.