Rédiger le cahier des charges d'une application mobile

Un cahier des charges pour une application mobile décrit ce que l’application doit faire, pour qui, sur quels appareils et sous quelles règles, assez précisément pour qu’un prestataire comprenne le besoin sans le deviner. Il sert aussi, à la livraison, de grille de vérification : objectif, parcours, périmètre, contraintes, données et critères de réception y sont écrits d’avance.

Ce qu’un cahier des charges pour une application mobile doit rendre possible

Le document a deux lecteurs : le prestataire, qui doit proposer une solution et l’estimer sans combler les blancs par ses propres hypothèses, puis l’entreprise au moment de la réception, c’est-à-dire de la vérification formelle de la livraison. Un cahier des charges qui ne sert qu’au premier lecteur produit des devis. Celui qui sert aussi au second produit une réception sereine.

Il s’agit d’un document fonctionnel : il décrit le besoin, les usages et les règles, pas la manière de coder. Le choix entre un développement natif, écrit séparément pour iOS et pour Android, et une base de code commune revient au prestataire, à partir des éléments fournis : appareils visés, usage hors connexion, recours à l’appareil photo ou à la localisation.

Le contexte et un objectif vérifiable

Le contexte tient en une page et répond à quatre questions :

• qui est l’entreprise ;
• quel processus l’application remplace ou complète ;
• qui l’utilisera ;
• pourquoi maintenant.

Il nomme aussi l’existant : logiciel de gestion, fichier partagé tenu à la main, site dont l’application reprendra des contenus. Découverts après la signature, ces systèmes font naître un autre projet.

L’objectif suit le contexte. « Moderniser la relation client » ne se vérifie pas. « Permettre aux techniciens de clôturer une intervention sur place, photo et signature comprises » se vérifie dès la première semaine. Un bon objectif décrit un changement observable, assorti d’un indicateur simple : part des interventions clôturées sur place, délai entre commande et confirmation.

Publics et parcours : décrire l’usage avant les écrans

Une liste d’écrans montre à quoi ressemble l’application. Les parcours utilisateurs disent ce qu’elle doit accomplir : c’est ce qu’un prestataire sait chiffrer et ce qu’une entreprise sait tester.

Des profils nommés, avec leurs conditions d’usage

Chaque public reçoit une fiche courte : son rôle, ses attentes, ses conditions réelles d’utilisation. Un préparateur de commandes ganté dans un entrepôt et un particulier qui ouvre l’application deux fois par an n’ont ni le même temps d’attention ni le même réseau. Ces conditions décident de la taille des boutons et du besoin d’un mode hors ligne.

Les récits utilisateurs, une phrase par besoin

Le récit utilisateur, traduction de l’anglais user story, tient en une phrase : en tant que tel profil, je veux faire telle action, afin d’obtenir tel résultat. Exemple : « En tant que technicien, je veux joindre des photos à mon rapport, afin que le client voie l’état de l’installation. » Le format oblige à dire pour qui et pourquoi, deux informations absentes d’une simple liste de fonctionnalités.

Les cas limites, là où les projets dérapent

Un parcours décrit d’abord le cas où tout se passe bien. Le prestataire a besoin des autres, ces cas limites à écrire pour chaque parcours important :

• le réseau se coupe au milieu d’une saisie ;
• l’utilisateur refuse l’accès à l’appareil photo ou à sa position ;
• la session expire pendant que l’application tourne en arrière-plan ;
• deux personnes modifient la même fiche depuis deux téléphones ;
• un compte est supprimé alors que des données lui sont rattachées.

Chaque cas appelle une décision métier. Laissé au développeur, il devient une règle de gestion inventée.

Le périmètre de la version 1, et ce qui attend la suivante

Le périmètre trace la frontière de la première livraison. Le rédiger demande surtout de renoncer, provisoirement, à des idées défendues en réunion.

Trier les récits plutôt que tout garder

La méthode MoSCoW classe chaque besoin en quatre catégories : indispensable (must have), important (should have), souhaitable (could have), exclu de cette version (won’t have). Elle fait émerger un parcours complet plutôt que dix parcours esquissés. Le périmètre fonctionnel d’une première version se juge sur une question : un utilisateur accomplit-il sa tâche principale de bout en bout ?

Ce tri pèse directement sur l’estimation, car un prestataire chiffre ce qu’il lit. Notre article sur la méthode de chiffrage d’un projet mobile montre comment un besoin découpé en lots devient une estimation vérifiable.

La liste de ce qui est reporté

Ce qui attend la version suivante s’écrit aussi, dans une section dédiée. Cette liste évite le malentendu le plus coûteux : une fonction jugée évidente par l’un, absente pour l’autre. Pour une place de marché, les règles de commission et de litiges entrent d’emblée dans le périmètre, comme le montre notre article pour créer une marketplace en ligne, quand la messagerie entre acheteurs et vendeurs peut attendre.

Les contraintes propres au mobile, une par une

Deux systèmes d’exploitation, des boutiques qui examinent chaque version, des réglages que l’utilisateur modifie à sa guise : le document décrit ces contraintes au lieu de les supposer connues.

Systèmes, appareils et mises à jour

Le document précise les systèmes visés, les versions minimales prises en charge, la place des tablettes et le rythme des mises à jour, que les boutiques imposent. D’après la documentation de Google Play, depuis le 31 août 2026, toute nouvelle application ou mise à jour doit cibler Android 16 (niveau d’API 36), c’est-à-dire être préparée pour cette version du système. Une application jamais adaptée cesse d’être proposée à une partie des utilisateurs.

Hors connexion et notifications

Chaque parcours indique s’il fonctionne sans réseau, en lecture seule ou pas du tout. Si la saisie hors connexion est prévue, la règle de synchronisation s’écrit noir sur blanc : quelle version d’une donnée l’emporte au retour du réseau ?

Les notifications se décrivent par événement déclencheur, destinataire et contenu. Depuis Android 13 (niveau d’API 33), selon la documentation Android, leur envoi exige une autorisation explicite de l’utilisateur. La règle 4.5.4 de l’App Store interdit les notifications promotionnelles sans accord exprès recueilli dans l’application.

Les permissions demandées à l’utilisateur

Localisation, appareil photo, micro, contacts : chaque accès sensible passe par une demande que l’utilisateur peut refuser. Pour chacune, le cahier des charges précise :

• la raison de la demande ;
• le moment où elle apparaît ;
• le comportement de l’application en cas de refus.

La CNIL, dans ses recommandations sur les applications mobiles publiées en septembre 2024, insiste sur des permissions réellement nécessaires, annoncées au bon moment. La règle 5.1.1 d’Apple donne l’exemple d’une adresse saisie à la main quand la localisation est refusée.

Les règles de publication des boutiques

Plusieurs règles des boutiques deviennent des fonctionnalités à inscrire au périmètre :

• la suppression du compte depuis toute application qui en crée (règle 5.1.1 d’Apple), complétée chez Google Play par un lien web de demande ;
• un lien vers la politique de confidentialité, sur la fiche de la boutique et dans l’application ;
• un compte de démonstration pour l’équipe d’examen d’Apple si une connexion est exigée (règle 2.1) ;
• une utilité propre, la règle 4.2 d’Apple écartant les applications qui reprennent simplement un site web.

Oubliés, ces points provoquent des refus qui décalent la mise en ligne.

L’accessibilité

Le RGAA, référentiel public français d’accessibilité aux personnes en situation de handicap, s’applique explicitement aux applications mobiles : usage avec un lecteur d’écran (VoiceOver sur iOS, TalkBack sur Android), contrastes, texte agrandi. Selon le site officiel de l’accessibilité numérique de l’État, il concerne les organismes publics et les entreprises dont le chiffre d’affaires réalisé en France atteint 250 millions d’euros en moyenne sur les trois derniers exercices. Les autres gagnent à reprendre ces exigences, simples à vérifier à la livraison.

Données, comptes et RGPD : ce que le prestataire ne devinera pas

Inventorier les données et les rôles

Le document liste les données manipulées (identité, position, photos, commandes), leur origine, leur stockage et les rôles qui y accèdent. Quand elles viennent d’un logiciel existant, l’échange passe souvent par une interface de programmation, et notre explication de l’API REST pour les non-développeurs aide à cadrer ce point.

Ce que le RGPD, la CNIL et les boutiques attendent

L’article 25 du RGPD impose la protection des données dès la conception, et le cahier des charges est l’endroit où elle se décide. Il fixe donc :

• la finalité de chaque donnée collectée, et rien au-delà ;
• les durées de conservation et la règle de suppression ;
• les traitements soumis au consentement, que l’utilisateur doit pouvoir retirer aussi simplement qu’il l’a donné, selon la CNIL ;
• les kits de développement tiers (SDK), briques de code d’autres éditeurs, et ce qu’ils collectent ;
• le contrat de sous-traitance exigé par l’article 28 du RGPD avec le prestataire et l’hébergeur.

Apple et Google demandent aussi une déclaration publique des données collectées, affichée sur la fiche de l’application : celle d’Apple couvre les outils tiers intégrés, et le formulaire Sécurité des données de Google reste obligatoire même sans aucune collecte. Tenu à jour, l’inventaire du cahier des charges rend ces déclarations fidèles.

Maquettes, croquis et critères de réception

Des croquis d’écrans joints au texte

Une maquette fonctionnelle, wireframe en anglais, est un schéma d’écran sans graphisme qui situe informations et actions. Des croquis au crayon photographiés suffisent souvent : ils lèvent des ambiguïtés que trois paragraphes laissent intactes, comme l’ordre des champs ou le nombre d’étapes. Chaque croquis renvoie au récit qu’il illustre.

Des critères de réception écrits avant le développement

Les critères de réception, ou critères d’acceptation, transforment chaque récit en test, souvent en trois temps : étant donné une situation, quand l’utilisateur agit, alors l’application produit un résultat observable. Exemple : étant donné un technicien hors réseau, quand il valide son rapport, alors celui-ci reste conservé sur le téléphone et part au retour de la connexion.

S’y ajoutent une liste d’appareils de test et une définition partagée de ce qui est terminé. La recette, phase de vérification par l’entreprise, devient un pointage plutôt qu’un débat, comme dans un audit technique de site web mené avec une grille posée d’avance.

Les défauts qui rendent le document inutilisable

Un cahier des charges d’application mobile peut être long, soigné et pourtant inexploitable. Les défauts les plus fréquents :

• imposer une solution technique au lieu de décrire le besoin ;
• employer des adjectifs invérifiables : « intuitive » ou « rapide » ne se testent pas, un nombre d’étapes si ;
• empiler des fonctionnalités sans priorité, ce qui rend les réponses incomparables ;
• taire l’existant et la qualité des données ;
• reprendre un modèle téléchargé sans l’adapter ;
• laisser le document sans responsable pour trancher les questions du prestataire.

Le document vit jusqu’à la livraison : chaque décision prise en cours de route y est reportée et datée, faute de quoi la réception perd sa référence.

Prochaine étape : rédiger le contexte, l’objectif et les cinq parcours principaux, puis les faire relire par un futur utilisateur. Une fois la première version stabilisée, les réponses des prestataires deviennent comparables, et notre analyse du coût réel d’une application d’entreprise aide à lire leurs écarts.