Comment créer une application mobile : les étapes, du cadrage aux stores

Créer une application mobile se fait en huit étapes : cadrer le problème et la première version, choisir le bon format, choisir la technologie, tester un prototype sur téléphone, développer par sprints, construire le back-end, publier sur l’App Store et Google Play, puis assurer le suivi. Pour une première version publiée sur les deux stores, comptez en général 12 à 18 semaines, hors délai de validation d’Apple et de Google. Ce guide s’adresse au dirigeant qui pilote le projet sans écrire de code.

Les phases et leur durée

La revue des stores s’ajoute aux 12 à 18 semaines : de quelques heures à quelques jours pour une mise à jour, davantage pour une première publication sur un compte neuf. Personne ne maîtrise ce délai.

Étape 1 : définir le problème et le périmètre de la V1

Avant de parler d’écrans, écrivez en une phrase le problème à résoudre, pour qui et dans quelle situation. Par exemple : « Nos techniciens notent leurs relevés sur papier et les ressaisissent le soir au bureau. » Cette phrase servira de filtre à chaque décision.

Listez ensuite les fonctionnalités envisagées et posez, pour chacune, une seule question : sans elle, l’utilisateur peut-il accomplir l’action principale ? Si oui, elle part en V2. Pour ces techniciens, la V1 tient en quatre écrans : connexion, interventions du jour, saisie du relevé avec photo, envoi au bureau. Le tableau de bord et l’export comptable attendront.

Le livrable est un document qui dit ce qui entre dans la V1, ce qui est repoussé, et pourquoi. Sans lui, aucun devis ferme n’est possible. La méthode de tri « doit / devrait / plus tard » est détaillée dans notre guide pour cadrer et chiffrer un MVP.

Étape 2 : choisir entre application mobile, application web et site

Une application mobile coûte plus cher qu’un équivalent web. Elle se justifie quand au moins une de ces deux conditions est remplie :

• L’usage est répété et en mobilité : plusieurs fois par semaine, loin d’un bureau (terrain, magasin, chantier, déplacement).
• Vous avez besoin du téléphone lui-même : notifications push fiables, caméra, géolocalisation en arrière-plan, biométrie, fonctionnement hors connexion.

Sinon, regardez ailleurs. Une application web s’utilise dans un navigateur, sans store ni installation, et suffit quand vos utilisateurs travaillent devant un écran. Si votre objectif est d’être trouvé et de présenter votre offre, un site internet suffit. Beaucoup de projets combinent les deux : une application mobile pour le terrain, une interface web d’administration pour le bureau.

Étape 3 : choisir la technologie, natif ou multiplateforme

Deux familles existent :

• Le natif : deux applications distinctes, en Swift pour l’iPhone et en Kotlin pour Android. Deux bases de code, donc deux développements et chaque correction à faire deux fois. Il reste pertinent pour des besoins pointus, comme un traitement graphique lourd.
• Le multiplateforme (React Native, Flutter) : une seule base de code produit les deux applications. Restent des ajustements propres à chaque système et des tests sur les deux.

Ne confondez pas le multiplateforme avec un site placé dans une coquille d’application : React Native pilote les composants natifs du téléphone, alors qu’un site encapsulé s’expose à un refus d’Apple.

Chez Milann, nous développons en React Native avec Expo. Votre critère à vous : un autre développeur pourra-t-il reprendre le code si vous changez de prestataire ? Avec une technologie répandue, oui.

Étape 4 : maquettes et prototype testé sur téléphone

Le designer dessine les écrans clés aux conventions de chaque système, puis les relie en un prototype cliquable que vous ouvrez sur votre téléphone. Rien n’est développé, mais vous parcourez l’application comme si elle existait.

Testez-le avec quelques futurs utilisateurs, debout et d’une seule main : un bouton confortable à la souris peut être inatteignable au pouce. Corriger une maquette prend quelques heures, corriger du code peut prendre des jours : c’est pour cela qu’une démarche de design UX/UI se mène avant le développement.

Étape 5 : développer par sprints, avec des versions de test

Le développement avance par cycles de deux semaines, les sprints. Chacun se termine par une version installée sur votre téléphone : côté iPhone via TestFlight, le service de test d’Apple, côté Android via la piste de test interne de Google Play. Vos testeurs l’installent comme n’importe quelle application, bien avant la publication.

Votre rôle : tester chaque version et arbitrer. Une idée nouvelle en cours de route remplace quelque chose de prévu ou rejoint la V2, ce qui protège le budget et la date.

La recette se fait sur appareils réels : un iPhone récent et un Android d’entrée de gamme vieux de quelques années ne réagissent pas de la même façon.

Étape 6 : construire le back-end, la partie qu’on ne voit pas

Derrière les écrans, et développé en parallèle, il y a le back-end :

• Les comptes : inscription, connexion, récupération d’accès, suppression du compte.
• Les données, de préférence hébergées en Europe pour simplifier la conformité au RGPD.
• L’API, qui relie l’application aux données et à vos outils (CRM, ERP, facturation).
• Les notifications et le back-office où votre équipe gère contenus et utilisateurs.
• Les paiements, le cas échéant. Un bien physique ou un service consommé hors de l’application peut passer par Stripe ; un contenu numérique consommé dans l’application passe en principe par l’achat intégré d’Apple ou de Google, avec une commission de l’ordre de 15 à 30 % selon les cas. Les règles européennes ouvrent, sous conditions, la possibilité de renvoyer vers un paiement externe. Cet arbitrage se tranche au cadrage.

C’est souvent là que se joue l’essentiel du budget. Pour son propre produit à abonnement, conçu et mis en production en interne, Milann a construit ce type de back-end : authentification par code à usage unique, base PostgreSQL, facturation Stripe.

Étape 7 : publier sur l’App Store et Google Play

Voici ce qu’il faut réunir :

1. Les comptes développeur, au nom de votre entreprise : environ 100 € par an chez Apple, environ 25 € une fois chez Google Play. Jamais au nom du prestataire ou d’un salarié, car ils portent votre application et ses avis.
2. Un numéro D-U-N-S. Pour inscrire une société, Apple comme Google Play exigent cet identifiant délivré par Dun & Bradstreet, puis vérifient l’organisation. Comptez de quelques jours à quelques semaines.
3. Les fiches des stores : nom, description, icône, captures d’écran.
4. La déclaration de collecte de données, affichée sur la fiche. Elle doit refléter ce que l’application et ses services tiers collectent réellement.
5. Une politique de confidentialité en ligne, exigée par les deux stores.
6. Un compte de démonstration pour le relecteur si l’application demande une connexion. Et si l’on peut y créer un compte, Apple exige qu’on puisse aussi le supprimer depuis l’application.

Vient la revue. Un refus n’a rien d’exceptionnel et il est rarement bloquant : les motifs courants sont formels, on corrige et on resoumet. Aucun prestataire ne peut garantir la validation ; il peut préparer un dossier qui évite les motifs connus.

Étape 8 : suivre et maintenir l’application

• Les correctifs : avec Expo Updates, une correction du code JavaScript part sans nouvelle soumission. Un changement natif, comme une nouvelle permission, repasse par la revue des stores.
• Les systèmes : iOS et Android changent de version chaque année, et les stores imposent de compiler avec des outils de développement récents pour continuer à publier.
• La surveillance des plantages et des avis.
• Les évolutions : la liste de la V2 devient votre feuille de route, corrigée par les retours des premiers utilisateurs.

Les erreurs les plus fréquentes

• Tout mettre en V1. Chaque ajout repousse le moment où de vrais utilisateurs vous diront ce qui compte. Une V1 resserrée publiée tôt vous apprend plus qu’une V1 complète publiée tard.
• Sous-estimer le back-end. Un devis qui ne parle que d’écrans est incomplet : demandez ce qui est prévu pour les comptes, les données, l’API et les paiements.
• Ouvrir les comptes stores trop tard. Le D-U-N-S et la vérification des comptes par Apple et Google peuvent bloquer une application terminée. Lancez-les dès le cadrage.
• Ne pas prévoir la maintenance. Une application qu’on ne met plus à jour fonctionne de moins en moins bien sur les nouveaux téléphones.

En résumé

• Une V1 publiée sur les deux stores demande en général 12 à 18 semaines, hors validation d’Apple et de Google.
• L’application mobile se justifie si l’usage est répété et en mobilité, ou si vous avez besoin des fonctions du téléphone. Sinon, une application web ou un site suffit.
• Le multiplateforme (React Native, Flutter) produit iOS et Android avec une seule base de code.
• Le back-end concentre souvent la plus grosse part du budget.
• Ouvrez les comptes développeur au nom de l’entreprise dès le début, et budgétez la maintenance.

Pour chiffrer votre projet, lisez notre guide du prix d’une application mobile en 2026 ou découvrez notre offre de création d’application mobile. Parlons-en : premier échange sous 48 h.