Cahier des charges application mobile en 2027 : le modèle

Qu’est-ce qu’un cahier des charges d’application, et en quoi diffère-t-il d’un brief ?

Le cahier des charges est le document qui décrit ce que l’application doit savoir faire et à quoi vous reconnaîtrez qu’elle est terminée. Trois personnes le lisent : vous, le designer et le développeur. Si tous les trois comprennent le texte de la même façon, vous supprimez la première source de litiges en projet : « je pensais que c’était inclus ».

Ne confondez pas trois documents. Le brief répond à « pourquoi » et « pour qui » : objectif, public, marché, budget. Le cahier des charges répond à « que doit-il fonctionner précisément » : écrans, actions, règles, données. Le devis répond à « combien et quand » et se fait à partir du cahier des charges. Pour un site, nous avons détaillé le brief dans l’article « Cahier des charges et brief pour un site web » ; pour une application, il y a plus d’exigences : le téléphone, les boutiques d’applications, les notifications, l’usage sans connexion.

Bonne nouvelle : inutile de rédiger 80 pages comme un ingénieur. 3 à 6 pages de texte simple, selon le modèle ci-dessous, suffisent. Le prestataire complétera les détails techniques, mais il ne peut pas deviner à votre place ce dont votre entreprise a besoin.

Autre avantage : un cahier des charges permet d’obtenir des devis comparables. Quand cinq agences chiffrent le même document, les prix se posent côte à côte. Quand chacune chiffre sa propre version de votre idée, il n’y a rien à comparer.

Modèle de cahier des charges pour application mobile : 10 rubriques

Copiez cette liste dans un document et remplissez chaque point, même en une ou deux phrases. Une rubrique vide est une question qu’il faudra de toute façon trancher, mais plus tard et plus cher.

1. Objectif et résultat mesurable. Une phrase : « les clients réservent seuls, et 30 % des réservations passent par l’application ». Sans chiffre, c’est acceptable, mais notez alors à quoi vous reconnaîtrez le succès.
2. Utilisateurs et rôles. Qui utilise l’application : client, praticien, administrateur, livreur. Chaque rôle a ses écrans et ses droits.
3. Plateformes. iOS, Android ou les deux ; faut-il une version tablette ; un site installable sur le téléphone comme une application (PWA) suffit-il, ou faut-il passer par les boutiques d’applications ? En cas de doute, comparez d’abord application, site et PWA par coût et par usage.
4. Carte des écrans. La liste de tous les écrans et les flèches entre eux : connexion, accueil, catalogue, fiche, panier, profil. Un schéma dessiné à la main et pris en photo suffit.
5. Parcours. Ce que fait la personne, étape par étape : « ouvre l’app, choisit la prestation, choisit l’horaire, paie, reçoit un rappel ».
6. Fonctions classées par priorité. Trois colonnes : « impossible de lancer sans », « ce serait bien », « plus tard ». C’est la rubrique la plus importante pour le budget.
7. Données et connexions. Où sont stockés les utilisateurs et les commandes, avec quoi l’application communique : paiement, CRM, comptabilité, cartes, e-mail, messageries.
8. Exigences non fonctionnelles. Rapidité, usage hors connexion, langues, sécurité, accessibilité (détails plus bas).
9. Publication et comptes. Au nom de qui sont créés les comptes développeur, qui rédige les descriptions pour les boutiques, pour quels pays.
10. Recette et étapes. Comment le résultat est vérifié, combien de tours de corrections, comment le paiement est réparti par étape.

Pour chaque point, ajoutez des exemples d’applications que vous aimez et une ligne sur ce qui vous plaît précisément. « Je veux la même chose qu’Uber » ne dit rien ; « je veux une carte avec des points qui ressemble à celle d’Uber, et une inscription par numéro de téléphone » dit tout.

Expression de besoin d’une application mobile : exigences fonctionnelles et non fonctionnelles

Un document d’exigences (en anglais app requirements document) contient en général deux types d’entrées. Les exigences fonctionnelles décrivent ce que fait l’application : « l’utilisateur peut déplacer un rendez-vous au plus tard 2 heures avant ». Les exigences non fonctionnelles décrivent la qualité de l’exécution : vite, en sécurité, clairement, dans les bonnes langues. Ce sont les secondes que l’on oublie le plus souvent, avant de se disputer.

Exemple pour une application de réservation en salon

Rôle « client » : inscription par numéro de téléphone avec code reçu par SMS. Catalogue des prestations avec prix et durée. Choix du praticien et d’un créneau libre. Acompte par carte. Rappel la veille et 2 heures avant. Annulation gratuite au plus tard 24 heures avant. Rôle « administrateur » : planning des praticiens, liste des réservations, remboursements, envoi d’offres promotionnelles.

C’est la partie fonctionnelle. On y ajoute la partie non fonctionnelle :

• Rapidité. L’écran d’accueil s’ouvre sans délai notable sur un téléphone moyen vieux de cinq ans.
• Connexion. Que voit le client sans internet : sa dernière réservation ou un message d’erreur ? Un vrai mode hors ligne se facture à part.
• Langues et devises. Combien de langues d’interface, dans quelle devise sont les prix, quel format de date.
• Sécurité et données. Quelles données personnelles sont conservées, qui les voit, comment une personne supprime son compte. Si vous travaillez dans votre pays, faites vérifier les règles sur les données personnelles par un juriste : pour l’UE, c’est le RGPD.
• Accessibilité. Grande police, contraste, libellés pour les lecteurs d’écran. C’est à la fois un confort et une obligation sur certains marchés.
• Appareils. À partir de quelle version d’iOS et d’Android l’application est prise en charge, et sur quels écrans elle est testée.

N’oubliez pas la partie « invisible » : la plupart des applications ont un back-office où l’équipe gère le contenu et les commandes. Dans le cahier des charges, il fait l’objet d’une rubrique à part ; sinon l’application sera prête, mais sans rien pour la piloter.

Que prévoir dans le cahier des charges pour l’App Store et Google Play

La publication est une étape à part, avec ses propres règles, et elle ne dépend pas que de nous. Il vaut donc mieux noter quelques points à l’avance.

• Comptes développeur. Apple prend 99 $ par an, Google Play 25 $ une seule fois. Nous publions l’application sur votre compte : indiquez donc qui le crée et qui conserve les accès.
• Version complète à soumettre. Selon les règles d’Apple (section 2.1, « exhaustivité de l’application »), on soumet une version terminée : sans éléments provisoires ni pages factices, avec des liens qui fonctionnent, et, s’il y a une connexion à un compte, avec un accès de démonstration pour le relecteur ; la partie serveur doit alors être en marche. Dans le cahier des charges, cela devient un critère de recette : « compte de test et description pour le relecteur prêts ».
• Tests pour Google Play. Pour les nouveaux comptes développeur personnels, Google exige un test fermé : au moins 12 testeurs inscrits pendant 14 jours consécutifs, et seulement ensuite la mise en ligne pour tous. Prévoyez ces deux semaines dans le calendrier, ou créez un compte d’organisation ; consultez l’aide de Google Play pour les conditions actuelles.
• Textes et visuels pour les boutiques. Description, captures d’écran, politique de confidentialité, classification par âge. Qui les rédige, et dans quelles langues.
• Paiements. Si l’application vend des biens numériques ou des abonnements, les boutiques ont leurs règles et leurs commissions. Pour des biens physiques et des services, les règles sont différentes. Notez ce que vous vendez, et le prestataire vous indiquera le bon schéma.

Les délais de validation des boutiques ne dépendent pas de nous, c’est pourquoi nous ne promettons jamais de date précise de mise en ligne. Pour le détail des étapes de publication, lisez l’article comment créer une application mobile : de l’idée à l’App Store.

Cinq erreurs de cahier des charges qui allongent les délais et gonflent le prix

1. Pas de priorités. Quand tout est « très important », le devis inclut tout, et vous lancez la première version au bout de six mois au lieu de deux. Répartissez les fonctions entre « indispensable », « ce serait bien » et « plus tard ».
2. Pas de critères de recette. « Beau et pratique » ne se vérifie pas. « Une réservation se crée en quatre touches maximum » se vérifie.
3. Back-office et rôles oubliés. L’application pour le client n’est que la moitié du produit. L’autre moitié, c’est l’outil de votre équipe.
4. Intégrations floues. « Connecter au CRM » représente des volumes de travail différents selon les systèmes. Nommez le système et décrivez quelles données vont où.
5. Pas de responsable. Si trois personnes prennent les décisions de votre côté, le projet s’enlise dans les validations. Désignez celui ou celle qui dit « oui » ou « non ».

Autre piège fréquent : écrire le cahier des charges d’un « produit idéal » fini. Mieux vaut décrire la première version, celle qui teste l’idée auprès de vraies personnes, et lister à part tout ce que vous ajouterez si elle fonctionne. À quoi ressemble cette première version et combien elle coûte, l’article MVP : de quoi s’agit-il et combien coûte un lancement l’explique.

Vérifiez que votre cahier des charges est prêt à être chiffré

Parcourez la courte check-list ci-dessous. Elle montre si le document peut partir chez les prestataires ou s’il faut d’abord combler des lacunes. Si vous répondez « non » à la plupart des points, ce n’est pas grave : une partie des questions peut se traiter avec le prestataire, et nous y sommes prêts.

Qui doit rédiger le cahier des charges : vous, le prestataire ou les deux

Il existe trois scénarios qui fonctionnent, et le choix dépend de la clarté de votre idée.

• Vous le rédigez vous-même avec le modèle. Convient si l’idée est simple et si vous connaissez votre public. Vous obtiendrez plusieurs devis et vous pourrez les comparer.
• Le prestataire le rédige à partir de votre brief. C’est pratique, mais plus le document est détaillé, plus le devis est précis. Un cahier des charges « gratuit » se transforme souvent en « cahier des charges calibré sur notre prix » ; demandez donc à qui il appartient si vous choisissez une autre équipe.
• Une étude préalable payante. Pour les produits complexes (rôles, paiements, plusieurs systèmes), nous la réalisons comme une étape distincte : l’atelier d’architecture à 3 500 €. Vous obtenez la cartographie du produit, le devis et le plan de la première version. Ce montant est déduit du projet, et la cartographie reste de toute façon à vous, même si vous choisissez ensuite une autre équipe.

Si vous avez besoin d’écrans, et pas seulement de texte, ajoutez le design et le prototype, à partir de 1 990 € : un prototype cliquable sur téléphone explique l’idée mieux que dix pages de description. Dans les offres d’application prêtes à l’emploi, le design est déjà inclus.

Pour choisir à qui confier le document et le projet lui-même dans votre pays, lisez comment choisir une agence web sans se tromper : les mêmes questions valent pour les développeurs d’applications. Et pour le coût de l’application elle-même, voyez l’article combien coûte le développement d’une application.

Que choisir dans votre situation

• L’idée est simple : un parcours, un rôle. Remplissez le modèle vous-même, envoyez-le à deux ou trois équipes et comparez les réponses. Chez nous, une application iOS et Android coûte à partir de 10 900 € ; le montant exact est établi dans le devis, après le cahier des charges.
• Il y a plusieurs rôles, du paiement, des intégrations. Ne rédigez pas tout à l’aveugle : commencez par un atelier d’architecture, et obtenez le cahier des charges sous forme de cartographie du produit et de devis.
• Vous n’êtes pas sûr qu’une application soit nécessaire. Un site sur téléphone ou une mini-application Telegram suffit peut-être. Comparez les options et leur coût avant d’écrire le document.
• Vous avez déjà un cahier des charges d’une autre agence. Montrez-le-nous et à d’autres prestataires : un seul document, plusieurs devis. Pour comparer honnêtement les réponses, lisez comment comparer des prestataires et des devis de développement.
• Vous devez lancer le plus vite possible. Ne décrivez que les fonctions indispensables et reportez le reste à la deuxième version.