Cahier des charges application mobile : les huit décisions qu'il doit contenir

Les modèles de cahier des charges qui circulent en ligne demandent votre email et rendent un document vide. Les huit décisions ci-dessous sont celles qu'un prestataire ou une équipe d'agents vous demandera de toute façon, et que personne ne peut prendre à votre place.

Tapez « cahier des charges application mobile » dans un moteur de recherche : vous tomberez sur des modèles Word échangés contre une adresse email, tous bâtis sur le même sommaire vide (relevé français, septembre 2026). Un dossier utile tranche huit décisions que vous seul pouvez prendre.

Ce que les modèles gratuits ne demandent jamais

Un gabarit vous propose des rubriques : contexte, objectifs, fonctionnalités, planning, budget. Vous les remplissez, vous obtenez un document qui se lit bien et qui ne décide de rien, parce qu'aucune rubrique ne vous a mis devant un arbitrage. Le prestataire qui reçoit ce document devra poser les vraies questions au premier rendez-vous, ou pire, y répondre seul. Les huit décisions qui suivent se prennent en une soirée, à condition d'accepter d'écrire une réponse plutôt qu'une intention. Chacune se formule en deux phrases, et chacune coûte cher si on la découvre après la construction.

Un et deux : la forme, et le hors réseau

Décision une : une application des boutiques, avec une icône sur l'écran d'accueil, ou un site que vos utilisateurs ouvrent depuis leur navigateur. La première ouvre l'appareil photo, les notifications et le paiement intégré, et elle vous engage dans deux processus de revue avec Apple et Google, plus des mises à jour à faire valider. La seconde se met à jour quand vous voulez et s'ouvre depuis n'importe quel appareil. Beaucoup de projets choisissent la boutique par réflexe alors que leur usage tient dans un navigateur ; Maestro ne construit d'ailleurs que des produits web, et nous l'écrivons quand la question se pose. Décision deux : ce qui doit fonctionner sans réseau. Un livreur dans un parking souterrain, un technicien en cave, un vendeur sur un marché : si l'un d'eux figure dans votre histoire, le travail hors ligne se décide maintenant, car il change la façon dont l'application est construite de fond en comble.

Trois et quatre : les droits, et ce qui arrive tout seul

Décision trois : qui a le droit de faire quoi. Nommez les rôles avec vos mots (le patron, l'assistante, le saisonnier), puis écrivez pour chacun ce qu'il voit, ce qu'il crée et ce qu'il ne doit jamais pouvoir supprimer. C'est la partie que les générateurs traitent le plus mal, parce qu'elle ne se voit pas à l'écran. Décision quatre : ce qui arrive sur le téléphone de vos utilisateurs sans qu'ils ouvrent l'application. Une notification de rendez-vous la veille au soir, un rappel d'échéance, une alerte quand un stock passe sous un seuil. Écrivez le déclencheur, l'heure et le destinataire de chaque message ; le reste suivra. Une application qui envoie trop se désinstalle en une semaine.

Cinq et six : les données, et l'argent

Décision cinq : où vivent les données et qui peut les sortir. Nommez ce que vous stockez de sensible (coordonnées de clients, photos de chantier, dossiers de santé), dites dans quel pays cela doit rester, et exigez un export lisible de tout, dans un format que vous ouvrez sans l'application. Décision six : le paiement. Encaisser à l'intérieur d'une application des boutiques passe par les règles d'Apple et de Google et par leur commission ; encaisser par un lien envoyé au client, ou hors application, change ces règles. Écrivez qui paie quoi, quand, et ce qui se passe pour un remboursement, avant que quiconque dessine un bouton. La question du prix global se traite à part, dans le calcul de ce que coûte un développement.

Sept et huit : les ratés, et l'après

Décision sept : ce qui se passe quand ça rate. Le réseau tombe au milieu d'un envoi, deux personnes modifient la même fiche, un utilisateur entre une date impossible. Décrivez le comportement attendu en français pour trois ou quatre cas de ce genre : c'est la partie du dossier qui distingue un produit d'une démonstration. Décision huit : qui répond après la mise en ligne. Une adresse qui reçoit les problèmes, quelqu'un qui les lit, et une idée de la fréquence des mises à jour. Un dossier qui s'arrête au jour du lancement laisse le projet sans propriétaire le lendemain.

Écrire les huit ce soir

Ouvrez un document vierge, écrivez les huit intitulés, et répondez en deux phrases chacun sans chercher le mot juste. Ce que vous n'arrivez pas à trancher, marquez-le d'une croix : ce sont les points à discuter avec votre associé ou votre comptable, et ceux qu'un outil décidera à votre place si vous les laissez vides. Faites relire le résultat par quelqu'un qui n'a pas assisté à vos réflexions, en dix minutes chrono, comme on relit un cahier des charges quand on n'est pas du métier. S'il vous pose une question à laquelle vous n'aviez pas pensé, le document a déjà servi. La suite, la construction, commence par le même exercice avec un outil qui vous interroge au lieu de deviner.