Cahier des charges application mobile : modèle PDF + guide

Un cahier des charges application mobile, c’est le document qui sépare les projets qui aboutissent de ceux qui explosent en vol. Pas un PDF de 80 pages que personne ne lit. Un document clair qui dit ce que ton app doit faire, pour qui, avec quel budget et dans quel délai.

Le problème : la majorité des fondateurs non techniques rédigent un cahier des charges trop vague ou trop ambitieux. Résultat - le même projet est chiffré entre 20 000 et 60 000 EUR selon le prestataire contacté. Personne ne sait ce qui est inclus. Les spécifications fonctionnelles manquent. Le périmètre fonctionnel est flou. Et quand ça tourne mal, il n’y a rien de solide pour se retourner.

Ce guide te donne la structure exacte d’un bon modèle de cahier des charges, les erreurs qui coûtent le plus cher, la protection juridique que personne ne mentionne, et la version allégée qui cadre vraiment un MVP sans te noyer sous la paperasse.

C’est quoi un cahier des charges application mobile

Un cahier des charges application mobile est le document qui décrit ce que ton app doit faire, pour qui, avec quel budget et dans quel délai. Il sert de référence contractuelle entre toi et le prestataire qui développe. Le porteur de projet le rédige, avec ou sans accompagnement, parce que le besoin vient de toi et pas du développeur.

Il se découpe en deux niveaux. Le cahier des charges fonctionnel décrit le quoi : les fonctionnalités, les parcours, les utilisateurs. Le cahier des charges technique décrit le comment : la stack, les intégrations, l’hébergement. Pour un projet simple, les deux tiennent dans le même document.

La longueur n’a rien d’absolu. Une application complexe avec des intégrations multiples peut demander 30 pages. Un MVP avec 5 fonctionnalités tient en 10 à 15 pages. La précision compte plus que le volume.

Que doit contenir un cahier des charges application mobile

Un cahier des charges application mobile contient dix sections : présentation, objectifs business, cible, périmètre, parcours utilisateur, spécifications techniques, charte graphique, planning, budget et critères de recette. Le tableau d’abord, les détails ensuite.

Le piège du cahier des charges vague

Écrire “l’application doit gérer les rendez-vous” dans un cahier des charges, c’est ouvrir la porte à toutes les interprétations. Combien de types de rendez-vous ? Rappels automatiques ? Synchronisation calendrier ? Annulation en ligne ? Chaque mot interprété différemment au départ devient un écart de milliers d’euros à l’arrivée.

La bonne formulation utilise des user stories : “En tant que patient, je veux réserver un créneau disponible chez mon médecin pour éviter d’appeler le cabinet.” C’est précis. C’est testable. C’est chiffrable.

Une application de prise de rendez-vous peut avoir 8 écrans et 12 clics pour réserver. Ou 3 écrans et 4 clics. Sans wireframes dans le cahier des charges, tu ne sais pas ce que tu achètes.

La méthode MoSCoW pour prioriser

Un restaurateur qui demande 35 fonctionnalités (menu dynamique, réservation, fidélité, livraison, chat avec le chef, réalité augmentée) pour un budget de 15 000 EUR, c’est un projet mort-né. Le piège le plus courant est de vouloir tout faire en V1, le mécanisme exact de la dérive du périmètre qui fait exploser les budgets.

La méthode MoSCoW trie chaque fonctionnalité en 4 catégories :

• Must have : sans ça, l’app ne sert à rien (V1)
• Should have : important mais pas bloquant (V1 si budget le permet)
• Could have : confort, pas prioritaire (V2)
• Won’t have : hors périmètre (jamais ou V3+)

Un MVP solide, c’est 5 à 8 fonctionnalités Must have pour définir ton MVP. Pas 35.

Les erreurs qui coûtent le plus cher

Les projets d’application dépassent leur budget dans 60 % des cas, selon OpenForge. La cause numéro un n’est pas technique : c’est un cahier des charges inexistant ou bâclé. Le Standish Group (CHAOS Report) mesure que seulement 31 % des projets IT sont livrés dans les temps et le budget. McKinsey et l’Université d’Oxford, sur 5 400 projets, relèvent un dépassement moyen de 45 % sur les grands projets. Et le PMI confirme : 47 % des échecs sont liés à une mauvaise gestion des exigences.

Ces chiffres ne sont pas une fatalité. Ils sont le résultat de cahiers des charges bâclés.

L’app livrée que personne n’utilise

Une application livrée à 40 000 EUR avec 12 téléchargements en 3 mois. Zéro stratégie de lancement prévue dans le cahier des charges. Le développement a mangé 100 % du budget. Il ne reste rien pour l’acquisition utilisateur.

Le cahier des charges classique s’arrête à la livraison. C’est une erreur. Il doit inclure une section post-lancement : budget ASO (App Store Optimization), page de destination, stratégie d’acquisition. Sinon tu construis un produit que personne ne découvre.

Le double paiement

Une application payée 8 000 EUR qui crashe une fois sur deux. Coût de reprise : presque autant que le budget initial. Pas de phase de test prévue dans le cahier des charges. Pas de critères de recette. Le prestataire a livré “ce qui était demandé” - et techniquement, il a raison.

La maintenance applicative est un autre angle mort. Sans contrat de maintenance, une app qui fonctionne en 2024 peut être inutilisable en 2026. Le coût de maintenance annuel se situe entre 15 et 20 % du budget initial. Sur une app à 40 000 EUR, c’est 6 000 à 8 000 EUR par an. Cher ? Moins qu’une mise à niveau d’urgence parce que l’app n’a pas été maintenue pendant deux ans.

Le tabou du budget

Sans indication budgétaire dans le cahier des charges, un même projet peut être chiffré à 20 000 EUR par une agence et à 60 000 EUR par une autre. Le prestataire ne sait pas si tu attends un MVP à 10 000 EUR ou une plateforme à 80 000 EUR. Il propose ce qu’il sait faire, pas ce dont tu as besoin. Un changement de périmètre en cours de route alourdit la facture de jusqu’à 50 %, selon les analyses du secteur.

Indiquer une fourchette dans le cahier des charges, c’est contre-intuitif. Beaucoup de fondateurs ont peur de montrer leur jeu. En réalité, ça filtre les prestataires non adaptés et ça force des propositions réalistes. Pour les fourchettes par type de projet, lis combien coûte un MVP en 2026.

La protection juridique que personne ne mentionne

Aucun article concurrent ne parle de jurisprudence. C’est pourtant l’argument le plus solide pour prendre le cahier des charges au sérieux.

La jurisprudence Oopet - agile sans cahier des charges

En 2020, la startup Oopet confie le développement de deux applications à un prestataire en méthode agile. Pas de cahier des charges. Quand les problèmes apparaissent, Oopet demande le remboursement.

Le tribunal de commerce de Paris rejette la demande (8ème chambre, 7 octobre 2020). Motif : en méthode agile, “le développement se construit au fur et à mesure”. Sans document de référence décrivant le résultat attendu, impossible de prouver que le prestataire n’a pas rempli ses obligations.

Le principe va plus loin. En choisissant la méthode agile sans expression écrite des besoins, le client récupère sur ses épaules une partie de la responsabilité qui pèse normalement sur le prestataire, comme l’analysent les avocats spécialisés en droit du numérique. Le cahier des charges n’est pas un frein à l’agilité - c’est ton filet de sécurité.

La jurisprudence Fédération Française de Bridge

La Fédération Française de Bridge commande un logiciel de résultats de tournois sur tablettes. Le prestataire, qui a rédigé le protocole d’accord, ne précise pas qui est responsable de la rédaction du cahier des charges. Résultat : retard majeur, projet en échec.

La Cour d’appel de Versailles (14 janvier 2021) ordonne la résolution du contrat aux torts du prestataire. Motif : le prestataire a une obligation de conseil. Il aurait dû guider le client non technique dans la rédaction du cahier des charges.

Ce que ça change pour ton projet

Les collaborations avec des développeurs freelances se terminent souvent en conflit. Délais non respectés, livrables incomplets, acomptes perdus. Le cahier des charges est ta meilleure protection :

• Il décrit précisément ce qui doit être livré
• Il fixe les jalons de paiement liés à des livrables vérifiables
• Il constitue la pièce maîtresse en cas de litige

Sans cahier des charges, c’est ta parole contre celle du prestataire. Avec, c’est un document contractuel qui a valeur de preuve. Pour mesurer les risques selon le type de prestataire, lis le comparatif agence ou freelance pour ton MVP.

Comment rédiger ton cahier des charges étape par étape

Rédiger un cahier des charges suit quatre étapes : cadrer le besoin, écrire les user stories, dessiner les wireframes, fixer les contraintes techniques et le budget. L’ordre compte autant que le contenu.

Attendre le bon moment

Ne rédige pas ton cahier des charges trop tôt. Si tu n’as pas encore 70 % de clarté sur ton besoin, tu vas écrire un document flou qui génère des devis flous. Commence par :

1. Valider que le problème existe (parle à 10 utilisateurs potentiels)
2. Lister toutes les fonctionnalités imaginées
3. Les trier avec MoSCoW
4. Dessiner les parcours utilisateurs principaux sur papier

Une fois que tu sais ce que ton app doit faire et pour qui, tu es prêt à rédiger.

Écrire les user stories

Chaque fonctionnalité du cahier des charges se décrit avec une user story :

“En tant que [rôle], je veux [action] afin de [bénéfice].”

Exemples concrets :

• “En tant que livreur, je veux scanner un QR code pour confirmer la livraison sans saisie manuelle.”
• “En tant qu’admin, je veux exporter les commandes en CSV pour les intégrer dans ma comptabilité.”
• “En tant qu’utilisateur, je veux me connecter avec Google pour éviter de créer un mot de passe.”

Ce format force la précision. “Gérer les commandes” devient 5 à 10 user stories distinctes, chacune chiffrable indépendamment.

Inclure les wireframes

Les wireframes ne sont pas des maquettes finales. Ce sont des schémas écran par écran qui montrent l’organisation des éléments. Tu peux les dessiner sur papier, avec Figma ou avec un outil gratuit comme Excalidraw.

Leur rôle dans le cahier des charges : éviter les interprétations. Un wireframe qui montre 3 écrans et 4 clics pour réserver un rendez-vous est plus clair que 2 pages de texte.

Couvrir les contraintes techniques

Le cahier des charges doit répondre à ces questions techniques :

• Plateformes : iOS, Android, les deux ? Natif ou cross-platform (React Native, Flutter) ?
• Intégrations : paiement (Stripe), géolocalisation, notifications push, SSO, calendrier ?
• Hébergement : cloud (AWS, GCP, Vercel) ou serveur dédié ?
• Conformité RGPD : quelles données personnelles sont collectées ? Mécanisme de consentement ? Droit à l’oubli ?
• Accessibilité : niveau de conformité WCAG visé ?

Chaque intégration ajoute de la complexité et du coût. Si tu veux prototyper rapidement avec le vibe coding avant de te lancer dans un développement complet, c’est le moment d’y réfléchir.

Prévoir la maintenance dès le départ

Le cahier des charges ne s’arrête pas à la livraison. Prévois :

• Un budget maintenance de 15 à 20 % du coût initial par an
• Les mises à jour OS (Apple et Google publient une version majeure par an)
• La correction de bugs post-lancement
• La supervision des performances

Négocie un contrat de TMA (tierce maintenance applicative) dès la signature. C’est plus simple et moins cher que de chercher un prestataire de maintenance après coup.

Cahier des charges traditionnel ou version light pour un MVP

Un MVP n’a pas besoin d’un cahier des charges de 80 pages. Il a besoin d’un document de cadrage léger : des user stories, les parcours critiques, et surtout une liste de ce que tu ne feras PAS. Le format exhaustif sert un appel d’offres ou un marché public. Pas une startup qui veut livrer en 4 semaines.

Le piège du format lourd est connu des équipes produit. Beaucoup d’équipes qui se disent agiles rédigent en réalité un gros document de spécifications en amont, puis le figent : du waterfall déguisé. Le temps passé à détailler chaque écran ne protège pas des changements qui arrivent quand même.

La version light : la méthode Shape Up

Basecamp a formalisé l’alternative sous le nom de Shape Up. Le document de cadrage, appelé “pitch”, tient en quelques pages et contient cinq blocs : le problème, le budget de temps (l’appetite), la solution esquissée, les pièges techniques, et les non-goals - ce qui est explicitement hors périmètre. Ryan Singer, son auteur, défend un cadrage qui fixe l’intention sans tout spécifier à l’avance.

Marty Cagan, du Silicon Valley Product Group, va dans le même sens. Il déconseille de passer trop de temps sur un document lourd au détriment du produit lui-même, et préfère un prototype cliquable à un cahier des charges fleuve. Mais il prévient : un cahier des charges bâclé rend un bon produit presque impossible. La nuance tient en une phrase. Le problème n’est pas le cahier des charges. C’est sa longueur quand ton vrai besoin tient en 12 pages.

Comparer les prestataires avec le même cahier des charges

Un bon cahier des charges sert aussi d’outil d’appel d’offres. Envoie le même document à 3 à 5 prestataires et compare les réponses sur une base identique.

La matrice de scoring

Crée une grille avec ces critères pondérés :

Le critère le plus important n’est pas le prix. C’est la compréhension du besoin. Un prestataire qui pose des questions sur ton cahier des charges montre qu’il l’a lu. Un prestataire qui répond en 48h avec un chiffre rond ne l’a probablement pas ouvert.

Ne jamais choisir sur le prix seul

Le réflexe du moins-disant est le piège classique. Choisir le prestataire le moins cher pour économiser, c’est souvent payer le double. Des bugs en production quelques semaines après le lancement, et tu finis par engager un deuxième prestataire pour reprendre le travail. Le cahier des charges te permet de comparer les agences MVP sur la même base. C’est sa valeur première dans la phase de sélection.

Faut-il un cahier des charges pour du vibe coding

Oui, mais pas le même. Le vibe coding consiste à construire une application en dialoguant avec une IA comme Cursor ou Claude Code. L’IA produit du code médiocre à partir d’une idée vague, et du code juste à partir d’un cadrage clair. Le cahier des charges léger devient la boussole de l’agent : user stories, modèles de données, parcours, contraintes.

C’est le principe du spec-driven development. Colle une idée floue dans un assistant de code, tu obtiens un résultat flou. Donne-lui des user stories précises, un schéma de données et les cas limites, il construit ce que tu voulais vraiment. Le cahier des charges ne disparaît pas avec l’IA - il change de rôle. Il passe de document contractuel de 80 pages à fichier de contexte de 10 pages que la machine lit en entier.

Pour un MVP construit en vibe coding, le bon cadrage tient donc dans la version light : assez précis pour guider la machine, assez court pour ne pas freiner le départ.

Avec Ary, ton MVP est cadré, chiffré et livré en 4 semaines pour 5 000 à 25 000 EUR, par un fondateur identifiable. C’est exactement ce que fait mon studio MVP solo à Paris.

Foire aux questions