Qu’est-ce qu’une application mobile : quatre types, la validation des stores et quand en avoir besoin

Une application mobile est un programme qui vit dans le téléphone

À qui demande qu’est-ce qu’une application mobile, la réponse courte tient en une ligne : c’est un programme fait pour un petit écran. Wikipédia la décrit comme une application conçue pour fonctionner sur un appareil mobile, comme un smartphone, une tablette ou une montre connectée. Le client la trouve dans un store, l’installe une fois, puis l’ouvre depuis une icône, sans taper d’adresse.

Presque toutes les applications arrivent sur les téléphones par les stores. Wikipédia cite Google Play pour Android et l’App Store pour iOS parmi les plus grands, et rappelle que la boutique d’Apple a ouvert le 10 juillet 2008. En Russie, il existe aussi RuStore, un store local d’applications Android. Les revenus des applications payantes et des achats sont en général partagés entre le créateur et le store, ce qu’il vaut mieux savoir avant de prévoir des ventes dans une application.

Native, multiplateforme, web ou PWA : les différences

Une application native est écrite pour un seul système d’exploitation. Wikipédia définit les applications natives comme conçues spécifiquement pour un système mobile, en général iOS ou Android. Concrètement, cela fait deux applications, deux bases de code et deux fois plus de travail. En échange, vous obtenez un accès complet au téléphone : appareil photo, capteurs, notifications, paiements, ainsi que la vitesse et l’apparence que l’utilisateur attend de son propre système.

Une application multiplateforme partage un seul code entre iOS et Android. Flutter promet des expériences mobiles, web, de bureau et embarquées à partir d’une base de code unique. React Native explique que ses composants se transforment en interface native de chaque plateforme, si bien que l’application utilise les mêmes ressources du système que les autres. Wikipédia mentionne aussi les applications hybrides, faites en HTML, CSS et JavaScript dans un conteneur natif, et note qu’elles sont moins performantes.

Une application web tourne dans le navigateur et ne s’installe pas. D’après Wikipédia, elle peut être nettement plus lente que son équivalent natif. Une application web progressive, ou PWA, se situe entre les deux : web.dev, un guide destiné aux développeurs web, définit les PWA comme des applications web construites et enrichies avec des API modernes, que l’on peut installer et qui s’ouvrent ensuite dans leur propre fenêtre, depuis une icône sur l’écran d’accueil.

Ce qu’une PWA sait faire, ou pas, à la place d’une application de store

Le meilleur argument en faveur d’une PWA, ce sont les mises à jour. Le cours de web.dev sur les PWA indique que l’utilisateur reçoit toujours la dernière version à chaque visite, sans empaquetage ni validation supplémentaire. Une application propre à une plateforme, selon le même cours, est livrée comme un paquet indivisible, et chaque mise à jour impose de refaire le paquet, la signature, l’approbation et l’installation sur l’appareil. Pour une carte, une grille tarifaire ou un formulaire de réservation qui change chaque semaine, l’écart est réel.

Les limites existent aussi. L’article de web.dev reconnaît que certaines capacités restent hors de portée du web. Son cours sur les PWA précise que l’implémentation d’Apple n’a pas beaucoup de fonctions présentes dans d’autres navigateurs, cite parmi elles des API d’intégration comme Web Bluetooth et WebNFC, et juge l’installation plus difficile sur iOS et iPadOS. Les navigateurs évoluent chaque année : vérifiez l’état actuel des fonctions dont vous avez besoin avant de choisir.

Comment Apple examine une application avant l’App Store

Un code terminé n’est pas encore une application publiée. Les App Store Review Guidelines d’Apple indiquent que chaque application est examinée par des experts. La section 2.1 demande des versions finales avec toutes les métadonnées et des liens qui fonctionnent, sans texte provisoire ni site vide, et prévient que les applications qui plantent ou montrent des problèmes techniques évidents seront refusées.

Deux règles surprennent souvent les dirigeants. La section 4.2 exige que l’application apporte des fonctions, du contenu et une interface qui la placent au-dessus d’un site web réemballé ; une boutique qui se contente d’envelopper son site dans une icône s’expose à un refus. La section 2.2 précise que les démos, bêtas et versions d’essai n’ont pas leur place sur l’App Store et doivent passer par TestFlight, le service de test d’Apple.

L’argent et les données ont leurs propres règles. La section 3.1.1 impose l’achat intégré quand l’application débloque des fonctions ou du contenu, comme un abonnement ou des contenus premium. La section 5.1.1 exige un lien vers la politique de confidentialité, à la fois dans la fiche du store et dans l’application. Pour publier, il faut adhérer à l’Apple Developer Program, dont la page affiche, au moment où ces lignes sont écrites, une adhésion annuelle de 99 dollars.

Google Play et RuStore : comptes, testeurs et modération

Google Play a une autre porte d’entrée. L’aide de la Play Console décrit des frais d’inscription uniques de 25 dollars américains et une vérification d’identité qui peut demander une pièce d’identité et une carte à votre nom légal. Pour les comptes de développeur personnels créés après le 13 novembre 2023, elle impose un test fermé avec au moins 12 testeurs inscrits pendant 14 jours d’affilée avant de demander l’accès à la production. Cet examen, selon Google, prend en général sept jours ou moins.

RuStore, important pour le marché russe, décrit trois étapes avant publication : une analyse antivirus automatique, une modération manuelle où des spécialistes testent l’application, et un contrôle juridique qui écarte les infractions à la loi et les contenus interdits. Sa page d’aide ajoute que les plaintes des utilisateurs sont examinées à la main, et qu’une infraction confirmée peut entraîner le blocage de l’application et empêcher le développeur d’en publier de nouvelles. Les règles des trois stores changent : lisez la version en vigueur avant de fixer des dates.

Quand une entreprise a besoin d’une application, et quand un site suffit

Une application trouve sa place quand les clients reviennent souvent. Un café avec une carte de fidélité, une salle de sport avec un planning hebdomadaire, un service de livraison avec des commandes répétées, une clinique avec des rendez-vous et des résultats d’analyses : à chaque fois, l’icône sur l’écran évite au client une recherche. La deuxième raison, c’est le téléphone lui-même, quand le service a besoin de l’appareil photo, de la géolocalisation, du mode hors ligne ou de notifications fiables.

Un site suffit quand les gens viennent une ou deux fois par an. Une entreprise de rénovation, un avocat ou une salle de réception gagnent peu avec une application que personne ne rouvrira, et chaque installation demande un effort que le client ne fera peut-être pas. Les nouveaux clients trouvent ce genre d’entreprise par Google, et la recherche mène à un site. Pour beaucoup de petites entreprises, la première étape est un site mobile rapide ; la question de l’application vient plus tard.

La PWA est la voie du milieu. Elle convient à un catalogue, à une réservation ou à un espace client utilisé par les habitués, à condition que les fonctions nécessaires marchent dans les navigateurs qu’ils ont vraiment. Elle demande une seule base de code, ne repasse pas en validation à chaque changement et peut quand même s’installer. Si plus tard l’entreprise a besoin de paiements intégrés, d’un accès poussé au téléphone ou d’une place dans les classements du store, la PWA devient le prototype.

Ce que comprend la création et la vie d’une application mobile

Créer une application, c’est quatre chantiers et non un seul. D’abord le design : scénarios d’usage, écrans pour les deux plateformes, états d’erreur et de listes vides. Ensuite le développement de l’application et, presque toujours, d’une partie serveur avec une interface d’administration, car les données doivent bien venir de quelque part. Puis la publication : comptes de développeur, fiches dans les stores avec captures et descriptions, politique de confidentialité, versions de test et réponses aux examinateurs.

Le quatrième chantier est celui que les budgets oublient : la maintenance. Apple et Google publient chaque année de nouvelles versions de leurs systèmes, les règles des stores évoluent, les bibliothèques vieillissent et les utilisateurs signalent des bugs depuis des téléphones que personne n’a testés. Chaque mise à jour de store repasse en validation, si bien qu’un petit correctif prend des jours plutôt que des minutes. Un plan réaliste prévoit du temps et de l’argent pour les mises à jour dès le premier mois, pas après le premier plantage.

Préparer la commande d’une application : MVP et scénarios

Commencez par la question qu’est-ce qu’une application mobile pour votre propre entreprise : quelle action répétée doit devenir un seul geste. Écrivez trois à cinq scénarios en phrases simples, par exemple « un client fidèle réserve une visite en moins d’une minute ». Notez quelles fonctions du téléphone chaque scénario demande, et lesquelles un navigateur pourrait couvrir.

Réduisez ensuite la première version à un MVP : la plus petite application qui accomplit le scénario principal et peut passer la validation du store. Préparez le contenu et les comptes qui vous appartiennent : textes, photos, prix, politique de confidentialité, comptes de développeur au nom de votre entreprise. Si vous avez un développeur en interne, une PWA ou une application multiplateforme simple est un projet raisonnable à tenter vous-même ; si vous passez par un studio comme VITON13, apportez ces scénarios et demandez le périmètre et le prix par écrit.