Tapez « comment créer une application mobile » dans Google : en août 2026, les premiers résultats sont des éditeurs d'outils sans code (GoodBarber, Canva), une discussion Reddit et des vidéos qui promettent une application « en 10 minutes, gratuitement ». Ces pages expliquent leur outil, pas ce qui se passe quand votre projet sort du modèle prévu.
Je suis développeur indépendant à Morlaix, dans le numérique depuis 2012, et j'ai livré entre autres Prono Léon, une plateforme de pronostics utilisée par 35 joueurs, et Douarmana, où une trentaine de praticiens réservent leurs salles chaque jour. Voici les 7 étapes réelles pour créer une application mobile, telles que je les vis sur chaque projet : l'idée, le cadrage, la maquette, le choix entre web app, hybride et natif, le développement, les tests, puis la publication et la maintenance. Pour chaque étape, je vous indique ce que vous produisez et la décision qui fait monter la facture si elle est mal prise.
En bref
- Créer une application mobile se fait en 7 étapes : idée, cadrage, maquette, choix de la technologie, développement, tests, publication et maintenance. Les trois premières ne demandent aucune ligne de code et évitent l'essentiel des erreurs coûteuses.
- Le choix le plus lourd de conséquences est la plateforme : une web app (PWA) se passe des stores, deux applications natives iOS et Android imposent deux codes à écrire et à maintenir.
- Publier sur les stores a un coût et un délai : Apple facture 99 $ par an, Google Play 25 $ une fois, et un nouveau compte Google Play personnel doit faire tester l'application par au moins 12 personnes pendant 14 jours avant la mise en production.
- Chez Web du Léon, une première version demande 4 à 12 semaines de développement après une maquette cliquable validée, et la maintenance se prévoit dès le départ (forfait à partir de 60 € par mois).
Les 7 étapes pour créer une application mobile, en un tableau
Une application mobile se construit dans cet ordre : on décide quoi faire, on le dessine, on choisit la technologie, puis seulement on code, on teste et on publie. Inverser l'ordre, par exemple coder avant d'avoir une maquette validée, est la cause de dépassement que je rencontre le plus souvent.
| Étape | Ce que vous obtenez | La décision qui coûte |
|---|---|---|
| 1. L'idée | Une phrase : qui utilise l'application, pour faire quoi | Viser tout le monde au lieu d'un usage précis |
| 2. Le cadrage | La liste des fonctions de la première version, et celles qui attendront | Tout mettre dans la version 1 |
| 3. La maquette | Des écrans cliquables, validés par de vrais utilisateurs | Sauter l'étape et découvrir les oublis pendant le code |
| 4. La technologie | Web app, hybride ou natif, et la stack | Choisir le natif par réflexe |
| 5. Le développement | Une application qui tourne sur un serveur de test | Mettre les règles métier dans l'écran au lieu de la base |
| 6. Les tests | Des parcours vérifiés automatiquement | Tester à la main, une fois, la veille du lancement |
| 7. Publication et maintenance | Une application en ligne, suivie et mise à jour | Oublier le délai des stores et le budget de maintenance |
Étapes 1 et 2 : de l'idée au cadrage
Une idée d'application est prête à être développée quand elle tient en une phrase qui nomme l'utilisateur, l'action et le moment. Pour Prono Léon, cela donnait : les joueurs pronostiquent chaque match depuis leur téléphone avant le coup d'envoi, et le classement se met à jour seul.
Le cadrage transforme cette phrase en liste. Pour chaque fonction, on se pose une question simple : l'application est-elle utilisable sans elle ? Si oui, elle attend la version 2. Sur un projet comme Prono Léon, une plateforme de pronostics de football amateur du Finistère nord, la première version doit gérer les comptes, les pronostics, le verrouillage avant le match et le calcul des points. Les e-mails de mi-saison et le sondage de fin de saison peuvent attendre.
Le cadrage sert aussi à écrire les règles qui ne doivent jamais bouger. Dans un jeu de pronostics, c'est l'heure limite de saisie et le barème des points. Dans une application de réservation comme Douarmana, c'est l'impossibilité de réserver deux fois la même salle sur le même créneau. Ces règles, écrites noir sur blanc avant le code, pèsent plus lourd dans le devis que le nombre d'écrans.
Ce que j'entends souvent à ce stade : « je gère déjà la prod, la compta, les salariés. Le web, je veux déléguer à quelqu'un de confiance ». C'est exactement le rôle du cadrage. Chez Web du Léon, il est gratuit, et il peut conclure qu'une application n'est pas nécessaire : un site responsive ou un outil du marché suffit parfois.
Étape 3 : une maquette cliquable avant la première ligne de code
La maquette cliquable est la version dessinée de l'application : on navigue d'écran en écran comme sur la vraie, mais rien n'est programmé. Elle se corrige bien plus vite qu'un écran déjà codé.
Je fais valider la maquette avant tout développement, pour trois raisons :
- Elle révèle les oublis. Que voit un joueur qui arrive après l'heure limite ? Que se passe-t-il si un match est reporté ? Ces questions surgissent en cliquant, pas en lisant un cahier des charges.
- Elle se teste sur de vraies personnes. Montrez-la à quelques futurs utilisateurs, sur leur téléphone. S'ils hésitent sur un bouton, vous venez d'économiser une correction en production.
- Elle rend le devis fiable. On chiffre ce qu'on voit. Sans maquette, un prix reste une estimation, et c'est la raison pour laquelle je vous renvoie au détail du prix d'une application mobile : le nombre de jours sort de la maquette.
Pensez la maquette pour le pouce : sur Prono Léon, la plupart des pronostics se font sur téléphone, les soirs de match. Les boutons, les formulaires et les listes sont dessinés pour une main, pas pour une souris.
Étape 4 : web app, hybride ou natif, le choix qui engage tout le reste
Pour la plupart des applications de PME, une web app mobile d'abord (souvent appelée PWA) est le bon point de départ : un seul code, pas de store, des mises à jour immédiates. Le natif se justifie quand l'application doit exploiter finement le matériel du téléphone ou quand sa présence dans les stores fait partie du modèle.
| Option | Ce que c'est | À choisir quand |
|---|---|---|
| Web app (PWA) | Une application qui s'ouvre dans le navigateur, s'ajoute à l'écran d'accueil et fonctionne aussi sur ordinateur | Outil métier, espace client, réservation, jeu entre membres : l'usage compte plus que la vitrine du store |
| Hybride | Un seul code (React Native, Flutter) compilé pour l'App Store et Google Play | Vous voulez être dans les stores sans payer deux développements |
| Natif | Une application iOS en Swift et une application Android en Kotlin | Accès avancé au matériel, performances graphiques exigeantes, modèle économique lié aux stores |
Prono Léon est une web app, sans store. Les joueurs pronostiquent depuis leur téléphone, l'organisateur saisit les résultats depuis son ordinateur, et c'est la même application. Quand un bug apparaît un soir de match, la correction est en ligne dès qu'elle est déployée, sans attendre une validation. Les cas où le natif reste nécessaire sont détaillés dans l'article web app ou application mobile pour une PME.
Un piège à connaître si vous visez l'App Store malgré tout : Apple demande qu'une application aille au-delà d'un « site web reconditionné » (règle 4.2 de ses consignes d'examen). Emballer un site existant dans une coquille d'application pour être présent sur le store expose à un refus.
Étapes 5 et 6 : développer et tester, là où se jouent les semaines
Comment développer une application mobile qui tient dans la durée ? En testant chaque règle métier au moment où on l'écrit, pas à la fin.
Le développement est l'étape la plus longue : chez Web du Léon, une première version demande 4 à 12 semaines selon le nombre de rôles, les paiements et les intégrations. C'est aussi là que se prennent des décisions invisibles pour vous, mais qui décident si l'application tiendra dans deux ans.
Pour Prono Léon, la stack est Next.js pour les écrans, PostgreSQL via Supabase pour les données et les comptes, Stripe pour le paiement et Brevo pour les e-mails automatiques. Des outils standard qu'un autre développeur peut reprendre. Le code et les données appartiennent au client.
La décision la plus importante de cette étape : où vivent les règles. Sur Prono Léon, le verrouillage des pronostics 15 minutes avant le coup d'envoi n'est pas dans l'écran, il est appliqué par la base de données elle-même. Un pronostic envoyé trop tard est rejeté, que le joueur soit sur téléphone ou sur ordinateur. Les points et les classements sont calculés par des fonctions de la base, donc recalculables à tout moment si un résultat est corrigé. Le récit complet du projet est dans le retour d'expérience sur Prono Léon.
Les tests suivent la même logique. Tester à la main la veille du lancement ne protège pas de la mise à jour du mois suivant. La bonne pratique : des scénarios automatisés qui rejouent les parcours principaux avant chaque mise en ligne. Sur une application comme Prono Léon, un tel test échouerait si un pronostic verrouillé redevenait modifiable après une évolution, avant la mise en ligne et non un soir de match.
Étape 7 : publier sur les stores, puis maintenir
Publier une application native ou hybride demande deux comptes développeur, un délai de validation et, chez Google, une phase de test imposée. Une web app se publie comme un site : elle est en ligne dès qu'elle est déployée.
| Étape de publication | App Store (Apple) | Google Play |
|---|---|---|
| Compte développeur | 99 $ par an | 25 $, une seule fois |
| Examen de l'application | En moyenne, 90 % des soumissions examinées en moins de 24 heures, selon Apple | Accès à la production accordé par Google après la phase de test |
| Contrainte à anticiper | L'application doit aller au-delà d'un site web reconditionné (règle 4.2) | Compte personnel créé après le 13 novembre 2023 : test fermé avec au moins 12 testeurs pendant 14 jours avant la production |
La règle des 12 testeurs pendant 14 jours surprend beaucoup de porteurs de projet : si vous lancez l'application sous un compte personnel, prévoyez ces deux semaines et ces testeurs dans votre calendrier. Sources : pages officielles d'Apple et de Google, consultées le 18 septembre 2026.
Une fois en ligne, l'application vit. Les systèmes des téléphones évoluent, les bibliothèques reçoivent des correctifs de sécurité, vos utilisateurs demandent des ajustements. Chez Web du Léon, la maintenance est un forfait à partir de 60 € par mois, chiffré à part dès le devis initial pour que vous connaissiez le coût réel de l'application sur la durée.
Ce que les outils sans code ne vous disent pas
Les créateurs d'applications sans code conviennent à un prototype, une application événementielle ou un catalogue simple. Ils deviennent coûteux quand votre projet a une règle métier que l'outil ne prévoit pas, ou quand vous voulez partir avec vos données.
- La règle qui ne rentre pas dans le modèle. Verrouiller une saisie à une heure précise, interdire une double réservation, prélever automatiquement chaque mois : ce sont ces règles qui font la valeur d'une application métier, et ce sont elles que les modèles tout faits gèrent le moins bien.
- L'abonnement qui ne s'arrête jamais. Vous louez l'outil. Le jour où le tarif change, vous suivez.
- La propriété. Ce que j'entends souvent à propos des outils de création de sites : « avec Wix, je n'ai pas la main, je dépends de la plateforme ». Avec un créateur d'applications sans code, c'est la même logique. Avec une application développée sur une stack standard, le code et les données sont à vous.
Ce que je ne fais pas : vous déconseiller le sans code par principe. Si votre besoin tient dans un modèle existant, le cadrage se conclut par une recommandation d'outil, sans devis. Ce que je fais : développer l'application quand la règle métier, le paiement ou le volume d'utilisateurs dépassent ce que l'outil permet, comme pour Douarmana, où les prélèvements mensuels et le suivi des échecs de paiement ne se configurent pas en quelques clics.
Vous avez une idée d'application et vous voulez savoir par où commencer ? Le cadrage est gratuit, depuis Morlaix ou en visio. Si le projet se confirme, une maquette cliquable est validée avant tout développement. La démarche est décrite sur la page application métier sur mesure, et vous pouvez me décrire votre projet ici.
Questions fréquentes sur la création d'une application mobile
Est-il difficile de créer une application mobile ?
Créer une application de démonstration est accessible avec un outil sans code. Créer une application mobile fiable, avec des comptes, des paiements et des règles qui ne doivent jamais être contournées, demande un vrai développement : chez Web du Léon, 4 à 12 semaines pour une première version, après une maquette cliquable validée.
Est-ce gratuit de créer une application ?
Non, même quand l'outil de départ l'est. Publier sur l'App Store coûte 99 $ par an et sur Google Play 25 $ une fois, l'hébergement et la maintenance sont récurrents, et le développement se chiffre en jours de travail. Une web app évite les frais de store, pas le reste.
Peut-on créer une application mobile sans passer par l'App Store ni Google Play ?
Oui. Une web app, ou PWA, s'ouvre dans le navigateur du téléphone et s'ajoute à l'écran d'accueil sans store. C'est le choix fait pour Prono Léon : les joueurs l'utilisent sur leur téléphone, l'organisateur sur son ordinateur, et chaque correction est en ligne sans attendre un store.
Par quelle étape commencer pour créer une application mobile ?
Par une phrase qui nomme l'utilisateur, l'action et le moment, puis par la liste des fonctions indispensables à la première version. La maquette cliquable vient ensuite, et le code seulement après sa validation.
