Cahier des charges d’une application mobile : la trame pour faire chiffrer votre app

Vous voulez faire développer une application pour iOS et Android et vous vous apprêtez à consulter des prestataires. Un cahier des charges d’application mobile efficace tient en une dizaine de pages : le contexte et les objectifs, les utilisateurs et leurs parcours, les fonctionnalités classées par priorité, le back-office, les intégrations, les contraintes propres au téléphone (capteurs, réseau, notifications), la publication sur les stores et le budget. Le document décrit le besoin sans imposer la solution, pour que chaque prestataire chiffre le même projet et que les devis se comparent. Vous trouverez ce qu’un prestataire mobile lit en premier, une trame commentée rubrique par rubrique, et les pièges qui font dériver un budget.

Ce qu’un prestataire mobile lit en premier pour chiffrer

Un devis d’application mobile se construit autour de quatre réponses, parce que chacune change la structure du devis plus que tout le reste du document.

• La cible. Une application grand public pour des clients, ou un outil interne pour des équipes ? Le premier cas privilégie l’expérience, la visibilité sur les stores et les notifications. Le second s’installe souvent hors stores, sur des téléphones fournis par l’entreprise. Sa maintenance compte plus que son habillage. L’application des salariés de Desoutter Tools, par exemple, réunit un assistant IA, le catalogue produit et des outils métier : c’est un outil de travail, jugé à l’aune du temps qu’il fait gagner.
• Les plateformes. iOS et Android ensemble, ou une seule ? Le prestataire a surtout besoin de connaître les appareils réels de vos utilisateurs. Si vos 60 techniciens ont des Android de milieu de gamme, écrivez-le : cela oriente les tests, les performances visées et le budget.
• Le contexte d’usage. L’application s’utilise-t-elle en transports, au bureau, au soleil, avec des gants, dans des zones où le réseau passe mal ? Chacune de ces situations ajoute des cas à prévoir.
• Les volumes. Précisez le nombre d’utilisateurs attendus, la quantité de données et les pics : une réservation de cours à 7 h du matin, un pointage à l’entrée le soir.

Le reste de la trame est commun à tout projet logiciel : contexte, utilisateurs, périmètre priorisé, critères d’acceptation. Le modèle de cahier des charges pour un développement logiciel les détaille section par section. Cet article s’attarde sur ce qui change quand le produit vit dans une poche et se publie sur deux stores.

Modèle de cahier des charges d’application mobile, commenté

Chaque rubrique s’appuie sur un même projet fictif, une application pour les adhérents d’un réseau de huit salles de sport, que vous pouvez transposer à votre cas.

1. Contexte et objectifs

Présentez l’entreprise en quelques lignes, le problème tel qu’il se vit aujourd’hui, puis deux ou trois objectifs chiffrés. Pour le réseau de salles : « 30 % des réservations de cours passent encore par téléphone aux heures de pointe, l’accueil y consacre une heure par jour. Nous voulons 80 % des réservations dans l’application d’ici un an. »

2. Utilisateurs et parcours clés

Listez chaque type d’utilisateur, son nombre, son appareil et son contexte. Les adhérents des salles viennent avec leurs téléphones personnels, des iPhone récents et des Android de toutes générations. Décrivez ensuite les trois à six parcours qui font l’essentiel de l’usage : l’adhérent réserve un cours, reçoit un rappel une heure avant, scanne un code à l’entrée. Le gérant crée les séances, ajuste les capacités et remplace un intervenant.

3. Fonctionnalités priorisées

Classez chaque fonctionnalité en « indispensable au lancement », « utile ensuite » ou « si le budget le permet ». La méthode MoSCoW (must, should, could, won’t) dit exactement cela. Pour les salles, la réservation et le code d’entrée sont indispensables, le suivi de ses séances passe en « utile ensuite », les défis entre adhérents attendront. Ce classement pèse davantage sur le devis que la liste elle-même, parce que le prestataire peut alors proposer une première version réaliste.

4. Écrans et intentions

Décrivez ce que l’utilisateur doit voir et faire, écran par écran, sans dessiner à sa place. Écrivez « l’adhérent retrouve ses réservations en un geste depuis l’écran d’accueil » plutôt que « un tableau de bord avec des cartes ». Les maquettes viennent plus tard, pendant le cadrage, avec le prestataire : votre document fixe l’intention, le cadrage produit le dessin.

5. Back-office et administration

Une application vit avec son administration : qui crée les séances, qui modifie les capacités, qui consulte les présences, avec quels droits. Chaque rôle listé dans cette rubrique devient des écrans d’administration et des règles d’accès à développer. Décrivez-la dès le départ : vous évitez l’avenant en cours de route et rendez les devis comparables sur la boucle complète, du téléphone de l’adhérent à celui du gérant.

6. Données et intégrations

Nommez chaque système avec lequel l’application doit échanger, le sens de l’échange, sa fréquence, et ce que vous savez de son API. L’application des salles récupère les abonnements depuis le logiciel de gestion et pousse les présences vers la facturation. Pour une application interne, précisez aussi l’authentification : comptes Microsoft de l’entreprise, SSO, gestion des droits. Joignez la documentation quand vous l’avez, et écrivez « à vérifier » quand vous ne l’avez pas. Un prestataire préfère lire cette mention plutôt que de découvrir l’API au troisième sprint.

7. Contraintes mobiles

Cette rubrique distingue un cahier des charges mobile d’un cahier des charges web. Listez :

• le mode hors ligne : l’application doit-elle fonctionner sans réseau puis se synchroniser ? C’est le poste le plus coûteux du mobile, indispensable sur le terrain et superflu pour la plupart des applications grand public
• les capteurs utilisés : caméra pour le code d’entrée, géolocalisation pour trouver la salle la plus proche, notifications push pour les rappels
• les permissions : chaque capteur demande une autorisation que le téléphone affiche au moment de l’usage, à expliquer à l’utilisateur juste avant
• les appareils visés : gammes, tailles d’écran, versions minimales d’iOS et d’Android, accessibilité

8. Publication sur l’App Store et Google Play

Précisez si l’application passe par les stores ou par une distribution interne, et qui possède les comptes développeur : le programme Apple coûte 99 $ par an, le compte Google Play 25 $ une seule fois, et ces comptes doivent appartenir à votre entreprise. Prévoyez aussi la préparation de la fiche store, les captures d’écran et le passage de la review. Si l’application vend des abonnements, dites-le ici : Apple et Google prélèvent une commission sur les achats intégrés, et le prestataire arbitrera entre le paiement dans l’application et le paiement sur le web.

9. RGPD et sécurité

Listez les données personnelles collectées, leurs finalités, leur durée de conservation, l’hébergement et les consentements (le tracking analytics en fait partie). Nommez le référent qui répondra aux demandes de droits. Pour une application interne, ajoutez le chiffrement des données sensibles et les règles d’accès.

10. Maintenance et mises à jour des OS

Chaque version majeure d’iOS et d’Android demande une passe de compatibilité, sans compter les mises à jour de dépendances et les correctifs. Comptez 15 à 25 % du coût initial par an et précisez qui l’assume après la publication. Une application laissée sans maintenance pendant 18 mois demande souvent une reprise technique avant même de repasser les reviews des stores. Le détail des coûts qui continuent après la publication est dans le prix d’une application mobile sur mesure.

11. Budget et calendrier

Donnez une fourchette de budget et la date qui compte vraiment, avec sa raison. « La rentrée, parce que 40 % des adhésions se font en septembre » oriente le périmètre de la première version. Avec un budget annoncé, chaque prestataire propose ce qui tient dedans plutôt que d’imaginer chacun une ampleur différente.

Copiez la trame vide dans votre éditeur de texte.

# Cahier des charges : application mobile [nom du projet]

## 1. Contexte et objectifs
- L’entreprise, le problème actuel, deux ou trois objectifs chiffrés

## 2. Utilisateurs et parcours clés
- Rôle, nombre, appareil, contexte d’usage
- Trois à six parcours, étape par étape

## 3. Fonctionnalités priorisées
- Indispensables au lancement
- Utiles ensuite
- Si le budget le permet

## 4. Écrans et intentions
- Ce que l’utilisateur voit et fait, écran par écran

## 5. Back-office et administration
- Qui gère quoi, avec quels droits

## 6. Données et intégrations
- Systèmes à connecter, sens, fréquence, documentation des API, SSO

## 7. Contraintes mobiles
- Fonctionnement hors ligne : que faire sans réseau
- Capteurs : caméra, géolocalisation, notifications push
- Appareils visés : gammes, versions minimales d’iOS et d’Android
- Accessibilité

## 8. Publication sur les stores
- App Store, Google Play, ou distribution interne
- Qui possède les comptes développeur
- Abonnement payé dans l’app ou sur le web

## 9. RGPD et sécurité
- Données collectées, finalités, hébergement, consentements, référent

## 10. Maintenance
- Compatibilité iOS et Android, correctifs, qui les assume

## 11. Budget et calendrier
- Fourchette de budget
- Date clé et raison de cette date

Les choix techniques à trancher ou à laisser ouverts

Un cahier des charges mobile décrit le besoin. La technologie appartient au devis, où le prestataire la justifie, sauf contrainte réelle que vous imposez : une DSI qui n’héberge que certains environnements, un parc de téléphones anciens, un matériel spécifique.

Ce tableau se résume en une règle : écrivez les appareils, le contexte d’usage et les contraintes de distribution, puis laissez le prestataire choisir le moyen d’y répondre. Deux applications séparées se justifient quand la performance brute est le produit lui-même, comme un jeu 3D temps réel. Pour tout le reste, une codebase unique couvre les deux plateformes pour environ la moitié du budget de développement et de maintenance.

Les erreurs qui font dériver le budget d’une application

Le développement d’une application coûte moins cher qu’il y a dix ans, grâce aux frameworks qui couvrent iOS et Android depuis une seule codebase. Ce qui pèse sur la facture, c’est de construire pendant trois mois une application dont le besoin était mal posé. Les fourchettes réelles par type de projet sont détaillées dans le prix d’une application mobile sur mesure. Quatre erreurs de cahier des charges reviennent le plus souvent.

Tout déclarer prioritaire

Quand chaque fonctionnalité est indispensable, le prestataire chiffre tout et le devis dépasse l’enveloppe. Le classement par priorité protège la première version : un produit minimum viable resserré sur le parcours qui crée la valeur arrive plus tôt dans les mains des utilisateurs. Le reste se priorise ensuite avec leurs retours.

Oublier le back-office

Une application qui affiche des données, envoie des notifications et gère des comptes vit avec un serveur, une API et une interface d’administration. La partie invisible pèse souvent la moitié du budget. Une rubrique d’administration vide donne deux devis impossibles à comparer, puisque chacun imagine ses propres écrans de gestion.

Négliger les règles des stores

Apple et Google publient des règles qui évoluent, sur le paiement, les données collectées, la modération de contenu. Une application qui les ignore se retrouve rejetée à la review, à quelques jours du lancement prévu. Les rubriques contraintes mobiles et publication sur les stores donnent au prestataire ce qu’il faut pour prévoir la conformité dès la conception plutôt qu’après coup.

Passer la maintenance sous silence

Un devis couvre la première publication. L’année suivante arrive une version majeure d’iOS, puis une d’Android, chacune avec sa passe de compatibilité. Écrire la maintenance dans le cahier des charges, avec sa cible de budget annuel, évite la mauvaise surprise de décembre et garde l’application dans les stores.

Du cahier des charges au premier sprint

Le cahier des charges fixe les objectifs et le budget. Le cadrage vient ensuite : le prestataire y anime des ateliers avec vos utilisateurs et livre les parcours, les maquettes, le backlog priorisé et l’architecture. Le document que vous avez écrit se traduit alors en écrans, si bien que le développement démarre sur des choix validés plutôt que sur des hypothèses.

Air Pays de la Loire a fourni un cahier des charges et la documentation de son API pour Naonair, son application sur la qualité de l’air. Lonestone en a tiré l’architecture, puis a travaillé les parcours et les wireframes avec l’équipe du client, avant de développer en sprints de deux semaines avec une démo testée en conditions réelles à chaque fin de sprint. Pour Gamtog, l’application qui met en relation les joueurs de jeux de société, Lonestone a livré une première version en un mois en resserrant le périmètre sur le parcours qui crée la valeur. Un jeu comme Lift & Drift, publié par le constructeur Manitou sur l’App Store et Google Play, est un produit de divertissement, où l’animation et le rendu portent l’expérience.

graph TD
  A[Cahier des charges<br/>besoin, priorités, contraintes, budget] --> B[Consultation des prestataires<br/>devis comparables]
  B --> C[Cadrage<br/>parcours, maquettes, backlog, architecture]
  C --> D[Sprints de 2 semaines<br/>une version installable à chaque démo]
  D --> E[Recette<br/>les critères d’acceptation deviennent des cas de test]
  E --> F[Publication sur l’App Store et Google Play]
  F --> G[Maintenance<br/>compatibilité iOS et Android, évolutions]
  G --> D

Lonestone construit des applications iOS et Android depuis 2015, en React Native depuis 2019 et en Flutter depuis 2021, pour plus de 200 clients accompagnés en 12 ans. Les ingénieurs ont pour la plupart entre 10 et 25 ans d’expérience. Les product designers interviennent dès le cadrage : sur mobile, l’expérience se joue à un geste près, au soleil ou dans le métro, et se travaille avant la première ligne de code. Si vous préférez confier la rédaction à une équipe, l’offre de cadrage Shape livre un cahier des charges fonctionnel, les parcours, les maquettes et une estimation, sans vous engager à faire développer ensuite.

Envoyez-nous votre cahier des charges, même incomplet, pour un projet d’application iOS et Android : vous repartez avec nos questions, des conseils et un devis détaillé. Pour savoir comment se passe un projet mobile avec nous, lisez notre approche de la création d’application mobile puis nos expertises en développement d’applications mobiles. Pour choisir un prestataire, le comparatif des agences françaises d’applications mobiles rassemble les équipes actives et leurs références.