Le guide du premier pas
Cahier des charges d’application mobile : le brief en 7 étapes
Pas besoin d’un cahier des charges de 50 pages pour parler de ton idée. Il te faut surtout un problème précis, un parcours simple et des priorités claires. Voici comment les poser, avec un modèle à remplir.
Par Yoann Guetta et David Bohbot, cofondateurs de Yodavio · Publié le · Mis à jour le
1. Pour qui, et pour résoudre quoi ?
Commence par une phrase : « Mon application aide [un public précis] à [faire quelque chose] quand [une situation se présente]. » Décris ensuite comment ces personnes font aujourd’hui et ce qui les bloque. Une cible comme « tout le monde » rend les décisions de design beaucoup plus difficiles.
Exemple fictif : une personne qui emprunte des livres veut retrouver ses notes de lecture sans chercher dans plusieurs carnets. Son premier besoin est de retrouver un livre et la note associée.
Si tu as déjà parlé à des utilisateurs, distingue leurs retours de tes hypothèses. Quelques observations concrètes aident davantage qu’une liste de fonctionnalités sans contexte.
2. Raconte un seul parcours, du début à la fin
Que fait la personne quand elle ouvre l’app ? Quelle action veut-elle terminer ? Écris les étapes avec des verbes : rechercher un livre, ouvrir sa fiche, ajouter une note, la retrouver. Tu obtiens une première liste d’écrans sans avoir besoin de savoir les dessiner.
Prévois aussi les cas moins visibles : une recherche sans résultat, une connexion perdue ou une donnée manquante. Note si un compte est indispensable dès le départ ou si l’usage peut commencer sans inscription.
Pour voir comment un sujet devient une interface, explore la conception de BOOXS, notre réalisation autour de la lecture, ou les écrans de Talkana pour apprendre le japonais. Ces projets servent de repères visuels ; ton parcours doit répondre à ton propre public.
3. Choisis ce qui entre dans la première version
Une première version, souvent appelée MVP, sert à proposer un usage cohérent et à confronter l’idée au terrain. Trie les fonctions en trois groupes :
- Indispensable : sans cette fonction, le parcours principal ne peut pas aboutir.
- À discuter : elle améliore l’expérience, mais on peut chercher une solution plus simple.
- Plus tard : elle répond à un autre usage ou nécessite d’abord des retours.
Messagerie, notifications, abonnements, intelligence artificielle et espace d’administration demandent chacun des choix supplémentaires. Précise leur rôle plutôt que de les ajouter par réflexe. Une fonction reportée doit être clairement identifiée pour que le périmètre soit compris par tout le monde.
4. Liste ce qui existe et ce qui manque
Indique les appareils visés, les langues, les textes, le logo, les références visuelles et les éventuelles maquettes. Chez Yodavio, on crée des applications iPhone et Android : précise dès le brief si tu vises l’iPhone, Android ou les deux.
Signale aussi les données et services nécessaires : catalogue, connexion à un outil, paiement, contenus audio ou API. Pour chaque élément, note qui le fournit et quand. Ne colle aucun mot de passe ni clé privée dans le brief.
Pour préparer une soumission App Store, Apple demande notamment une app complète, des informations à jour et un accès de démonstration si certaines fonctions nécessitent une connexion. Consulte les consignes officielles App Review et identifie les éléments à préparer avec le studio. Les choix de collecte de données et de confidentialité doivent être anticipés.
5. Pose le budget, les dates et les dépendances
Donne une enveloppe ou un plafond si tu en as un. Si tu n’en as pas encore, dis-le : l’objectif du cadrage est aussi de comprendre ce qu’il faut chiffrer. Le nombre d’écrans ne suffit pas à déterminer un prix ; les connexions à d’autres services, la gestion des données et les fonctions attendues comptent aussi.
Précise si une date correspond à un test, une présentation ou une mise à disposition publique. Note qui valide les écrans, qui fournit les contenus et les moments où cette personne est disponible.
Pour le parcours de 21 jours présenté par Yodavio, le jour 21 correspond à l’envoi de l’app à Apple ou à Google Play. Leur délai de validation vient ensuite et ne dépend pas du studio. Le périmètre et les prérequis de ton projet se cadrent avant de démarrer : vois notre méthode de développement en 4 étapes.
6. Décris comment tu valideras le résultat
Remplace « il faut que ce soit intuitif » par des situations vérifiables. Pour chaque fonction importante, écris ce que l’utilisateur doit pouvoir faire et ce qui doit se passer si l’action échoue.
Exemple fictif de critère : après avoir ajouté une note à un livre, je peux fermer l’app, la rouvrir et retrouver cette note dans la fiche du même livre.
Liste les livrables attendus et les sujets à clarifier : écrans Figma, version à tester sur iPhone, soumission App Store, accès aux fichiers et au code, puis besoins de maintenance. Écrire ces questions au départ évite de découvrir des attentes différentes à la livraison.
7. Ton brief, prêt à remplir
Copie cette trame dans ton document. « À définir » est une réponse utile : elle nous indique ce qu’il reste à cadrer ensemble.
Mon idée en une phrase : Le public et son problème : Comment il fait aujourd’hui : Le parcours principal, étape par étape : Les fonctions indispensables : Ce qui peut attendre : Les appareils et les langues : Les contenus et services déjà disponibles : Les données à traiter et les points à clarifier : Le budget ou plafond envisagé : La date souhaitée et ce qu’elle signifie : Qui fournit les éléments et qui valide : Les critères pour valider la première version : Les questions encore ouvertes :Télécharger le modèle de brief (.txt)
Pour préciser ton projet
À lire aussi
On cadre ton idée ensemble ?
Tu peux nous parler de ton projet même si le brief n’est pas complet. Chez Yodavio, le cadrage précède les écrans Figma, puis la construction et la soumission à Apple.
Réserver un appel