Sommaire
Cahier des charges application mobile : comparer les devis
47 % des projets qui n'atteignent pas leurs objectifs le doivent d'abord à une gestion des exigences défaillante. Pas d'abord au code, ni au budget, ni au prestataire : à ce qui avait été écrit, ou pas, avant de commencer.
Un cahier des charges application mobile ne sert donc pas à « présenter le projet ». Il sert à ce que trois prestataires chiffrent le même produit, et à ce que ce produit passe la validation d'Apple et de Google. Voici les rubriques qui rendent les devis comparables, les exigences des stores qu'il faut écrire avant tout chiffrage, et la grille pour lire les réponses.
47 %des projets qui ratent leurs objectifs le doivent d'abord à des exigences mal gérées
Une précision de méthode : les enquêtes du PMI portent sur des projets de toutes natures, informatique, construction, énergie ou administration. Aucune ne porte spécifiquement sur les applications mobiles. Elles mesurent un mécanisme général, la dérive d'un projet mal spécifié, pas un taux d'échec propre au mobile.
Pourquoi un cahier des charges application mobile vague rend les devis incomparables
Un devis chiffre une interprétation. Quand le document dit « espace utilisateur », un prestataire comprend un e-mail et un mot de passe, un autre une connexion Google, Apple et Facebook avec récupération de compte. Les deux montants sont justes, mais ils ne portent pas sur la même application.
Le problème n'a rien de marginal, et il est resté stable tant que le PMI l'a mesuré. Le PMI demande chaque année aux chefs de projet quelles ont été les causes principales de leurs projets échoués, plusieurs réponses étant possibles. La part qui cite des exigences mal recueillies :
| Édition du Pulse of the Profession | Répondants citant des exigences mal recueillies parmi les causes principales d'échec |
|---|---|
| 2013 | 32 % |
| 2014 | 37 % |
| 2017 | 39 % |
| 2018 | 35 % |
Source : PMI, Pulse of the Profession 2017
La série s'arrête là : 2018 est la dernière édition consultée qui publie ce classement des causes d'échec.
Dans l'édition 2018, seuls deux motifs la devancent : le changement de priorités de l'organisation (39 %) et le changement d'objectifs du projet (37 %). La même édition mesure que 52 % des projets terminés dans l'année ont subi une dérive de périmètre, c'est-à-dire des ajouts ou des changements non maîtrisés, sans ajustement du délai, du budget ni des ressources.
Le coût se calcule. Le rapport de 2014 estime que 5,1 % de chaque euro dépensé en projet est perdu à cause d'une mauvaise gestion des exigences. Posons un budget de développement de 60 000 €, pris comme simple hypothèse de calcul :
- Moyenne de l'enquête : 60 000 × 5,1 % = 3 060 € perdus
- Organisations les moins performantes, près de 10 % : environ 6 000 €
- Organisations les plus performantes, 1 % : 600 €
Entre les organisations les plus rigoureuses et les moins rigoureuses, la perte varie d'un facteur dix. Ce sont des moyennes tous secteurs, mesurées en 2014 : elles donnent un ordre de grandeur, pas une prévision pour votre application. Pour savoir quel budget poser au départ, l'article sur le prix d'une application mobile détaille les postes de coût.
Que doit contenir le cahier des charges pour obtenir des devis comparables ?
Une réponse courte : tout ce qui change le montant d'un devis doit être écrit, et tout ce qui n'est pas écrit doit être déclaré hors périmètre. Les modèles qui circulent listent des rubriques de présentation — l'historique de l'entreprise, son marché, ses concurrents. Utiles, mais aucune ne fait varier le chiffrage. Ce sont les rubriques suivantes qui le font. Pour une application destinée aux équipes d'une entreprise, le périmètre porte aussi sur les processus remplacés, comme le chiffre l'article sur l'application métier sur mesure, et pour un CRM sur le seuil face aux abonnements.
| Rubrique | Ce qu'il faut écrire | Ce que ça change dans le devis |
|---|---|---|
| Objectif mesurable | Le résultat attendu, chiffré : inscriptions, ventes, temps gagné | Permet au prestataire de proposer un périmètre plus réduit qui l'atteint |
| Parcours utilisateurs | Chaque parcours en une phrase : qui fait quoi, dans quel ordre, avec quelle règle | Fixe le nombre d'écrans et la logique à coder |
| Fonctionnalités priorisées | Indispensable, important, souhaitable, exclu | Rend visible ce que chaque devis inclut réellement |
| Plateformes | iOS, Android, tablette, versions minimales | Une ou deux bases de code, un ou deux jeux de tests |
| Comptes et connexion | Méthodes de connexion, récupération, suppression de compte | Ajoute des obligations des stores, détaillées plus bas |
| Back-office | Qui administre quoi, avec quels droits | Un second logiciel à part entière, à faire figurer au devis |
| Paiement | Contenu numérique ou bien physique, abonnement ou achat unique | Achat intégré imposé ou non par les stores |
| Données | Données personnelles traitées, hébergement, durée de conservation | Politique de confidentialité, sécurité, conformité |
| Contenus et design | Fournis par vous ou à produire | Un poste de design entier peut apparaître ou disparaître |
| Livrables | Code source, propriété, accès aux comptes développeur, documentation | Ce que vous possédez à la fin du contrat |
La troisième ligne fait le gros du travail. Classer chaque fonctionnalité force à trancher avant le devis plutôt que pendant le développement, et c'est la base d'un MVP d'application bien découpé.
Les spécifications fonctionnelles, enfin, s'écrivent en règles et non en écrans. « L'utilisateur peut annuler une réservation jusqu'à 24 heures avant, sans frais » se chiffre. « Une page Mes réservations » ne se chiffre pas : la règle est à inventer, et chaque prestataire l'inventera à sa façon.
Les exigences des stores à écrire avant le premier devis
Apple et Google ne valident pas seulement qu'une application fonctionne : ils valident aussi qu'elle respecte leurs règles. Plusieurs de ces règles imposent des fonctionnalités, et donc des lignes de devis.
Le volume de refus donne l'échelle. En 2025, Apple a examiné 9 100 620 soumissions et en a rejeté 2 093 244, soit 23 %. La section Performance des règles, qui couvre notamment la complétude de l'application, totalise 1 354 418 motifs de rejet, à elle seule plus que toutes les autres sections réunies. Une soumission pouvant être refusée pour plusieurs motifs, les sections additionnées dépassent le total. Apple précise par ailleurs que plus de 40 % des problèmes non résolus relèvent de la règle 2.1, la complétude : plantages, contenus provisoires, informations manquantes.
Source : Apple Developer, App Review, section Avoiding common issues
Les règles qui ont un effet direct sur le périmètre, telles qu'elles s'appliquent en octobre 2026 :
| Règle | Source | Ce qu'il faut écrire dans le cahier |
|---|---|---|
| Suppression du compte depuis l'application | Apple 5.1.1(v) ; Google Play exige en plus un lien web | Un parcours de suppression et une page web dédiée |
| Politique de confidentialité accessible dans l'app | Apple 5.1.1(i) | Le texte, sa page et son lien dans les réglages |
| Connexion Google ou Facebook : option équivalente obligatoire | Apple 4.8 | Une méthode qui limite les données au nom et à l'e-mail, permet de masquer l'adresse et ne piste pas l'utilisateur à des fins publicitaires sans consentement |
| Contenu numérique débloqué : achat intégré | Apple 3.1.1 | Le modèle de paiement et ses exceptions régionales |
| Pas un simple site reconditionné | Apple 4.2 | Ce que l'application apporte de plus que le site |
| Compte de démonstration pour la revue | Apple 2.1 | Un compte de test et un back-end actif à la soumission |
| Cibler Android 16 (API 36) | Google Play, depuis le 31 août 2026 | La version d'Android visée, et son maintien dans les mises à jour |
| 12 testeurs pendant 14 jours | Google Play, comptes personnels créés après le 13 novembre 2023 | Une phase de test fermé avant la publication |
Source : Apple, App Review Guidelines, mise à jour du 8 juin 2026
Source : Android Developers, exigences de niveau d'API cible, page mise à jour le 1er octobre 2026
Source : Google Play Console, exigences de suppression de compte
Le détail de la soumission elle-même, comptes développeur, fiches et délais de revue, est traité dans le guide pour publier une application sur l'App Store et Google Play.
Comment comparer les devis d'application mobile reçus
Un devis ne se compare pas à son total. Il se compare ligne par ligne contre votre grille, et trois questions suffisent à faire apparaître les écarts.
Qu'est-ce qui est exclu ? Un devis plus bas n'a pas forcément oublié de facturer : il a retiré le back-office, la suppression de compte ou la publication sur les stores. Demandez à chaque prestataire de lister explicitement ce qu'il n'inclut pas.
Quelles hypothèses ont été posées ? Nombre d'écrans, nombre d'allers-retours de design, volume d'utilisateurs prévu pour l'hébergement. Deux devis aux hypothèses différentes ne mesurent pas le même risque.
Que se passe-t-il après la livraison ? Google relève régulièrement le niveau d'API exigé pour publier une mise à jour, aujourd'hui Android 16 : une application n'est jamais terminée. Un devis sans ligne de maintenance n'est pas moins cher, il est incomplet.
Le choix entre un indépendant et une structure plus large change aussi la lecture : la question est traitée dans freelance ou agence pour une application mobile.
Trois erreurs que les données rendent prévisibles
Décrire des écrans au lieu de règles. Une maquette montre à quoi ressemble l'application, pas ce qu'elle fait quand l'utilisateur annule, paie deux fois ou perd sa connexion. C'est une forme de l'imprécision des exigences que mesure le PMI, et elle se paie en ajouts non prévus.
Découvrir les obligations des stores à la soumission. Avec plus d'une soumission sur cinq refusée chez Apple, attendre la revue pour apprendre qu'il faut une suppression de compte ou un achat intégré revient à ajouter un chantier après la date de livraison.
Laisser le prestataire écrire le périmètre seul. Il est le mieux placé pour décrire la technique, mais pas pour décider de ce qui est indispensable à votre activité. Un périmètre rédigé par celui qui chiffre est un périmètre qui ne se compare à aucun autre.
Un cahier des charges application mobile bien construit ne garantit pas que le projet sera rentable. Il garantit que vous savez ce que vous achetez. La rentabilité se calcule à part, dans l'article sur la rentabilité d'une application mobile, à partir des coûts que ces devis vous auront donnés.
Questions fréquentes
Comment faire un cahier des charges pour une application mobile ?
Partez de l'objectif mesurable, puis décrivez les utilisateurs et leurs parcours, la liste des fonctionnalités classées par priorité, les plateformes visées, les données traitées, le back-office, les contenus fournis, les livrables attendus et les exigences des stores. Terminez par une grille de réponse imposée aux prestataires, pour qu'ils chiffrent tous le même périmètre.
Qui doit rédiger le cahier des charges d'une application ?
Le porteur du projet, parce que lui seul connaît le besoin métier et les règles de gestion. Un prestataire peut l'aider à formuler la partie technique, mais s'il écrit seul le périmètre, il chiffre sa propre interprétation et les devis concurrents ne portent plus sur le même produit.
Quelle différence entre cahier des charges fonctionnel et technique ?
Le fonctionnel décrit ce que l'application doit faire du point de vue de l'utilisateur : parcours, règles, priorités. Le technique décrit comment : langages, hébergement, API, sécurité. Pour une première application, un cahier fonctionnel précis suffit souvent ; le choix technique peut faire partie de ce que vous demandez aux prestataires de justifier.
Faut-il prévoir les règles de l'App Store dans le cahier des charges ?
Oui. Plusieurs règles d'Apple et de Google imposent des fonctionnalités : suppression de compte depuis l'application, lien vers la politique de confidentialité, achat intégré pour débloquer du contenu numérique, option de connexion équivalente si vous proposez Google ou Facebook. Absentes du cahier, elles sont absentes du devis, puis ajoutées en avenant.