Un client m'appelle en février. Il a une idée d'appli pour les artisans du bâtiment, il a déjà payé 4 800 € à une agence qui n'a jamais livré une seule ligne de code fonctionnelle, et il me demande de reprendre le projet « pour pas trop cher ». J'ai regardé le cahier des charges : 47 écrans, un back-office complet, un système de paiement, une messagerie temps réel et un mode hors-ligne. Pour une première application. Voilà typiquement le mur dans lequel tout le monde se fracasse.
Créer sa première application mobile, ce n'est pas un problème technique. C'est un problème de cadrage, de budget et d'ego. Je vais vous raconter ce que j'ai vu marcher, et surtout ce qui a échoué.
Points clés à retenir
- Comptez 25 $ une fois chez Google et 99 $ par an chez Apple rien que pour publier sur les stores.
- Une appli no-code correcte démarre autour de 30 à 60 € par mois ; un développeur freelance sérieux, c'est plutôt 3 000 à 10 000 € pour un MVP sobre.
- Le vrai piège du premier projet n'est pas le langage, c'est le périmètre : visez 3 écrans, pas 15.
- Apple refuse environ une appli sur quatre à la première soumission pour des motifs souvent bêtes (métadonnées, compte de démo manquant).
- Le coût que personne ne budgète : la maintenance. Comptez 15 à 20 % du coût initial chaque année.
Quel budget pour créer une application mobile ?
Le prix varie énormément selon la voie choisie. Il n'y a pas un tarif, il y a une fourchette par approche. Voici les ordres de grandeur que j'ai constatés sur mes propres projets et ceux de confrères.
Les trois grandes options de budget
| Approche | Coût typique | Pour qui |
|---|---|---|
| No-code / low-code | 30 à 60 € / mois, plus les frais de store | Prototype rapide, budget serré, projet simple |
| Freelance | 3 000 à 10 000 € pour un MVP | Projet sur mesure, budget intermédiaire |
| Agence | 15 000 à 50 000 € | Projet complexe, besoin d'un interlocuteur unique |
Au-dessus, ajoutez les frais fixes des stores : 25 $ une seule fois chez Google, et 99 $ par an chez Apple. Ces montants sont publics et ne bougent pas depuis des années. Ce n'est pas ça qui plombe un budget — c'est le reste.
Franchement, l'erreur que je vois le plus souvent, c'est de regarder le prix de la construction et d'oublier celui de la vie de l'appli. Une application qui ne plante jamais n'existe pas. Les mises à jour d'iOS et d'Android cassent des choses tous les ans, les API tierces changent, les certificats expirent. Sur mes projets, je réserve 15 à 20 % du coût initial par an rien que pour ça.
Le coût caché que personne n'anticipe
Un exemple concret. J'ai livré une appli de réservation à un salon de coiffure pour 6 200 €. La première année, tout allait bien. La deuxième, le prestataire de paiement a changé son API : 400 € de mise à jour. Puis Apple a durci ses règles sur les comptes de connexion : encore 300 €. Sur 24 mois, on est déjà à plus de 10 % du budget initial juste en maintenance subie.
Donc quand vous chiffrez votre première appli, multipliez mentalement par 1,3 sur 3 ans. C'est plus honnête.
Quel langage ou framework choisir pour un premier projet ?
Ici, tout le monde se focalise sur le mauvais point. Le langage importe moins que la question : de quoi avez-vous réellement besoin ?
Une grille de décision simple
- Swift : uniquement iPhone. Performant, mais vous abandonnez la moitié du marché mondial (Android).
- Kotlin : uniquement Android. Symétrique du précédent.
- Flutter : un seul code pour les deux plateformes. Mon choix par défaut pour un premier projet sérieux.
- React Native : même logique, pertinent si vous venez déjà du web en JavaScript.
- No-code : vous ne codez rien. Idéal pour valider une idée, limitant dès que vous voulez du sur-mesure.
Sur mon dernier projet perso, j'ai testé Flutter après des années de développement natif. Le gain de temps a été net : j'ai livré les deux versions en une seule fois, là où le natif m'aurait pris le double. Ce n'est pas une règle universelle — pour une appli très gourmande en graphismes ou en capteurs, le natif garde l'avantage.
Mon avis tranché
Pour une première application, si vous n'avez aucune compétence technique et un budget de moins de 2 000 €, allez vers le no-code. Sans hésiter. C'est la seule voie qui vous permet de tenir un délai crédible sans vous ruiner. Dès que votre budget dépasse 3 000 € et que le projet a une ambition réelle, passez au framework cross-platform.
Les erreurs de première expérience à éviter absolument
Aucune des pages que j'ai lues sur le sujet n'aborde ces écueils. Pourtant, ce sont eux qui tuent les projets.
Erreur n°1 : viser trop large dès le départ
Le client de février, c'était exactement ça. 47 écrans pour une première version. La règle que j'applique maintenant : un MVP tient sur 3 écrans maximum. Un écran qui affiche, un écran qui agit, un écran qui confirme. Le reste attend.
Ce n'est pas une contrainte technique. C'est une contrainte de survie. Chaque écran en plus, c'est du code en plus, des bugs en plus, des tests en plus, et surtout une date de livraison repoussée.
Erreur n°2 : confondre « simple » et « incomplet »
Un MVP, ce n'est pas une version bâclée. C'est la version qui résout un seul problème, mais qui le résout bien. J'ai vu des applis « minimales » avec un onboarding catastrophique et un bouton de paiement qui plantait une fois sur cinq. Ce n'est pas un MVP, c'est une démo cassée.
Erreur n°3 : négliger la soumission aux stores
La première fois que j'ai soumis une appli à Apple, j'ai pris un refus. Motif : compte de démonstration manquant dans les notes de révision. Trois jours perdus. Au global, environ une appli sur quatre est rejetée à la première soumission, souvent pour des raisons administratives, pas techniques. Préparez vos métadonnées, vos captures d'écran et un compte de test avant d'appuyer sur « envoyer ».
Combien de temps entre l'idée et la mise en ligne ?
Les cours en ligne annoncent « 8 heures pour faire votre première appli ». C'est vrai pour un exercice guidé. Faux pour un vrai projet publié.
Ma fourchette honnête, pour un débutant seul avec un budget no-code : comptez 4 à 8 semaines entre l'idée et une appli en ligne. Pour un projet développé en freelance, plutôt 2 à 4 mois. Le développement lui-même n'est jamais le plus long. Ce qui prend du temps, c'est :
- Valider l'idée auprès de 10 personnes réelles
- Dessiner les écrans — c'est-à-dire vraiment les dessiner, pas juste y penser
- Le développement, la première moitié
- Les tests, et là vous découvrez plein de bugs que vous n'aviez pas imaginés
- La soumission, l'attente de validation, les éventuels refus
La validation de l'idée, c'est le point que tout le monde saute. Vous voulez savoir si les gens utiliseront votre appli ? Montrez-leur un croquis sur une feuille. Si personne ne réagit, aucun code ne sauvera le projet.
Par où commencer, concrètement
Une scène que je connais par cœur. Le dimanche soir, un carnet, une idée. Le lundi matin, l'envie de tout construire d'un coup. Le piège.
Ce que je recommande, dans l'ordre :
- Écrivez votre idée en une phrase. Si vous avez besoin de trois lignes, elle n'est pas claire.
- Montrez-la à 10 personnes de votre cible. Pas à votre famille.
- Dessinez 3 écrans sur papier.
- Choisissez votre voie (no-code ou framework) en fonction du budget réel, pas du budget rêvé.
- Construisez, testez avec 5 utilisateurs, corrigez, publiez.
Si je devais résumer : la première application mobile n'est pas un projet technique, c'est un projet de renoncement. Renoncer aux fonctionnalités qu'on adorerait ajouter. Renoncer au design parfait. Renoncer au lancement triomphal. Et c'est précisément ce renoncement qui fait qu'un projet aboutit au lieu de mourir dans un cahier des charges à 47 écrans.
Mon client de février ? Je l'ai convaincu de partir sur 4 écrans et un budget de 5 500 €. L'appli est en ligne depuis six mois. Elle a 200 utilisateurs actifs, ce qui n'est pas énorme — mais elle existe. C'est déjà plus que ce que la plupart des premières idées deviennent.
