Cahier des charges d’application mobile, août 2026
Page mise à jour le 24 août 2026
Le cahier des charges est le document le plus rentable de votre projet mobile : une journée passée à l’écrire économise des semaines d’allers-retours et des milliers d’euros d’avenants. Voici comment le rédiger section par section. Avec un modèle Word et une trame budget Excel à télécharger, gratuits et sans inscription.
Téléchargements directs : Modèle de cahier des charges (.docx). Les 12 sections pré-remplies de consignes · Trame de budget (.xlsx). Postes, fourchettes du marché et colonnes de chiffrage pour comparer les agences. Aucune inscription demandée.
À quoi sert vraiment un cahier des charges
Beaucoup de porteurs de projet le voient comme une formalité administrative. C’est une erreur de lecture : le cahier des charges est d’abord un outil de négociation et de comparaison. Sans lui, chaque agence chiffre un projet différent (celui qu’elle a imaginé à partir de votre brief oral) et les devis reçus vont du simple au triple sans que vous puissiez les départager. Avec lui :
- les agences chiffrent le même périmètre, et les écarts de prix deviennent significatifs ;
- les oublis coûteux (back-office, reprise de données, RGPD) sont traités avant la signature, pas en avenant ;
- vous disposez d’une référence écrite en cas de désaccord sur ce qui était prévu.
Inutile en revanche d’en faire un roman : 8 à 15 pages suffisent pour la plupart des projets. Un document trop long n’est pas lu ; un document trop précis techniquement enferme l’agence dans vos hypothèses au lieu de profiter de son expertise.
Les 12 sections indispensables
1. Présentation de l’entreprise et du projet
Une page pour situer le lecteur : votre activité, votre marché, et la raison d’être de l’application. Terminez par une phrase de vision : « Notre application permet à [cible] de [bénéfice] sans [friction actuelle] ». Si cette phrase est difficile à écrire, le projet n’est pas mûr.
2. Objectifs et indicateurs de succès
Trois à cinq objectifs chiffrés : utilisateurs actifs visés, taux de rétention, chiffre d’affaires, coûts évités. Ajoutez les non-objectifs (ce que le projet ne cherche pas à faire) pour verrouiller le périmètre.
3. Cibles et personas
Deux à quatre profils types : qui sont-ils, sur quel téléphone, dans quelle situation d’usage, à quelle fréquence ? Désignez le persona prioritaire : celui pour qui la V1 doit être excellente.
4. Périmètre fonctionnel
La section la plus importante. Listez chaque fonctionnalité sur une ligne et classez-la selon la méthode MoSCoW : Must (indispensable à la V1), Should (importante), Could (souhaitable), Won’t (explicitement exclue). Le MVP, c’est la colonne des Must. Et rien d’autre.
5. Parcours utilisateurs et écrans clés
Décrivez les trois à cinq parcours principaux, de l’ouverture de l’application à l’objectif atteint, et listez les écrans. Des croquis à main levée valent mieux que pas de croquis du tout. N’oubliez pas les cas limites : sans réseau, sans compte, panier vide.
6. Spécifications techniques
Posez vos contraintes (plateformes visées, intégrations avec l’existant, hébergement imposé) sans trancher ce que vous ne maîtrisez pas. « Technologie : à recommander par le prestataire, choix argumenté attendu » est une réponse parfaitement valable. Souvent la meilleure.
7. Design et charte graphique
Ce qui existe (logo, couleurs, typographies), ce qui reste à créer, et trois applications que vous admirez avec la raison de cette admiration. Précisez le niveau d’exigence : design entièrement sur mesure ou composants standards personnalisés.
8. Contenus et données
Qui fournit les textes, photos et traductions ? Quelles données existantes faut-il reprendre (volume, format, qualité) ? Quelles données personnelles seront collectées, pour quelles finalités ? Le RGPD se traite ici, pas après la mise en production.
9. Back-office et administration
La partie immergée de l’iceberg, souvent 30 à 40 % du budget : qui administre les utilisateurs, les contenus, les commandes ? Quels tableaux de bord, quels rôles et permissions, quels exports ? Un cahier des charges qui décrit seulement l’application visible sera systématiquement sous-chiffré.
10. Contraintes légales et sécurité
Exigences sectorielles (santé, finance, mineurs), authentification, chiffrement. Et la clause qui ne se négocie pas : la propriété du code livré. Elle doit être cédée en totalité, avec remise du dépôt Git.
11. Budget et planning
Annoncez votre enveloppe en fourchette. Contrairement à l’intuition, cacher son budget n’obtient pas de meilleurs prix : cela produit des devis incomparables, calibrés sur des périmètres devinés. Précisez aussi la date de mise en service souhaitée et le budget de maintenance envisagé (15 à 20 % du budget initial par an. Voir notre guide des prix).
12. Modalités de consultation et critères de choix
Date limite de réponse, format attendu (devis par postes, équipe nommée, références comparables) et critères de sélection pondérés. Des agences qui savent comment elles seront jugées répondent mieux. Et celles qui ne répondent pas au format demandé vous renseignent aussi.
Les pièges classiques du cahier des charges
- Tout mettre en priorité 1. Si tout est indispensable, rien ne l’est : le chiffrage explose et le MVP disparaît. La discipline MoSCoW est votre meilleur outil d’économie.
- Spécifier la solution au lieu du besoin. « Un bouton bleu en haut à droite qui ouvre une popup » enferme l’agence. Décrivez le besoin (« l’utilisateur doit pouvoir recommander sa dernière commande en moins de 10 secondes ») et laissez les experts concevoir.
- Oublier le back-office. Le premier poste de sous-chiffrage. Si personne ne peut administrer l’application, elle est inutilisable dès la première semaine.
- Ignorer la reprise de données. Migrer une base clients ou un catalogue se chiffre en jours, parfois en semaines. Mentionnez volume et format.
- Ne rien dire du budget. Vous recevrez des propositions de 20 000 € et de 150 000 € pour le même document, et aucune ne sera comparable.
- Figer le document. Un cahier des charges est une base de discussion : les bonnes agences le challengeront. Celle qui le prend tel quel sans une seule question est celle qui vous facturera des avenants.
Comment utiliser le modèle
Le modèle .docx reprend les 12 sections ci-dessus, chacune avec ses consignes et ses points à renseigner : remplacez les consignes par vos réponses, supprimez ce qui ne s’applique pas. La trame budget .xlsx liste les postes standards d’un projet mobile avec les fourchettes du marché français et deux colonnes vides pour reporter les devis reçus : les totaux et le coût de possession sur trois ans se calculent seuls.
Une fois vos devis reçus, poursuivez avec notre guide « Comment lire un devis d’application mobile » et sa grille comparative.
Questions fréquentes sur le cahier des charges
Quelle longueur pour un cahier des charges d’application mobile ?
De 8 à 15 pages pour la plupart des projets. En dessous, les agences devinent ; au-delà, elles survolent. La précision doit porter sur le périmètre fonctionnel et les priorités, pas sur les détails d’implémentation.
Faut-il maîtriser la technique pour le rédiger ?
Non. Votre travail est de décrire le besoin, les utilisateurs et les contraintes. Les choix techniques (natif, Flutter, architecture serveur) sont précisément ce que vous achetez à une agence. Posez des questions, exigez des choix argumentés, ne les faites pas à leur place.
Dois-je indiquer mon budget dans le cahier des charges ?
Oui, en fourchette. C’est le seul moyen d’obtenir des réponses calibrées sur un périmètre réaliste et comparables entre elles. Une agence sérieuse vous dira ce qui rentre dans l’enveloppe et ce qui doit attendre la V2.
Un cahier des charges m’engage-t-il juridiquement ?
Le document lui-même n’est pas un contrat, mais il est généralement annexé au contrat de prestation et fait alors référence en cas de litige sur le périmètre. Raison de plus pour y écrire les exclusions aussi clairement que les inclusions.
Puis-je envoyer le même document à plusieurs agences ?
C’est exactement son rôle. Consultez deux à quatre agences avec le même cahier des charges et le même calendrier de réponse : vous obtiendrez des propositions comparables et une vraie base de négociation.
Le modèle est-il vraiment gratuit ?
Oui : téléchargement direct, sans inscription ni e-mail. Mettre de bons outils entre les mains des porteurs de projet, c’est la raison d’être de ce guide.
Besoin d’un regard expert sur votre cahier des charges ?
Notre équipe technique relit volontiers votre document et vous dit franchement ce qui manque, lors d’un échange gratuit de 30 minutes :
Réserver une consultation technique gratuite
Ou directement par téléphone : +33 6 32 64 24 80
Écran par écran : ce qu’il faut écrire, pas ce qu’il faut copier
Un cahier des charges faible décrit une intention (« une app de rendez-vous »). Un cahier des charges utile décrit des écrans et des règles. Ci-dessous, quatre captures des fiches App Store. C’est le matériau que vous enverrez à une agence pour qu’elle chiffre le même projet que vous : le flux, pas le dégradé.
1. Recherche + carte + filtres (Doctolib)
Cet écran n’est pas « une carte ». C’est un système de matching. Dans le CDC, une ligne par règle :
- Requête. Texte libre, spécialité, nom du praticien, ou les trois ? Autocomplete ? Combien de caractères avant de lancer la recherche ?
- Carte. Fond (Apple Plans, Google, Mapbox), clustering des pastilles, zoom par défaut, géolocalisation de l’utilisateur (permission iOS/Android, repli si refus).
- Filtres. Chaque filtre est un champ : disponibilité (créneau, jour, « aujourd’hui »), honoraires (secteur 1 / 2), motif de consultation. Ce qui n’est pas listé n’existera pas en V1.
- Fiche résultat. Photo, nom, spécialité, distance, prochain créneau. Qui fournit la photo ? Droit à l’image du professionnel ?
- Volume. « 120 résultats » implique pagination, performance, et un index. Si votre base fait 12 fiches, cet écran est trop cher. Si elle en fait 12 000, il est indispensable.
Le piège : chiffrer « une map » à deux jours. La map, ici, est le produit. Comptez plutôt conception + API + cache + états vides (aucun praticien, hors zone, hors horaires).
2. Accueil + téléconsultation (Doctolib, autre capture)
Dès qu’il y a de la vidéo, le CDC change de catégorie. Il faut écrire, noir sur blanc :
- qui est dans l’appel (patient, praticien, éventuellement un tiers) ;
- WebRTC maison ou prestataire (et donc sous-traitant RGPD, DPA, hébergement UE, HDS si données de santé) ;
- permissions caméra / micro, et le repli si elles sont refusées ;
- compte rendu après l’appel : stocké où, combien de temps, qui y a accès.
Une application de rendez-vous sans vidéo et une application de téléconsultation n’ont pas le même palier de prix. Le guide national reste le même : MVP 15 000 à 40 000 € HT, projet moyen 40 000 à 120 000 €, complexe 120 000 à 300 000 €. La vidéo, le matching et le dossier patient poussent presque toujours vers le palier complexe.
3. Destination, carte, adresses mémorisées (Uber)
Cet écran a l’air simple. Il cache cinq systèmes. Le CDC doit les nommer, sinon le devis les oublie :
- Compte. « Bonjour, Antoine » : inscription, session, oubli de mot de passe, suppression de compte (droit RGPD).
- Géolocalisation temps réel. Permission, précision, batterie, que faire si le GPS saute dans un tunnel.
- Autocomplete d’adresse. Prestataire (Places, Ban, etc.), coût à la requête, pays couverts.
- Adresses favorites. CRUD, libellés, ordre. Anodin, toujours demandé en recette.
- Deuxième face. Cet écran est le client. Le chauffeur a le miroir : course proposée, navigation, paiement. Un CDC « type Uber » qui n’écrit que le client est un CDC à moitié.
Méthode Hooked appliquée ici : on ne demande pas « faites comme Uber ». On découpe le flux (déclencheur → action « où allez-vous » → récompense variable du devis → investissement des adresses). Chaque flèche est une exigence, un écran, un critère d’acceptation.
4. Leçon, vies, progression (Duolingo)
Les applications « éducatives » meurent sur le contenu, pas sur le bouton Continuer. Le CDC doit dire :
- qui écrit les items (vous, un prestataire, un import) et dans quel format ;
- combien d’items à la V1 (50, 500, 5 000) : ça change le back-office ;
- ce que sont les cœurs : cosmétique, ou un paywall quand ils tombent à zéro ;
- notifications de streak : fuseau, heure, désinscription, et la base légale RGPD (intérêt légitime ou consentement).
5. Prompts de profil (Tinder)
Toute application où un humain en voit un autre exige, dans le CDC, une section modération : qui signale, qui traite, délai, conservation des preuves, bannissement. Apple et Google la demandent à la soumission. Si elle n’est pas dans le CDC, elle arrive en avenant, juste avant le passage store.
Tableau : écran vu → ligne de CDC → piège de devis
| Écran | Ce que le CDC écrit | Ce que le devis sous-chiffre |
|---|---|---|
| Carte + 120 résultats | Moteur de recherche, index, filtres, pagination, états vides | « Une map », deux jours |
| Appel vidéo | WebRTC ou prestataire, HDS le cas échéant, permissions, compte rendu | Un bouton caméra |
| Où allez-vous ? | Deux faces, GPS, autocomplete, courses, paiement, litige | Un champ d’adresse |
| Leçon + cœurs | Catalogue, back-office, économie virtuelle, IAP, notifs | Trois écrans de quiz |
| Prompts de profil | Modération, âge, signalement, CGU stores | Un formulaire d’inscription |
Comment on travaille ces captures, comme sur nos tutoriels
Les articles du guide (publication App Store, ASO, Android 17) sont construits de la même façon : une capture réelle, une traduction en décisions. Ici, les fiches stores. On garde le flux, on écrit l’exigence, on indique le piège de chiffrage.
Pour un type d’application précis (VTC, rencontre, leçons, marketplace), ouvrez les modèles par analogie : chaque page reprend les modules, la fourchette du guide des prix, et les captures de la fiche store quand elles existent.
Ensuite, envoyez le même Word à deux ou quatre agences, comparez avec la grille de lecture des devis, et gardez un créneau de 30 minutes si un avis technique vous fait gagner une semaine d’allers-retours.