Cahier des charges application mobile : le modèle qui protège votre budget

Un cahier des charges d’application mobile n’a pas besoin de faire 80 pages. Il doit surtout empêcher deux dépenses : développer une fonction que personne n’utilise et refaire un parcours parce que le mot « simple » n’avait pas le même sens pour le client et le développeur. Sur un MVP de 40 jours, trois jours de reprise représentent déjà 540 € avec un développeur à 180 €/jour, avant même de compter le retard commercial. Mon verdict : visez 12 à 20 pages utiles, complétées par des maquettes et des critères d’acceptation vérifiables.

Commencez par la décision business, pas par la liste des écrans

Le défaut le plus courant est de commencer par « connexion, profil, notifications, messagerie ». Cette liste ressemble à une application, mais elle ne dit ni qui l’utilise, ni pour quoi faire, ni comment l’entreprise saura que le produit mérite un second budget.

La première page du cahier des charges doit tenir en cinq réponses :

1. Quel problème précis est résolu ? Décrivez une situation observable, pas une ambition générale. « Un responsable de club passe deux heures par semaine à relancer les adhérents » est exploitable. « Digitaliser la relation client » ne l’est pas.
2. Qui rencontre ce problème ? Nommez le rôle, le contexte et la fréquence. Un utilisateur occasionnel n’a pas les mêmes besoins qu’un opérateur qui ouvre l’application cinquante fois par jour.
3. Quelle action centrale doit devenir plus rapide ? Réserver, payer, scanner, déclarer, livrer ou suivre : choisissez un verbe principal.
4. Quel indicateur validera le MVP ? Par exemple, 30 utilisateurs complètent le parcours principal, 20 % reviennent la semaine suivante ou le temps de traitement passe de 15 à 5 minutes.
5. Quelle décision sera prise après le test ? Continuer, changer de cible, supprimer une fonction ou arrêter. Sans cette règle, le MVP devient une première version permanente que l’on enrichit sans apprendre.

DataForSEO mesure environ 140 recherches mensuelles en France sur « cahier des charges application mobile », avec une intention informationnelle. La page de résultats est remplie de listes de rubriques et de modèles à télécharger. Le manque n’est donc pas un énième sommaire : c’est une méthode pour transformer le document en outil de décision, de devis et de recette.

Cette dernière ligne est souvent la plus rentable. Écrire ce qui n’est pas prévu ferme les interprétations sans bloquer les versions futures.

Utilisez un modèle en 12 blocs que le prestataire peut réellement chiffrer

Un bon document sépare le besoin métier des choix techniques. Le fondateur reste responsable du problème, du public et des priorités. Le développeur ou le lead dev propose ensuite l’architecture, c’est-à-dire l’organisation du logiciel qui permet de livrer et maintenir le produit.

Voici les douze blocs que je demande avant un devis ferme ou une estimation par lots.

1. Contexte et objectif. Résumez l’entreprise, le problème, l’utilisateur et l’indicateur de succès sur une page. Ajoutez les contraintes déjà connues : lancement lié à un événement, intégration à un logiciel existant ou pays ciblés.

2. Utilisateurs et rôles. Décrivez les droits de chaque profil. Un client, un opérateur et un administrateur ne voient pas les mêmes données et ne peuvent pas effectuer les mêmes actions. Une matrice simple « voir, créer, modifier, supprimer » évite des semaines d’ambiguïté.

3. Parcours principal. Dessinez le chemin le plus important depuis l’ouverture jusqu’au résultat. Chaque étape doit préciser l’action, la réponse attendue et les erreurs possibles. Les maquettes n’ont pas besoin d’être belles ; elles doivent rendre le parcours compréhensible.

4. Fonctionnalités prioritaires. Classez-les en trois catégories : obligatoire pour tester la valeur, utile après validation, et hors périmètre. Je limite le premier groupe à ce qui permet d’exécuter le parcours principal et de mesurer son usage.

5. Règles métier. Indiquez les calculs, limites et exceptions. Qui peut annuler ? Jusqu’à quelle heure ? Que se passe-t-il si le paiement réussit mais que la confirmation échoue ? Ces règles font souvent plus varier le devis que le nombre d’écrans.

6. Données et permissions. Listez chaque donnée collectée, sa raison et sa durée de conservation. La CNIL a actualisé en avril 2025 ses recommandations relatives aux applications mobiles. Elle distingue notamment les permissions techniques du téléphone et le consentement juridique. Un accès accordé à la localisation ne dispense donc pas d’expliquer l’usage de la donnée ni de choisir une base légale adaptée.

7. Intégrations externes. Paiement, cartographie, SMS, CRM, appareil Bluetooth ou API métier : nommez le service, le titulaire du compte, les limites connues et le comportement attendu en cas de panne. « Connecter Stripe » est insuffisant si personne ne décide qui gère les remboursements et les litiges.

8. Plateformes et appareils. Précisez iOS, Android, téléphones, tablettes et versions minimales. Une application native, développée séparément pour chaque système, offre plus de contrôle. Une base multiplateforme comme React Native ou Flutter partage davantage de code. Le cahier des charges doit exprimer les contraintes ; le choix final vient après l’analyse du produit.

9. Administration. La plupart des applications ont besoin d’un back-office, c’est-à-dire d’un écran interne pour gérer comptes, contenu, paiements et incidents. Le supprimer du devis ne supprime pas le travail : il le transforme en interventions manuelles dans la base.

10. Qualité, sécurité et exploitation. Définissez les tests, la sauvegarde, les journaux d’erreur, le suivi des crashs et la procédure de retour arrière. Une application « terminée » mais impossible à diagnostiquer crée une dette technique, le coût caché du code qui ralentit chaque évolution future.

11. Livrables et propriété. Exigez le dépôt Git, les comptes de publication au nom de l’entreprise, les accès au cloud, les scripts de déploiement et une documentation de reprise. Le code livré dans une archive à la fin n’offre pas la même réversibilité qu’un dépôt accessible dès le premier jour.

12. Planning, budget et gouvernance. Découpez le projet en lots courts avec une démonstration et une décision à chaque jalon. Indiquez qui valide, sous quel délai, et comment une demande supplémentaire est chiffrée. Pour estimer l’enveloppe globale, le guide sur le budget d’un MVP SaaS complète utilement ce document.

Transformez chaque fonction en résultat testable avant de demander un devis

Une fonctionnalité ne devrait jamais être une simple ligne. Utilisez ce format :

En tant que [rôle], je veux [action] afin de [résultat]. La fonction est acceptée lorsque [preuves vérifiables].

Exemple : « En tant que membre, je veux réserver un créneau afin de garantir ma place. La fonction est acceptée lorsque je vois les places disponibles, que deux personnes ne peuvent pas prendre la dernière place, que je reçois une confirmation et que l’annulation remet la place à disposition. »

Ajoutez ensuite les cas qui coûtent du temps : absence de réseau, paiement refusé, session expirée, permission de localisation refusée, compte supprimé et notification désactivée. Apple recommande de ne demander que les données nécessaires et de prévoir une alternative quand l’utilisateur refuse une permission. Ses règles imposent également une suppression de compte dans l’application lorsqu’elle permet d’en créer un. Ces exigences doivent apparaître dans le cahier des charges, car elles modifient les écrans, le stockage et les tests.

Pour chaque fonction, définissez quatre niveaux de preuve :

• preuve visuelle : l’écran correspond à la maquette validée sur les tailles ciblées ;
• preuve fonctionnelle : le scénario principal et les erreurs prévues sont testés ;
• preuve de données : la création, la modification et la suppression sont vérifiées ;
• preuve d’exploitation : une erreur est visible dans les logs, c’est-à-dire l’historique technique permettant de diagnostiquer un incident.

Le fil Reddit consulté oppose deux visions du MVP : certains participants acceptent un produit très brut, d’autres rappellent qu’il doit rester assez bon pour fournir une vraie valeur. Je retiens la seconde. « Minimum » signifie périmètre réduit, pas qualité aléatoire. Ce signal reste anecdotique, mais il décrit bien le piège : supprimer les fonctions secondaires est sain ; supprimer les tests du parcours central ne l’est pas.

Deux vidéos francophones sur le cahier des charges mobile ont aussi été examinées. Aucun transcript n’a été rendu disponible par YouTube dans l’environnement utilisé. Je ne leur attribue donc aucun conseil. Les exigences relatives aux permissions, aux comptes et à la confidentialité viennent des documents CNIL et Apple directement consultés.

Avant d’envoyer le document, faites enfin une revue de 45 minutes avec un décideur métier et un développeur senior. Le premier vérifie la valeur et les exceptions. Le second repère les dépendances, les données sensibles et les fonctions difficiles à estimer. Si une ligne ne peut pas être testée ou reliée à l’objectif, réécrivez-la ou sortez-la du MVP.

Mon verdict : testez le projet quand le parcours central, les rôles, les données et les critères d’acceptation tiennent dans un document court que deux prestataires peuvent chiffrer de façon comparable. Attendez si vous ne savez pas encore quel comportement utilisateur doit valider l’idée. Dans ce cas, une maquette cliquable et cinq entretiens valent mieux qu’un développement complet.