Créer une application mobile : les étapes, du cadrage à la publication

On nous demande souvent « par où on commence ? ». La réponse tient en sept étapes, toujours les mêmes, que l’application soit un outil interne pour vingt techniciens ou un produit grand public. Ce qui change d’un projet à l’autre, c’est la durée de chaque étape et la quantité de décisions à prendre.

Cet article donne la vue d’ensemble : l’ordre des étapes, ce qu’elles produisent, combien de temps elles prennent et, surtout, ce que vous devez apporter à chacune. Pour le détail de chaque étape, nous renvoyons vers nos articles dédiés plutôt que de les répéter ici.

Les sept étapes en un tableau

Les durées ci-dessous sont nos ordres de grandeur par étape. Le design et le développement se chevauchent : les premiers écrans validés partent en développement pendant que les suivants se dessinent. Les totaux correspondent à nos délais habituels.

En charge de travail, un MVP représente typiquement 30 à 60 jours-homme, une application complète 120 à 200. Pour une plateforme métier ou une marketplace, comptez 5 à 8 mois et 250 à 450 jours-homme.

Étape 1 : l’idée, formulée comme un problème

Avant de parler d’écrans, il faut pouvoir répondre à trois questions en une phrase chacune. Quel problème l’application résout-elle ? Pour qui, précisément ? Que font ces personnes aujourd’hui à la place ?

La troisième question est la plus utile. Si la réponse est « rien, ça leur est égal », le projet est fragile. Si la réponse est « un tableur, des appels et beaucoup de ressaisie », vous tenez un vrai besoin, et une base pour mesurer le gain.

Ce que vous apportez : ces trois réponses, une idée du budget que vous êtes prêt à engager et, si possible, quelques utilisateurs potentiels à qui parler. Une enveloppe, même large, fait gagner beaucoup de temps : elle dit tout de suite si l’on part sur un MVP ou sur une version complète. Notre guide du coût d’une application mobile détaille les paliers de budget.

Étape 2 : le cadrage, là où se décide le délai

Le cadrage transforme l’idée en un périmètre chiffrable. Il produit un parcours utilisateur principal, une liste de fonctionnalités priorisée, les choix techniques, les intégrations nécessaires (paiement, ERP, CRM, API existantes) et un planning.

C’est l’étape la plus courte et celle qui pèse le plus sur la suite. Un périmètre flou au cadrage se paie en semaines au développement. Deux décisions s’y prennent :

• Le périmètre de la première version. La plupart des projets gagnent à commencer par un MVP. Notre méthode pour couper le périmètre d’un MVP explique comment passer de quarante fonctionnalités à six sans abîmer le produit.
• La technologie. Sur un projet iOS + Android, le cross-platform (React Native, Flutter) fait économiser 30 à 40 % par rapport à deux applications natives. Le natif (Swift, Kotlin) reste pertinent pour les usages très matériels : capteurs, Bluetooth, traitement vidéo poussé. Nous détaillons l’arbitrage dans React Native, Flutter ou natif.

Le livrable du cadrage est un cahier des charges court et vivant. Le modèle de cahier des charges que nous utilisons montre ce qu’il doit contenir et ce qu’il est inutile d’y mettre.

Ce que vous apportez : une personne qui tranche (pas un comité), les objectifs chiffrés que l’application doit atteindre, les contraintes connues (dates, réglementation, données de santé, hébergement) et les accès ou la documentation des systèmes avec lesquels l’application doit dialoguer.

Étape 3 : le design, du parcours aux écrans

Le design commence par des maquettes fonctionnelles (l’enchaînement des écrans, sans couleur), puis passe aux maquettes graphiques et à un prototype cliquable. Le prototype permet de faire tester le parcours principal à quelques utilisateurs avant d’écrire une ligne de code. Corriger un écran à ce stade prend une heure ; le corriger une fois développé prend des jours.

Deux points méritent l’attention dès cette étape : l’onboarding, qui décide d’une bonne partie de la rétention, et les états « vides » ou « erreur » que personne ne dessine spontanément et que tout le monde verra.

Ce que vous apportez : votre charte graphique (logo, couleurs, typographies), les vrais contenus plutôt que du faux texte, et des retours groupés et rapides. Un aller-retour de maquettes qui attend une semaine une validation décale tout le planning d’une semaine.

Étape 4 : le développement, par itérations courtes

Nous développons par itérations d’une à deux semaines. Chacune se termine par une démonstration sur téléphone : vous voyez l’application avancer, vous l’installez sur votre propre appareil, et vous corrigez la trajectoire tant que c’est peu coûteux.

Ce rythme a une conséquence directe : les changements de cap sont possibles, mais ils se négocient à budget constant. Une fonctionnalité qui entre en remplace une autre, ou décale la date. C’est la règle qui empêche un MVP de 6 semaines d’en durer 14.

Le développement couvre l’application elle-même, mais aussi le back-end (base de données, API, back-office), les notifications, l’analytique et les intégrations décidées au cadrage. Les intégrations avec des systèmes tiers sont la principale source d’imprévu : une API mal documentée ou un accès qui tarde peut bloquer une itération entière.

Ce que vous apportez : votre présence aux démonstrations, des retours écrits dans les 48 heures, les accès aux API et environnements de test des outils à connecter, et des données de test réalistes.

Étape 5 : la recette, sur de vrais téléphones

La recette vérifie que l’application fait ce qui a été convenu, sur les appareils de vos utilisateurs et dans leurs conditions réelles : réseau faible, ancien téléphone, mode sombre, texte agrandi, interruption par un appel. Une partie des tests est automatisée et tourne en continu pendant le développement ; la recette finale reste humaine.

Les anomalies sont classées par gravité. Les bloquantes sont corrigées avant publication, les mineures peuvent partir dans la première mise à jour. Cette distinction évite de repousser un lancement pour une marge de trois pixels.

Ce que vous apportez : des testeurs qui connaissent le métier, quelques appareils représentatifs de votre public (pas seulement le dernier iPhone de la direction), des scénarios de test écrits à partir de vos cas réels, et la relecture de tous les textes de l’application.

Étape 6 : la publication sur l’App Store et Google Play

La publication n’est pas un clic. Il faut préparer les fiches store (nom, description, captures, mots-clés), la politique de confidentialité en ligne, les déclarations sur les données collectées et un compte de démonstration pour les équipes de validation.

Les délais sont connus et doivent être planifiés :

• Apple indique examiner au moins 50 % des soumissions en moins de 24 heures et 90 % en moins de 48 heures. Le risque n’est pas la durée de l’examen, c’est le refus suivi d’une nouvelle soumission.
• Google Play impose aux comptes personnels créés après le 13 novembre 2023 un test fermé avec au moins 12 testeurs inscrits pendant 14 jours d’affilée, avant de demander l’accès à la production, dont l’examen prend en général sept jours ou moins. Cette règle, telle que Google la publie, vise les comptes personnels : une raison de plus d’ouvrir le compte au nom de l’entreprise.

Côté frais, l’Apple Developer Program coûte 99 USD par an d’adhésion et Google Play demande 25 USD une seule fois. Les causes de refus les plus fréquentes, et comment les éviter, sont détaillées dans notre article sur les motifs de refus de l’App Store et de Google Play.

Ce que vous apportez : les comptes développeur ouverts au nom de l’entreprise (étape 2), l’URL de votre politique de confidentialité, la validation des textes et des visuels des fiches, et les informations légales demandées par les stores.

Étape 7 : mesurer, corriger, maintenir

Le lancement ouvre la période la plus instructive du projet. Pendant les quatre à huit premières semaines, trois chiffres suffisent : combien de personnes terminent le parcours principal, combien reviennent la semaine suivante, et où les autres abandonnent. Ce sont eux qui décident de la version 2, pas la liste des idées écartées au cadrage.

En parallèle, l’application doit suivre les nouvelles versions d’iOS et d’Android, les exigences des stores et les mises à jour de ses dépendances. Une application qu’on ne touche plus finit par être retirée ou par ne plus fonctionner sur les téléphones récents. Comptez 15 à 20 % du coût initial par an ; le détail de ce budget est dans notre article sur ce que coûte vraiment la maintenance.

Ce que vous apportez : des objectifs chiffrés pour la mesure, une personne qui lit les retours des utilisateurs et les avis sur les stores, et un budget annuel prévu dès le départ plutôt que découvert au premier incident.

Les trois pièges qui allongent un projet

Le décideur introuvable. Quand chaque arbitrage passe par trois personnes qui ne sont jamais disponibles en même temps, une itération d’une semaine en dure deux. Le planning d’un projet mobile dépend autant de vos délais de réponse que de ceux de l’équipe technique.

Le périmètre qui grossit par petites touches. « Juste un champ de plus », « tant qu’on y est ». Chaque ajout coûte peu, leur somme coûte un mois. La seule parade qui tienne est l’échange à budget constant.

Les stores oubliés jusqu’à la fin. Comptes non ouverts, D-U-N-S à demander, politique de confidentialité inexistante, test fermé Google à lancer : ce sont autant de délais incompressibles découverts au moment où l’application est prête. Traités au cadrage, ils courent en parallèle du développement et ne coûtent plus rien.

Un projet mobile tient ses délais quand les décisions sont prises au bon moment : le périmètre au cadrage, les écrans au design, les priorités à chaque démonstration.

Pour aller plus loin : notre page création d’application mobile présente notre façon de mener ces sept étapes, du premier atelier de cadrage à la publication sur les stores.

Sources

• Apple Developer, App Review : délais d’examen des soumissions (au moins 50 % en moins de 24 heures, 90 % en moins de 48 heures).
• Apple Developer, Enrollment : coût de l’Apple Developer Program (99 USD par an) et exigence du numéro D-U-N-S pour les organisations.
• Apple Developer, D-U-N-S Number : délai d’obtention du numéro (jusqu’à 5 jours ouvrés) et de réception par Apple (jusqu’à 2 jours ouvrés).
• Google Play Console Help, App testing requirements for new personal developer accounts : test fermé de 12 testeurs pendant 14 jours, examen de l’accès à la production en sept jours ou moins en général.
• Google Play Console Help, Get started with Play Console : frais d’inscription unique de 25 USD.