Les étapes de création de votre application mobile, de l’idée aux stores

Créer une application mobile n’a rien de mystérieux quand le chemin est clair. Voici les étapes de création d’une application mobile telles que je les mène, de l’idée notée sur un carnet à l’application téléchargeable sur l’App Store et Google Play. Pour chacune : ce que je fais, ce que j’attends de vous, ce que vous recevez et le temps que cela prend. C’est la méthode de toute ma création d’application mobile : elle a servi, par exemple, pour LSF-CFB, une application e-learning en langue des signes française livrée entre janvier et avril 2026.

Vue d’ensemble : 7 étapes, 2 à 6 mois

Chez AppliWin, la création d’une application mobile suit sept étapes : cadrage, cahier des charges et devis, maquettes, développement Flutter et back-office WordPress, tests et bêta, publication sur les stores, puis maintenance. Comptez deux à six mois entre le premier appel et la mise en ligne, selon le périmètre et la rapidité des validations.

Certaines étapes se chevauchent : le back-office avance pendant que vous validez les maquettes, et les tests commencent dès les premiers jalons de développement. C’est ce qui permet de tenir des délais raisonnables sans sacrifier la qualité.

Étape 1 : l’appel découverte et le cadrage

Le cadrage sert à comprendre avant de chiffrer : votre métier, vos utilisateurs, le problème que l’application doit résoudre et la façon dont elle rapportera de l’argent ou fera gagner du temps. Cet échange est gratuit. Il se conclut par une première fourchette de budget et une liste de décisions à prendre.

Je vous pose des questions simples, mais décisives. Qui utilisera l’app, et que font ces personnes aujourd’hui sans elle ? Quelle action doit-elle rendre évidente ? Quels outils existent déjà : site WordPress, boutique WooCommerce, CRM, agenda ? Y a-t-il une échéance, comme un salon, une rentrée ou une saison ? Venez avec un problème plutôt qu’avec une solution toute faite. Le cadrage sert aussi à dire quand une application n’est pas la bonne réponse : parfois, un site rapide ou une application web suffit.

• Un compte rendu écrit de l’échange
• Une première fourchette de budget et de délai
• La liste des points à trancher avant le devis

Étape 2 : le cahier des charges et le devis

Le cahier des charges transforme le cadrage en liste précise de fonctionnalités, classées par priorité avec la méthode MoSCoW. C’est lui qui rend le devis fiable et comparable. Si vous n’en avez pas, je le construis avec vous ; si vous en avez un, je le relis et signale les zones floues avant de chiffrer.

Le devis découle directement de ce document : un lot par grand ensemble fonctionnel, chacun avec ses livrables, son prix et son délai. Vous pouvez ainsi lancer d’abord une première version utile, puis planifier la suite sans tout renégocier. Avant même ce devis, les fourchettes de ma page prix d’une application mobile donnent un premier repère. Pour préparer cette étape, utilisez mon modèle de cahier des charges commenté.

Étape 3 : UX/UI et maquettes Figma

Avant d’écrire une ligne de code, je dessine les parcours puis chaque écran dans Figma, jusqu’à un prototype cliquable que vous testez sur votre téléphone. Corriger une maquette prend quelques minutes ; corriger un écran développé prend des heures. Cette étape protège donc à la fois votre budget et votre planning.

• Parcours utilisateurs : inscription, achat, réservation, messagerie.
• Maquettes en basse fidélité pour valider la logique, puis en haute fidélité aux couleurs de votre marque.
• Mode clair et mode sombre si le projet le demande.
• Prototype cliquable partagé par simple lien.
• Respect des conventions d’iOS et d’Android, et des contrastes nécessaires à l’accessibilité.

Vous validez les maquettes par écrit avant le développement. Une modification de fond reste possible ensuite, mais elle fait l’objet d’un avenant chiffré : c’est la règle qui évite les dérives de budget des deux côtés.

Étape 4 : développement Flutter et back-office WordPress

Je développe une seule application en Flutter, qui produit les versions iOS et Android, et un back-office WordPress sur mesure relié à l’app par une API REST. Vous suivez l’avancement sur des versions de test installées sur votre téléphone à chaque jalon, au lieu de découvrir le résultat à la fin du projet.

Un seul back-office, deux plateformes : contenus, utilisateurs, commandes et notifications push se gèrent depuis WordPress, une interface que beaucoup d’équipes connaissent déjà. Sur LSF-CFB, ce back-office pilote le catalogue de cours vidéo, les prix, les abonnements, les locations de 7, 30 ou 90 jours, le forum et les comptes entreprise, sans aucun plugin LMS. Un seul code Flutter permet de livrer une application iOS et Android sans payer deux fois le même travail.

Le développement avance par jalons : comptes et navigation, puis fonctionnalités cœur, puis paiement, notifications et finitions. Chaque jalon donne lieu à une version de test et à un point d’avancement, pour corriger le tir tôt plutôt que tard.

Étape 5 : tests, recette et bêta (TestFlight, test fermé Google)

Avant toute publication, l’application est testée sur de vrais appareils iOS et Android, puis confiée à quelques utilisateurs via TestFlight chez Apple et un test fermé sur Google Play. Vous faites la recette avec une liste de scénarios ; les anomalies sont corrigées et retestées avant le feu vert pour les stores.

• Appareils récents et plus anciens, petits et grands écrans.
• Connexion lente ou coupée, reprise après interruption.
• Paiements en mode test : Stripe, achats intégrés en environnement de test.
• Notifications push, liens profonds, mode sombre.
• Accessibilité : grandes tailles de texte, lecteurs d’écran.

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

La publication demande un compte développeur à votre nom, des fiches complètes (textes, captures, politique de confidentialité, déclaration des données collectées) et la revue des deux stores. Selon Apple, au moins la moitié des soumissions sont examinées en moins de 24 heures et 90 % en moins de 48 heures ; chez Google, comptez de quelques heures à sept jours.

Ce que vérifient Apple et Google

• Une vraie valeur ajoutée : Apple refuse les apps qui ne sont qu’un site web reconditionné (règle 4.2 sur les fonctionnalités minimales).
• La suppression de compte depuis l’application, dès qu’on peut y créer un compte.
• Les contenus numériques vendus via les achats intégrés ; les biens et services physiques via un paiement classique.
• Une politique de confidentialité accessible et des déclarations exactes : « App Privacy » chez Apple, « Sécurité des données » chez Google.
• Des outils à jour : Xcode 26 exigé par Apple depuis le 28 avril 2026, Android 16 (API 36) exigé par Google Play depuis le 31 août 2026.
• Un compte de démonstration pour l’équipe de revue si l’app demande une connexion.

Les comptes développeur

Le compte Apple Developer Program coûte 99 $ par an, le compte Google Play Console 25 $ une seule fois. Pour une entreprise, chaque compte se crée au nom de la société, avec un numéro D-U-N-S gratuit qui atteste de son existence. Ces démarches sont souvent les plus lentes du projet : je vous accompagne pas à pas. Le détail est dans mon guide pour publier une application sur l’App Store.

Étape 7 : maintenance et évolutions

Une application vit après sa sortie. Chaque année, iOS et Android changent de version, et Apple et Google relèvent leurs exigences ; sans maintenance, l’app finit par ne plus pouvoir être mise à jour. Je propose un suivi qui couvre ces mises à jour, la correction des bugs, la sécurité du back-office et les évolutions.

Les premières semaines après la sortie sont les plus instructives : avis sur les stores, statistiques d’usage, retours de vos clients. On s’en sert pour prioriser la version suivante, en reprenant la liste MoSCoW du cahier des charges là où on l’avait laissée.

Durée de chaque étape

Comptez quelques jours à deux semaines pour le cadrage, une à deux semaines pour le cahier des charges, deux à quatre semaines pour les maquettes, quatre à quatorze semaines de développement, deux à trois semaines de tests et jusqu’à deux semaines pour la publication. Le chevauchement des étapes raccourcit le total.

Étape	Durée indicative	Ce qui l’allonge
1. Cadrage	Quelques jours à 2 semaines	Plusieurs décideurs, besoin encore flou
2. Cahier des charges et devis	1 à 2 semaines	Intégrations à étudier (ERP, API métier)
3. Maquettes	2 à 4 semaines	Nombre d’écrans, allers-retours de validation
4. Développement	4 à 14 semaines	Profils multiples, temps réel, paiements
5. Tests et bêta	2 à 3 semaines	Règle des 12 testeurs sur un compte Google personnel récent
6. Publication	Quelques jours à 2 semaines	Création des comptes, refus à corriger
7. Maintenance	En continu	—

Deux repères réels : une application mobile et un site pour une société de nettoyage ont été menés d’avril à juin 2026 ; l’application LSF-CFB, bien plus riche, de janvier à avril 2026. Pour des délais détaillés par type d’app, lisez combien de temps pour développer une application.

Livrables et propriété : code, comptes stores et droits

À la fin du projet, vous êtes propriétaire de ce que vous avez payé : le code source de l’application et du back-office, les maquettes, les applications publiées sur vos propres comptes Apple et Google, et les droits d’exploitation cédés par contrat. Vous restez libre de faire évoluer l’app avec moi ou avec un autre prestataire.

• Code source Flutter de l’application et code du back-office WordPress, dans un dépôt Git.
• Fichiers Figma des maquettes et du prototype.
• Applications publiées sous vos comptes Apple Developer Program et Google Play Console.
• Accès administrateur au back-office et à l’hébergement.
• Guide de prise en main du back-office.
• Cession des droits patrimoniaux prévue au contrat, effective au paiement du solde.

Outils et communication pendant le projet

Vous avez un seul interlocuteur : moi. Les échanges passent par visio, téléphone et e-mail, avec un point d’avancement à chaque jalon et des versions de test installables sur votre téléphone. Les maquettes se commentent directement dans Figma, et chaque décision importante est confirmée par écrit pour garder un historique clair.

• Figma pour les maquettes et le prototype.
• TestFlight et la Play Console pour les versions de test.
• Git pour le code, avec un historique complet des modifications.
• Firebase pour les notifications push.
• WordPress pour le back-office, que vous prenez en main dès la phase de tests.

Une rencontre en personne reste possible. Je travaille depuis Paris avec des clients partout en France, et je me déplace quand le projet le justifie, comme à Lyon pour un centre de formation. Pour connaître mon parcours, lisez ma page à propos. Et si votre projet est prêt à être cadré, décrivez-le dans le formulaire de demande de projet : ces étapes de création d’application mobile commencent par cet échange.

Questions fréquentes sur la création d’une application