Le mythe du document de 40 pages
Cherchez « cahier des charges application mobile » et vous tomberez sur des modèles de 40 pages, avec des sections sur la charte graphique, la matrice des risques et le diagramme de Gantt. La vérité vécue de notre côté de la table : ces documents ne servent presque jamais. Ils sont écrits une fois, jamais relus, et le projet dévie dès la deuxième semaine.
Ce qui fait réussir un projet d'application, ce n'est pas l'épaisseur du document. C'est la clarté sur une poignée de décisions. Les voici.
Les 9 questions qui comptent
Répondez à ces questions en une ou deux phrases chacune. Si une réponse dépasse un paragraphe, c'est le signe que la décision n'est pas prise.
- Qui utilise l'app, dans quelle situation ? Pas « les 18-35 urbains ». Plutôt : « quelqu'un qui se réveille à 6 h 30 et se rendort après son alarme ».
- Quel problème l'app résout-elle en une phrase ? Si vous avez besoin de « et aussi », vous décrivez deux apps.
- Quelle est LA fonctionnalité de la première version ? Une seule. Les autres attendront les chiffres.
- Comment l'app gagne-t-elle de l'argent ? Abonnement, achat unique, gratuite pour servir autre chose. Cette réponse change l'architecture dès le premier jour.
- Que se passe-t-il sans compte ? Décider tôt ce qui est accessible sans inscription évite des semaines de refonte.
- Quelles données doivent survivre à un changement de téléphone ? C'est la question qui décide s'il faut un backend.
- iOS seulement, ou les deux ? Notre position : iOS d'abord, presque toujours. Le public y paie plus volontiers et un lancement concentré s'apprend plus vite.
- Qu'est-ce qui est explicitement HORS de la première version ? La section la plus utile du document. Elle coupe les débats avant qu'ils n'existent.
- Comment saurez-vous que ça marche ? Un chiffre à 30 jours : des téléchargements, des abonnés, des réservations. Un seul.
Le piège du catalogue de fonctionnalités
Le réflexe naturel est de lister tout ce que l'app « devra faire » : la carte, le chat, les notifications, le mode sombre, le parrainage. Ce catalogue est le meilleur prédicteur d'un projet qui n'aboutit pas, pour une raison simple : chaque fonctionnalité ajoutée avant le lancement retarde le moment où de vrais utilisateurs vous disent ce qui compte.
Une bonne première version fait UNE chose remarquablement. Nos propres applications suivent cette règle, et c'est aussi la méthode qu'on applique aux projets clients : cadrer serré, publier, mesurer, puis décider la suite avec des chiffres.
Ce que votre document doit contenir (et rien de plus)
- Les réponses aux 9 questions ci-dessus, une page maximum.
- Trois à cinq captures ou croquis d'apps dont vous aimez l'expérience, avec un mot sur pourquoi.
- Vos contraintes réelles : budget, échéance, compte développeur Apple existant ou non.
C'est tout. Les maquettes précises, l'architecture, le choix des technologies : c'est le travail du cadrage avec le studio, pas le vôtre. Un bon prestataire transforme votre page en périmètre exact et en prix ferme ; s'il vous demande 40 pages avant de parler, méfiance.
Passez de la page au projet
Si vous avez répondu aux 9 questions, vous avez déjà fait mieux que la majorité des projets qui nous arrivent. La suite logique : envoyez-nous cette page. En 30 minutes d'appel, on la transforme en périmètre de première version, avec un prix qui ne bougera pas et une réponse honnête si le projet n'est pas prêt.
Et si vous préférez construire vous-même, gardez le document : c'est exactement le support qu'on utilise pour démarrer un accompagnement de formation.
