Cahier des charges pour application mobile : le guide complet

Tout le monde vous dit de rédiger un cahier des charges avant de contacter une agence. C'est le conseil qu'on lit partout. C'est aussi le conseil qui fait le plus de dégâts sur les projets d'application mobile en 2026.

Notre agence de création d'application mobile firstapp traite des dizaines de demandes par mois. On a longtemps demandé des cahiers des charges. On a arrêté. Cet article vous explique ce qu'un bon cahier des charges doit contenir, et pourquoi, chez firstapp, on fait différemment.

‍

Les 7 sections indispensables

1. Contexte et objectifs business

C'est la section que la plupart des fondateurs bâclent. C'est pourtant la plus importante.

Décrivez quel problème votre app résout, pour qui, et pourquoi maintenant. Précisez vos objectifs business à 6 et 12 mois : nombre d'utilisateurs actifs, MRR cible, taux de conversion visé. Une agence qui ne comprend pas vos objectifs business ne pourra pas faire les bons arbitrages quand il faudra choisir entre deux fonctionnalités.

2. Cible utilisateur et cas d'usage

Décrivez votre utilisateur cible en détail : âge, comportement mobile, contexte d'utilisation. Puis listez les 3 à 5 cas d'usage principaux dans l'ordre de priorité, pas une liste de fonctionnalités, des scénarios concrets. "Un utilisateur ouvre l'app pour la première fois et comprend la valeur en moins de 2 minutes" est un cas d'usage. "Page d'accueil avec liste de produits" est une fonctionnalité.

3. Fonctionnalités par priorité (MVP vs V2)

Utilisez une matrice simple à deux colonnes :

MVP (lancement) : les fonctionnalités sans lesquelles l'app n'a pas de valeur.V2 (post-lancement) : les fonctionnalités qui enrichissent l'expérience mais ne bloquent pas le lancement.

La règle : si une fonctionnalité ne contribue pas directement à la conversion ou à la rétention, elle va en V2. Pour comprendre ce qui drive vraiment les revenus d'une app, lisez notre article sur la stratégie de paywall mobile.

4. Choix technologiques et contraintes

Précisez vos contraintes : stack imposée, API existante, exigences de sécurité. Si vous n'avez pas d'avis sur la technologie, dites-le. Chez firstapp, le choix par défaut est React Native — une seule base de code iOS + Android, des coûts réduits de 20 à 40% et un écosystème de monétisation mature. Pour comprendre pourquoi ce choix compte, lisez notre article sur les agences React Native.

5. Stratégie de monétisation et paywall

C'est la section la plus souvent absente. Et la plus critique.

Selon le State of Subscription Apps 2026 de RevenueCat, les apps avec un hard paywall convertissent 5 fois mieux que les apps freemium à la médiane (10.7% vs 2.1% à J35). Ce choix doit être fait avant de designer le moindre écran. Décrivez votre modèle : abonnement mensuel ou annuel, freemium, trial. Si vous hésitez encore, notre article sur freemium vs abonnement vs achat unique vous donnera les éléments pour décider.

6. Intégrations tierces

Listez les services externes : RevenueCat ou Adapty pour les abonnements, analytics, push notifications, authentification sociale, APIs spécifiques à votre secteur. Chaque intégration représente des jours de développement supplémentaires. Une intégration oubliée dans le cahier des charges = une ligne de facturation surprise en cours de projet.

7. Critères de succès et métriques cibles

Définissez comment vous mesurerez le succès 3 mois après le lancement : taux de conversion du trial, MRR, DAU, note App Store, rétention à J30. Cette section force une réflexion saine sur ce qui compte vraiment et permet à l'agence d'aligner ses choix sur vos vrais objectifs.

‍

Ce qu'on oublie toujours

L'onboarding

Presque personne ne décrit son onboarding dans le cahier des charges initial. C'est pourtant l'écran le plus important de votre app. Selon RevenueCat, 55% des annulations de trial arrivent au Jour 0, avant même que l'utilisateur ait utilisé l'app. Décrivez le parcours envisagé pour un nouvel utilisateur, même approximativement. Notre guide sur l'optimisation de l'onboarding mobile vous donnera une base de réflexion.

Les états d'erreur et cas limites

Que se passe-t-il si l'utilisateur perd sa connexion au milieu d'une transaction ? Si son paiement échoue ? Ces cas représentent plusieurs jours de développement s'ils ne sont pas anticipés.

La stratégie ASO

Le nom de l'app, sa description sur les stores, ses mots-clés, ça se décide avant le lancement et ça impacte directement votre visibilité organique. La plupart des fondateurs y pensent trois jours avant la soumission. C'est trop tard.

Le plan post-lancement

Qui sont vos premiers 100 utilisateurs ? Comment les acquérez-vous ? Une agence ne peut pas répondre à ces questions à votre place, mais elle peut aligner certains choix de développement si elle connaît votre plan de lancement.

‍

Les erreurs qui font exploser les budgets

⚠️ Ces erreurs dans un cahier des charges coûtent cher :

Lister des fonctionnalités sans priorité. Quand tout est "essentiel", l'agence ne peut pas faire d'arbitrage. Résultat : un devis maximal qui inclut tout, ou un projet qui dérive faute de cadre clair.

Décrire le "quoi" sans le "pourquoi". "L'app doit avoir un système de gamification" sans expliquer l'objectif ne permet pas à l'agence de vous challenger ou de proposer une alternative plus efficace.

Oublier la maintenance dans le scope. Qui gère les mises à jour iOS quand Apple change ses guidelines ? Si ça n'est pas dans le cahier des charges, ça ne sera pas dans le devis. Notre article sur le devis application mobile détaille tous ces postes de coût.

Confondre MVP et "version complète moins quelques features". Un vrai MVP est la version minimale qui valide votre hypothèse business, pas une app complète à laquelle vous avez retiré trois fonctionnalités.

‍

Le problème des cahiers des charges générés par IA

⚠️ Ce phénomène détruit des budgets en 2026.

Depuis que ChatGPT et ses concurrents sont accessibles à tous, on voit arriver une nouvelle catégorie de cahiers des charges : des documents de 20 à 40 pages, générés en quelques minutes, qui semblent ultra-complets et ultra-professionnels.

Le problème ? L'IA ne connaît pas votre budget.

Elle ajoute tout ce qu'un cahier des charges "devrait" contenir selon ses données d'entraînement : système de notifications avancé, tableau de bord analytics, module de gamification, gestion multi-langues, mode offline, intégrations sociales... Le fondateur reçoit le document, voit 35 pages bien structurées et pense qu'il a fait un travail sérieux. L'agence reçoit ce document et doit annoncer un budget de 80 000€ pour un projet qui en vaut 20 000€ sans les 15 fonctionnalités que l'IA a inventées.

On a reçu des cahiers des charges générés par IA avec des sections entières sur des fonctionnalités que le fondateur n'avait jamais envisagées, ne voulait pas, et ne pouvait pas financer. Mais comme le document avait l'air sérieux, personne n'osait remettre en question le scope.

Un cahier des charges généré par IA n'est pas un cahier des charges. C'est une liste de souhaits sans filtre budgétaire. Et c'est la première raison pour laquelle chez firstapp, on a arrêté d'en demander.

‍

Ce qu'on fait chez firstapp à la place

Chez firstapp, on a arrêté de demander des cahiers des charges. Pas par paresse, par conviction.

Un fondateur qui écrit son cahier des charges seul passe des semaines à formaliser des hypothèses qui n'ont jamais été confrontées à la réalité technique et budgétaire. Et quand l'agence reçoit le document, elle passe ensuite des heures à désosser le scope pour proposer quelque chose de cohérent.

Notre approche : un premier call, puis un workshop design sur Figma.

Le premier call dure 30 à 45 minutes. On pose les questions qui comptent : quel problème vous résolvez, pour qui, avec quel modèle économique, quel budget, quel délai. Pas de formulaire, pas de document à remplir. Une conversation directe.

Si le projet est aligné avec notre expertise, on enchaîne sur un workshop design sur Figma. On pose ensemble les bases visuelles et fonctionnelles de l'app : les premiers écrans, le parcours onboarding, la structure du paywall, les features MVP. En 2 heures, on produit plus de clarté qu'un cahier des charges de 20 pages.

Pourquoi Figma et pas un document ? Parce qu'un écran parle plus qu'une page de specs. Quand vous voyez votre onboarding dessiné, vous comprenez immédiatement ce qui manque, ce qui est superflu, et ce qui compte vraiment. Vous prenez des décisions sur du concret, pas sur des hypothèses.

Ce workshop nous permet de vous proposer un devis précis, ligne par ligne, sans surprise budgétaire. Pour comprendre ce que ça représente en termes de coût global.

Si vous cherchez à comparer les approches des agences avant de choisir, notre top 10 des meilleures agences de création d'application mobile vous donne une vue d'ensemble des acteurs francophones, et les critères pour les évaluer.

‍

Vous avez un projet ? On commence par un call.

Pas besoin de cahier des charges. Envoyez-nous votre projet en quelques lignes, on organise un premier call de 30 minutes, et si c'est aligné, on enchaîne sur un workshop design Figma.

‍

FAQ - Ce que tout le monde se demande

Faut-il absolument un cahier des charges pour contacter une agence de création d'application mobile ?

Non. Un brief d'une page suffit pour un premier contact sérieux : contexte du projet, cible utilisateur, modèle de monétisation envisagé et budget indicatif. Chez firstapp, on préfère un premier call direct suivi d'un workshop design sur Figma plutôt qu'un long document rédigé dans le vide. Ce qui compte, c'est la qualité de la réflexion, pas la longueur du document.

Est-ce qu'un cahier des charges généré par ChatGPT est utilisable ?

Comme point de départ pour organiser vos idées, oui. Comme document envoyé à une agence, non. L'IA génère des fonctionnalités que vous n'avez pas demandées et qui feront gonfler votre devis inutilement. Relisez chaque ligne et demandez-vous : "est-ce que j'ai vraiment besoin de ça pour lancer ?" Supprimez impitoyablement tout ce qui ne répond pas directement à cette question.

Combien de pages doit faire un cahier des charges d'application mobile ?

Entre 5 et 10 pages pour la grande majorité des projets. En dessous de 5 pages, le document est probablement trop vague. Au-delà de 15 pages, vous avez sur-spécifié des détails qui devraient être laissés à l'expertise de l'agence — ou vous avez utilisé l'IA sans filtrer. Un document court et précis vaut toujours mieux qu'un document long et approximatif.

Peut-on faire rédiger son cahier des charges par l'agence ?

Oui, c'est souvent la meilleure approche. Chez firstapp, on remplace le cahier des charges par un workshop design sur Figma : on part des vrais besoins, on dessine les premiers écrans ensemble, on pose les bases du MVP en quelques heures. Le résultat est plus utile et plus précis qu'un document de 20 pages rédigé seul.

Doit-on inclure des maquettes dans son cahier des charges d'application mobile ?

Non, sauf si vous avez travaillé avec un designer professionnel. Des maquettes non professionnelles brident la réflexion de l'agence sur l'onboarding et le design. Décrivez les parcours en texte et laissez l'agence proposer l'approche visuelle, c'est pour ça que vous la payez.