Cahier des charges d’application mobile : le modèle qu’on utilise
6 min de lecture
À retenir
- Un MVP n’est pas une version dégradée : c’est une version complète d’un périmètre plus petit.
- Gardez un seul parcours utilisateur de bout en bout, et faites-le parfaitement.
- Ne coupez jamais l’authentification, la gestion d’erreur ni la mesure d’usage.
- Une fonctionnalité utile à moins de 20 % des utilisateurs attend la version 2.
- Un back-office manuel remplace avantageusement trois semaines d’automatisation.
Chaque projet commence par la même scène. Une liste de quarante fonctionnalités, toutes « indispensables », et un budget qui en permet dix. Le réflexe est de tout garder en le faisant moins bien. C’est la seule stratégie qui échoue à coup sûr.
Un MVP n’est pas un produit à moitié fini. C’est un produit fini sur un périmètre réduit. La différence est visible immédiatement par les utilisateurs, et elle décide de tout.
Le test du parcours unique
Posez-vous une seule question : quel est le parcours qui, s’il fonctionne parfaitement, prouve que le produit a de la valeur ?
Pour une application de réservation, c’est : je trouve un créneau, je réserve, je reçois une confirmation. Pas la gestion des annulations, pas le programme de fidélité, pas le partage sur les réseaux, pas les statistiques.
Ce parcours devient votre colonne vertébrale. Tout ce qui n’y contribue pas directement passe en version 2. Sans exception, sans discussion.
La règle qui débloque tous les arbitrages : une fonctionnalité entre dans le MVP si son absence empêche le parcours principal de se terminer. Si le parcours se termine sans elle — même moins agréablement — elle attend.
Les quatre choses qu’il ne faut jamais couper
Elles ne se voient pas sur une maquette, elles ne se vendent pas en réunion, et les couper détruit le MVP.
1. L’authentification propre. Créer un compte, se connecter, réinitialiser son mot de passe, se déconnecter. Bâcler cette partie fait perdre 30 à 50 % des utilisateurs avant même qu’ils voient le produit.
2. La gestion des erreurs. Réseau coupé, serveur indisponible, saisie invalide, session expirée. Un utilisateur qui voit un écran blanc ne revient pas, et il ne vous dira jamais pourquoi.
3. La mesure d’usage. Sans analytics, votre MVP ne répond à aucune question. Vous aurez dépensé le budget et vous ne saurez toujours pas si ça marche. Trois événements bien choisis valent mieux que trente mal posés.
4. Le canal de retour utilisateur. Un bouton « signaler un problème » qui envoie un email. Une journée de développement, et c’est votre meilleure source d’information pendant les trois premiers mois.
Les six coupes qui font gagner le plus de temps
| Ce qu’on coupe | Ce qu’on fait à la place | Gain typique |
|---|---|---|
| Back-office d’administration | Accès direct à la base par l’équipe, ou un outil de type tableur connecté | 2 à 4 semaines |
| Notifications push segmentées | Un email transactionnel simple | 1 à 2 semaines |
| Mode hors-ligne complet | Message clair « connexion requise » | 2 à 3 semaines |
| Onboarding en cinq écrans | Un écran, puis l’aide contextuelle | 1 semaine |
| Rôles et permissions fines | Deux rôles : utilisateur et administrateur | 1 à 3 semaines |
| Paiement intégré | Lien vers une page de paiement existante | 1 à 2 semaines |
Le premier point mérite d’être souligné. Le back-office est le poste le plus sous-estimé et le plus facile à repousser. Tant que vous avez moins de quelques centaines d’utilisateurs, une opération manuelle faite par une personne de l’équipe coûte infiniment moins cher que son automatisation. Automatisez quand la douleur devient réelle, pas quand elle est théorique.
L’arbitrage en atelier, en pratique
Nous procédons en trois tours, sur deux heures.
Tour 1 — Tout le monde écrit. Chaque participant liste les fonctionnalités qu’il juge indispensables. Sans discussion, sans filtre. On obtient typiquement 40 à 60 éléments.
Tour 2 — Le filtre du parcours. Pour chaque élément : « le parcours principal peut-il se terminer sans ? ». Si oui, l’élément sort. Il en reste généralement 12 à 18.
Tour 3 — Le filtre des 20 %. Pour chaque élément restant : « quelle proportion des utilisateurs l’utilisera dès la première semaine ? ». En dessous de 20 %, l’élément sort. Il en reste 5 à 8.
C’est votre MVP. Le reste n’est pas perdu : il forme la feuille de route, priorisée par des données plutôt que par le volume sonore des participants.
40 → 6Réduction typique du périmètre après trois tours d’arbitrage
8–14 sem.Durée réaliste d’un MVP mobile, cadrage et publication compris
≈ 50 %Des fonctionnalités écartées qui s’avèrent finalement inutiles
Le piège du MVP qui n’en est plus un
Le périmètre déborde toujours de la même façon : par petites additions raisonnables. « Tant qu’on y est », « c’est juste un champ de plus », « le client l’a demandé ». Chacune coûte un jour ; quinze d’entre elles coûtent un mois.
La parade est simple et un peu brutale : toute fonctionnalité ajoutée en cours de MVP doit en remplacer une autre, à budget constant. Cette règle transforme instantanément les discussions. Ce qui était « indispensable » redevient négociable dès qu’il faut sacrifier autre chose.
Un MVP qui a pris trois mois de retard n’est plus un MVP : c’est une version 1 mal budgétée, livrée en retard, avec les défauts des deux approches.
Après le lancement
Mesurez quatre à huit semaines avant de décider quoi que ce soit. Trois chiffres suffisent : combien de personnes terminent le parcours principal, combien reviennent la semaine suivante, et où exactement les autres abandonnent.
Ces trois chiffres valent plus que tous les ateliers de priorisation du monde — et ils coûtent beaucoup moins cher. Pour situer le budget global d’un MVP dans l’ensemble d’un projet, notre article sur le coût d’une application mobile donne les fourchettes complètes.
