- Le cahier des charges d’une application mobile aligne les parties prenantes et cadre la consultation des prestataires.
- Sa structure ressemble à celle d’un site, mais le mobile ajoute des contraintes : stores, versions d’OS, fonctions de l’appareil, hors connexion, permissions.
- Décrivez les besoins en user stories et priorisez-les ; ne figez pas le choix natif, hybride ou PWA trop tôt.
- Anticipez la publication sur les stores, les permissions et le RGPD dès la conception.
- Un cahier des charges précis et priorisé est ce qui permet d’obtenir des devis fiables et comparables.
Vous portez un projet d’application mobile et vous ne savez pas par où commencer. La première étape n’est pas technique, elle est documentaire : le cahier des charges. C’est lui qui transforme une intention en projet cadré, et qui vous permet de comparer les prestataires sur une base solide.
Ce guide s’adresse aux décideurs qui lancent une application à enjeu : direction digitale, direction générale, DSI. Il propose une méthode moderne, et signale ce qui distingue un cahier des charges mobile d’un cahier des charges de site. Pour ce dernier, nous avons d’ailleurs un guide dédié : le cahier des charges d’un site internet.
À quoi sert un cahier des charges d’application mobile ?
Le cahier des charges définit votre projet : sa raison d’être, ses objectifs, sa cible, son périmètre et ses contraintes. Il rend trois services. Il aligne les parties prenantes autour d’une vision commune. Il cadre la consultation des prestataires, qui répondent sur un périmètre comparable. Il sert de référence pour arbitrer les ajustements en cours de route.
Un point mérite d’être corrigé d’emblée, car l’ancienne version de cet article le recommandait : un bon cahier des charges n’a pas besoin de “référencer toutes les fonctionnalités” dans le moindre détail. Il doit surtout être clair sur le pourquoi et les priorités. Le détail s’affine ensuite, avec le prestataire.
Ce qui change par rapport à un site internet
La structure est proche, mais le mobile impose des sujets supplémentaires, à traiter explicitement :
- Les stores. App Store et Google Play imposent leurs règles de validation, leurs délais de revue et leurs fiches de publication.
- Les versions d’OS. Quelles versions d’iOS et d’Android supporter ? Ce choix a un impact direct sur le coût et la maintenance.
- Les fonctions de l’appareil. Caméra, GPS, biométrie, Bluetooth : chaque accès déclenche une permission et une exigence de confidentialité.
- Le hors connexion. Une application mobile est souvent utilisée en mobilité, parfois sans réseau.
- Les notifications push et les deep links, qui structurent l’engagement.
- La performance sur l’appareil : démarrage, fluidité, consommation de batterie, poids de l’application.
L’anatomie d’un cahier des charges mobile
La logique reste la même que pour tout projet : du pourquoi vers le comment. On cadre l’intention et les usages, on décrit le périmètre, on traite ensuite la technique, les contraintes et le cadre projet.
La première section reste la plus importante. Présentez votre contexte et surtout vos objectifs mesurables : nombre de téléchargements visés, taux de rétention, conversion, réduction d’un coût opérationnel. Un objectif chiffré oriente toutes les décisions qui suivent.
Décrire les besoins en user stories
Comme pour un site, la bonne pratique consiste à exprimer le périmètre en user stories plutôt qu’en listes de fonctionnalités. Une story tient en une phrase : “En tant que livreur, je veux scanner un colis hors connexion, afin de valider une livraison même sans réseau.”
Ce format garde l’utilisateur au centre, rend chaque besoin testable et laisse au prestataire la liberté de proposer la meilleure implémentation. Pour les parcours clés (inscription, paiement, scan, géolocalisation), un schéma vaut mieux qu’un paragraphe. Nous détaillons cette étape dans notre article sur l’usage des wireframes.
Natif, hybride ou PWA : ne tranchez pas trop tôt
C’est la question technique centrale du mobile, et l’erreur classique est d’y répondre dans le cahier des charges sans contrainte réelle. Décrivez plutôt vos besoins (fonctions device, performance, hors connexion, budget, délai) et laissez l’agence recommander l’approche.
| Critère | Natif | Hybride / cross-platform | PWA |
|---|---|---|---|
| Base de code | Une par OS | Une seule | Une seule (web) |
| Performance | Maximale | Très bonne | Bonne |
| Accès aux fonctions device | Complet | Large | Limité |
| Présence sur les stores | Oui | Oui | Non (ou limitée) |
| Coût et délai | Les plus élevés | Maîtrisés | Les plus faibles |
Pour approfondir, nos articles sur le choix natif ou hybride, sur le développement cross-platform et sur React Native détaillent les arbitrages.
Les exigences non fonctionnelles à ne pas oublier
C’est l’angle mort des cahiers des charges. Sur mobile, ces exigences conditionnent l’acceptation sur les stores et la satisfaction des utilisateurs.
| Exigence | Ce qu’il faut préciser |
|---|---|
| Performance | Temps de démarrage, fluidité, poids de l’app, consommation de batterie |
| Hors connexion | Quelles fonctions doivent marcher sans réseau, et la synchronisation |
| Permissions et données | Accès device justifiés, transparence, conformité RGPD |
| Accessibilité | Compatibilité avec les réglages système (taille de texte, lecteur d’écran) |
| Sécurité | Authentification, stockage chiffré, gestion des sessions |
| Stores et ASO | Fiches de publication, visuels, mots-clés, respect des règles |
Deux sujets méritent un cadrage explicite. Les permissions sont scrutées par les stores et par vos utilisateurs : ne demandez que ce qui est justifié, et traitez le RGPD dès la conception. Et la conformité aux règles des stores doit être anticipée, sous peine de refus à la publication.
Budget, publication et gouvernance
Donnez une fourchette de budget réaliste et indiquez vos contraintes de planning, en distinguant la date idéale de la date impérative. Définissez la gouvernance : qui décide, qui valide, à quel rythme.
Trois éléments propres au mobile sont souvent oubliés et coûtent cher. Les comptes développeur : qui détient les comptes App Store et Google Play conditionne votre indépendance, exigez qu’ils soient à votre nom. Les délais de revue des stores, à intégrer au planning de lancement. Et la maintenance : les OS évoluent chaque année et imposent des mises à jour régulières, c’est un engagement de run, pas un coût ponctuel.
Les erreurs qui coûtent cher
- Sauter les objectifs mesurables. Sans cible, le projet dérive vers les préférences de chacun.
- Figer l’approche technique sans raison. Vous fermez la porte aux meilleures propositions.
- Tout déclarer prioritaire. Sans arbitrage, le budget et le délai explosent. Cadrez un premier périmètre utile, un MVP.
- Oublier les stores et les permissions. Un refus de publication bloque tout le lancement.
- Négliger comptes, recette et réversibilité. Sans clauses claires, vous restez dépendant.
Un document vivant
Une application mobile n’est pas figée le jour de la signature. Les besoins s’affinent au contact des premières maquettes et des premiers retours. Le bon cahier des charges cadre fermement les objectifs et les priorités, tout en laissant le détail s’ajuster par itérations. Livrez d’abord le périmètre indispensable, apprenez, puis enrichissez.
Notre approche chez Sooyoos
Nous aidons régulièrement nos clients à transformer une intention en cahier des charges exploitable. La méthode est constante : un atelier de diagnostic pour cadrer les objectifs, la cible et les priorités, puis une mise en forme structurée que vous gardez et faites circuler.
Cette base nourrit la suite : la conception et le développement d’une application sur mesure, mobile comprise, avec une approche cross-platform quand elle est pertinente. Nous restons ensuite présents en run, car une application vit au rythme des mises à jour des systèmes.
Questions fréquentes
Faut-il choisir entre application native, hybride ou PWA dès le cahier des charges ?
Non, sauf contrainte forte. Décrivez plutôt vos besoins : fonctions device attendues (caméra, GPS, biométrie), exigences de performance, mode hors connexion, budget et délai. Laissez ensuite l’agence recommander l’approche. Pour beaucoup de projets, une approche hybride ou cross-platform (React Native, Flutter) offre le meilleur rapport performance, coût et délai. Le natif s’impose quand la performance ou l’accès device sont critiques, la PWA quand on veut éviter les stores.
Faut-il développer pour iOS et Android en même temps ?
Cela dépend de votre cible et de votre budget. Une approche cross-platform permet de livrer les deux plateformes à partir d’une même base de code, ce qui réduit le coût d’un double développement natif. Si votre budget initial est serré, vous pouvez aussi lancer d’abord sur la plateforme majoritaire de vos utilisateurs, puis étendre. Le cahier des charges doit indiquer les plateformes visées et les versions d’OS à supporter.
Comment prendre en compte la publication sur les stores dans le cahier des charges ?
Prévoyez explicitement la publication : comptes développeur App Store et Google Play, fiches store (titre, description, visuels, ASO), respect des règles de validation d’Apple et de Google, et délais de revue. Précisez aussi qui détient les comptes développeur, point souvent oublié qui conditionne votre indépendance. La conformité aux règles des stores, notamment sur la confidentialité, doit être anticipée dès la conception.
Le cahier des charges d’une application mobile est-il différent de celui d’un site ?
La structure est proche, mais le mobile ajoute des contraintes spécifiques : publication sur les stores et leurs règles, versions d’OS à supporter, accès aux fonctions de l’appareil et gestion des permissions, mode hors connexion, notifications push et performance sur des terminaux variés. Ces points doivent figurer explicitement dans le document, en plus des sections communes à tout projet digital.
Combien coûte le développement d’une application mobile ?
Il n’y a pas de prix unique : le budget dépend du périmètre fonctionnel, du nombre de plateformes, de la complexité des intégrations et du niveau d’exigence sur le design et la performance. La meilleure approche consiste à prioriser les fonctionnalités, à cadrer un premier périmètre utile (un MVP), puis à demander des devis sur cette base claire. Un cahier des charges précis et priorisé est ce qui permet d’obtenir des estimations fiables et comparables.
Conclusion
Un bon cahier des charges d’application mobile n’est pas le plus exhaustif, c’est le plus clair. Il dit pourquoi l’application existe, ce qu’elle doit accomplir en priorité, et dans quelles contraintes (stores, OS, device, budget). Il laisse au prestataire la liberté de proposer le meilleur chemin technique.
Vous préparez une application mobile à fort enjeu ? Nous pouvons cadrer votre projet et structurer votre cahier des charges avec vous. Commençons par un diagnostic, ou contactez-nous pour en discuter.
