Cahier des charges d’application mobile : modèle complet

Un cahier des charges d’application mobile utile ne décrit pas seulement des écrans. Il explique qui utilisera le produit, dans quelle situation, avec quelles données, quelles contraintes du téléphone et quel résultat devra être observé. Ce cadre permet à une équipe de comparer des solutions, d’identifier les risques et d’estimer un premier périmètre sans inventer les détails manquants.

Le document peut tenir en quinze pages s’il est précis. Une liste de cinquante fonctionnalités reste insuffisante si elle ne dit rien du hors-ligne, des erreurs, des permissions, du backend, de la publication sur les stores ou des critères de recette.

Le modèle en douze sections

1. contexte, problème et résultat attendu ;
2. utilisateurs et situations d’usage ;
3. proposition de valeur et parcours prioritaire ;
4. choix mobile, plateformes et appareils ;
5. fonctionnalités, règles et états ;
6. données, comptes, backend et intégrations ;
7. hors-ligne, synchronisation et performance ;
8. permissions, notifications et fonctions du téléphone ;
9. sécurité, vie privée et conformité ;
10. mesure, analytics et exploitation ;
11. publication, maintenance et responsabilités ;
12. planning, budget, livrables et critères d’acceptation.

Chaque section doit distinguer ce qui est certain, ce qui est supposé et ce qui reste à décider. Cette différence évite qu’une hypothèse glissée dans une phrase devienne une obligation contractuelle coûteuse.

1. Décrire le problème avant la solution

Commencez par une page de synthèse : activité de l’organisation, situation actuelle, personnes concernées, problème observé et résultat souhaité. Remplacez « nous voulons une application moderne » par une formulation vérifiable : « permettre à un technicien de clôturer une intervention sur site en moins de trois minutes, même lorsque la connexion est instable ».

Ajoutez les preuves disponibles : entretiens, volumes, demandes clients, temps de traitement, tickets support ou limites d’un outil existant. Indiquez aussi pourquoi le mobile semble nécessaire. Une application est cohérente lorsqu’elle accompagne un usage fréquent, utilise la caméra ou la localisation, doit fonctionner hors ligne ou mérite un accès immédiat. Un site responsive peut être plus simple pour un besoin occasionnel et éditorial.

Notre guide pour choisir entre application mobile, web app et PWA aide à tester cette décision avant d’engager les stores.

2. Définir les utilisateurs dans leur contexte

Évitez les personas décoratifs. Décrivez des situations : rôle, objectif, environnement, fréquence, équipement, connexion, niveau d’aisance et conséquences d’une erreur.

Question	Exemple terrain
Qui agit ?	technicien salarié et sous-traitant
Où ?	chantier intérieur, parfois sans réseau
Avec quoi ?	téléphone Android professionnel, écran moyen
Pour obtenir quoi ?	preuve de passage et compte rendu accepté
À quelle fréquence ?	quatre à huit interventions par jour
Quel échec est critique ?	perdre les photos ou créer deux clôtures

Précisez les besoins d’accessibilité : taille du texte, contraste, navigation avec technologies d’assistance, usage à une main, conditions lumineuses ou motrices. Ces contraintes influencent la conception dès le départ.

3. Choisir un parcours prioritaire

Le cahier des charges doit raconter un parcours complet. Par exemple : recevoir une mission, consulter les informations, naviguer jusqu’au lieu, constater, photographier, faire signer, envoyer, puis retrouver la preuve dans le système métier.

Pour chaque étape, notez l’entrée, l’action, la règle, le résultat et l’erreur possible. Un MVP n’est pas une collection d’écrans partiels : il doit rendre un service de bout en bout à un groupe limité.

Hiérarchisez ensuite les autres parcours avec quatre niveaux :

• indispensable au lancement : sans lui, le service prioritaire échoue ;
• nécessaire à l’exploitation : administration, support, correction ou conformité ;
• utile après preuve : améliore un usage déjà démontré ;
• hors périmètre : idée conservée sans engagement.

Cette classification facilite la comparaison des devis et protège le budget contre l’accumulation de « petites fonctions ».

4. Préciser plateformes et parc d’appareils

Indiquez si l’application doit viser iOS, Android ou les deux, ainsi que les versions minimales envisagées. Décrivez les téléphones et tablettes réellement utilisés, leur propriété — personnelle ou entreprise — et les éventuels systèmes de gestion de parc.

Le choix natif, multiplateforme ou web dépend des fonctions, de l’équipe, de la performance attendue et de la durée de vie. Ne l’imposez pas uniquement à partir d’une préférence technique. Demandez à la proposition d’expliquer l’accès aux API natives, les mises à jour, les tests, la taille de l’application et le partage de code.

Ajoutez les orientations d’interface : langues, portrait ou paysage, tablette, thème sombre, tailles dynamiques et comportement lorsque le clavier apparaît. Les maquettes devront couvrir les appareils les plus contraignants, pas seulement un grand écran récent.

5. Décrire fonctions, règles et états

Une fonctionnalité devient estimable lorsqu’elle contient ses états. « L’utilisateur peut créer un compte » doit préciser inscription, vérification, connexion, mot de passe oublié, compte bloqué, déconnexion, suppression et erreur réseau.

Utilisez une fiche par capacité importante :

Champ	Contenu attendu
Intention	résultat recherché par l’utilisateur
Précondition	compte, permission, donnée ou connexion nécessaire
Parcours nominal	étapes courtes et ordonnées
Règles	droits, seuils, calculs et validations
États	vide, chargement, succès, erreur, indisponible
Exceptions	conflit, doublon, donnée périmée, action refusée
Critère d’acceptation	résultat observable et reproductible

Joignez les règles métier connues dans un vocabulaire stable. Un glossaire évite que « client », « membre » ou « bénéficiaire » désignent la même personne selon les écrans.

6. Rendre le backend et les intégrations visibles

L’application n’est souvent que l’une des interfaces d’un système. Identifiez où vivent les comptes, produits, commandes, dossiers ou messages. Pour chaque donnée, indiquez le système de vérité, le propriétaire, la fréquence de mise à jour et les droits.

Listez les API existantes, leur documentation, les environnements de test, les quotas et la personne qui peut répondre. Si le backend doit être créé, dites-le explicitement : authentification, base, administration, stockage de fichiers, e-mails, paiements et journaux représentent une part importante du projet.

Les intégrations tierces doivent préciser leur but et leur responsabilité. Qui possède les comptes Apple, Google, paiement, cartographie, notifications ou analytics ? Qui paie les abonnements ? Que se passe-t-il si un fournisseur modifie son API ?

7. Concevoir le hors-ligne et la synchronisation

« Fonctionner hors ligne » n’est pas une case. Décrivez ce que l’utilisateur peut voir et faire sans réseau, pendant combien de temps et avec quelle quantité de données. Précisez la manière dont l’application signale une action en attente.

Trois questions sont essentielles :

1. quelle donnée est disponible localement et jusqu’à quand ?
2. que se passe-t-il si la même information change sur deux appareils ?
3. comment éviter de répéter un paiement, un envoi ou une clôture après une coupure ?

Définissez une politique de conflit : serveur prioritaire, dernière modification, fusion ou décision humaine. Les actions sensibles doivent pouvoir être relancées sans produire de doublon. Ajoutez une synchronisation visible et une issue lorsque le stockage du téléphone est plein.

Pour la performance, fixez des budgets sur les parcours importants : temps de démarrage, taille des médias, délai d’affichage d’une liste et comportement sur une connexion lente. Le ressenti doit être testé sur un appareil moyen, pas seulement sur le téléphone du développeur.

8. Justifier permissions et notifications

Listez chaque permission : caméra, photos, localisation, microphone, contacts, Bluetooth, mouvement ou notifications. Pour chacune, reliez la demande à une action compréhensible et prévoyez le refus.

Une application ne doit pas demander toutes les permissions au premier lancement. Expliquez leur utilité au moment où la personne déclenche la fonction. Si elle refuse, le parcours doit rester cohérent ou proposer une alternative.

Pour les notifications, définissez l’événement, le destinataire, le délai, le contenu minimal, le lien d’arrivée et les réglages. Une notification n’est utile que si elle porte une information attendue ou une action temporelle. Précisez les plages silencieuses, la fréquence maximale et la gestion des préférences.

9. Encadrer sécurité et données personnelles

Le document doit inventorier les catégories de données, leur finalité, leur durée de conservation et les personnes autorisées. Indiquez les données sensibles, les contraintes sectorielles, la localisation d’hébergement et les besoins d’audit.

Décrivez l’authentification, les rôles, la révocation d’une session, le chiffrement en transit, la protection du stockage local et le traitement d’un téléphone perdu. Ne placez pas de secret durable directement dans l’application distribuée.

Prévoyez les droits sur les données et la suppression du compte lorsque le service l’exige. La CNIL propose un guide de sécurité des données personnelles ; il aide à transformer la conformité en mesures concrètes plutôt qu’en simple mention juridique.

10. Définir la mesure avant le lancement

Les analytics doivent répondre à une question produit. Définissez d’abord le résultat : activation, tâche réussie, délai, rétention adaptée au service, achat, erreur ou recours au support. Puis listez les événements nécessaires, avec leur signification et leurs propriétés.

Exemple de plan minimal :

• mission_opened : une mission accessible est consultée ;
• report_started : la saisie du compte rendu commence ;
• report_queued : la clôture est stockée en attente hors ligne ;
• report_synced : le serveur confirme une clôture unique ;
• report_failed : une erreur nécessite une intervention.

Évitez d’envoyer le texte libre ou les données personnelles dans un outil d’analyse. Précisez le consentement lorsqu’il est requis et le fonctionnement sans mesure facultative. L’équipe doit disposer de journaux techniques distincts des analytics marketing.

11. Préparer les stores et l’exploitation

La publication demande des comptes organisationnels, informations juridiques, captures, descriptions, politique de confidentialité, classification d’âge et réponses sur les données collectées. Attribuez la production et la validation de chaque élément.

Apple publie ses App Review Guidelines et Google détaille les attentes de qualité des applications et jeux. Ces règles évoluent : vérifiez-les au moment de soumettre plutôt que de considérer une ancienne acceptation comme acquise.

Décrivez ensuite les environnements, les versions de test, le déploiement progressif, le suivi des crashs, les alertes, le support, les sauvegardes et le délai de correction attendu. Qui décide qu’une version est prête ? Qui peut interrompre un déploiement ? Qui répond à une demande urgente du store ?

12. Rendre budget, planning et livrables comparables

Indiquez une enveloppe ou une contrainte de financement si elle existe. Elle permet aux équipes de proposer un périmètre réaliste. Notre article sur le prix d’une application mobile en 2026 détaille les facteurs de coût au-delà du nombre d’écrans.

Demandez de distinguer découverte, UX/UI, développement mobile, backend, administration, intégrations, tests, publication et garantie. Chaque phase doit préciser ses livrables, les participants nécessaires et la décision attendue.

Le planning doit inclure les validations internes, la création des comptes, l’accès aux API, la production de contenus, la recette et l’incertitude des stores. Une date de lancement imposée doit expliquer ce qui peut être réduit sans compromettre le service principal.

Modèle de critères d’acceptation

Un critère utile est observable par une personne qui n’a pas écrit la fonction. Exemple :

Étant donné une mission téléchargée et l’absence de réseau, lorsque le technicien ajoute trois photos puis clôture le rapport, l’application conserve l’action avec un statut visible. Au retour du réseau, elle crée un seul rapport côté serveur, affiche la confirmation et conserve les photos associées.

Ajoutez des critères pour la sécurité, l’accessibilité, la performance et les erreurs, pas seulement pour le parcours nominal. Définissez les appareils de test, les navigateurs du backoffice et les données de recette.

Les annexes vraiment utiles

Joignez ce qui réduit une ambiguïté : schéma des systèmes, exemples de données, règles de calcul, charte, inventaire de contenus, API, contraintes légales, appareils cibles et accès à un environnement de démonstration. Masquez les secrets et les données personnelles.

Un prototype cliquable peut clarifier la structure, mais il ne prouve ni la synchronisation ni la performance. Un tableur d’exemples peut être plus utile qu’une longue spécification s’il révèle les règles et exceptions.

Comparer les réponses à votre consultation

Évaluez la compréhension du problème, les inconnues identifiées, la cohérence du premier périmètre, la qualité des critères, la gestion des données, l’exploitation et l’équipe réelle. Méfiez-vous d’un prix ferme produit sans question sur le backend, les comptes ou les cas hors ligne.

Une proposition solide peut recommander une phase de cadrage, un prototype ou même une solution web. Cette capacité à contester le format protège davantage le projet qu’une promesse de tout livrer immédiatement.

Zence conçoit et développe des applications mobiles iOS et Android. Nous transformons le cahier des charges en décisions démontrables : parcours prioritaire, architecture proportionnée, états complets, critères de recette et plan d’exploitation. Le document ne doit pas prédire chaque détail ; il doit permettre de décider sans cacher les risques.

Vous pouvez générer une première version avec le modèle éditable de cahier des charges, puis utiliser la méthode pour choisir une agence d’application mobile afin de comparer les réponses sur les mêmes critères.