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

Un bon cahier des charges d’application mobile explique à qui sert l’application, ce que l’utilisateur doit pouvoir y faire, et ce qui est indispensable dès la première version. Il n’a pas besoin d’être long ni technique : quelques pages claires valent mieux qu’un document épais que personne ne relit. Voici comment le construire, partie par partie, et les points que l’on oublie presque toujours.

À quoi sert un cahier des charges d’application mobile ?

Le cahier des charges est le document qui décrit votre projet avant le développement. Il a trois usages concrets :

• obtenir des propositions comparables : si vous consultez plusieurs prestataires, ils répondent à la même demande, et vous pouvez comparer leurs réponses ;
• clarifier vos propres idées : en écrivant, on découvre les questions qu’on ne s’était pas posées (qui peut créer un compte ? que se passe-t-il sans réseau ?) ;
• servir de référence pendant le projet : quand une demande nouvelle apparaît, on sait si elle était prévue ou non.

Il ne remplace pas la discussion avec l’équipe qui développera. Il lui donne une base solide, qu’elle complétera de ses questions et de ses propositions.

Commencer par le problème et les utilisateurs

La première page ne parle pas d’écrans ni de technologie. Elle répond à trois questions :

1. Quel problème l’application résout-elle ? En une ou deux phrases. Par exemple : « Nos clients nous appellent pour savoir où en est leur commande ; nous voulons qu’ils le voient eux-mêmes. »
2. Qui va l’utiliser ? Vos clients, vos équipes sur le terrain, le grand public ? Avec quel niveau d’aisance sur téléphone ? Une application pour des techniciens qui travaillent avec des gants ne se conçoit pas comme une application pour des étudiants.
3. Comment saurez-vous qu’elle fonctionne ? Moins d’appels, plus de commandes, des rapports d’intervention envoyés le jour même : un ou deux critères mesurables suffisent.

Si vous ne devez écrire qu’une page, écrivez celle-ci. Un développeur expérimenté peut proposer des fonctionnalités à partir d’un problème bien décrit ; l’inverse est beaucoup plus difficile.

Comment décrire les fonctionnalités ?

La méthode la plus simple consiste à raconter ce que fait chaque type d’utilisateur, en petites phrases : « Le client reçoit une notification quand sa commande est prête, pour ne pas se déplacer pour rien. » Chaque phrase dit qui agit, ce qu’il fait et pourquoi. Les équipes de développement appellent souvent ces phrases des « récits utilisateur ».

Regroupez ensuite ces phrases par parcours : s’inscrire, commander, payer, suivre, contacter. Pour chaque parcours, notez les cas particuliers : mot de passe oublié, paiement refusé, commande annulée.

Enfin, classez chaque fonctionnalité par priorité. Le tableau suivant, inspiré de la méthode dite MoSCoW, est un bon point de départ :

Priorité	Signification	Exemple pour une application de commande
Indispensable	Sans elle, l’application n’a pas de sens	Consulter la carte et passer commande
Importante	Attendue rapidement, mais peut suivre de peu	Paiement en ligne
Souhaitable	Apporte un confort réel	Commander à nouveau en un geste
Plus tard	Bonne idée, mais pas pour la première version	Programme de fidélité

Ce classement est la partie la plus utile du document. Il permet de construire une première version solide et de la publier vite, plutôt que de tout attendre en même temps. Les fonctionnalités classées « plus tard » ne sont pas abandonnées : elles forment déjà la liste des versions suivantes.

Les écrans et les contenus

Vous n’avez pas besoin de maquettes professionnelles. Des croquis sur papier, photographiés, ou des captures d’applications que vous aimez, avec une note sur ce qui vous plaît, sont très parlants. Indiquez aussi :

• votre identité visuelle : logo, couleurs, polices, si elles existent ;
• les contenus : qui écrit les textes, qui fournit les photos, qui les met à jour ;
• les langues : une seule, ou plusieurs dès le départ ;
• l’accessibilité : taille de texte réglable, contrastes, utilisateurs âgés ou malvoyants si c’est votre public.

Ce qu’on oublie presque toujours

Ces points pèsent lourd dans le projet et sont rarement écrits :

Le back-office

Qui ajoute un produit, modifie un horaire, répond à un message, consulte les inscrits ? Il faut presque toujours une interface d’administration, sur ordinateur, pour faire vivre l’application sans toucher au code. Décrivez qui l’utilisera et ce qu’il doit pouvoir y faire.

Les comptes et leur suppression

Si l’application permet de créer un compte, elle doit aussi permettre de le supprimer depuis l’application : c’est une exigence écrite des règles de l’App Store (section 5.1.1). Google Play demande également un chemin dans l’application et un lien web pour demander la suppression du compte et des données. Mieux vaut le prévoir dès le départ.

Les paiements

Les règles diffèrent selon ce que vous vendez. Pour débloquer un contenu ou une fonction numérique dans l’application (un abonnement, une version complète), Apple impose en règle générale son système d’achat intégré. Pour un bien physique ou un service consommé en dehors de l’application (un repas, une course, une intervention), il faut au contraire un autre moyen de paiement, comme une carte bancaire ou Apple Pay. Précisez ce que vous vendez, et le prestataire vous dira quel circuit s’applique.

Les notifications

Lesquelles, à quel moment, envoyées automatiquement ou par quelqu’un de votre équipe ? Une notification de trop pousse l’utilisateur à les couper toutes.

Les données personnelles

Listez les données collectées et pourquoi : nom, adresse, position, photos. Chaque donnée doit avoir une raison. L’App Store et Google Play exigent une politique de confidentialité, et le RGPD s’applique dès que vous traitez des données de personnes en Europe. La CNIL publie un guide RGPD pour les équipes de développement qui aide à poser les bonnes questions.

Les contraintes techniques et la propriété

Quelques informations orientent fortement les choix techniques :

• iPhone, Android ou les deux ; avec une technologie comme Flutter, une seule base de code sert les deux plateformes (nous comparons les approches dans Application native ou hybride) ;
• le fonctionnement sans réseau : un technicien en sous-sol doit-il pouvoir remplir un rapport hors connexion ?
• les outils existants : logiciel de caisse, agenda, CRM, ERP avec lesquels l’application doit échanger ;
• les fonctions du téléphone : appareil photo, géolocalisation, Bluetooth, paiement sans contact.

Écrivez aussi ce qui doit vous appartenir à la fin du projet : le code source, les comptes développeur Apple et Google à votre nom, le serveur, le nom de domaine, la documentation. Ce point évite bien des difficultés le jour où vous voudrez changer de prestataire ou reprendre la main.

Budget, délais et publication

Même sans chiffre précis, donnez un ordre de grandeur de votre enveloppe et une date qui compte vraiment pour vous : un salon, une saison, l’ouverture d’un magasin. Un prestataire sérieux vous dira ce qui est réaliste dans ce cadre et ce qu’il faudrait reporter.

Pensez enfin à la publication : les fiches des stores, les captures d’écran, les délais de validation par Apple et Google. Nos articles sur la publication sur l’App Store et sur Google Play détaillent ces étapes.

Les erreurs fréquentes

• Décrire la solution au lieu du besoin : « un bouton rouge en haut à droite » plutôt que « l’utilisateur doit pouvoir appeler l’agence en urgence ».
• Tout mettre en priorité haute : si tout est indispensable, rien ne l’est, et la première version n’arrive jamais.
• Copier une application célèbre : ses fonctions répondent à son public et à ses moyens, pas forcément aux vôtres.
• Oublier l’après : mises à jour pour les nouvelles versions d’iOS et d’Android, corrections, évolutions. Une application se fait vivre.

Questions fréquentes

Quelle longueur doit faire un cahier des charges d’application ?

Pour une première version, cinq à quinze pages suffisent souvent. La longueur compte moins que la clarté : un problème bien posé, des parcours décrits et des priorités tranchées.

Faut-il des maquettes dans le cahier des charges ?

Elles ne sont pas obligatoires. Des croquis, des captures d’applications existantes et des descriptions de parcours suffisent pour démarrer ; les maquettes détaillées sont généralement réalisées ensuite, avec l’équipe qui conçoit l’application.

Peut-on faire évoluer le cahier des charges en cours de projet ?

Oui, et c’est normal : les premiers tests sur téléphone font toujours apparaître des ajustements. L’important est de noter chaque changement et d’en mesurer l’effet sur le délai, pour décider en connaissance de cause.

Le prestataire peut-il nous aider à le rédiger ?

Oui. Beaucoup de projets commencent par un simple échange où l’on décrit son activité et son problème. Le prestataire pose les questions qui manquent et propose une première liste de fonctionnalités, que vous validez.

Vous n’avez pas encore de cahier des charges ? Ce n’est pas un obstacle pour commencer. Décrivez-nous votre activité et ce que l’application doit changer pour vos clients ou vos équipes sur la page Parler de votre projet ; la page Applications mobiles présente notre manière de mener un projet, de la première maquette jusqu’aux stores.