Cahier des chargesMobileMéthodeApplication métier
Cahier des charges d'une application mobile : modèle, exemple et règles des stores
11 min de lecture
Le cahier des charges d'une application mobile ressemble à celui de toute application, avec une dizaine de questions en plus qui font toute la différence : sur quels téléphones, avec ou sans réseau, quelles autorisations demander, par quel magasin la distribuer, et comment respecter les règles d'Apple et de Google. Ce sont ces questions que les modèles en ligne survolent, et ce sont elles qui font dériver un budget ou bloquer une publication.
Ce guide donne un modèle en douze rubriques, les exigences propres au mobile que l'on oublie, un exemple condensé et une checklist avant envoi.
À quoi sert le document
Il doit permettre trois choses : obtenir des devis comparables, aligner l'entreprise sur ce que fait (et ne fait pas) la première version, et servir de référence lors de la recette. La méthode générale, valable pour toute application, est détaillée dans notre guide sur le cahier des charges d'une application interne. Ici, on se concentre sur ce qui est propre au mobile.
Avant d'écrire, vérifiez qu'il vous faut vraiment une application à installer. Une application web, éventuellement installable (PWA), couvre beaucoup de besoins pour un coût moindre. Notre comparatif application web, PWA ou native vous aide à trancher. Si le mobile s'impose, voici quoi écrire.
Le modèle en 12 rubriques
| N° | Rubrique | Ce qu'elle doit contenir |
|---|---|---|
| 1 | Contexte et objectifs | Le problème, les objectifs mesurables, ce qui existe déjà |
| 2 | Utilisateurs | Profils, nombre, conditions d'usage (terrain, gants, soleil, bruit) |
| 3 | Parcours principaux | Les trois à cinq actions qui justifient l'application |
| 4 | Écrans clés | Croquis ou captures d'outils existants, sans imposer le design |
| 5 | Plateformes et appareils | iOS, Android, tablettes, versions minimales, appareils fournis ou non |
| 6 | Hors connexion | Ce qui doit marcher sans réseau, et comment se synchronise le reste |
| 7 | Fonctions de l'appareil | Position, caméra, scan, notifications, Bluetooth, biométrie |
| 8 | Back-office et intégrations | Qui administre quoi, liens avec l'ERP, le CRM, la facturation |
| 9 | Comptes et sécurité | Connexion, rôles, suppression de compte, perte du téléphone |
| 10 | Distribution et stores | Stores publics, distribution privée, comptes développeur, fiches |
| 11 | Données personnelles et mesure | Données collectées, SDK tiers, consentement, hébergement |
| 12 | Projet, maintenance, réponse | Budget, jalons, maintenance après lancement, format des offres |
Rubriques 2 et 3 : les conditions réelles d'usage
Une application mobile s'utilise debout, d'une main, dehors, entre deux tâches. Décrivez ces conditions, elles changent la conception :
- un technicien avec des gants a besoin de grands boutons et de saisies par choix plutôt que par texte ;
- un chauffeur en tournée a besoin d'une application qui reprend là où elle s'est arrêtée après un appel ;
- un client grand public ouvrira l'application une fois par mois, et doit tout comprendre sans aide.
Puis limitez les parcours. Une bonne première version fait trois à cinq choses très bien. Par exemple : consulter la tournée du jour, enregistrer une intervention avec photos, faire signer le client, envoyer le rapport. Tout le reste peut attendre une deuxième version, comme nous l'expliquons dans MVP : quoi développer en premier.
Rubrique 5 : plateformes et appareils
Écrivez :
- les plateformes : iOS, Android, ou les deux, en partant de vos utilisateurs. Pour une application interne, c'est le parc fourni par l'entreprise qui décide ;
- les versions minimales à supporter, en sachant que chaque ancienne version ajoutée coûte des tests ;
- les tablettes et ordinateurs : la même application doit-elle aussi tourner au bureau ?
- les appareils particuliers : terminaux durcis, lecteurs de codes, imprimantes Bluetooth.
Le choix technique (natif, ou base de code commune comme React Native ou Flutter) relève du prestataire, mais vos contraintes l'orientent. Notre article React Native ou Flutter présente les deux approches.
Rubrique 6 : le hors connexion, la question qui change le budget
C'est l'exigence qui fait le plus varier un chiffrage, et celle que les cahiers des charges oublient le plus souvent. Soyez précis :
- quelles données doivent être disponibles sans réseau (la tournée du jour, le catalogue, l'historique client) ;
- quelles actions doivent pouvoir se faire hors ligne (saisir, photographier, faire signer) ;
- comment résoudre les conflits : si deux personnes modifient la même fiche hors ligne, laquelle l'emporte ?
- combien de temps l'application doit tenir sans réseau : une heure en sous-sol, ou trois jours en zone blanche.
« Fonctionne hors ligne » ne se chiffre pas. « Un technicien saisit et photographie une intervention sans réseau, et le rapport part automatiquement au retour du réseau, sans doublon » se chiffre et se vérifie.
Rubrique 7 : les autorisations demandées
Chaque fonction de l'appareil passe par une autorisation que l'utilisateur peut refuser. Pour chacune (position, caméra, photos, contacts, notifications, Bluetooth, micro), écrivez pourquoi l'application en a besoin et ce qui se passe si l'utilisateur refuse. Une application qui plante ou se bloque après un refus est un défaut, et une autorisation non justifiée inquiète l'utilisateur comme le magasin d'applications.
La position en arrière-plan mérite une attention particulière : elle est encadrée plus strictement par Apple et Google, et sensible au regard du RGPD, surtout pour suivre des salariés.
Rubrique 9 : les comptes, dont la suppression
Trois exigences à ne pas oublier :
- la connexion : identifiants de l'entreprise, lien magique, code, biométrie ; et ce qui se passe quand un salarié quitte l'entreprise ;
- la perte ou le vol d'un téléphone : déconnexion à distance, données chiffrées sur l'appareil ;
- la suppression du compte. Si l'application permet de créer un compte, les règles de l'App Store (règle 5.1.1 (v)) imposent de proposer sa suppression depuis l'application. Google Play exige de son côté un chemin dans l'application et une page web pour demander la suppression du compte et des données associées (applications privées d'entreprise exemptées). Consultés le 7 novembre 2026.
Rubrique 10 : distribution, stores et comptes développeur
Le mode de distribution se décide dans le cahier des charges, pas à la fin du projet :
| Mode | Pour qui | Ce qu'il implique |
|---|---|---|
| App Store et Google Play publics | Clients, grand public | Validation à chaque version, fiches, captures, politique de confidentialité |
| Distribution privée | Salariés, réseau de partenaires | Applications sur mesure Apple via Apple Business Manager, applications privées Google Play |
| Application web installable (PWA) | Usage interne simple, peu de fonctions natives | Aucun store, mise à jour immédiate, accès limité à l'appareil |
Quatre points à écrire :
- les comptes développeur sont au nom de votre entreprise, et non du prestataire, qui reçoit un accès délégué. Les frais sont modestes (le détail est dans notre article sur le prix d'une application mobile) ;
- une application publique doit apporter plus qu'un site emballé : la règle 4.2 d'Apple refuse les applications qui ne sont qu'un site web reconditionné ou qui manquent d'utilité propre ;
- Google impose une version cible récente d'Android : selon la documentation Android, depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16 (niveau d'API 36), les applications privées d'entreprise étant exemptées. Cette exigence revient chaque année, et justifie à elle seule un budget de maintenance ;
- qui prépare les fiches (textes, captures, catégorie, questionnaire de confidentialité) et qui répond en cas de refus.
Rubrique 11 : données personnelles, SDK et mesure d'audience
La CNIL a publié des recommandations dédiées aux applications mobiles le 24 septembre 2024, révisées le 8 avril 2025. Elles visent l'éditeur comme le développeur. Dans le cahier des charges, demandez :
- la liste des données collectées, et pour chacune l'usage et la durée de conservation ;
- la liste des SDK tiers (mesure d'audience, crash, publicité) avec ce qu'ils collectent, car ils remplissent aussi les questionnaires de confidentialité des stores ;
- le recueil du consentement quand il est nécessaire, avant tout traceur non indispensable ;
- le lieu d'hébergement du back-office et des sauvegardes.
Notre article RGPD et application métier complète ces points.
Rubrique 12 : maintenance et format de réponse
Une application mobile n'est jamais finie : chaque année, Apple et Google publient une nouvelle version de leur système, et les règles des stores évoluent. Demandez aux prestataires de chiffrer séparément le développement initial et la maintenance annuelle (mises à jour des systèmes, des bibliothèques, corrections), et précisez :
- les jalons : prototype, version de test interne, bêta, publication ;
- les livrables : code source, accès aux comptes, documentation, avec des droits définis au cas par cas dans le contrat ;
- le coût total sur trois ans, pas seulement le premier devis.
Un exemple condensé
Contexte : une entreprise de maintenance de 25 techniciens gère ses interventions sur papier ; les rapports arrivent avec deux à cinq jours de retard et la facturation suit.
Objectif : rapport envoyé au client le jour même, facturation lancée sous 48 heures.
Parcours indispensables : voir sa tournée du jour ; enregistrer une intervention (pièces, temps, photos) ; faire signer le client sur l'écran ; envoyer le rapport PDF.
Hors connexion : tout le parcours fonctionne sans réseau pendant une journée ; synchronisation automatique au retour du réseau.
Plateformes : Android, téléphones fournis par l'entreprise ; une vue bureau web pour le planning.
Distribution : privée, appareils gérés par l'entreprise.
Intégrations : clients et contrats lus dans l'ERP ; interventions renvoyées à l'ERP pour facturation.
Hors périmètre de la version 1 : devis sur place, application client, paiement.
Si ce type de besoin vous parle, notre article sur le logiciel de gestion des interventions sur mesure va plus loin.
Les erreurs les plus fréquentes
- Écrire « comme telle application connue ». Elle a coûté des années de travail ; dites ce qui vous plaît précisément.
- Oublier le back-office. Quelqu'un doit créer les comptes, modifier le catalogue, consulter les rapports : c'est souvent la moitié du projet.
- Taire le hors connexion. Découvert pendant les tests, il se paie au prix fort.
- Laisser les comptes stores au prestataire. Vous en devenez dépendant.
- Ne pas budgéter la maintenance. Une application non mise à jour finit par ne plus être proposée sur les téléphones récents.
La checklist avant envoi
- Les trois à cinq parcours indispensables sont décrits, le reste est classé.
- Les plateformes et versions minimales sont fixées.
- Le hors connexion est décrit en données, actions et durée.
- Chaque autorisation est justifiée, avec le comportement en cas de refus.
- La suppression de compte est prévue si des comptes se créent.
- Le mode de distribution et le titulaire des comptes sont écrits.
- Les données collectées et les SDK tiers sont listés.
- La maintenance annuelle est demandée à part.
Voir l'application avant de la commander
Sur mobile plus qu'ailleurs, un écran vaut mieux qu'une page de texte : on juge une application en la tenant en main. Nous construisons un prototype gratuit des écrans principaux, présenté en visio sous 5 jours ouvrés, à partir de votre cahier des charges ou d'une simple conversation. Vos utilisateurs réagissent sur du concret avant le moindre développement, comme expliqué dans voir son logiciel avant de le payer.