Application mobile ou application web : que choisir ?

« Faut-il faire une application mobile ou une application web ? » C'est la première question de presque tous les projets d'application qu'on nous confie, et elle est souvent mal posée. En France, 91 % des personnes de 12 ans et plus possèdent un smartphone, selon le Baromètre du numérique 2026 de l'Arcep et du CRÉDOC. Tout le monde veut donc être « sur mobile ». Mais une application web installable s'ouvre aujourd'hui depuis l'écran d'accueil d'un iPhone, envoie des notifications et fonctionne sans réseau. La vraie décision n'oppose plus le téléphone au navigateur : elle porte sur la distribution par les stores, avec leurs règles et leurs commissions. Voici ce que chaque option sait faire, ce qu'elle coûte, et comment nous avons tranché pour Athlos.

Application mobile, application web, PWA : de quoi parle-t-on ?

On distingue trois familles : l'application native, écrite pour iOS ou pour Android et publiée sur les stores ; l'application multiplateforme, un seul code publié sur les deux stores ; et l'application web, ouverte dans le navigateur, que la PWA rend installable sur l'écran d'accueil. Les trois peuvent être utilisées sur un téléphone. Elles diffèrent par la façon dont on les obtient, dont on les met à jour et dont on les paie.

Le vocabulaire entretient la confusion. « Application mobile » désigne en général une application téléchargée sur l'App Store ou Google Play, alors qu'une application web bien conçue se manie tout aussi bien au pouce.

L'application native, écrite pour un seul système

Une application native est écrite dans le langage du système qu'elle vise, Swift pour l'iPhone, Kotlin pour Android, et elle a accès à toutes les fonctions du téléphone dès leur sortie. C'est l'option la plus performante et la plus coûteuse : viser les deux systèmes revient à construire deux applications. On la réserve aux produits qui exploitent le matériel en profondeur (capteurs, Bluetooth, réalité augmentée) ou dont la fluidité est l'argument principal, comme un jeu.

L'application multiplateforme, un code pour deux stores

React Native ou Flutter produisent une application publiée sur l'App Store et sur Google Play à partir d'un seul code principal, avec une expérience proche du natif. C'est le choix courant quand la présence dans les stores est nécessaire et que le budget ne permet pas deux applications. Le gain est réel mais pas total : il reste du code propre à chaque système, deux processus de publication, et des mises à jour d'iOS et d'Android à suivre chaque année. Sur la page de notre service de développement d'applications, React Native fait partie de la pile que nous proposons quand les stores sont indispensables.

L'application web et sa version installable, la PWA

Une application web tourne dans le navigateur, et une PWA (progressive web app) est une application web qui peut s'installer sur l'écran d'accueil, s'ouvrir en plein écran sans barre d'adresse, envoyer des notifications et garder des données pour fonctionner hors connexion. Pour être installable, elle n'a besoin au minimum que d'une adresse en HTTPS et d'un fichier manifeste qui décrit son nom, ses icônes et son mode d'affichage. Pour l'utilisateur, une fois l'icône posée sur l'écran d'accueil, la différence avec une application téléchargée est souvent invisible.

Stores ou navigateur : où se joue vraiment le choix ?

Puisqu'une PWA s'installe, notifie et fonctionne hors ligne, la ligne de partage ne passe plus entre « mobile » et « web » : elle passe entre une distribution par les stores, avec leur vitrine, leurs règles et leurs commissions, et une distribution directe par une adresse web. C'est cette question qu'il faut trancher en premier, avant la technologie.

Ce que les stores apportent : une vitrine et un réflexe

L'App Store et Google Play apportent deux choses qu'un site n'a pas : un moteur de recherche où le grand public cherche des applications, et un geste d'installation que tout le monde connaît. Pour une application grand public qui doit être découverte par des inconnus, cette vitrine compte.

Y être visible demande pourtant un travail de fiche, d'avis et parfois de publicité, au milieu de millions d'applications. Pour une application métier destinée à vos équipes ou à vos clients existants, elle n'apporte presque rien : vos utilisateurs ne vous cherchent pas dans l'App Store, ils reçoivent un lien de votre part.

Ce qu'ils coûtent : compte développeur, validation, commission

Publier sur les stores ajoute trois coûts : un compte développeur payant, une validation de chaque version par la plateforme, et une commission sur les ventes de contenus numériques faites dans l'application. Aucun n'est rédhibitoire, mais ils s'additionnent sur toute la vie du produit.

Ces taux ont bougé en 2026. En France, la commission d'Apple est passée de 30 % à 26 % le 1er octobre, et le taux réduit de 15 % vaut pour les développeurs qui ont gagné jusqu'à un million de dollars l'année précédente. Chez Google, la grille européenne a changé le 30 juin 2026 : 10 % de commission plus 5 % de frais de facturation sur le premier million de dollars annuel et sur les abonnements, selon la page des frais de service de Google Play. Côté délais, Apple indique examiner « at least 50% of submissions in less than 24 hours and 90% in less than 48 hours » sur sa page consacrée à l'App Review, et un compte Google personnel récent doit faire tester l'application par 12 testeurs pendant 14 jours avant de la publier.

Ce que le web apporte : une adresse, un code, une mise à jour

Une application web se partage par un lien, se met à jour pour tous les utilisateurs à la seconde où vous publiez, et ses pages publiques peuvent être trouvées dans Google. Une application des stores est invisible pour les moteurs de recherche, alors qu'une application web peut avoir des pages publiques (présentation, tarifs, contenus) qui travaillent votre référencement naturel et votre visibilité dans les IA. Pour un produit qui vit de l'acquisition par Google, c'est un argument de poids. Le revers : sans store, l'utilisateur ne pense pas spontanément à « installer » votre application, et il faut le lui proposer au bon moment.

Que sait faire une application web installable en 2026 ?

En 2026, une PWA s'installe sur l'écran d'accueil d'un iPhone comme d'un Android, envoie des notifications, fonctionne hors connexion, accède à l'appareil photo et à la géolocalisation tant qu'elle est ouverte, et encaisse des paiements par le web. Les limites qui restent sont précises, et nous les détaillons dans la section suivante.

Notifications sur iPhone : les conditions exactes

Depuis iOS 16.4, une application web ajoutée à l'écran d'accueil d'un iPhone peut recevoir des notifications, à condition que l'utilisateur l'ait installée et qu'il ait accepté les notifications après un geste de sa part. Apple l'écrit dans sa documentation sur les notifications web : la demande doit passer par un geste, « such as clicking or tapping a button », et aucun compte développeur payant n'est nécessaire pour envoyer ces notifications. La même mise à jour a ouvert les pastilles de compteur sur l'icône de l'application, comme pour une application téléchargée.

Ces deux conditions changent la conception : la demande d'autorisation suit une action de l'utilisateur, par exemple un bouton « Être prévenu de mes défis », et le parcours doit expliquer l'installation au moment où elle a du sens. Depuis iOS 26, sorti en septembre 2025, ce geste est devenu plus simple : « by default, every website added to the Home Screen opens as a web app », écrit l'équipe de WebKit, le moteur de Safari, dans sa présentation de Safari 26. Le site s'ouvre alors en plein écran, sans la barre du navigateur.

Hors connexion et données gardées sur le téléphone

Une PWA fonctionne sans réseau grâce à un service worker, un petit programme qui met en cache l'interface et les données utiles, et elle peut stocker des informations sur le téléphone. Un technicien qui saisit un rapport dans une cave sans réseau peut le terminer et l'envoyer au retour de la connexion. Sur iPhone, Safari peut effacer les données d'un site consulté dans le navigateur après sept jours sans visite, mais une application installée sur l'écran d'accueil échappe à cet effacement : l'équipe WebKit a confirmé une exception explicite pour les web apps de l'écran d'accueil, dont les données sont en plus isolées de celles de Safari.

Appareil photo, géolocalisation, paiement : l'essentiel est couvert

L'appareil photo, la géolocalisation pendant l'utilisation, le partage, le paiement en ligne, la lecture de QR codes et l'authentification par empreinte ou visage sont accessibles à une application web. Ce sont les fonctions dont ont besoin la plupart des applications métier et des applications de service : prendre une photo de chantier, trouver l'agence la plus proche, payer un acompte, se connecter sans mot de passe. Les applications dont nous parlons dans notre guide pour remplacer un fichier Excel par une application métier entrent presque toutes dans ce cadre : des formulaires, des statuts, des photos, des tableaux de bord, consultés au bureau comme sur le terrain.

Quand une application des stores reste-t-elle indispensable ?

L'application des stores reste indispensable dans trois cas : quand elle doit utiliser des fonctions que Safari n'ouvre pas aux sites (géolocalisation en arrière-plan, Bluetooth, NFC), quand son public la cherche dans l'App Store, et quand elle exige des performances de jeu ou de 3D. En dehors de ces cas, le web couvre le besoin pour un coût moindre.

Les fonctions que l'iPhone réserve aux applications des stores

Une application web ne peut pas suivre la position de l'utilisateur quand elle est fermée, et l'iPhone ne donne pas aux sites l'accès au Bluetooth ni au NFC. La spécification de la géolocalisation du W3C réserve les mises à jour de position aux pages ouvertes et visibles, « exclusively for fully-active visible documents » : dès que l'application passe en arrière-plan, elles sont ignorées. Quant au Bluetooth et au NFC, leurs interfaces web n'existent pas dans Safari sur iPhone, et le NFC web n'est disponible que dans Chrome sur Android. Une application de livraison qui suit un coursier écran éteint, un objet connecté piloté en Bluetooth, un badge d'accès lu par NFC : ces usages imposent une application des stores. Il en va de même pour les widgets sur l'écran d'accueil ou l'intégration profonde avec les données de santé. Si votre cahier des charges contient l'un de ces besoins, la question est réglée.

Quand votre public cherche dans l'App Store

Pour une application grand public qui doit être trouvée par des inconnus, l'absence des stores est un handicap commercial, même si la technique suit. Le réflexe « je cherche une application dans l'App Store » est ancré chez beaucoup d'utilisateurs. À l'inverse, une application réservée à vos clients, à vos adhérents ou à vos équipes n'a pas besoin d'être trouvée : elle est envoyée. C'est la situation de la plupart des applications métier sur-mesure, et de nombreuses plateformes B2B.

Les performances : jeu, 3D, traitement lourd

Un jeu exigeant, de la réalité augmentée, du montage vidéo ou du traitement d'image en temps réel restent mieux servis par du natif. Pour une application de gestion, de réservation, de suivi ou de réseau social, l'écart de performance ne se voit pas : la différence se joue sur la qualité du code et sur le temps de chargement, pas sur le choix du support. Une application web bien construite répond aussi vite qu'une application téléchargée, et notre article sur les Core Web Vitals détaille les seuils de réactivité qu'elle doit tenir.

Athlos : une application sociale complète, installée depuis le navigateur

Athlos, application de suivi sportif que nous avons conçue, est une PWA installable : classement national en temps réel, défis en un contre un, notifications, détection du club le plus proche et abonnement Premium, sans passer par l'App Store ni par Google Play. C'est la preuve qu'une application grand public complète tient aujourd'hui dans un navigateur.

Ce que l'application devait faire

Le cahier des charges d'Athlos réunissait ce qu'on croit souvent réservé aux applications des stores : des scores et des classements mis à jour en temps réel, des notifications pour les défis reçus et les records battus, et une détection automatique du club à proximité à l'inscription. S'y ajoutait un back-office multi-rôles pour les athlètes, les coachs et les gérants de club, avec les indicateurs de pilotage (membres actifs, risque de départ, séances) et un abonnement Premium mensuel ou annuel suivi en revenu récurrent. Le détail du projet est sur la fiche du cas Athlos.

Pourquoi la PWA tenait la route

Chacune de ces fonctions existe sur le web : le temps réel par des connexions maintenues avec le serveur, les notifications par le web push, la détection du club par la géolocalisation demandée au moment de l'inscription, quand l'application est ouverte. Aucune ne demandait le suivi de position en arrière-plan, le Bluetooth ou le NFC, les trois verrous de la section précédente. La PWA apportait en plus trois avantages concrets : un seul code pour le téléphone de l'athlète et l'écran du gérant de club, des corrections en ligne le jour même sans attendre une validation, et un abonnement Premium encaissé par le web, donc hors des commissions des stores sur les contenus numériques.

Ce que ce choix demande en échange

Sans fiche dans les stores, une PWA doit gagner son installation : l'utilisateur arrive par un lien, et c'est l'application qui doit lui proposer de l'ajouter à son écran d'accueil, au moment où il en voit l'intérêt. Sur iPhone, ce geste conditionne aussi les notifications. L'acquisition passe par le bouche-à-oreille, les clubs et les pages publiques du site, et pas par la recherche dans l'App Store. Pour une application sociale qui grandit par les clubs et par les défis entre membres, c'est un échange acceptable. Pour une application qui compterait sur la découverte dans les stores, il ne le serait pas.

Abonnements et paiements : ce que les stores prélèvent

Sur l'App Store, une application qui vend des contenus ou des fonctions numériques doit passer par le système d'achat intégré d'Apple, qui prélève une commission ; une application web encaisse ses abonnements par un prestataire de paiement, sans commission de plateforme. Pour un modèle à abonnement, cette différence pèse sur la marge pendant toute la vie du produit.

La règle de l'achat intégré et ses commissions

Les règles de l'App Store imposent l'achat intégré pour débloquer des fonctionnalités ou des contenus numériques dans une application. La règle 3.1.1 des App Store Review Guidelines donne elle-même les exemples : abonnements, monnaies de jeu, niveaux, accès à du contenu premium, déblocage d'une version complète. Concrètement, sur 100 € d'abonnements hors taxes vendus dans l'application, 26 € partent chez Apple pour un développeur hors programme, 15 € pour un membre du programme pour petites entreprises.

Biens physiques et services : hors du système d'achat intégré

Une application qui vend des biens physiques ou des services consommés hors de l'application, un repas, une séance de coaching, une réparation, n'est pas soumise à l'achat intégré et encaisse avec le prestataire de paiement de son choix. La règle 3.1.3(e) d'Apple va même plus loin : pour des biens physiques ou des services « consumed outside of the app », l'application doit utiliser un autre moyen de paiement que l'achat intégré, comme Apple Pay ou la carte bancaire. Une application de réservation pour un restaurant ou de prise de rendez-vous pour un coach n'est pas concernée, qu'elle soit publiée sur les stores ou non.

Sur le web, l'abonnement reste chez vous

Une application web vend ses abonnements par son propre tunnel de paiement : le prix, la relation client, les données de facturation et la marge restent chez vous. Vous payez les frais de votre prestataire de paiement, de l'ordre de quelques pourcents par transaction, et vous gardez la main sur les relances, les essais gratuits et les offres annuelles. C'est le fonctionnement des SaaS que nous développons, et c'est l'un des postes que nous détaillons dans notre article sur le budget d'un SaaS, du MVP à la V1. Vendre sur le web impose en contrepartie de traiter vous-même ce que le store traitait pour vous : facturation, TVA et règles de résiliation.

Combien coûte une application mobile ou web ?

Sur notre grille publique, une application web ou PWA démarre à 5 000 € pour un MVP et va jusqu'à 20K€ pour une application complète, tandis qu'une application native iOS et Android relève de notre formule sur-mesure, sur devis. L'écart vient du nombre de bases de code à construire, à publier et à maintenir.

Un code, deux codes ou trois

Le premier facteur de coût est le nombre de bases de code : une PWA en a une, une application multiplateforme en a une principale plus les adaptations à chaque store et souvent un site à côté, une application native en a une par système. Chaque base de code se conçoit, se teste et se maintient. Une PWA qui sert à la fois les utilisateurs sur téléphone et un back-office sur ordinateur évite de payer deux fois les mêmes écrans. Les tarifs de notre grille détaillent ce que comprend chaque palier, et notre article sur le coût d'une application métier sur-mesure explique comment lire un devis en jours de travail.

Les frais qui n'existent qu'avec les stores

Une application des stores ajoute des frais que le web n'a pas : les comptes développeur, la commission sur les ventes numériques et du temps de validation à chaque version. Chaque version passe en validation, jusqu'à 48 heures pour 90 % des soumissions selon Apple, et un refus impose une correction puis une nouvelle soumission. Sur une application qui évolue chaque semaine, ce délai compte dans le planning, et il pèse surtout le jour où il faut corriger un bug en urgence.

La maintenance : les mises à jour que vous ne choisissez pas

Une application des stores doit suivre les nouvelles versions d'iOS et d'Android, sous peine de dysfonctionner ou de ne plus pouvoir être mise à jour, alors qu'une application web suit surtout l'évolution des navigateurs, plus progressive. Dans les deux cas, une application vit : correctifs de sécurité, dépendances à mettre à jour, petites évolutions. C'est l'objet de notre offre de maintenance et de croissance, à prévoir dès le budget initial plutôt qu'après la mise en ligne.

L'accessibilité, une obligation qui ne dépend pas du support

Depuis le 28 juin 2025, les services de commerce électronique destinés aux particuliers doivent être accessibles aux personnes handicapées, qu'ils passent par un site ou par une application mobile. La directive européenne 2019/882, transposée en France par la loi du 9 mars 2023 et son décret du 9 octobre 2023, vise expressément les services fournis « via des sites internet, des services intégrés sur des appareils mobiles ». Les microentreprises de services, moins de 10 salariés et au plus 2 millions d'euros de chiffre d'affaires ou de bilan, en sont dispensées. Contrastes, navigation au clavier ou à la voix, textes alternatifs se prévoient donc dès la conception, sur le web comme dans les stores. Notre guide de la création de site e-commerce détaille ce que cette règle change pour une boutique.

La grille de décision : sept questions avant de choisir

Sept questions suffisent à orienter le choix, et aucune ne porte sur la technologie : elles portent sur vos utilisateurs, les fonctions du téléphone, votre modèle économique et votre budget. Répondez-y avant de parler technologie.

Les signaux qui orientent vers le web

Un public que vous connaissez, un usage mixte téléphone et ordinateur, des évolutions fréquentes et un budget de lancement serré désignent une application web installable. C'est le profil de la plupart des applications métier, des portails clients, des outils de réservation et des MVP de startup. Pour un premier produit, la PWA a un avantage de plus : elle teste l'usage réel avant d'investir dans les stores. C'est la logique que nous défendons dans notre article sur quand quitter le no-code pour le sur-mesure : prouver avant d'industrialiser.

Les signaux qui orientent vers les stores

Une fonction matérielle fermée au web, un large public qui cherche dans les stores, ou des performances de jeu désignent une application des stores. Dans ce cas, la question suivante est celle du multiplateforme ou du natif, qui dépend du niveau d'exigence sur le matériel et la fluidité. Une application de livraison avec suivi en arrière-plan, une application d'objet connecté ou un jeu mobile entrent ici, et le budget se construit alors sur devis.

La voie intermédiaire : la PWA d'abord, les stores ensuite

Une PWA peut être publiée plus tard sur Google Play, et une application web peut être enveloppée dans une coque native pour l'App Store, à condition d'y ajouter de vraies fonctions natives. Google documente la publication d'une PWA sur Google Play sous la forme d'une « Trusted Web Activity », avec un outil dédié, dans sa documentation pour les développeurs Chrome, et Google précise qu'une application ainsi publiée qui vend du numérique passe par sa facturation. Apple est plus strict : sa règle 4.2 exige des fonctions, du contenu et une interface « that elevate it beyond a repackaged website », faute de quoi l'application est refusée. Une coque native qui se contente d'afficher votre site est refusée : il faut lui ajouter de vraies fonctions natives, comme des notifications riches ou un accès au matériel. Commencer par le web ne ferme donc aucune porte : le code métier, l'API et le back-office restent, seule la couche de présentation change.

Par où commencer votre projet d'application ?

Commencez par décrire l'usage, pas la technologie : qui utilise l'application, où, à quel moment, et ce qu'il doit pouvoir faire en moins d'une minute. Le choix entre web et stores découle de ces réponses, presque toujours sans débat.

1. 1

   Décrire les usages

   1 semaine

   Lister les profils d'utilisateurs, les trois actions les plus fréquentes de chacun, et le contexte (bureau, terrain, déplacement, hors réseau).
2. 2

   Lister les fonctions du téléphone

   2-3 jours

   Pour chaque usage, noter ce qui est demandé au téléphone : photo, position, notifications, Bluetooth, NFC, arrière-plan.
3. 3

   Trancher stores ou web

   1 rendez-vous

   Confronter la liste aux verrous de l'iPhone et au mode d'acquisition. Dans la plupart des cas, la réponse tombe d'elle-même.
4. 4

   Livrer, mesurer, décider la suite

   6 à 12 semaines

   Livrer une première version, mesurer l'usage réel et l'installation, puis décider si une présence dans les stores se justifie.

Écrire les usages avant les écrans

Une liste d'usages concrets vaut mieux qu'une maquette pour choisir entre web et stores : « le technicien prend trois photos et fait signer le client sur le chantier » dit tout de suite ce dont l'application a besoin. Les maquettes viennent après, quand on sait sur quel support elles s'affichent. C'est aussi ce document qui sert à chiffrer le projet sans surprise, et que nous travaillons avec vous dans nos missions de conseil et de stratégie.

Penser à l'écran de l'ordinateur

Presque toutes les applications ont un deuxième public, sur ordinateur : le gérant, le service client, la comptabilité, qui consultent et pilotent ce que les utilisateurs saisissent sur leur téléphone. Oublier ce public conduit à construire une application des stores, puis un back-office web à côté, soit deux projets. Une application web traite les deux d'un même code, avec des écrans adaptés à chaque taille. C'est ce qui fait souvent pencher la balance pour les PME, qu'il s'agisse d'un site et d'outils pour une PME ou d'un outil pour des artisans qui travaillent sur le terrain.

Prévoir l'installation dans le parcours

Si vous partez sur une PWA, l'invitation à installer l'application fait partie du produit : elle doit arriver après une première action réussie, avec une explication courte adaptée à l'iPhone et à Android. C'est elle qui donne accès aux notifications sur iPhone et qui ramène l'utilisateur chaque jour. Une PWA techniquement parfaite mais jamais installée se comporte comme un site qu'on oublie. Nous concevons ce parcours avec le reste de l'application dans nos projets de développement web.

FAQ : vos questions sur le choix entre application mobile et web