Cahier des charges application mobile : Contenu, étapes et erreurs à éviter
Un cahier des charges d’application mobile, on en reçoit de toutes les formes. Trois lignes dans un e-mail. Un PowerPoint de 40 slides. Un document de 80 pages qui détaille chaque écran mais oublie le back-office.
Je suis cheffe de projet chez TheCodingMachine, une agence qui développe des applications web et mobiles sur mesure depuis 2005. Je me suis aussi formée à la gestion de projet avec la méthode PMP. Les deux m’ont appris la même chose : un bon cahier des charges application mobile ne se juge pas à son nombre de pages, mais à sa capacité à éviter les mauvaises surprises.
Ce guide vous donne une méthode simple pour y arriver. Pour la rendre concrète, on va suivre un exemple tout au long de l’article : une entreprise de maintenance qui veut une application mobile pour ses techniciens terrain.
Pourquoi rédiger un cahier des charges pour votre application mobile ?
Le cahier des charges sert à trois choses : clarifier ce que vous voulez, parler le même langage que votre prestataire, et garder la main sur le budget.
Sans lui, chaque agence imagine une application différente. Vous recevez des devis de 30 000 € à 300 000 €, et vous ne savez pas lesquels comparer.
Définir clairement vos objectifs et attentes
Avant de décrire l’application, décrivez ce qu’elle doit changer.
Un objectif utile se mesure. « Digitaliser les interventions » ne dit rien. « Permettre aux techniciens de saisir leurs rapports sur le terrain, même sans réseau, et supprimer 100 % des ressaisies au bureau » dit tout.
Écrire le cahier des charges fait aussi remonter les désaccords. La direction, le marketing et les équipes terrain n’attendent pas toujours la même application. Mieux vaut le découvrir sur un document que pendant le développement.
Pensez aussi à tous ceux que le projet concerne, pas seulement aux utilisateurs : qui finance, qui valide, et qui sera touché sans utiliser l’application (le support, la comptabilité, la DSI). Une personne oubliée au début, c’est souvent une demande de changement à la fin.
Faciliter la communication avec votre prestataire
Le cahier des charges est le langage commun entre vous et votre prestataire de développement d’application mobile
Il évite les malentendus de vocabulaire. Un « compte », une « commande » ou une « intervention » n’ont pas le même sens pour tout le monde. Ajoutez un petit glossaire en annexe : dix lignes suffisent et évitent des semaines d’incompréhension.
Chez TCM, votre cahier des charges devient le point de départ de notre spécification de besoin. Chaque règle métier y reçoit un numéro : « RG12 : une intervention ne peut pas être clôturée sans signature du client ». Ce numéro suit la règle jusqu’au développement et jusqu’aux tests. Résultat : rien ne se perd en route.
Éviter les erreurs et maîtriser votre budget
Un cahier des charges précis donne un chiffrage fiable. Un chiffrage fiable évite les avenants.
Ce qui fait déraper un budget, c’est rarement l’écran oublié. Ce sont les règles implicites, les cas particuliers et les connexions avec vos outils existants, découverts en cours de route.
Retenez une règle simple : les fonctionnalités, le délai et le budget sont liés. Si l’un bouge, les autres bougent aussi. Ajouter une fonctionnalité sans toucher au budget ni au délai, c’est forcément rogner sur la qualité. Votre cahier des charges fixe l’équilibre de départ.
Les éléments essentiels d’un cahier des charges application mobile
Un cahier des charges application mobile complet tient en 8 parties : contexte, objectifs, utilisateurs, fonctionnalités, contraintes techniques, design, budget et planning, critères de validation.
Pas besoin d’être exhaustif partout. Le cœur du document, ce sont les fonctionnalités et les contraintes. Le reste peut tenir en une page par partie.
Présentation du contexte et des objectifs du projet
Le contexte explique pourquoi le projet existe. Les objectifs disent ce qu’il doit changer.
Présentez votre entreprise, vos utilisateurs, vos outils actuels et ce qui a déclenché le projet. Puis fixez 3 à 5 objectifs chiffrés.
Notre exemple : « Nos 45 techniciens remplissent des rapports papier, ressaisis le soir par deux assistantes. Nous perdons environ 15 % des rapports ou des photos. Objectifs : zéro ressaisie, rapport envoyé au client le jour même, 90 % des techniciens utilisateurs actifs après 3 mois. »
Écrivez aussi ce que vous supposez et ce qui vous est imposé. Une supposition, c’est ce que vous tenez pour vrai sans l’avoir vérifié (« tous les techniciens ont un smartphone professionnel »). Une contrainte, c’est ce qui ne se discute pas (« lancement avant la saison de chauffe en octobre »). Les écrire noir sur blanc permet au prestataire de les challenger.
Description des fonctionnalités attendues
Décrivez chaque fonctionnalité du point de vue de l’utilisateur, avec ses règles et sa priorité.
Le format le plus simple est la « user story » : En tant que [qui], je veux [quoi] afin de [pourquoi].
Notre exemple : « En tant que technicien, je veux prendre des photos de l’installation depuis l’application afin de les joindre à mon rapport. » Règles : 10 photos maximum, compressées automatiquement, envoyées dès que le réseau revient.
Pensez aussi aux fonctionnalités qu’on oublie toujours : création de compte, mot de passe oublié, notifications, consentements RGPD, suppression de compte (obligatoire sur les stores)… et surtout le back-office.
C’est l’oubli numéro un dans les cahiers des charges que nous recevons. Une application mobile a presque toujours besoin d’une interface d’administration, dans un navigateur (browser), pour gérer les contenus, les utilisateurs ou les statistiques.
Spécifications techniques et contraintes
Les spécifications techniques décrivent l’environnement de l’application. Pas besoin d’être technicien : il suffit de répondre à quelques questions.
- Sur quels appareils ? iOS, Android, tablettes ?
- Faut-il fonctionner hors connexion ?
- Avec quels outils communiquer ? ERP, CRM, paiement, logiciel métier ?
- Quelles fonctions du téléphone ? Photo, GPS, notifications, scan de QR code ?
- Quelles données sensibles ? Données personnelles, données de santé ?
- Combien d’utilisateurs, aujourd’hui et dans 3 ans ?
Notre exemple : Android et iOS, mode hors connexion indispensable (caves, sous-sols), synchronisation avec l’ERP, signature du client sur l’écran.
Pour détailler cette partie, voir notre guide pour rédiger des spécifications techniques.
Budget prévisionnel et délais de réalisation
Donnez une enveloppe budgétaire, même large. C’est le meilleur moyen d’obtenir des propositions comparables.
Beaucoup d’entreprises hésitent, de peur que le prestataire « remplisse » l’enveloppe. En réalité, c’est l’inverse : sans budget, chacun imagine une ambition différente. Avec une fourchette, on vous propose la meilleure application possible dans ce cadre.
Côté délai, indiquez la date de lancement souhaitée et ce qui la justifie. Et prévoyez la validation par Apple et Google : quelques jours en général, plus si l’application est refusée une première fois.
Comment rédiger votre cahier des charges étape par étape
Rédiger un cahier des charges application mobile se fait en 5 étapes : analyser l’existant, prioriser les fonctionnalités, préciser les contraintes, décrire les parcours utilisateurs, puis fixer le planning et le budget.
Étape 1 : Analyser l’existant et définir le besoin
Observez avant d’imaginer. Passez une journée avec les futurs utilisateurs. Regardez comment ils travaillent, ce qui les agace, ce qu’ils contournent.
Notre exemple : en suivant un technicien, on découvre qu’il n’a pas de réseau dans la moitié des caves. Cette seule observation change toute l’architecture de l’application.
Regardez aussi les applications concurrentes et leurs avis sur les stores. Les critiques des utilisateurs sont une mine d’or.
Étape 2 : Lister les fonctionnalités par ordre de priorité
Listez tout, puis triez en quatre catégories avec la méthode MoSCoW.
- Must : indispensable, l’application n’a pas de sens sans.
- Should : important, mais peut attendre quelques semaines.
- Could : bonus, si le budget le permet.
- Won’t : pas pour cette version (et c’est très bien de l’écrire).
Les « Must » forment votre première version. Ce tri est votre meilleur levier budgétaire : si le devis dépasse l’enveloppe, vous savez tout de suite quoi repousser.
La colonne « Won’t » est aussi importante que les autres : elle dit clairement ce qui n’est pas inclus, et évite les discussions plus tard.
Étape 3 : Préciser les contraintes techniques et les outils souhaités
Écrivez ce qui est imposé. Laissez ouvert ce qui ne l’est pas.
Si votre DSI impose une technologie, un hébergeur ou un outil de connexion d’entreprise, dites-le. Sinon, laissez le prestataire proposer : sa réponse vous dira beaucoup sur son expertise.
Le grand choix porte sur la façon de développer :
| Approche | En deux mots | Pour qui |
|---|---|---|
| Native | Une application par système | Besoins très poussés en performance |
| Cross-platform (Flutter, React Native) | Un seul code pour iOS et Android | La plupart des projets |
| PWA | Un site web installable | Usages simples, sans passer par les stores |
Pour trancher, lisez notre article quelle technologie d’application mobile choisir ?
Étape 4 : Définir les profils utilisateurs et leurs parcours
Décrivez qui utilise l’application, dans quelles conditions, et le chemin qu’il suit pour accomplir sa tâche.
Notre exemple : « Arnaud, 52 ans, technicien depuis 20 ans. Utilise son téléphone surtout pour appeler. Travaille souvent avec des gants, parfois dans le noir. » Avec ce portrait, tout le monde comprend qu’il faut de gros boutons, peu de saisie et une lampe torche accessible.
Puis racontez les parcours clés : « Arnaud ouvre sa tournée du jour, arrive chez le client, prend trois photos, remplit le rapport, fait signer le client. Le rapport part tout seul dès que le réseau revient. »
N’oubliez pas les profils internes : le responsable planning, l’assistante, l’administrateur. Ce sont eux qui utiliseront le back-office.
Étape 5 : Établir le planning et le budget
Découpez le projet en grandes phases et gardez une marge de 15 à 20 % pour les imprévus.
Une phase qu’on sous-estime toujours : votre propre temps. Ateliers, réponses aux questions, validation des maquettes, tests. Prévoyez une personne disponible quelques heures par semaine pendant tout le projet.
Pensez aussi à l’après : hébergement, comptes développeur Apple et Google, maintenance, mises à jour pour les nouvelles versions d’iOS et d’Android.
Les erreurs courantes à éviter dans votre cahier des charges
Quatre erreurs coûtent plus cher que toutes les autres : des fonctionnalités trop vagues, des contraintes techniques oubliées, un budget et un délai sous-estimés, et l’absence de critères de validation.
Être trop vague sur les fonctionnalités
« Un espace client » ou « une messagerie » ne suffisent pas. Une messagerie peut être un simple formulaire de contact, ou un chat en temps réel avec pièces jointes et notifications. Le prix n’est pas du tout le même.
Le bon test : si deux prestataires peuvent comprendre votre phrase de deux façons différentes, elle est trop vague.
Négliger les spécifications techniques
Les contraintes oubliées sont les plus chères à rattraper. Découvrir en cours de projet qu’il faut fonctionner hors connexion ou se brancher sur un vieil ERP peut remettre en cause toute l’architecture.
Ajoutez une courte section « risques ». Listez ce qui pourrait mal tourner : un ERP sans API, des utilisateurs réticents, une validation Apple incertaine. Pour chaque risque, une phrase sur ce que vous prévoyez. Cinq lignes suffisent, et votre prestataire verra tout de suite que vous avez réfléchi.
Sous-estimer les délais et le budget
Le développement n’est qu’une partie du projet. Conception, tests, validation des stores et disponibilité de vos équipes pèsent autant.
Méfiez-vous aussi de l’effet « tant qu’on y est ». Chaque petite demande ajoutée en cours de route semble anodine. Mises bout à bout, elles font dériver le projet. Le remède est simple : toute nouvelle demande passe par une évaluation de son impact avant d’être acceptée.
Oublier de définir les critères de validation
Sans critères de validation, personne ne peut dire si l’application est terminée.
Pour chaque fonctionnalité importante, écrivez comment vous la vérifierez. Notre exemple : « Un technicien sans réseau peut enregistrer un rapport avec photos. Au retour du réseau, le rapport arrive dans le back-office en moins de 5 minutes. »
Ces critères servent de base aux tests fonctionnels et à la recette.
Chez TCM, nous construisons un cahier de recette avec un onglet par module. Chaque ligne reprend un cas de test, le résultat attendu et le résultat obtenu. Quand les critères sont déjà dans le cahier des charges, ce travail va beaucoup plus vite.
Comment utiliser votre cahier des charges pour sélectionner la bonne agence de développement
Envoyez le même cahier des charges à 3 ou 4 prestataires, puis comparez leurs réponses sur la même grille. Freelance, ESN ou agence de développement sur-mesure : le cahier des charges est votre outil de comparaison.
Comparer les propositions techniques et commerciales
Ne comparez pas des prix. Comparez ce que chaque prix contient.
Posez-vous ces questions pour chaque devis :
- Le back-office, la recette et la publication sur les stores sont-ils inclus ?
- Quelles hypothèses le prestataire a-t-il prises là où vous étiez flou ?
- Forfait (prix fixe) ou régie (temps passé) ?
- Le code vous appartient-il, et sera-t-il sur votre propre dépôt ?
- Que se passe-t-il après la mise en ligne ?
Un devis beaucoup moins cher que les autres a souvent laissé une partie du travail de côté.
Évaluer l’expertise du prestataire sur votre technologie
Demandez à voir des applications comparables, publiées sur les stores, que vous pouvez télécharger. Parcourez les références des prestataires, et demandez à parler à un ancien client.
Vérifier la compréhension de vos objectifs métier
Un bon prestataire reformule votre besoin, pose des questions, et ose challenger certains choix.
Méfiez-vous d’une réponse qui recopie votre cahier des charges sans une seule question. Elle reprend aussi vos angles morts. Les meilleures propositions suggèrent parfois de retirer une fonctionnalité, ou de la faire autrement, avec un vrai argument métier.
Quand le besoin est encore flou, nous proposons souvent de commencer par une courte phase de cadrage : ateliers, spécification, maquettes et chiffrage détaillé. Vous repartez avec un cahier des charges complet.
Questions fréquentes sur le cahier des charges application mobile
Quelle longueur doit faire un cahier des charges application mobile ?
En général 10 à 30 pages. La précision compte plus que la longueur : 10 pages claires valent mieux que 60 pages de captures d’inspiration. Pour un premier échange avec un prestataire, 3 à 5 pages suffisent souvent.
Faut-il un cahier des charges différent pour iOS et Android ?
Non, un seul suffit. Il précise les systèmes visés et les éventuelles différences (paiement, notifications). Avec une technologie cross-platform comme Flutter ou React Native, un seul code sert les deux.
Peut-on modifier le cahier des charges en cours de projet ?
Oui, c’est même normal. Il faut juste encadrer les changements : chaque demande est évaluée (impact sur le délai, le budget, la qualité), puis acceptée ou reportée. En forfait, cela passe par un avenant. En agile, par la revue des priorités à chaque sprint.
Qui doit rédiger le cahier des charges : le client ou le prestataire ?
Le client exprime son besoin : contexte, objectifs, utilisateurs, fonctionnalités, budget. Le prestataire le complète avec les spécifications détaillées. Beaucoup d’entreprises confient cette rédaction à leur futur prestataire pendant une phase de conception.
Votre projet
Vous avez un cahier des charges, même incomplet ?
Envoyez-le nous. On le relit et on vous dit ce qu’il faut préciser avant de lancer quoi que ce soit.
Publié le 1 octobre 2026
