Cahier des charges application mobile : modèle 2026 + exemple complet

Réponse rapide : Un cahier des charges d’application mobile doit contenir 11 sections obligatoires : contexte business, personas, fonctionnalités must-have, nice-to-have, stack technique, intégrations tierces, contraintes légales, volumétrie, calendrier, budget et KPIs. Format idéal : 12 à 20 pages structurées. C’est l’outil qui permet à 3 agences de chiffrer le même périmètre.

Un cahier des charges clair décide du succès ou de l’échec de votre application mobile. En 2021, une étude IPS sur 5 000 projets digitaux échoués a révélé que 39 % des échecs venaient d’une mauvaise définition des attentes, souvent à cause d’un cahier des charges incomplet. Cet article vous donne le modèle exact que nous utilisons chez Tikup pour cadrer chaque projet, avec les 11 sections obligatoires, les exemples concrets de formulations, et les 6 erreurs les plus coûteuses à éviter. Tout est réutilisable, copiable, exploitable, sans inscription.

Qu’est-ce qu’un cahier des charges d’application mobile ?

Un cahier des charges n’est pas un document de bureaucrate. C’est l’outil qui permet à 3 agences de vous chiffrer le même périmètre, donc de comparer des pommes avec des pommes. Sans cahier, chaque agence va imaginer son propre périmètre, son propre tarif, et vous n’aurez aucun moyen de savoir si le devis à 22 k€ est meilleur que celui à 65 k€. Voir notre article complet sur comment choisir une agence de développement web.

39 %des projets digitaux échouent à cause d’un cahier des charges incompletSource : Étude IPS sur 5 000 projets, 2021

Les 11 sections obligatoires d’un cahier des charges app mobile

1. Contexte et objectif business

Décrivez en 5 phrases : votre entreprise, le problème que vous résolvez, le résultat business attendu (chiffre d’affaires, leads, gain de temps). C’est ce qui permet à l’agence de proposer la meilleure solution, pas juste celle que vous avez imaginée.

2. Personas et parcours utilisateur

Listez 2-3 personas avec : démographie, contexte d’usage (où, quand, comment), motivation, frein. Décrivez le parcours type en 5-8 étapes. Sans ça, l’agence va designer pour un utilisateur fantôme.

3. Fonctionnalités obligatoires (must-have)

Listez les features sans lesquelles l’app n’a pas de sens. Pour une marketplace : auth, profil, recherche, paiement, messagerie. Maximum 10 must-have. Au-delà, vous mélangez MVP et roadmap (voir notre article MVP vs produit fini).

4. Fonctionnalités souhaitées (nice-to-have)

Les features qui ajoutent de la valeur sans être bloquantes : push notifications, partage social, mode sombre. L’agence chiffrera séparément ces blocs, et vous pourrez les sacrifier si le budget serre.

5. Stack technique imposée ou libre

Si vous avez déjà un back-end Node.js, dites-le. Si vous voulez React Native pour pouvoir reprendre la main, dites-le. Si vous n’avez aucune contrainte, dites-le aussi — c’est utile à savoir. Notre comparatif React Native vs Flutter vs natif aide à trancher.

6. Intégrations tierces

Stripe, Mailchimp, HubSpot, Sentry, Amplitude, Algolia, etc. Chaque intégration coûte 1-3 jours-homme. Ne pas les lister fausse le devis.

7. Contraintes légales et réglementaires

RGPD, accessibilité RGAA (obligatoire pour le secteur public), DSP2 si paiement, HDS si données de santé. Une contrainte oubliée peut multiplier le coût final par 2.

8. Volumétrie et performances attendues

Combien d’utilisateurs simultanés ? Combien de transactions/jour ? Quel temps de chargement maximum acceptable ? Une app à 100 utilisateurs/mois et une app à 100 000 ne sont pas la même architecture.

9. Calendrier souhaité

Date de mise en ligne idéale et dates intermédiaires si vous avez un événement (salon, lancement produit). Plus c’est précis, plus l’agence pourra planifier ses ressources.

10. Budget

Donnez une fourchette honnête (« entre 30 k€ et 50 k€ »). Cacher le budget pousse les agences à faire des propales génériques, et vous fait perdre du temps si elles sont hors de portée. Pour caler la fourchette, lire Combien coûte une application mobile.

11. Critères de succès et KPIs

Comment saurez-vous que le projet est réussi ? 1 000 téléchargements en 3 mois ? Note 4,5+ sur App Store ? 20 % de conversion sur le parcours d’achat ? Sans KPI, vous ne pourrez ni récompenser une bonne livraison ni en réclamer une meilleure.

Exemple concret : section « Fonctionnalités must-have » bien rédigée

## 3. Fonctionnalités obligatoires (must-have)

### Authentification
- Inscription email + mot de passe
- Connexion via Google et Apple ID
- Récupération de mot de passe par email
- Suppression de compte conforme RGPD

### Profil utilisateur
- Édition photo, nom, prénom, ville
- Vérification numéro de téléphone par SMS
- Historique des transactions consultable

### Recherche prestataire
- Filtres : zone géo, prix, note, disponibilité
- Carte interactive avec pins
- Tri par pertinence, prix, distance

### Réservation et paiement
- Stripe Payment Intent avec séquestre 48h
- Annulation gratuite jusqu'à H-24
- Reçu PDF envoyé par email

### Messagerie
- Chat 1-1 chiffré end-to-end
- Notifications push sur nouveau message
- Signalement de message inapproprié

Les 6 erreurs qui coûtent cher

1. Listing « toutes les features possibles » : un cahier de 80 features coûte 250 k€ à chiffrer correctement. Filtrez à 10-15 must-have max pour le MVP.
2. Pas de KPI : sans critère de succès, vous ne pourrez pas refuser une livraison médiocre ni valider une livraison excellente.
3. Stack imposée pour le mauvais motif : « je veux du React Native parce que c’est moderne » ≠ « je veux du React Native parce que mon équipe peut le maintenir après ».
4. Budget caché : vous recevrez 5 devis dont 4 hors de portée. Perte de temps assurée.
5. Pas de personas : l’agence va designer une app générique. Vous découvrirez à la livraison qu’elle ne correspond pas à votre cible.
6. Document de 80 pages : personne ne le lira. Cahier idéal = 12-20 pages, structuré, scannable.

Modèle de cahier des charges téléchargeable

Format et structure recommandés

Le format optimal du cahier des charges est un document Markdown ou Notion partageable. Pourquoi pas Word :

• Les agences se réfèrent au document plusieurs fois pendant le projet — Markdown se lit dans tout éditeur
• Les mises à jour sont traçables (Git, historique Notion)
• Les liens internes (entre sections) sont natifs
• L’export PDF reste possible pour les annexes contractuelles

À retenir

• Un cahier des charges idéal fait 12-20 pages, structuré en 11 sections obligatoires. Au-delà personne ne le lit, en-dessous vous manquez de précision.
• 39 % des projets digitaux échouent à cause d’un cahier des charges incomplet (étude IPS 2021 sur 5 000 projets).
• Donnez toujours une fourchette budget honnête. Cacher le budget = 4 devis sur 5 hors de portée + perte de temps assurée.
• Listez 10 must-have maximum. Au-delà vous mélangez MVP et roadmap, le devis explose à 250 k€+.
• Sans KPI mesurables, vous ne pourrez ni refuser une livraison médiocre ni valider une excellente. Fixez 3-5 critères chiffrés dès le début.
• Format Markdown ou Notion partageable bat Word : versioning Git, liens internes natifs, lisible dans tout éditeur.

Questions fréquentes

Combien de pages doit faire un cahier des charges d’application mobile idéal ?

12 à 20 pages pour un projet de 30 à 100 k€. En dessous, vous manquez de précision. Au-dessus, personne ne le lit. La règle : chaque page doit pouvoir être contestée et défendue. Si une section ne contient pas d’information actionnable, supprimez-la. Le cahier sert à briefer, pas à impressionner.

Peut-on faire chiffrer un projet d’application sans cahier des charges ?

Oui, mais le chiffrage sera très approximatif (±60 %). C’est utile pour savoir si vous êtes dans la fourchette « 10 k€ », « 50 k€ » ou « 200 k€ ». Pour un devis signable, le cahier est indispensable. Chez Tikup, on le rédige avec vous gratuitement pendant la phase de cadrage (sous 48 h après l’appel découverte).

Faut-il faire signer un NDA avant d’envoyer son cahier des charges ?

Si votre projet contient une idée vraiment nouvelle (rare en réalité), oui. La plupart des agences signent un NDA mutuel sous 1 h ouvrée sur demande. Dans 95 % des cas, votre cahier décrit une solution à un problème connu, pas une innovation brevetable — le NDA est plus rassurant que vraiment protecteur.

Quelles sont les 11 sections obligatoires d’un cahier des charges d’app ?

Les 11 sections : 1) contexte business, 2) personas et parcours, 3) fonctionnalités must-have, 4) fonctionnalités nice-to-have, 5) stack technique imposée ou libre, 6) intégrations tierces, 7) contraintes légales (RGPD, RGAA, DSP2, HDS), 8) volumétrie et performances, 9) calendrier daté, 10) budget en fourchette honnête, 11) KPIs de succès mesurables.

Quelle différence entre cahier des charges fonctionnel et technique ?

Le cahier fonctionnel décrit le QUOI (ce que l’app doit faire, vu utilisateur) et est rédigé par le client. Le cahier technique décrit le COMMENT (architecture, base de données, API, sécurité) et est rédigé par l’agence après le cadrage. Pour un MVP, seul le cahier fonctionnel est nécessaire au début. Le technique est livré par l’agence dans sa proposition.

Comment rédiger un cahier des charges quand on n’est pas technique ?

Écrivez en langage métier, jamais en jargon technique. Décrivez ce qu’un utilisateur doit pouvoir faire (« un parent doit pouvoir réserver une nounou pour 3 heures dans un rayon de 5 km »), pas comment l’app doit le faire techniquement. L’agence traduira en spec technique. Un bon cahier fonctionnel se lit comme une nouvelle, pas comme un manuel d’API.

Glossaire

• Persona : Profil-type d’un utilisateur cible décrit avec démographie, contexte d’usage, motivation et frein. Tikup recommande 2-3 personas par projet, jamais plus.
• Must-have / Nice-to-have : Classement des fonctionnalités par criticité. Must-have = sans elles l’app n’a pas de sens (max 10). Nice-to-have = ajoutent de la valeur sans bloquer.
• RGPD : Règlement Général sur la Protection des Données. Obligatoire pour toute app collectant des données personnelles d’utilisateurs UE. Inclut droit à l’oubli, portabilité, consentement explicite.
• RGAA : Référentiel Général d’Amélioration de l’Accessibilité. Obligatoire pour le secteur public et les entreprises > 250 salariés sur leur service en ligne.
• DSP2 : Directive sur les Services de Paiement 2. Impose l’authentification forte (3-D Secure 2) pour tout paiement en ligne dans l’UE depuis 2021.
• HDS : Hébergement de Données de Santé. Certification française obligatoire pour héberger des données médicales. Coût certification : 40-80 k€, à anticiper si applicable.
• Volumétrie : Nombre d’utilisateurs simultanés et de transactions par jour anticipés. 100 vs 100 000 utilisateurs ne sont pas la même architecture (et pas le même prix).

Sources

• Conformité RGPD, mode d’emploi — CNIL
• RGAA · Référentiel accessibilité — DINUM
• Guides France Num pour la digitalisation — France Num
• Cahier des charges fonctionnel, méthode Bpifrance — Bpifrance
• Les TIC dans les entreprises françaises — INSEE
• Stripe Atlas, business of SaaS — Stripe Press

Ressources liées

• Combien coûte une application mobile — caler la fourchette budget
• comment choisir une agence de développement web — 12 critères de sélection
• MVP vs produit fini — filtrer les must-have
• React Native vs Flutter vs natif — choix de stack mobile
• services Tikup — tarifs publics par prestation
• notre méthode de cadrage — phase de brief 48 h
• brief 30 min offert — cahier inclus dans les livrables