Trouver une idée, c'est facile. J'en ai trois par semaine, dans la douche. Le problème commence au moment où il faut transformer ça en quelque chose qui s'installe sur le téléphone de quelqu'un d'autre.
La bonne nouvelle, en 2026, c'est qu'on peut publier une application sans écrire une seule ligne de code. La mauvaise, c'est qu'on peut aussi perdre six mois et quelques milliers d'euros à apprendre à coder pour un résultat que le no-code vous aurait donné en trois semaines. J'ai fait les deux. Dans le mauvais ordre.
Ce guide n'est pas une liste d'étapes à cocher. C'est ce que j'aurais aimé lire quand j'ai voulu créer ma première application mobile : les trois voies possibles, ce qu'elles coûtent vraiment, combien de temps elles prennent, et à quel moment je me suis trompé.
Points clés à retenir
- Trois voies existent : le no-code (2 à 6 semaines), le développement natif (3 à 8 mois seul), et la sous-traitance (délai le plus court, budget le plus lourd).
- Les frais de publication sont fixes et modestes : 25 $ une fois chez Google Play, 99 $ par an chez Apple.
- Un MVP no-code coûte entre 0 et 60 € par mois selon l'outil ; un MVP sous-traité se compte en milliers d'euros.
- Le piège numéro un n'est pas technique. C'est de vouloir tout construire avant de montrer quoi que ce soit à personne.
- L'intelligence artificielle génère du code crédible, mais jamais un produit fini. Elle vous fait gagner des heures, pas des décisions.
Les trois façons de créer sa première application mobile (et laquelle choisir)
Personne ne vous le dira franchement, alors je le fais : le choix de la méthode compte plus que le choix de l'idée. Une idée moyenne bien exécutée trouve son public. Une idée brillante mal exécutée reste un fichier oublié sur un bureau.
La voie no-code
C'est celle que je recommande à presque tous les débutants. Vous assemblez des blocs, vous configurez des écrans, vous branchez une base de données. Pas de compilateur, pas de fichiers de configuration, pas de nuit blanche sur un bug d'installation.
Ce que ça donne concrètement : un outil comme FlutterFlow, Glide, Adalo ou Bubble vous laisse produire un MVP fonctionnel en deux à six semaines, en y consacrant vos soirées. Sur mon deuxième projet, j'ai mis 19 jours entre la première maquette et une version installable sur les deux stores.
- Paiement : de 0 € en version gratuite bridée à environ 60 € par mois pour un plan sérieux
- Ce qu'on sacrifie : la performance brute, et la liberté totale sur les animations
- Le vrai risque : devenir dépendant de la plateforme. Si l'outil ferme ou triple ses tarifs, votre application est coincée.
La voie native
Vous apprenez Kotlin et Jetpack Compose pour Android, Swift et SwiftUI pour iOS. Ou bien vous partez sur du multiplateforme avec Flutter ou React Native, qui produit les deux versions depuis une seule base de code.
Franchement, c'est la voie que j'ai choisie en premier. Mauvaise idée. J'ai passé cinq mois à apprendre, et mon application n'a jamais dépassé l'écran de connexion. Je corrigeais des erreurs de compilation au lieu de résoudre des problèmes d'utilisateurs. Le code était propre. Il ne servait à personne.
Le natif devient le bon choix dans un cas précis : quand votre application dépend d'une fonction matérielle pointue (capteur, Bluetooth, traitement d'image en temps réel) ou quand vous visez des dizaines de milliers d'utilisateurs et que chaque milliseconde compte.
La voie de la sous-traitance
Vous payez quelqu'un. Un freelance seul ou une petite agence. C'est la voie la plus rapide sur le papier et la plus risquée dans les faits, parce qu'elle vous retire le contrôle sans vous retirer la responsabilité.
Comptez un budget à quatre chiffres pour un MVP honnête, et trois à cinq mois avec un interlocuteur sérieux. Le piège classique : le devis initial explose, et chaque modification devient un avenant. Exigez un périmètre écrit, écran par écran, avant de signer.
| Critère | No-code | Natif / multiplateforme | Sous-traitance |
|---|---|---|---|
| Délai réaliste pour un MVP | 2 à 6 semaines | 3 à 8 mois | 3 à 5 mois |
| Budget de départ | 0 à 60 €/mois | 0 € (votre temps) | Plusieurs milliers d'euros |
| Compétence requise | Aucune en code | Apprentissage réel | Aucune, mais pilotage ferme |
| Contrôle final | Total, dans les limites de l'outil | Total | Faible après livraison |
Si vous ne retenez qu'une chose de ce tableau : commencez par le no-code, même si vous rêvez de natif. Vous apprendrez plus sur votre produit en trois semaines de no-code qu'en trois mois de tutoriels.
Combien coûte réellement une application mobile
Les frais de publication sont la partie simple, et c'est souvent la seule qu'on vous explique. Un compte développeur Google Play se paie 25 $ une seule fois, à vie. Le compte Apple Developer, lui, coûte 99 $ chaque année, sans exception. Si vous arrêtez de payer, votre application disparaît de l'App Store.
Le reste est moins visible.
Les coûts qu'on oublie systématiquement
Un backend managé pour stocker vos données et gérer les comptes utilisateurs : la plupart proposent un palier gratuit généreux, puis facturent à l'usage. L'envoi de notifications push reste généralement bon marché, mais l'envoi d'e-mails transactionnels grimpe vite si votre application en génère beaucoup.
Et puis il y a le coût que personne ne chiffre : votre temps. Sur mon premier projet, j'ai estimé avoir passé environ 200 heures sur des tâches qui n'avaient rien à voir avec le produit — lectures de documentation contradictoires, tests d'outils abandonnés, migrations inutiles.
Peut-on créer une application mobile avec l'IA, gratuitement ?
Oui, partiellement — et cette nuance vaut son pesant d'or.
Les assistants de code génèrent aujourd'hui des écrans entiers, des requêtes de base de données, des maquettes de composants. Ils sont excellents pour débloquer une situation : vous ne savez pas comment structurer un formulaire, vous demandez, vous obtenez quelque chose de fonctionnel en trente secondes. Sur un projet perso, ça m'a fait gagner des heures que j'aurais passées sur des forums.
Ce qu'ils ne font pas : décider. Une IA ne sait pas que votre écran d'accueil doit montrer une seule action évidente plutôt que six boutons. Elle ne teste pas votre application avec un pouce, debout, dans le métro. Elle produit du code plausible, ce qui est exactement le danger — du code plausible peut cacher une faille de sécurité ou une logique absurde que vous ne verrez pas avant la mise en production.
Mon usage : je génère, puis je relis ligne par ligne. Toujours. C'est plus rapide que d'écrire, c'est plus lent que de faire confiance aveuglément — et c'est le bon compromis.
Et si je veux absolument coder moi-même, par où commencer ?
Choisissez une plateforme, pas deux. Apprenez le langage de cette plateforme, construisez une application minuscule qui n'a qu'une fonction, publiez-la. Le but n'est pas qu'elle soit utile. Le but est de traverser tout le tunnel : développement, signature, envoi sur le store, validation, mise en ligne. Une fois ce chemin parcouru, vous saurez apprendre le reste.
Publier sur le Play Store et l'App Store sans se faire refuser
Le rejet fait mal. Il arrive après des semaines de travail, sous forme d'un message court et impersonnel. J'ai eu droit à deux refus sur mon premier envoi. Les deux fois, c'était ma faute.
Les motifs de refus que je vois le plus souvent
- Une politique de confidentialité absente ou inaccessible depuis l'application elle-même. Obligatoire dès que vous collectez quoi que ce soit.
- Des captures d'écran qui ne correspondent pas au produit réel — Apple vérifie.
- Un formulaire de connexion sans possibilité de supprimer son compte. C'est une exigence ferme des deux stores.
- Une application qui n'est qu'une page web encapsulée. Si elle n'apporte rien de plus qu'un navigateur, elle sera recalée.
La validation prend généralement de quelques heures à quelques jours côté Google, et plutôt deux à sept jours côté Apple. Prévoyez cette attente dans votre planning, pas après.
Le plan que je donnerais à quelqu'un qui commence aujourd'hui
Une idée qui tient en une phrase. Un seul problème résolu. Trois écrans maximum.
Ensuite, la partie que tout le monde saute : montrez une maquette à cinq personnes avant de construire quoi que ce soit. Pas à votre famille. À des gens qui ont le problème que vous prétendez résoudre. Si trois d'entre eux haussent les épaules, vous venez d'économiser deux mois.
Puis construisez en no-code pendant trois semaines. Mettez en ligne. Regardez ce qui se passe. La plupart des applications meurent à cette étape, non pas parce qu'elles sont mauvaises, mais parce que personne ne les a jamais vues. Une fois que vous avez des utilisateurs — même dix — vous saurez enfin quoi améliorer, et si le natif ou la sous-traitance valent le coup pour la suite.
Je termine sur ce qui m'a le plus surpris. Ce n'est pas la technique qui m'a arrêté. C'est la publication. Le moment où l'on appuie sur le bouton et où l'on réalise que plus personne, à part soi, n'attend cette application. C'est désagréable, et c'est exactement ce qui fait avancer. Votre première application sera probablement médiocre. Ce n'est pas grave. La deuxième partira de là où celle-là vous aura laissé — et ce point de départ, aucun tutoriel ne peut vous l'offrir.
