Cahier des charges application mobile : méthode et pièges

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, dans 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 et la protection juridique que personne ne mentionne dans les articles concurrents. Je te montre aussi comment prioriser tes fonctionnalités avec la méthode MoSCoW pour définir ton MVP avant d’envoyer ton exemple de cahier des charges application mobile à des prestataires.

Que doit contenir un cahier des charges application mobile

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.

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. Pas 35.

Les erreurs qui coûtent le plus cher

Les données sont sans appel. Selon le Standish Group (CHAOS Report), seulement 31% des projets IT sont livrés dans les temps et le budget. McKinsey et l’Université d’Oxford, sur 5 400 projets, mesurent un dépassement moyen de 45% sur les grands projets IT. 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), landing page, 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 à 6 000 EUR 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.

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 de prix par type de projet, lis l’exemple de devis d’application mobile que j’ai décortiqué ligne par ligne. Et si tu veux une estimation rapide, consulte nos tarifs.

La protection juridique que personne ne mentionne

Aucun article concurrent ne parle de jurisprudence. C’est pourtant l’argument le plus concret 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 (Oopet Fit, Oopet Love) à un prestataire en méthode agile. Pas de cahier des charges. Quand les problèmes apparaissent, Oopet demande le remboursement au tribunal de commerce de Paris.

Le tribunal rejette la demande (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 message est clair. Même en agile, un document d’expression des besoins est indispensable. Le cahier des charges n’est pas un frein à l’agilité - c’est un 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

La majorité des collaborations avec des développeurs freelances se terminent 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 une analyse complète des risques selon le type de prestataire, lis le comparatif agence vs freelance pour le développement d’application.

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

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 doit être décrite 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 hébergement 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
• Le monitoring 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. Pour voir comment je structure cette étape dans mes projets, regarde mon process de A à Z.

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.

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 à périmètre égal. C’est sa valeur première dans la phase de sélection.

Si tu hésites entre agence et freelance, le comparatif agence vs freelance t’aide à trancher selon ton budget et ton niveau technique.

Si tu veux que je t’accompagne dans la rédaction ou le développement, c’est exactement ce que fait mon agence vibe coding à Paris.

Foire aux questions

Comment faire un cahier des charges pour une application mobile ?

Commence par définir l’objectif business de l’app, ta cible utilisateur et les fonctionnalités prioritaires avec la méthode MoSCoW. Détaille chaque fonctionnalité en user stories (“En tant que X, je veux Y pour Z”). Ajoute les contraintes techniques (plateformes, intégrations, RGPD), le budget sous forme de fourchette, le planning avec des jalons et les critères de recette. Un bon cahier des charges fait entre 10 et 30 pages selon la complexité.

Que doit contenir un cahier des charges application mobile ?

Les 10 sections essentielles : présentation du projet, objectifs business mesurables, cible utilisateur (personas), périmètre fonctionnel priorisé (MoSCoW), parcours utilisateur avec wireframes, spécifications techniques (stack, APIs, hébergement), charte graphique, planning avec jalons, budget et critères de recette. Chaque fonctionnalité doit être décrite avec une user story, pas une phrase vague.

Combien coûte la rédaction d’un cahier des charges ?

Gratuit si tu le rédiges toi-même avec un template. Entre 1 000 et 3 000 EUR si tu confies la rédaction à un prestataire ou un consultant. C’est un investissement qui se rentabilise : un cahier des charges précis évite les devis à géométrie variable et les dépassements de budget.

Qui doit rédiger le cahier des charges ?

Le porteur de projet, avec ou sans accompagnement. La Cour d’appel de Versailles a jugé en 2021 qu’un prestataire qui ne précise pas dans le contrat qui rédige le cahier des charges engage sa responsabilité. Le prestataire a une obligation de conseil - il doit guider le client non-technique - mais le besoin vient de toi.

Faut-il indiquer son budget dans le cahier des charges ?

Oui, sous forme de fourchette. Sans indication budgétaire, un même projet peut être chiffré entre 20 000 et 60 000 EUR. La fourchette filtre les prestataires non adaptés et force des propositions réalistes alignées sur tes moyens. Ce n’est pas “montrer ton jeu” - c’est gagner du temps.

Quelle différence entre cahier des charges et spécifications fonctionnelles ?

Le cahier des charges est stratégique : il décrit le quoi et le pourquoi. Les spécifications fonctionnelles sont techniques : elles décrivent le comment pour les développeurs. Le cahier des charges vient en premier et sert de base aux specs. En pratique, les deux peuvent être dans le même document pour un projet simple.

Peut-on développer en agile sans cahier des charges ?

Techniquement oui. Juridiquement, c’est risqué. En 2020, le tribunal de commerce de Paris a rejeté la demande de remboursement d’une startup (affaire Oopet) parce qu’en agile, “le développement se construit au fur et à mesure”. Sans document de référence, impossible de prouver la défaillance du prestataire.

Comment éviter le scope creep sur un projet d’application ?

Trois mécanismes. Un périmètre gelé après validation du cahier des charges. Un processus formel de change request - chaque modification est estimée en coût et délai avant exécution. Et un budget de contingence de 15 à 20% pour absorber les imprévus sans exploser le budget total.

Combien de pages doit faire un cahier des charges application mobile ?

Entre 10 et 30 pages selon la complexité. Un MVP avec 5 fonctionnalités tient en 10-15 pages. Une application complexe avec intégrations multiples peut nécessiter 30 pages ou plus. La précision compte plus que la longueur : 15 pages détaillées valent mieux que 40 pages vagues.

Un cahier des charges est-il juridiquement obligatoire ?

Non, il n’y a pas d’obligation légale. Mais c’est le document de référence en cas de litige. Sans cahier des charges, c’est ta parole contre celle du prestataire. Deux jurisprudences françaises récentes (Oopet 2020, Fédération Française de Bridge 2021) confirment que son absence fragilise considérablement ta position devant un tribunal.