Développer sa première application mobile : le guide sans prise de tête

Un compte Google Play : 25 $. Un compte Apple Developer : 99 $ par an. Un Mac pour compiler la version iOS : à partir de 700 € même en occasion. Voilà le vrai ticket d'entrée pour développer sa première application mobile. Ce n'est pas un article sur le marché des smartphones ni sur la croissance de l'App Store. C'est la facture.

Je pose ces chiffres tout de suite parce que 90 % des contenus sur le sujet vous vendent une vision aseptisée : « trouvez une idée, designez, codez, publiez ». Merci, on avait compris. Sauf qu'entre « trouver une idée » et « publier », il y a une décision qui bloque tout le monde au bout de deux semaines : avec quoi je code, et sur quelle plateforme ? Et personne ne vous le dit clairement.

Ce qui change quand c'est votre première application mobile

Quand on développe sa première application mobile, le problème n'est presque jamais technique. Il est décisionnel. Vous avez trois choix à faire en moins d'une semaine, et ils conditionnent tout le reste : le langage, la cible (Android, iOS, ou les deux) et le type de projet (from scratch ou no-code).

Je l'ai vécu sur mon tout premier projet. J'ai voulu faire une app de suivi d'habitudes qui tournait sur iPhone et Android. Résultat : j'ai passé trois mois à apprendre React Native en même temps que je découvrais les stores, et j'ai livré un produit à moitié cassé sur Android. Trois mois pour rien. Le vrai apprentissage n'était pas le code. C'était de comprendre qu'il fallait d'abord choisir une plateforme unique.

Commencer par un seul OS, oui

C'est contre-intuitif quand on veut toucher « tout le monde ». Mais un débutant qui vise Android ET iOS tout de suite se complique la vie pour un gain nul au départ. Vous n'avez pas encore d'utilisateurs. La question n'est pas « quel est le plus grand marché ». C'est « sur quel terrain je peux itérer le plus vite ».

Android permet de compiler et tester sur votre propre téléphone sans payer un centime, sauf les 25 $ du compte développeur au moment de publier. Sur iOS, impossible d'installer une app sur un iPhone réel sans Mac et sans compte Apple payant. C'est la barrière qui décourage. Commencez sur Android si vous partez de zéro.

Quel est le coût pour développer une application mobile ?

La fourchette dépend d'abord de qui développe. Pour un débutant qui code lui-même, le coût matériel et logiciel reste faible. Pour une app confiée à un prestataire, la facture grimpe vite.

Côté développement solo, comptez :

• compte Google Play : 25 $, une seule fois
• compte Apple Developer : 99 $ par an, uniquement si vous visez l'App Store
• Mac obligatoire pour compiler iOS : à partir de 700 € en occasion
• nom de domaine et éventuelle politique de confidentialité : quelques dizaines d'euros par an

Côté prestataire, les montants changent d'échelle. Un MVP ou prototype démarre autour de 5 000 à 20 000 €, en 1 à 3 mois. Une application B2B ou métier se situe entre 20 000 et 50 000 €. Un projet e-commerce ou avec back-office monte à 50 000 – 100 000 €. Et une app grand compte avec intégration dans un système d'information dépasse largement les 100 000 €.

Ce qu'on oublie systématiquement : la maintenance. Prévoyez 15 à 20 % du budget initial chaque année. Une app publiée n'est jamais terminée. Un nouveau système d'exploitation sort, une API change, un bug apparaît. Le coût ne s'arrête pas à la mise en ligne.

Type de projet	Technologie	Budget estimé (HT)	Délai
MVP / prototype	React Native / no-code	5 000 – 20 000 €	1 – 3 mois
App B2B / métier	Flutter / React Native	20 000 – 50 000 €	3 – 5 mois
E-commerce / back-office	Flutter / natif	50 000 – 100 000 €	5 – 8 mois
App complexe (IA, marketplace)	Natif	80 000 – 150 000 €+	6 – 12 mois

Spoiler : si vous débutez seul, vous ne payez rien de tout ça. Mais vous payez en temps. Et le temps, sur un premier projet, c'est la ressource la plus rare.

Choisir son langage : la décision qui décide de tout

Voilà l'arbitrage que presque aucun guide ne tranche. Alors je le tranche, quitte à être partial.

Kotlin, Swift, Flutter ou React Native ?

Si vous visez uniquement Android : Kotlin. C'est le langage officiel recommandé par Google, la documentation est à jour, et vous trouverez un tutoriel pour chaque problème. Vous partez sur Android Studio, l'environnement officiel fourni par Google.

Si vous visez uniquement iOS : Swift, dans Xcode. Aucune raison sérieuse de faire autrement aujourd'hui.

Si vous voulez vraiment les deux plateformes avec une seule base de code : Flutter ou React Native. C'est là que je place mon opinion, et je la défends : pour un premier projet multi-plateforme, je préfère React Native. La raison n'est pas technique. C'est la densité de ressources. React Native s'appuie sur JavaScript, le langage le plus documenté du web, et la communauté est énorme. Quand vous bloquez à 23 h sur un composant cassé, vous trouvez une réponse. Flutter est excellent aussi, plus performant sur certaines interfaces, mais l'écosystème reste plus fermé aux débutants.

Le no-code, enfin, mérite d'être cité. Des outils en ligne permettent de créer une application sans écrire une ligne de code, gratuitement pour commencer. C'est parfait pour valider une idée. C'est insuffisant dès que vous voulez un comportement un peu spécifique. Si votre objectif est d'apprendre à coder, il ne vous apprendra pas à coder.

Décidez une fois, et arrêtez de comparer. Le meilleur langage est celui sur lequel vous irez au bout du projet.

Peut-on créer une application gratuitement ?

Oui, jusqu'à un certain point. Et c'est précisément ce point qui surprend.

Tout le développement peut se faire gratuitement : Android Studio, VS Code, Flutter, React Native, les tutos, les documentations. Pendant des mois, votre budget peut rester à zéro.

Ce qui devient payant, c'est la mise sur le marché :

1. Google Play : 25 $ une fois, pour publier
2. Apple App Store : 99 $ par an, plus le matériel Mac
3. un hébergement si votre app a un serveur (les offres gratuites existent, mais bridées)

Donc « créer une application gratuitement » est vrai tant que vous restez en local. Le jour où vous voulez que quelqu'un d'autre l'installe, la carte bancaire entre en jeu. Aucun contournement sérieux. J'ai vu des gens chercher des failles pendant des semaines. Perte de temps.

Publier sur les stores : le parcours concret

La publication n'est pas la partie longue. La préparation l'est.

Délais de validation réels

Sur Google Play, une première publication passe souvent en quelques heures, parfois jusqu'à deux jours. Sur l'App Store, comptez plutôt 24 à 48 h pour une première soumission. Ce n'est pas le délai qui pose problème, c'est le refus.

Les refus fréquents, et comment les éviter

Apple est réputé plus strict. Les motifs de rejet les plus courants pour une première app :

• une page de politique de confidentialité absente ou incomplète
• une description qui ne correspond pas au contenu réel de l'app
• des captures d'écran trompeuses
• un crash au lancement lors du test par le relecteur

La politique de confidentialité n'est pas une option, surtout si votre app collecte la moindre donnée. Si vous touchez des utilisateurs en Europe, le RGPD s'applique et vous devez indiquer clairement ce que vous collectez et pourquoi. C'est fastidieux, personne n'aime le faire, et c'est ce qui bloque le plus de première publications.

Faut-il tester sur un appareil réel avant de publier ?

Toujours. L'émulateur ne reproduit pas les performances réelles, la batterie, ni les bizarreries de l'écran tactile. J'ai publié une app qui marchait parfaitement dans l'émulateur et qui plantait sur un téléphone d'entrée de gamme. Un utilisateur me l'a signalé en deux jours. Testez sur au moins un appareil physique, idéalement le moins puissant que vous possédez.

Les erreurs qui coulent un premier projet

La plus grosse, et de très loin : un périmètre trop ambitieux. Vous voulez une app avec comptes utilisateurs, messagerie, notifications, paiement, mode hors-ligne. Rien de tout ça n'est nécessaire pour apprendre, et tout ça multiplie par dix le temps de développement.

Le principe du MVP, version minimale viable, s'applique parfaitement ici. Une seule fonctionnalité, faite correctement. Publiez-la. Voyez si quelqu'un l'utilise. Ensuite seulement, ajoutez.

Autres pièges dans lesquels je suis tombé :

• ne pas gérer les versions dès le début (un vrai désastre pour retrouver une ancienne build)
• reporter les tests sur appareil réel à la fin
• ignorer les utilisateurs qui signalent un bug au lieu de les remercier

Le dernier point paraît anodin. Il ne l'est pas. Les premiers utilisateurs qui vous écrivent sont en or. Chaque retour vaut mieux qu'un mois passé à deviner.

Un plan d'action réaliste semaine par semaine

Si vous partez de zéro, voici un rythme tenable. Pas un marathon de trois jours qui vous épuise, mais une progression régulière.

• Semaines 1-2 : choisir la plateforme et le langage. Installer l'environnement. Faire un « bonjour monde » qui s'affiche sur votre téléphone.
• Semaines 3-6 : construire UNE fonctionnalité, la plus simple possible. Pas de compte, pas de paiement.
• Semaines 7-8 : tester sur appareil réel, corriger les crashs, préparer les visuels et les textes du store.
• Semaine 9 : publier. Même imparfait.
• Ensuite : écouter les retours et n'ajouter qu'une seule chose à la fois.

Un cours structuré comme celui d'OpenClassrooms, environ 8 heures pour les bases Android, ou les codelabs officiels de Google, suffisent largement pour ce plan. Pas besoin de dix formations. Une seule, suivie jusqu'au bout, vaut mieux que dix commencées.

Et si vous bloquez sur un concept — les états, les appels réseau, la persistance —, ne culpabilisez pas. J'ai mis deux semaines à comprendre pourquoi mon application perdait toutes ses données à chaque redémarrage. La réponse était évidente une fois trouvée. Elle ne l'était pas avant.

Ce que personne ne dit sur la suite

Publier sa première application ne fait pas de vous un développeur. Ça fait de vous quelqu'un qui a fini un projet. La différence est énorme, et c'est peut-être la leçon la plus utile.

La deuxième application sera deux fois plus rapide. La troisième, trois fois. Ce n'est pas que vous devenez meilleur à coder. C'est que vous arrêtez de vous poser les mêmes questions au départ. Le vrai coût d'un premier projet, ce n'est pas l'argent. C'est le temps passé à hésiter avant de commencer.

Alors la seule question qui compte, au fond : quelle fonctionnalité unique allez-vous construire cette semaine ?