Cahier des charges d’une application mobile : le modèle qui évite les devis flous

Un bon cahier des charges ne décrit pas cent écrans avant même d’avoir parlé aux utilisateurs. Il donne au studio assez de contexte pour comprendre le problème, proposer une solution réaliste et chiffrer le même périmètre que ses concurrents. Il protège aussi votre entreprise contre les zones grises : qui possède le code, qui ouvre les comptes Apple et Google, quelles données l’application collecte et comment vous validerez la livraison.

Vous n’avez pas besoin d’un document de cinquante pages. Vous avez besoin de décisions claires. Le modèle ci-dessous tient dans huit blocs. Vous pouvez le copier dans un document, répondre avec ce que vous savez aujourd’hui et laisser les inconnues visibles. Un studio sérieux vous aidera à les résoudre pendant le cadrage.

1. Commencez par le problème, pas par la liste des écrans

Écrivez en une phrase ce qui ne fonctionne pas aujourd’hui. Par exemple : « Nos techniciens remplissent des fiches papier, puis une personne ressaisit les informations au bureau. » Ajoutez l’effet concret : délai, erreurs, absence de visibilité ou expérience client incohérente. Cette phrase devient le filtre de toutes les fonctionnalités.

Ajoutez ensuite un résultat observable. Évitez « moderniser notre activité ». Préférez « permettre au technicien de clôturer une intervention sur place, même sans réseau, puis synchroniser le dossier ». Vous n’avez pas besoin d’inventer un chiffre. Décrivez simplement ce que l’utilisateur pourra faire et ce que votre équipe n’aura plus à refaire.

2. Nommez les utilisateurs et leurs situations réelles

Une application utilisée par un client, un opérateur terrain et un administrateur contient rarement le même parcours pour chacun. Pour chaque profil, notez son objectif, son contexte, son niveau d’accès et l’appareil qu’il utilise. Un utilisateur dans un entrepôt avec des gants, un commercial en déplacement et un responsable devant un ordinateur ne demandent pas la même interface.

Décrivez trois à cinq scénarios sous une forme simple : « En tant que [profil], je veux [faire quelque chose] afin de [résultat]. » Ajoutez les situations difficiles dès maintenant : réseau intermittent, utilisation à une main, langue différente, compte partagé, photo sensible ou validation par un responsable.

3. Séparez le MVP de la suite

Classez les fonctionnalités dans trois colonnes : indispensable au premier lancement, utile après validation et explicitement hors périmètre. Cette troisième colonne évite beaucoup de malentendus. Une messagerie, un mode hors ligne, des paiements, plusieurs rôles, une synchronisation avec le système interne ou une console d’administration changent fortement la conception.

Pour le MVP, gardez le parcours qui prouve la valeur de bout en bout. Si votre application sert à planifier des interventions, le premier périmètre peut couvrir la réception d’une mission, la navigation vers le site, la saisie du compte rendu et la validation. Les tableaux de bord avancés, les recommandations automatiques et les intégrations secondaires peuvent attendre une vraie utilisation.

4. Fixez les plateformes et les contraintes techniques

Indiquez si vous visez iPhone, Android, tablette et web. Précisez si vos équipes utilisent des appareils imposés par l’entreprise ou si le public apporte son propre téléphone. Listez les capacités nécessaires : caméra, localisation, Bluetooth, notifications, biométrie, fonctionnement hors ligne ou fichiers volumineux.

Ne choisissez pas une technologie dans le brief uniquement parce qu’un nom revient souvent. Exposez plutôt vos contraintes : qualité attendue, calendrier, intégrations, parc d’appareils et compétences de l’équipe qui reprendra le produit. Le studio pourra alors expliquer le compromis entre développement natif, multiplateforme et application web.

5. Cartographiez les données et les intégrations

Listez les données que l’application lit, crée, modifie et supprime. Pour chaque donnée personnelle, précisez pourquoi elle est nécessaire, où elle part et combien de temps vous souhaitez la conserver. La CNIL recommande d’intégrer la protection des données à chaque étape d’une application mobile, y compris lors du choix des SDK et des permissions.

Ajoutez les systèmes à connecter : CRM, ERP, outil de paiement, identité d’entreprise, agenda, stockage ou API métier. Donnez le nom du propriétaire interne et l’état de la documentation. « Connexion au CRM » ne suffit pas : faut-il lire les contacts, créer une opportunité, synchroniser dans les deux sens ou fonctionner quand le CRM est indisponible ?

Apple examine notamment la collecte, l’usage et le partage des données dans ses règles de validation de l’App Store. Google demande également une déclaration qui couvre les pratiques de l’application et celles des bibliothèques tierces dans la section Data safety. Si vous attendez la fin du développement pour dresser cet inventaire, vous créez une dette de conformité au pire moment.

6. Définissez ce que « terminé » veut dire

Transformez les fonctions importantes en critères d’acceptation observables. Exemple : « Quand un technicien perd le réseau après avoir ouvert une mission, il peut enregistrer les photos et le compte rendu ; l’application synchronise le dossier sans doublon au retour de la connexion. » Ce critère dit davantage qu’une ligne « mode hors ligne ».

Ajoutez les appareils à tester, les versions minimales, les langues, les besoins d’accessibilité et les volumes réalistes. Précisez qui valide côté client et combien de temps cette personne peut consacrer aux retours. Sans responsable disponible, les petites décisions attendent et le projet ralentit.

7. Protégez la propriété et la continuité du produit

Le cahier des charges doit demander noir sur blanc qui possède le code source, les maquettes, le nom de domaine, les comptes cloud, les certificats et les fiches App Store et Google Play. Votre entreprise devrait détenir les comptes de production et donner les accès nécessaires au studio, pas dépendre du compte personnel d’un prestataire.

Demandez aussi les livrables de fin : dépôt Git, documentation d’installation, variables d’environnement, inventaire des services tiers, procédure de déploiement, sauvegardes et état des licences. Fixez la période de correction des anomalies et séparez-la de la maintenance évolutive. Vous pourrez ainsi changer de partenaire sans reconstruire l’application.

8. Donnez le contexte de décision

Indiquez votre échéance réelle et ce qui la rend importante : salon, changement réglementaire, fin d’un contrat, pilote interne ou saison commerciale. Si la date peut bouger mais pas le périmètre, dites-le. Si la date ne peut pas bouger, acceptez de réduire le premier périmètre.

Pour le budget, vous pouvez donner une enveloppe ou demander plusieurs scénarios. Un studio peut proposer un noyau, une version recommandée et une phase suivante. Si vous cherchez d’abord un ordre de grandeur, utilisez notre calculateur de projet d’application mobile ; le cahier des charges servira ensuite à remplacer les hypothèses par des choix précis.

Modèle de cahier des charges à copier

1. Contexte : activité, problème actuel, personnes concernées et conséquence.
2. Résultat attendu : ce que l’utilisateur pourra accomplir et comment vous validerez l’utilité.
3. Utilisateurs : profils, droits, appareils, contexte et contraintes d’usage.
4. Parcours prioritaires : trois à cinq scénarios complets, du déclencheur au résultat.
5. Périmètre : fonctions du MVP, phase suivante et éléments hors périmètre.
6. Plateformes : iOS, Android, tablette, web, versions minimales et capacités du téléphone.
7. Données : données collectées, finalité, durée, suppression, permissions et acteurs qui y accèdent.
8. Intégrations : systèmes, API, propriétaires, documentation et sens de synchronisation.
9. Qualité : critères d’acceptation, appareils de test, accessibilité, langues et volumes.
10. Livraison : code, comptes, maquettes, documentation, déploiement, garantie et maintenance.
11. Organisation : décideur, interlocuteurs, disponibilité pour tester et circuit de validation.
12. Contraintes : échéance, dépendances, enveloppe ou scénarios de périmètre.

Ce que Doved Studio fait avec ce document

Je ne transforme pas votre première liste en devis automatique. Je vérifie le parcours principal, je relève les décisions qui changent l’architecture et je distingue le nécessaire de ce qui peut attendre. Vous recevez un périmètre que vous pouvez comprendre, tester et reprendre.

Vous gardez le code, les comptes et le produit. Si vous avez déjà un brief, même incomplet, envoyez-le à Doved Studio. Je vous dirai quelles réponses manquent avant de parler de construction.

Questions fréquentes

Faut-il dessiner tous les écrans avant de demander un devis ?

Non. Des croquis peuvent aider, mais un studio doit d’abord comprendre les utilisateurs, les parcours et les règles métier. Des écrans très détaillés peuvent masquer une décision de fond encore ouverte.

Quelle longueur doit faire le cahier des charges ?

Visez la clarté, pas un nombre de pages. Un document de cinq à quinze pages avec des annexes utiles suffit souvent pour lancer le cadrage d’un MVP. Les projets réglementés ou fortement intégrés demandent davantage de détail.

Peut-on commencer si certaines réponses manquent ?

Oui, si vous marquez les inconnues et prévoyez une phase de cadrage. Le risque vient des hypothèses invisibles, pas des questions ouvertes.