Cahier des charges application mobile : les 9 décisions à trancher avant de demander un devis
Réponse courte : un cahier des charges d'application mobile utile tient en deux pages et répond à neuf questions. Trois d'entre elles ne dépendent pas de vous mais des règles d'Apple et de Google Play, et aucun modèle à télécharger ne peut les trancher à votre place.
Un prestataire ne chiffre pas une idée, il chiffre des décisions. Chaque point laissé ouvert sera comblé par une hypothèse, différente d'un devis à l'autre, et vous comparerez ensuite des prix qui ne décrivent pas le même projet. La logique est la même que pour un site, détaillée dans notre article sur le cahier des charges d'un site internet, mais une application ajoute un acteur que le web n'a pas : le store, qui relit votre application avant de la laisser paraître.
Les neuf décisions à écrire
1. Le geste principal. La chose que l'utilisateur vient faire, en une phrase avec un verbe : réserver un créneau, scanner un colis, suivre une séance. S'il vous faut trois phrases, il y a probablement trois applications dans votre projet.
2. Les appareils. iPhone, Android, les deux, tablettes comprises ou non. Indiquez aussi ce que vous savez du matériel de vos utilisateurs : un parc de téléphones professionnels fournis par l'entreprise n'appelle pas la même réponse qu'un public grand public.
3. Compte ou pas de compte. Cette ligne a une conséquence réglementaire. Les règles de l'App Store demandent de laisser utiliser l'application sans connexion lorsqu'elle n'a pas de fonctions significatives liées à un compte, et précisent que si l'application permet de créer un compte, elle doit aussi permettre de le supprimer depuis l'application. Google Play demande en plus un lien web où la suppression peut être demandée. La suppression de compte est donc une fonctionnalité à chiffrer, pas un détail de fin de projet.
4. Les données collectées. Listez-les : e-mail, position, photos, données de santé, identifiants publicitaires. Apple exige un lien vers une politique de confidentialité dans la fiche de l'application et dans l'application elle-même ; Google Play fait remplir un formulaire « Sécurité des données ». Ces déclarations sont publiques et engagent l'éditeur, c'est-à-dire vous.
5. Hors connexion. L'application doit-elle fonctionner sans réseau, et si oui pour quelles actions exactement ? « Consulter » et « saisir puis synchroniser plus tard » ne représentent pas le même travail.
6. L'argent. Que vend l'application, et à qui ? La distinction qui compte est celle des règles de l'App Store : les biens et services physiques consommés hors de l'application se règlent par d'autres moyens que l'achat intégré (carte bancaire, Apple Pay), alors que les contenus et services numériques relèvent de l'achat intégré. La page du programme développeur d'Apple annonce pour ces ventes numériques une commission de 30 %, ou 15 % dans certains programmes dont l'App Store Small Business Program. Les conditions varient selon les régions : c'est un point à faire vérifier pour votre marché avant de fixer un prix de vente.
7. Les notifications. Lesquelles, déclenchées par quoi, et qui les rédige. Une notification suppose un événement côté serveur : chaque type demandé est une fonctionnalité à part entière.
8. L'administration. Qui gère les contenus, les utilisateurs et les commandes, et avec quel outil. L'interface d'administration est la moitié invisible du projet : vérifiez qu'elle figure bien dans chaque devis reçu.
9. Les comptes développeur. Qui en est titulaire, vous ou le prestataire, et qui paie les frais. Ce point décide de qui possède réellement l'application le jour où la collaboration s'arrête.
Ce que les stores imposent, et que le document doit prévoir
Les règles ci-dessous ont été relues sur les pages officielles d'Apple et de Google le 7 octobre 2026. Elles changent : la date de lecture compte autant que le chiffre.
| Règle | App Store (Apple) | Google Play |
|---|---|---|
| Frais de compte | 99 USD par année d'adhésion | 25 USD, une seule fois |
| Suppression de compte | Obligatoire dans l'application si elle permet d'en créer un | Dans l'application, plus un lien web |
| Confidentialité | Lien vers la politique dans la fiche et dans l'application | Formulaire « Sécurité des données » |
| Avant la mise en production | Revue de l'application selon les règles de l'App Store | Comptes personnels créés après le 13 novembre 2023 : test fermé avec au moins 12 testeurs inscrits pendant 14 jours consécutifs |
La dernière ligne modifie un calendrier. Si le compte Google Play est un compte personnel récent, il faut réunir douze testeurs et les garder inscrits deux semaines avant de pouvoir demander l'accès à la production. Un cahier des charges qui annonce une date de lancement sans dire qui ouvre le compte, et sous quel statut, annonce une date qu'il ne maîtrise pas. Google Play fixe aussi chaque année un niveau d'API Android minimal à cibler : la mise à jour correspondante fait partie de la maintenance annuelle, et mérite une ligne dans le document.
Ce qu'il vaut mieux ne pas écrire
La technologie. Natif, multiplateforme ou application web installable : c'est une réponse, pas une exigence. Décrivez les contraintes et laissez chaque prestataire justifier son choix.
Un nombre d'écrans. Dix écrans de consultation et dix écrans de saisie synchronisée hors connexion ne coûtent pas la même chose.
« Comme telle application connue ». La référence décrit un résultat visible, pas les années de travail et l'infrastructure qui le produisent. Citez plutôt l'écran précis ou le parcours qui vous intéresse.
Exemple de plan en deux pages
- Contexte (cinq lignes) : qui vous êtes, pour qui est l'application, ce qu'elle remplace aujourd'hui.
- Les neuf décisions, une à trois lignes chacune.
- Première version et suite : deux listes séparées, ce qui doit exister au lancement et ce qui peut attendre.
- L'existant : logo, charte, textes, données à reprendre, comptes déjà ouverts, outils à connecter.
- Contraintes : date visée, enveloppe budgétaire, personne qui décide.
- Ce que vous attendez en retour : un devis poste par poste, les hypothèses retenues, le coût récurrent après livraison.
Une fois ce document écrit, les fourchettes de notre guide sur le coût de développement d'une application mobile deviennent lisibles : vous savez dans quelle catégorie votre projet se range, et pourquoi.
Questions fréquentes
Que doit contenir un cahier des charges d'application mobile ?
Neuf décisions suffisent : le geste principal de l'utilisateur, les appareils visés, la présence ou non d'un compte, les données collectées, le fonctionnement hors connexion, le mode de paiement, les notifications, l'outil d'administration et le titulaire des comptes développeur. On y ajoute la liste de ce qui existe déjà (logo, textes, données, comptes) et une date. Deux pages suffisent, à condition que chaque ligne soit une décision et pas une intention.
Faut-il un modèle de cahier des charges en PDF ou en Word ?
Le format n'a pas d'importance. Un modèle donne des rubriques, pas des réponses. Un document de deux pages qui tranche les neuf points ci-dessus produit des devis comparables ; un modèle de trente pages rempli avec des formules vagues produit des devis qui décrivent des projets différents.
Combien coûte un compte développeur pour publier une application ?
D'après les pages officielles lues le 7 octobre 2026 : l'Apple Developer Program coûte 99 USD par année d'adhésion, et Google Play demande des frais d'inscription uniques de 25 USD. Ces montants sont ceux des éditeurs des stores, ils peuvent être affichés en monnaie locale et ils ne comprennent ni le développement ni la maintenance de l'application.
Qui doit être titulaire du compte développeur : le client ou le prestataire ?
Le client, sauf raison précise. L'application, ses avis et ses utilisateurs sont rattachés au compte qui la publie. Écrire dans le cahier des charges que les comptes Apple et Google sont ouverts au nom de l'entreprise cliente évite d'avoir à organiser un transfert le jour où la relation avec le prestataire s'arrête.
Faut-il choisir la technologie dans le cahier des charges ?
Non. Décrivez le besoin et les contraintes (appareils, hors connexion, accès au matériel du téléphone), puis demandez à chaque prestataire de justifier sa proposition : natif, multiplateforme ou application web installable. La justification vous en apprend plus sur le prestataire que le choix lui-même.
Vous n'avez que trois des neuf réponses ?
C'est suffisant pour commencer. Envoyez-nous ce que vous avez, même en quelques lignes : nous vous renvoyons les questions qui manquent, puis un devis détaillé poste par poste, frais de stores et maintenance compris. Sans engagement.
Envoyer mon projet d'applicationSources
- Apple, Apple Developer Program, « What's included » : frais d'adhésion et commission (lu le 7 octobre 2026).
- Apple, App Store Review Guidelines, sections 3.1.3(e) et 5.1.1 : paiements hors application, politique de confidentialité, suppression de compte (lu le 7 octobre 2026).
- Google, aide de la Play Console : frais d'inscription, exigences de test pour les nouveaux comptes personnels, suppression de compte, niveau d'API cible (lu le 7 octobre 2026).