Cahier des charges application mobile : modèle d'une page

Cahier des charges d'une application mobile : la réponse courte

Un bon cahier des charges d'application mobile, quand tu crées ta propre app, tient sur une page. Il répond à dix questions : pour qui, quel problème, quelle fonction principale, comment l'app gagne de l'argent, ce qui se passe sans compte, quelles données doivent survivre, sur quelle plateforme, ce qui est hors de la première version, comment tu sauras que ça marche, et avec quelles contraintes. Le modèle à copier est plus bas. Tu peux aussi télécharger la trame et sa grille de validation (.md), sans inscription.

Les modèles de 40 pages que tu trouves en ligne sont écrits pour un autre usage : un client qui commande une app à un prestataire et qui a besoin d'un document contractuel. Toi, tu es à la fois celui qui décide et celui qui construit, souvent avec l'aide de l'IA. Ton cahier des charges sert à deux choses : trancher les décisions avant de coder, et donner à Claude, ChatGPT ou Cursor un contexte clair pour qu'ils construisent la bonne app.

Je publie mes propres apps iOS. Solys, un réveil à mini-jeux, et TradaZen, un simulateur de trading, sont sur l'App Store. Nolera et Clic ont été refusées par Apple, puis corrigées. C'est la méthode que j'applique à chacune d'elles, et c'est celle que je te propose ici.

Pourquoi une page suffit pour cadrer ta propre app

Un long document donne l'impression d'avoir avancé. En pratique, il est écrit une fois, rarement relu, et le projet s'en écarte dès les premières semaines. Une page, au contraire, se relit en deux minutes avant chaque session de travail.

La contrainte d'espace a aussi un effet utile : elle t'oblige à décider. Si une réponse dépasse deux phrases, c'est souvent que la décision n'est pas prise. Mieux vaut le découvrir sur une feuille que dans ton code, trois semaines plus tard.

Enfin, une page est la bonne taille pour l'IA. Tu peux la coller en entier dans une conversation, ou la ranger dans le fichier de contexte de ton projet. Un document court facilite la relecture et réduit les consignes contradictoires. Il ne garantit pas que l'IA les suivra : vérifie ses propositions par rapport à ce cadre.

Que doit contenir un cahier des charges pour une application mobile ?

Réponds à chacune de ces questions en une ou deux phrases.

1. Qui utilise l'app, et dans quelle situation ? Pas « les 18-35 ans ». Plutôt une personne précise, à un moment précis de sa journée.
2. Quel problème l'app résout-elle, en une phrase ? Si tu as besoin de « et aussi », tu décris deux apps.
3. Quelle est LA fonction principale de la première version ? Une seule. Les autres attendront les chiffres. La page MVP d'application iOS explique comment choisir.
4. Comment l'app gagne-t-elle de l'argent ? Abonnement, achat unique ou gratuite. Cette réponse change l'app dès le premier écran. Si tu hésites, lis abonnement ou achat unique pour une app iOS.
5. Que peut-on faire sans créer de compte ? Décider tôt ce qui est accessible sans inscription t'évite de refaire tout le parcours d'arrivée.
6. Quelles données doivent survivre à un changement de téléphone ? C'est la question qui décide si tu as besoin d'un backend comme Supabase, ou si tout peut rester sur l'appareil.
7. iOS seulement, ou iOS et Android ? Mon conseil quand tu débutes : iOS d'abord. Je détaille pourquoi dans app iOS et Android en même temps.
8. Qu'est-ce qui est explicitement HORS de la première version ? La section la plus utile du document. Elle coupe les débats avant qu'ils n'existent, avec toi‑même comme avec l'IA.
9. Comment sauras-tu que ça marche ? Un seul signal, mesurable dans les semaines qui suivent la sortie : des essais gratuits démarrés, des abonnés, des utilisateurs qui reviennent.
10. Quelles sont tes contraintes réelles ? Le temps que tu peux y consacrer chaque semaine, ton matériel, et ton compte Apple Developer, qui coûte 99 $ par an. Pas de Mac ? Ce n'est pas bloquant, comme je l'explique dans publier une app iOS sans Mac.

Le modèle de cahier des charges à copier

Copie ce modèle dans une note ou dans un fichier texte à la racine de ton projet, puis remplace chaque ligne.

• Nom provisoire de l'app : …
• Pour qui : une personne qui … au moment où …
• Problème résolu, en une phrase : …
• Fonction principale de la version 1 : …
• Ce que l'utilisateur voit en ouvrant l'app pour la première fois : …
• Modèle économique : abonnement / achat unique / gratuit, et ce qui est payant : …
• Sans compte, on peut : …
• Données à conserver entre deux téléphones : aucune / …
• Plateforme : iOS d'abord (Android plus tard si les chiffres suivent)
• Hors version 1 : …, …, …
• Signal de réussite : …
• Stack : React Native, Expo, Supabase si besoin de comptes, RevenueCat pour les abonnements
• Contraintes : … heures par semaine, compte Apple Developer ouvert ou non, Mac ou non
• Apps dont j'aime l'expérience, et pourquoi : …

Ajoute trois à cinq captures d'apps que tu aimes, avec un mot sur ce qui te plaît. C'est plus parlant qu'une charte graphique, pour toi comme pour l'IA.

Un cahier des charges n'est pas une liste de souhaits. C'est une liste de décisions prises.

Exemple : la page remplie pour une app fictive

Pour voir le niveau de détail attendu, voici le modèle rempli pour une app inventée pour l'exemple, un minuteur de révision.

• Pour qui : un étudiant qui révise seul le soir et décroche au bout de dix minutes.
• Problème : il n'arrive pas à tenir une séance de travail sans toucher à son téléphone.
• Fonction principale : lancer une séance chronométrée et voir sa série de jours tenus.
• Premier écran : un seul bouton pour démarrer une séance.
• Modèle économique : abonnement pour les statistiques détaillées, séance de base gratuite.
• Sans compte : tout, sauf la sauvegarde entre deux téléphones.
• Hors version 1 : mode groupe, classement entre amis, widgets, version Android.
• Signal de réussite : des utilisateurs qui reviennent plusieurs jours de suite.

Remarque ce qui manque volontairement : aucune liste de vingt écrans, aucune couleur imposée, aucune architecture. Ces choix viendront en construisant, et la page te sert à vérifier qu'ils restent au service de la fonction principale.

Comment utiliser ton cahier des charges pour guider l'IA

C'est là que ta page rapporte le plus. Une IA qui code sans contexte devine, et elle devine souvent une autre app que la tienne.

Mets la page dans le contexte permanent du projet. Claude Code lit un fichier CLAUDE.md à la racine, Cursor a ses propres fichiers de règles. Colle-y ton cahier des charges, avec ta stack. Chaque demande part alors de la même base.

Cite la section « hors version 1 » quand l'IA en fait trop. Les assistants proposent volontiers des fonctions en plus : un mode sombre, un partage, une notification. Ta liste d'exclusions te donne une réponse toute faite : pas maintenant.

Demande un plan qui respecte la page. Avant un gros chantier, écris : « voici mon cahier des charges, propose un plan pour la fonction principale, ne code pas encore ». Tu repères tout de suite si le plan s'éloigne de ce que tu as décidé.

Fais-lui relire la page, pas seulement le code. Demande : « quelles questions de ce cahier des charges sont floues ou contradictoires ? ». C'est un usage sous-estimé de l'IA, et il t'évite des semaines de travail dans la mauvaise direction.

Pour aller plus loin sur ce sujet, j'ai détaillé les pièges et les vérifications dans créer une app iOS avec l'IA.

Transformer les décisions en critères de validation

Une fonction principale doit avoir un résultat observable. Pour le minuteur fictif de cet exemple, « le minuteur fonctionne » est trop vague. Écris plutôt : « Je lance une séance, le temps restant s'affiche, je peux l'arrêter et retrouver la dernière séance terminée après avoir rouvert l'app. » Décide séparément si le minuteur doit continuer écran verrouillé : ce choix peut changer le travail technique.

Ajoute pour chaque fonction trois lignes : action, résultat attendu, preuve. La preuve peut être un test automatisé pour un calcul ou une vérification sur appareil pour un parcours. Note aussi ce qui n'a pas été testé. Cette petite grille évite de confondre un écran terminé et une fonction prête à être utilisée.

Voici une grille remplie pour notre minuteur fictif. Ce sont des critères à vérifier, pas des tests déjà réussis :

Décision du cadrage	À tester	Résultat attendu
La séance de base est accessible sans compte	Installer l'app et lancer une séance sans s'inscrire	Aucun formulaire d'inscription ne bloque le démarrage
Une séance abandonnée ne compte pas dans la série	Arrêter une séance avant sa fin, puis ouvrir l'historique	Aucune séance terminée n'est ajoutée
L'historique reste sur l'appareil	Terminer une séance, fermer puis rouvrir l'app	La séance apparaît une seule fois avec la bonne durée
Le minuteur de base fonctionne sans réseau	Activer le mode avion et terminer une séance	Le minuteur et l'enregistrement local restent utilisables
Les statistiques détaillées sont payantes	Ouvrir les statistiques sans abonnement	L'offre s'affiche ; la séance de base reste accessible

Les sujets encore flous deviennent des décisions à prendre. Par exemple : que faire si l'utilisateur verrouille l'écran ou change l'heure du téléphone pendant une séance ? Ne laisse pas l'agent choisir silencieusement. Écris le comportement voulu, puis ajoute le cas à la grille. Pour organiser cette recette sur une vraie installation, utilise le guide tester son app iPhone avec TestFlight.

Décider quoi retirer quand la première version déborde

Reprends chaque fonction et pose une question : « Sans elle, l'utilisateur peut-il encore obtenir le résultat promis ? » Pour notre minuteur, un classement entre amis peut attendre. Retrouver une séance terminée est nécessaire si tu promets une série de jours. Un écran d'abonnement devient nécessaire seulement si tu commercialises effectivement les statistiques dès cette version.

Note la décision et sa raison dans le journal du modèle téléchargeable. Tu pourras revenir sur ce choix après des tests, sans perdre le pourquoi du périmètre initial. Le tutoriel créer une application avec Claude Code montre ensuite comment transformer ce cadrage en demandes limitées et vérifiables.

Pour un retour de terrain, TradaZen a changé de périmètre après sa publication. Le cadrage sert à sortir une première version mesurable, puis à décider de la suivante avec des retours réels.

Le piège du catalogue de fonctionnalités

Le réflexe naturel est de lister tout ce que l'app « devra faire » : la carte, le chat, les notifications, le parrainage, le mode hors ligne. Ce catalogue est le signe le plus fiable d'un projet qui n'aboutit pas, pour une raison simple : chaque fonction ajoutée avant la sortie retarde le moment où de vrais utilisateurs te disent ce qui compte.

Une bonne première version fait une chose, et la fait bien. Attention quand même à l'excès inverse : Apple demande qu'une app aille au-delà d'un site web emballé, selon la règle 4.2 des App Review Guidelines. Une seule fonction principale, oui ; une coquille vide, non : c'est le motif de la guideline 4.2.

Ce qu'un cahier des charges d'app mobile ne doit pas contenir

• Une charte graphique complète. Quelques captures de référence suffisent au départ.
• Un planning jour par jour. Tu n'as pas encore les informations pour le tenir. Un objectif de semaine suffit.
• Une architecture technique détaillée. Choisis une stack éprouvée, puis laisse les détails se décider en construisant.
• Des fonctions « pour plus tard » mélangées au reste. Elles vont toutes dans la section hors version 1.

Quand mettre à jour ton cahier des charges ?

Relis-le au début de chaque semaine de travail. Mets-le à jour seulement quand une décision change pour une vraie raison : un test sur ton iPhone qui montre qu'un écran ne marche pas, un retour de testeur, une contrainte d'Apple découverte en route. Si tu le modifies tous les jours, c'est qu'il ne cadre plus rien.

Une fois la première version publiée, la page devient la base de la suivante : ce qui était hors version 1 remonte, trié par ce que les chiffres te disent. La vue d'ensemble du parcours, de l'idée à la publication, est sur la page créer une application iPhone.

Passer de la page à l'app publiée

Si tu as répondu aux dix questions, tu as déjà fait le travail que beaucoup de projets sautent. La suite, c'est construire la fonction principale, la tester sur ton iPhone, brancher les abonnements et préparer le dossier pour Apple.

Ce parcours est celui du Kit iOS, en quatre étapes à suivre à ton rythme : la première sert à choisir l'app qui peut rapporter, son public et son prix, et ton cahier des charges en est le point de départ.

Tu ne sais pas si ton idée est prête à tenir sur une page ? Le diagnostic gratuit te dit ce qui bloque ton projet aujourd'hui et quelle étape attaquer d'abord. L'accueil montre ensuite comment créer une app mobile à partir de ce cadrage, avec Claude Code.

Je ne te promets ni revenu ni publication : c'est Apple qui valide, et le marché qui décide du reste. Sans le kit, ce modèle te suffit pour démarrer.

Questions fréquentes

Comment rédiger un cahier des charges pour une application mobile ?

Tiens ton cahier des charges sur une page : dix questions, une ou deux phrases par réponse. Elles portent sur le public, le problème, la fonction principale, le modèle économique, ce qui se passe sans compte, les données qui doivent survivre, la plateforme, ce qui est hors de la première version, le signal de réussite et les contraintes. Si une réponse dépasse deux phrases, c'est souvent que la décision n'est pas prise.

Quel logiciel utiliser pour rédiger un cahier des charges d'application ?

Une simple note ou un fichier texte à la racine de ton projet : tu y copies le modèle, puis tu remplaces chaque ligne. Tu peux aussi télécharger la trame et sa grille de validation (.md), sans inscription. Pour guider une IA, range-le ensuite dans le fichier de contexte de ton projet.

Faut-il un cahier des charges de 40 pages pour une application ?

Non, quand tu crées ta propre app : une page suffit. Les modèles de 40 pages qu'on trouve en ligne sont écrits pour un client qui commande une app à un prestataire et qui a besoin d'un document contractuel. Toi, tu décides et tu construis : ta page sert à trancher les décisions avant de coder et à donner du contexte à l'IA.

Comment donner son cahier des charges à une IA qui code ?

Mets la page dans le contexte permanent du projet : Claude Code lit un fichier CLAUDE.md à la racine, Cursor a ses propres fichiers de règles. Cite la section « hors version 1 » quand l'IA en fait trop. Avant un gros chantier, demande un plan qui respecte la page, sans coder tout de suite.

Comment vérifier qu'une fonction respecte le cahier des charges ?

Ajoute pour chaque fonction trois lignes : l'action, le résultat attendu et la preuve. La preuve peut être un test automatisé pour un calcul, ou une vérification sur appareil pour un parcours. Note aussi ce qui n'a pas été testé, pour ne pas confondre un écran terminé et une fonction prête à être utilisée.

Que ne faut-il pas mettre dans un cahier des charges d'application ?

Quatre choses à éviter : une charte graphique complète, un planning jour par jour, une architecture technique détaillée, et des fonctions « pour plus tard » mélangées au reste. Quelques captures de référence suffisent au départ, et un objectif de semaine suffit pour le planning. Les fonctions pour plus tard vont toutes dans la section hors version 1.