Cahier des charges application mobile : structure et exemple

Réponse courte

Un cahier des charges d'application mobile utile tient en 5 à 12 pages, pas en 50. Il doit décrire le contexte, les utilisateurs, les parcours clés, les fonctionnalités V1, les données, les intégrations et les contraintes (budget, délai, technique). Un cahier des charges trop long masque les vraies décisions et empêche les studios de te chiffrer correctement. Mieux vaut un document court mais clair qu'un pavé exhaustif qui laisse tout interprétable.

À quoi sert vraiment un cahier des charges

Un cahier des charges n'est pas une œuvre littéraire ni un livrable de prestige. C'est un outil opérationnel qui sert trois choses :

Aligner les prestataires sur le même périmètre pour obtenir des devis comparables.
Forcer le client à prendre des décisions avant que le code commence.
Servir de référence contractuelle pour cadrer ce qui est inclus et ce qui ne l'est pas.

Si ton cahier ne sert pas ces trois fonctions, il est inutile.

Le piège du cahier des charges trop long

Beaucoup d'entreprises font appel à un consultant qui produit un document de 80 pages avec sections "Architecture cible", "Vision stratégique", "Schéma fonctionnel détaillé niveau 4". Personne ne le lit en entier, ni le client, ni le prestataire.

Conséquence : les studios chiffrent au pifomètre, le projet démarre sur des malentendus, les avenants explosent. Le document long donne une fausse impression de rigueur.

Un cahier de 5 à 12 pages, lisible en 20 minutes, lu deux fois par le studio avant de chiffrer, vaut mieux qu'un document de 80 pages survolé en 5 minutes.

Structure recommandée pour un cahier utile

Section 1 : contexte et objectif (1 page)

Qui es-tu : entreprise, secteur, taille, stade (startup amorçage, PME établie, ETI).
Pourquoi tu fais cette app : quel problème elle résout, pour qui.
Quel est l'objectif business mesurable (acquisition, rétention, productivité interne, gain de temps mesurable).
Quelle est la concurrence directe ou indirecte (3 à 5 exemples).

Section 2 : utilisateurs cibles (0,5 à 1 page)

2 à 4 personas brièvement décrits : rôle, contexte d'usage, attentes, frictions actuelles.
Volumes attendus : combien d'utilisateurs en V1, dans 6 mois, dans 18 mois.

Section 3 : parcours utilisateurs principaux (1 à 2 pages)

Décris les 3 à 5 parcours principaux en étapes courtes, pas en spécifications.
Exemple : "Un client crée un compte → renseigne son besoin → reçoit 3 propositions → choisit, paie, attend la livraison → laisse un avis".
Si tu peux ajouter des wireframes Figma cliquables, le prestataire aimera beaucoup.

Section 4 : fonctionnalités V1 (1 à 2 pages)

Liste claire de ce qui est inclus en V1, structurée par module :

Authentification (email/mot de passe, Google, Apple).
Profil utilisateur (édition, photo, paramètres).
Module métier principal (le cœur de l'app, à décrire en 5 à 10 lignes).
Notifications push.
Back-office d'administration (si nécessaire en V1).

Pour chaque fonctionnalité, mentionne ce qui est explicitement HORS V1. Cette liste de "non-V1" est aussi précieuse que la liste V1.

Section 5 : données et intégrations (0,5 à 1 page)

Quelles données sont collectées, stockées, exposées.
RGPD : données personnelles, données sensibles, durée de conservation.
Intégrations tierces : Stripe, paiement, notifications, analytics, cartographie, services métier.
Sources de données existantes à reprendre (Airtable, base interne, autre app).

Section 6 : contraintes (0,5 page)

Budget cible (fourchette, pas nombre exact).
Délai cible et date d'évènement clé (lancement, salon, levée de fonds).
Contraintes techniques imposées (stack, hébergement, intégrations forcées).
Contraintes légales (mention CGU, agrément, certification HDS pour le médical).

Section 7 : critères de succès (0,5 page)

Comment tu mesureras si la V1 est un succès (KPI clairs).
À quoi ressemble une livraison "réussie" pour toi.
Quels sont les attendus de support et de maintenance après la V1.

Les 5 questions auxquelles un bon cahier répond

Si ton cahier n'apporte pas une réponse claire à ces 5 questions, retravaille-le avant de le diffuser :

Qui utilise cette app et pourquoi régulièrement ?
Quel est le parcours principal qui doit absolument fonctionner ?
Quelles sont les 3 à 5 fonctionnalités sans lesquelles l'app n'a aucun sens ?
Quel est le budget réel et la date limite ?
Qu'est-ce qui n'est explicitement PAS dans le périmètre V1 ?

Si tu ne sais pas répondre à la question 5, ton scope va déborder dès la première semaine.

Les erreurs fréquentes à éviter

Vouloir décrire le design dans le cahier. Le design se fait avec un designer, pas dans un Word. Décris les principes (clair, minimaliste, accessible), pas les couleurs précises et les écrans détaillés.

Lister 80 fonctionnalités sans hiérarchie. Si tout est "must have", rien ne l'est. Tri brutal : 5 à 10 en V1, le reste en backlog futur.

Imposer la stack sans raison. Si tu écris "stack obligatoire : Vue.js + MongoDB + Firebase" sans expertise tech derrière, tu vas écarter de bons prestataires pour rien.

Confondre cahier des charges et cahier de tests. Le cahier dit ce qu'on construit, pas comment on teste. Les critères d'acceptation viennent après, lors du cadrage avec le prestataire.

Écrire pour soi-même. Le cahier est lu par 3 à 5 prestataires différents. Écris pour eux, dans un langage qu'ils peuvent comprendre sans connaître ton entreprise.

Faut-il un cahier des charges avant de contacter un studio ?

Pas obligatoirement. Beaucoup de bons projets démarrent par un brief de 2 pages ou même par un appel d'1 heure, suivi d'une phase de cadrage payée avec le studio sélectionné.

Cette phase de cadrage produit elle-même le document de référence qui sert pour le développement. Elle coûte 1 à 3 k€ et fait gagner 2 à 3 semaines vs. écrire un cahier seul.

L'avantage de cadrer avec un studio : il pose les bonnes questions techniques que tu ne te poses pas en interne, et il chiffre précisément en sortie. L'inconvénient : tu te lies un peu plus avec le studio que tu cadres.

Comment on procède chez Inyka

Chez Inyka, la semaine 1 d'un projet est dédiée au cadrage strict, payée mais déductible si la mission continue. On produit un document de 8 à 12 pages avec parcours, écrans, scope V1 et scope hors-V1, intégrations, planning. À la fin de cette semaine, tu sais exactement ce que tu paies, pour quoi et pour quand.

Si tu préfères arriver avec un cahier déjà rédigé en interne, on l'utilise comme base et on l'enrichit. Si tu n'as rien, on construit ensemble.