Réponse en bref
Vérifiez d’abord qu’il faut au produit une application et non un site mobile : elle se justifie par les notifications, l’usage hors ligne, les capteurs ou le store. Choisissez ensuite la méthode (natif, multiplateforme ou outil sans code), réduisez la première version à un utilisateur et un scénario, testez un prototype cliquable, prévoyez le serveur, ouvrez les comptes développeur à votre nom et gardez du temps pour la validation et les mises à jour.
Vérifiez d’abord que l’idée a vraiment besoin d’une application
Ceux qui cherchent comment créer une application mobile ont souvent déjà décidé qu’il leur fallait une application. Cette décision mérite une heure de plus, car le web a beaucoup appris. MDN, la référence de Mozilla pour les développeurs web, décrit une application web progressive comme construite avec les technologies du web, mais qui se comporte comme une application propre à une plateforme. D’après sa description, elle peut s’installer, fonctionner hors ligne et afficher des notifications du système, le tout avec un seul code.
Une application de plateforme, dans la liste de MDN, possède par nature l’intégration au système d’exploitation, l’accès à la caméra, au GPS ou à l’accéléromètre et la distribution sur le store. Sur un iPhone, la limite se sent vite : l’équipe de WebKit écrivait en février 2023 que le push web arrivait avec iOS 16.4, pour les applications web que l’utilisateur a ajoutées à l’écran d’accueil. Si le produit vit de notifications quotidiennes, de capteurs ou de sa présence sur le store, faites une application. Si on l’ouvre deux fois par an, un site mobile le sert mieux.
Trois façons de la construire : natif, multiplateforme ou outil sans code
Une application native s’écrit séparément pour chaque plateforme, avec les outils de son propriétaire : un projet pour l’iPhone, un autre pour Android. Vous payez deux bases de code et obtenez l’accès le plus complet à chaque système. La deuxième façon : un seul code pour les deux. Le site de Flutter décrit un framework pour créer des applications compilées nativement à partir d’une base de code unique ; celui de React Native dit : écrit en JavaScript, rendu avec du code natif. Une seule équipe coûte moins cher, mais une nouveauté de la plateforme peut vous parvenir plus tard.
La troisième façon est un outil sans code : vous assemblez des écrans à partir de blocs prêts à l’emploi et le service produit l’application. C’est la voie la plus rapide vers quelque chose qu’un client peut tenir en main, et un moyen raisonnable de tester la demande. La règle 4.2.6 des App Review Guidelines d’Apple précise que les applications créées à partir d’un modèle commercialisé ou d’un service de génération d’applications seront rejetées, sauf si le fournisseur du contenu les soumet directement. L’application est donc publiée depuis votre propre compte développeur, pas depuis celui de l’outil.
La première version : un utilisateur et un scénario, du début à la fin
La première version n’est pas une petite copie du rêve. C’est une personne qui fait une seule chose, du premier écran au résultat : une cliente réserve une coupe, un livreur clôt une livraison, un parent paie un cours. Écrivez ce scénario comme une suite d’écrans et rayez tout ce dont la personne peut se passer pendant un mois. Ce qui reste est le chemin le plus court entre l’ouverture de l’application et le résultat.
Les stores récompensent cette discipline. La page d’Apple consacrée à App Review indique qu’en moyenne plus de 40 % des problèmes non résolus relèvent de la règle 2.1, App Completeness, qui couvre les plantages, les contenus provisoires et les informations incomplètes. Une première version étroite compte moins de recoins à moitié finis. Elle atteint aussi plus tôt de vraies personnes, et leur comportement pendant la première semaine répond à des questions qu’aucune réunion de cadrage ne tranche.
Le design avant le code : prototype cliquable et règles d’interface des plateformes
Le code est l’endroit le plus coûteux pour changer d’avis. Le scénario devient donc d’abord des écrans simples, puis ces écrans deviennent un prototype cliquable : une maquette qu’on ouvre sur un téléphone et qu’on parcourt du doigt. Confiez-la à cinq personnes qui ressemblent à votre utilisateur et regardez où elles s’arrêtent. Une hésitation repérée ici coûte une heure de designer ; la même, après la sortie, coûte un cycle de développement et une validation de plus sur le store.
Les deux plateformes publient ce à quoi leurs applications doivent ressembler. Les Human Interface Guidelines d’Apple se définissent comme des recommandations et des bonnes pratiques pour concevoir une belle expérience sur toute plateforme de la marque. La documentation d’Android pour les développeurs présente Material Design 3 comme un système ouvert et adaptable de règles, de composants et d’outils. Demandez au designer quels composants standards l’application utilise, car chaque contrôle sur mesure, c’est du design en plus, du code en plus et une chose de plus à apprendre.
Le serveur que personne ne voit : comptes, données, paiements et notifications
Ce que l’utilisateur tient en main, c’est la moitié du produit. L’autre moitié vit sur un serveur : clients, planning, commandes et une interface d’administration pour votre équipe. Quand un devis paraît étonnamment bas, vérifiez qu’il comprend cette partie. Les comptes ont aussi leurs règles : selon la règle 5.1.1 des consignes de validation d’Apple, une application qui permet de créer un compte doit aussi proposer sa suppression dans l’application, et toute application doit renvoyer vers sa politique de confidentialité. Ce que votre loi impose pour les données personnelles est une question pour un juriste.
Les paiements se divisent en deux. Selon la règle 3.1.1 d’Apple, débloquer des fonctions ou du contenu dans l’application passe par l’achat intégré ; selon la règle 3.1.3(e), les biens physiques et les services consommés hors de l’application se règlent par d’autres moyens. La politique de paiement de Google Play trace une ligne comparable. Un studio de yoga avec des cours en salle et un service de leçons en vidéo construisent donc des paiements différents. Les notifications ont aussi leur règle : la 4.5.4 n’admet les promotions par push que si le client y a explicitement consenti.
Publication : comptes développeur, test fermé de Google et validation des stores
Pour publier, il vous faut un compte développeur sur chaque store, et il doit vous appartenir, pas au prestataire. La page d’inscription d’Apple fixe l’Apple Developer Program à 99 dollars américains par année d’adhésion. L’aide de Google Play Console, consultée en octobre 2026, mentionne des frais uniques de 25 dollars américains. Un compte personnel créé après le 13 novembre 2023 doit en outre mener un test fermé avec au moins 12 testeurs pendant 14 jours consécutifs avant de demander l’accès à la production. Les deux entreprises modifient ces conditions : ouvrez les pages le jour de l’inscription.
Vient ensuite la validation. Apple affirme qu’App Review traite en général au moins la moitié des soumissions en moins de 24 heures et 90 % en moins de 48. Google prévient que, pour certains comptes développeur, l’examen peut durer jusqu’à sept jours, voire plus dans des cas exceptionnels. Un refus n’est pas un verdict : Apple indique la règle qui n’a pas été respectée et permet de répondre ou de faire appel, et Google laisse corriger puis soumettre à nouveau. Prévoyez le lancement avec une semaine de marge.
La vie après le lancement : mises à jour du système, rapports de plantage, avis et support
Une application n’est pas terminée le jour de sa sortie : les plateformes bougent sans cesse. L’aide de Google Play sur le niveau d’API cible indique que, depuis le 31 août 2026, les nouvelles applications et les mises à jour doivent cibler Android 16. La liste des exigences d’Apple indique que, depuis le 28 avril 2026, les applications envoyées sur App Store Connect doivent être compilées avec Xcode 26 ou plus récent. Les chiffres seront différents l’an prochain ; le schéma, non. Environ une fois par an, quelqu’un doit recompiler et resoumettre l’application, même si rien n’a changé chez vous.
La qualité aussi est mesurée pour vous. La documentation d’Android décrit Android vitals, des indicateurs de qualité relevés sur les appareils des utilisateurs, et fixe un seuil de 1,09 % pour le taux de plantages perçus par l’utilisateur. Au-delà, Google Play peut réduire la visibilité de l’application et afficher un avertissement sur sa fiche du store. Les avis sont publics : Apple note que, lorsqu’un développeur répond, l’auteur de l’avis en est informé et peut le modifier. Prévoyez donc au budget quelqu’un qui lit les rapports de plantage et répond aux utilisateurs chaque semaine.
Ce qu’il faut préparer avant de commander une application et comment choisir le premier périmètre
Avant de commander, mettez quatre choses par écrit. L’utilisateur et l’unique scénario de la première version, décrit étape par étape. La réponse à la question du web ou de l’application, avec sa raison : notifications, usage hors ligne, un capteur, le store. La liste de ce qui se passe sur le serveur, des comptes et des paiements à l’interface d’administration. Et les noms inscrits sur les comptes développeur. Avec cette feuille, n’importe quel prestataire peut fournir une estimation comparable, et vous verrez lequel l’a vraiment lue.
Le faire soi-même est réaliste quand il s’agit de tester la demande avec un outil sans code ou un site mobile. Commander a du sens quand l’application manipule de l’argent ou des données personnelles, doit fonctionner sur les deux plateformes, ou quand personne chez vous ne peut assurer les mises à jour annuelles. VITON13 Studio fait partie des endroits qui se chargent de ce travail ; les indépendants et les équipes internes en sont d’autres. Quelle que soit l’option, la question de savoir comment créer une application mobile devient bien plus petite dès que le premier scénario tient sur une page.
Checklist pratique
- Écrivez l’unique scénario de la première version sous forme de liste numérotée d’écrans.
- Choisissez entre un site mobile et une application, et notez la raison de ce choix.
- Ouvrez les comptes développeur Apple et Google à votre nom ou à celui de votre société.
- Listez ce que le serveur doit faire : comptes, données, paiements, notifications, interface d’administration.
- Fixez par écrit qui recompile l’application quand Android et iOS changent leurs exigences.
Questions et réponses
Peut-on créer une application sans savoir programmer ?
Oui, de deux manières. Avec un outil sans code, vous assemblez vous-même une application simple, ce qui suffit pour tester la demande. Pour tout ce qui comporte des paiements, des données personnelles ou deux plateformes, vous faites appel à des gens qui codent, et votre rôle devient le scénario, le contenu et les décisions. Dans les deux cas, les comptes développeur sont à votre nom.
Combien de temps dure la validation d’une nouvelle application sur les stores ?
Apple affirme qu’App Review examine en général au moins la moitié des soumissions en moins de 24 heures et 90 % en moins de 48. Google indique que certains comptes ont un examen plus long, jusqu’à sept jours ou plus dans des cas exceptionnels. Un nouveau compte personnel Google Play doit d’abord terminer son test fermé de 14 jours, et l’aide de Play Console indique que l’examen d’une demande d’accès à la production prend en général sept jours ou moins.
Une application web progressive suffit-elle à la place d’une application sur les stores ?
Souvent oui, pour une première version. MDN décrit des applications web qui s’installent, fonctionnent hors ligne et envoient des notifications avec un seul code. Les limites apparaissent sur iPhone, où le push web demande que l’utilisateur ajoute d’abord l’application web à l’écran d’accueil, et dans la découverte : celui qui cherche sur un store n’y trouve pas un produit qui n’y figure pas.
À quel nom ouvrir les comptes développeur : le fondateur ou le prestataire ?
Au nom du fondateur, ou de sa société. La page d’inscription d’Apple indique que le nom du compte est affiché comme vendeur sur le store, et celui qui détient le compte contrôle chaque mise à jour. Une organisation doit être une entité juridique dotée d’un numéro D-U-N-S et d’un site web en service : commencez donc ces démarches avant le développement, pas la semaine du lancement.
Pourquoi une application terminée a-t-elle besoin de mises à jour chaque année ?
Parce que les plateformes bougent. Google Play exige que les nouvelles applications et les mises à jour ciblent une version récente d’Android, et Apple exige des versions compilées avec une édition récente de ses outils. Ajoutez la correction des plantages et les réponses aux avis, et la maintenance devient une ligne permanente du plan plutôt qu’une surprise de la deuxième année.