Cahier des charges d’une application mobile : le plan à suivre
En bref
Le cahier des charges d’une application mobile décrit à qui elle s’adresse, ce qu’elle doit permettre de faire et dans quelles contraintes. Quelques pages suffisent si elles couvrent les utilisateurs, les parcours principaux, le back-office, les connexions à vos outils, le budget et le calendrier.
À quoi sert le cahier des charges
Le cahier des charges permet d’obtenir des devis comparables et d’éviter les malentendus en cours de projet. Sans lui, chaque prestataire chiffre une application différente, et vous comparez des prix qui ne portent pas sur la même chose.
Il n’a pas besoin d’être long ni technique. Son rôle est de décrire le besoin ; la solution technique est le travail du prestataire.
Le plan type en neuf rubriques
Voici la structure que nous conseillons, à adapter à votre projet :
- Contexte : votre entreprise, le problème à régler, ce qui existe déjà (site, logiciel, application actuelle).
- Objectifs : ce que l’application doit changer, avec si possible un indicateur (commandes, réservations, temps gagné).
- Utilisateurs : qui s’en servira, dans quelle situation, avec quel niveau d’aisance.
- Parcours principaux : ce que chaque type d’utilisateur doit pouvoir faire, étape par étape.
- Fonctionnalités : la liste classée en trois niveaux, indispensable, souhaitable, plus tard.
- Back-office : ce que vos équipes doivent pouvoir gérer elles-mêmes (contenus, utilisateurs, commandes, statistiques).
- Connexions : les outils avec lesquels l’application doit échanger (paiement, CRM, logiciel de gestion, notifications).
- Contraintes : plateformes visées (iOS, Android), charte graphique, RGPD, accessibilité, fonctionnement hors connexion.
- Budget et calendrier : l’enveloppe envisagée et la date de mise en ligne souhaitée.
Décrire des parcours plutôt que des écrans
La rubrique la plus utile est celle des parcours. Écrivez-les comme des scènes : « Un client ouvre l’application, choisit un créneau, paie, puis reçoit une confirmation et un rappel la veille. » Ce format fait apparaître les questions que les listes de fonctionnalités cachent : que se passe-t-il si le paiement échoue, si le créneau n’est plus disponible, si le client veut annuler ?
Vous n’avez pas à dessiner les écrans. Des croquis aident à se comprendre, mais les maquettes font partie du projet.
Indiquer un budget, même approximatif
Beaucoup de porteurs de projet préfèrent ne pas annoncer de budget, de peur que les devis s’alignent dessus. L’effet est inverse : sans fourchette, les prestataires répondent à l’aveugle et les propositions vont du simple au décuple.
Une enveloppe indicative permet au prestataire de vous dire ce qui tient dedans, et ce qu’il vaut mieux reporter à une deuxième version.
Les erreurs fréquentes
- Oublier le back-office : il représente souvent une part importante du développement.
- Mettre toutes les fonctionnalités au même niveau de priorité.
- Imposer une technologie sans raison précise.
- Ne rien prévoir pour l’après : publication sur les stores, mises à jour, maintenance, hébergement.
- Rédiger seul, sans les personnes qui utiliseront l’application ou le back-office.
Et si le besoin n’est pas encore clair ?
Vous pouvez tout à fait contacter un prestataire avant d’avoir un cahier des charges abouti. Une phase de cadrage sert précisément à cela : préciser les utilisateurs, les parcours et les priorités, puis en tirer un périmètre et un chiffrage.