Cahier des charges d'application mobile : ce qu'il faut vraiment ecrire Tu as décidé de faire développer ton application, on t'a dit qu'il fallait un cahier des charges, et tu es devant une page blanche. Combien de pages, quel niveau de détail, faut-il décrire les écrans ?
Je m'appelle Noé Calmes, je conçois des applications mobiles pensées pour générer des revenus. J'ai publié plus de 20 applications. Voici ce que je demande réellement avant un devis, et pourquoi c'est beaucoup moins que ce que tu crois.
À quoi sert vraiment ce document
Un cahier des charges a une seule utilité pratique : permettre à plusieurs prestataires de chiffrer la même chose . C'est tout. Ce n'est ni un contrat, ni un plan de développement, ni une garantie.
Or ce qui rend deux devis incomparables n'est presque jamais le manque de détail technique. C'est le flou sur trois points seulement : combien de types d'utilisateurs, y a-t-il un paiement, y a-t-il du temps réel. Ce sont eux qui font le prix, comme détaillé dans le prix d'une application mobile .
Le test en une phrase
Si ton document permet à deux prestataires qui ne se connaissent pas d'arriver à des chiffrages proches, il est bon. S'il fait dix pages et que les devis vont du simple au triple, il est long, pas précis.
Pourquoi l'écrire trop tôt coûte cher
C'est la partie contre-intuitive, et c'est celle qui compte.
Quand tu écris trente pages avant d'avoir parlé à qui que ce soit, tu prends des dizaines de décisions de conception. Sauf que tu les prends au pire moment : tu ne sais pas encore ce que chacune coûte, ni laquelle est réellement nécessaire.
Tu figes des choix sans en connaître le prix. Écrire une messagerie interne dans le document prend une ligne. La développer ajoute plusieurs semaines. Personne ne te l'a dit avant que tu l'écrives.Tu transformes des idées en engagements. Ce qui est écrit devient dur à retirer, parce que le retirer donne l'impression de reculer. Un besoin exprimé oralement se discute, un besoin écrit se défend.Tu paies deux fois. Une fois pour développer ce qui était dans le document, une fois pour corriger quand les premiers utilisateurs montrent que ce n'était pas ça.
1 page
c'est ce qui suffit pour obtenir des devis comparables, et c'est une heure d'écriture. Le reste du cadrage se fait à deux, au moment où tu sais enfin ce que chaque choix coûte.
La page qui suffit vraiment
Cinq questions. Réponds-y en quelques lignes chacune, sans jargon, et tu as un document meilleur que 90 % de ce que je reçois.
Sur le budget, une précision qui surprend souvent : l'annoncer ne te fait pas payer plus cher . Il permet d'arbitrer le périmètre en face. Sans lui, on chiffre au hasard et tu reçois un devis hors de portée ou une proposition au rabais.
Ce qu'il ne faut pas y mettre
Autant que ce qu'il faut écrire, voici ce qui alourdit sans rien apporter.
La description écran par écran. C'est le travail de conception, il se fait après le cadrage et avec quelqu'un dont c'est le métier.Le choix de la technologie. Sauf contrainte réelle, par exemple un existant à reprendre, ce n'est pas à toi de trancher, et l'imposer coûte parfois cher sans raison.La liste exhaustive des fonctionnalités. Une liste de quarante lignes ne dit pas ce qui est indispensable. Elle oblige à tout chiffrer, donc à te faire un devis trop cher pour une première version.Les formulations qui n'engagent à rien. « Interface moderne et intuitive », « performant », « évolutif ». Tout le monde est d'accord, personne ne sait ce que ça veut dire, et ça ne se chiffre pas.
Ce qui vaut mieux qu'une page de texte
Deux ou trois captures d'applications que tu aimes , avec une phrase disant ce qui te plaît dedans, et une que tu détestes avec ce qui te gêne. Ça transmet en trente secondes ce qu'un paragraphe met une page à expliquer, et ça évite les malentendus de goût.
Ce que ton document révèle du prestataire
C'est un usage auquel on ne pense pas : la façon dont on te répond en dit plus long que n'importe quelle référence.
Envoie ta page à trois personnes et regarde ce qui revient.
Celui qui te pose des questions sur ton modèle de revenus a compris que l'enjeu n'est pas technique.Celui qui te renvoie un devis immédiat sans rien demander a chiffré des hypothèses. Ce sont les siennes, pas les tiennes.Celui qui te demande de compléter un formulaire de trente pages te fait faire son travail de cadrage.
Le détail de ce qu'on peut demander à chaque profil est dans choisir le bon expert pour ton application .
Le cas où un vrai cahier des charges s'impose
Il faut être honnête, il existe des situations où le document long est justifié, et les balayer serait malhonnête.
Un appel d'offres public , où le formalisme est imposé et non négociable.Une contrainte réglementaire : santé, données sensibles, accessibilité obligatoire. Ce qui est réglementaire s'écrit, parce que ça ne se discute pas.Une reprise d'existant , où il faut décrire ce qui existe déjà et doit être conservé. Voir reprendre une application mobile existante .Plusieurs équipes en parallèle , qui ne peuvent pas toutes te parler.
Hors de ces cas, le document long est un confort pour celui qui l'écrit, et un coût pour le projet.
Ce qui se décide ensemble, et pourquoi c'est mieux
Une fois ta page envoyée, le vrai cadrage commence, et il se fait à deux. C'est là qu'on tranche les questions qui décident du budget :
Combien de profils dans la première version. Sortir d'abord celui du client plutôt que client et professionnel fait souvent baisser le devis d'un tiers.Ce qui attend la version suivante. Retirer n'est pas renoncer : c'est financer la suite avec les revenus de la première version.Où se place l'offre payante. Cette décision change l'architecture, elle ne s'ajoute pas à la fin.
Ce cadrage produit un document précis, chiffré, qui sert de référence pendant tout le projet. C'est lui, le vrai cahier des charges. Il est écrit à deux, et il arrive au moment où tu sais ce que chaque ligne coûte.
Par où commencer
Trois étapes, une heure en tout, et aucune ne demande de compétence technique.
Écris les cinq réponses du tableau plus haut. En vrac, sans mise en forme, dans un simple document texte.Ajoute deux captures d'applications que tu aimes et une que tu n'aimes pas, avec une phrase pour chacune.Envoie ça tel quel. Ne l'embellis pas, ne l'allonge pas. Un document brut mais honnête se chiffre mieux qu'un document soigné mais flou.
Pour savoir combien de temps prendra ensuite la réalisation, regarde combien de temps pour créer une application mobile . Et si tu préfères que ces cinq questions te soient posées plutôt que de les écrire seul, l'audit gratuit les pose en deux minutes et te renvoie une première lecture du potentiel, du budget et du délai.
À lire aussi :
← Retour au blog Accueil · Concevoir une application qui rapporte · Ma méthode · Blog · Tester ton idée · FAQ