Application native ou PWA ? Quand le web suffit

Imaginez une réunion où l’on entend : « il nous faut une appli ». Quelques semaines plus tard, l’entreprise compare déjà des devis pour deux applications natives, alors que personne n’a demandé à quelle fréquence les gens ouvriront le produit ni s’ils ont besoin de quelque chose qu’un navigateur ne sait pas faire.

Ce qui détermine le choix de la plateforme, c’est la fréquence et le contexte d’utilisation du produit, ce que l’appareil doit savoir faire et ce que coûte la maintenance de plusieurs versions en parallèle. Application native ou PWA : ce ne sont donc pas les préférences du prestataire qui doivent trancher.

« Il nous faut une appli » est un réflexe, pas un cahier des charges

L’envie d’une application naît souvent d’un regard sur la concurrence, et elle désigne une solution avant même que le problème soit nommé. La démarche sensée suit l’ordre inverse : comprendre d’abord l’entreprise et ses processus, supprimer les étapes inutiles, concevoir ensuite l’expérience utilisateur et ne choisir la technologie qu’en dernier. Dans le modèle en couches de l’entreprise, le choix de la plateforme relève de la couche Experience : il détermine où l’utilisateur rencontre le produit et l’effort que cela lui demande.

Les options expliquées aux dirigeants

L’application native est un logiciel développé directement pour un seul système d’exploitation : une version pour iOS, une autre pour Android. Cela implique deux bases de code, c’est-à-dire deux ensembles de code source maintenus séparément.
L’application multiplateforme est issue du développement cross-platform : une seule base de code permet de générer l’application pour iOS comme pour Android. C’est le cas de Flutter, de Google, qui, selon sa propre FAQ (mise à jour le 14 septembre 2026), permet de réunir les développeurs dans une seule équipe et de synchroniser les sorties de versions ; il s’agit toutefois d’une affirmation de l’éditeur. Flutter appelle le code natif via ce que l’on appelle des platform channels : la connaissance d’iOS et d’Android ne disparaît donc pas complètement de l’équipe.
La web app, ou application web, fonctionne dans le navigateur, sans installation. Dans son cours Learn PWA (mis à jour le 20 septembre 2024), Google indique que le web s’affranchit de l’empaquetage, de la vérification de contenu supplémentaire et des délais de mise à jour.
La PWA, ou application web progressive, est une application web que l’on peut installer. Une fois installée, elle dispose, selon le même cours, d’une icône sur l’écran d’accueil et de sa propre fenêtre, sans l’interface du navigateur. Le mode hors ligne, c’est-à-dire le fonctionnement sans connexion réseau, repose sur le service worker : un script que le navigateur exécute selon les besoins et qui, d’après la documentation MDN de Mozilla, peut stocker les fichiers de l’application dans un cache local.

Les critères qui tranchent avant la technologie

Fréquence d’utilisation. Un outil ouvert plusieurs fois par jour mérite une icône sur l’écran d’accueil, mais une PWA l’offre aussi. Pour un service qu’un client utilise quelques fois par an, l’installation ne fait qu’ajouter une étape avant la première utilisation.
Contexte. Un technicien au sous-sol sans réseau, un magasinier qui porte des gants, un chauffeur au volant. Pour le mode hors ligne, il faut définir précisément ce qui doit se passer sans connexion : lecture, écriture, synchronisation, mais aussi résolution des conflits entre modifications.
Fonctionnalités de l’appareil. Caméra, géolocalisation en arrière-plan, Bluetooth, NFC, notifications, biométrie. Vérifiez la prise en charge de celles dont vous ne pouvez pas vous passer sur les appareils cibles, à la date de la décision, car elle évolue. Attention à l’exécution en arrière-plan : MDN (13 septembre 2026) précise que le service worker ne tourne pas en permanence et que Chrome l’arrêtera probablement, par exemple après 30 secondes d’inactivité.
Distribution. Une application web s’ouvre via un lien ou un QR code. Selon Google, les applications natives s’installent sur mobile principalement depuis les stores, qui décident de qui peut publier quoi.
Mises à jour. Selon Google, une mise à jour native exige un nouvel empaquetage, une signature, une validation et une installation. Tant que l’utilisateur ne l’a pas installée, votre serveur doit continuer à prendre en charge l’ancienne version.
Public cible. Un salarié se voit fournir l’outil, alors qu’un client doit être convaincu : face à un client, chaque étape supplémentaire peut donc coûter une partie des conversions.

Les coûts que le premier devis ne montre pas

Développement et bases de code. Deux applications natives et une version web représentent trois bases de code. Chaque fonctionnalité est développée, testée et publiée trois fois, les versions divergent avec le temps, et le taux d’anomalies augmente, tout comme le coût du support.
La validation App Store est le contrôle par lequel Apple examine chaque application et chaque mise à jour avant publication. Apple indique lui-même traiter en moyenne 90 % des soumissions en moins de 24 heures. Plus que le délai, ce qui compte est que la décision de publication ne vous appartient pas : selon la section 2.1 des App Review Guidelines (mises à jour le 8 juin 2026), Apple rejette les applications incomplètes et celles qui plantent.
Frais des stores. Les commissions portent sur la vente de contenus et de services numériques et amputent directement la marge. La section 3.1.1 de ces règles impose l’achat intégré (In-App Purchase) pour débloquer des fonctionnalités, des contenus ou un abonnement, sauf exceptions régionales. Les biens physiques et les services consommés en dehors de l’application doivent, à l’inverse, être réglés par un autre moyen. Pour les applications distribuées dans l’UE, Apple indique, dans des conditions en vigueur à partir du 1er octobre 2026, une commission de 26 % sur les ventes réalisées via In-App Purchase, et de 15 % pour les membres de l’App Store Small Business Program. Google indique que 97 % des développeurs distribuent leurs applications sur Google Play sans frais et, pour les transactions dans l’EEE à compter du 30 juin 2026, facture 10 % sur le premier million USD de revenus annuels, plus 5 % de frais pour son système de paiement.
Mises à jour des systèmes d’exploitation. Chaque évolution majeure d’iOS ou d’Android justifie de tester l’application et, souvent, de la republier, deux fois s’il y a deux applications natives. Google juge obligatoires les tests à chaque nouvelle version des systèmes et des navigateurs, y compris pour une PWA.

La PWA dans la réalité : ce qu’elle sait faire ou non aujourd’hui, en particulier sur iOS

Installation. Selon MDN (7 septembre 2026), le navigateur ne propose l’installation que pour un site doté d’un manifeste, c’est-à-dire d’un fichier qui décrit l’application, et servi via une connexion sécurisée HTTPS. Le service worker n’en est pas une condition : le mode hors ligne doit donc être conçu délibérément. Sur Android, seuls Chrome, sur les appareils équipés des Google Mobile Services, et Samsung Internet, sur les appareils Samsung, installent une PWA comme une application à part entière. Les autres navigateurs créent seulement un raccourci qui ouvre le site dans le navigateur.
iPhone et iPad. Selon MDN, sur iOS 16.4 et versions ultérieures, une PWA s’installe depuis le menu Partager. iOS ne prend pas en charge de bouton d’installation propre au site : il faut donc guider l’utilisateur. D’après le blog WebKit (15 septembre 2025), dans iOS 26 et iPadOS 26, tout site ajouté à l’écran d’accueil s’ouvre par défaut comme une application web, même sans manifeste.
Les notifications push sont des messages envoyés par un serveur, que l’appareil affiche même lorsque l’application n’est pas lancée. Le 16 février 2023, Apple a annoncé sur le blog WebKit qu’iOS et iPadOS 16.4 apportaient le Web Push aux applications web ajoutées à l’écran d’accueil : selon cette annonce, le push est donc lié à cette étape. Toujours selon elle, l’autorisation ne peut être demandée qu’à la suite d’une action directe de l’utilisateur.
Exécution en arrière-plan. Lorsque le navigateur le prend en charge, Background Sync tente d’achever une tâche une fois la connexion rétablie. Selon MDN (13 septembre 2026), cette tâche ne peut toutefois être enregistrée que lorsque l’application est ouverte, et les navigateurs limitent le nombre comme la durée des tentatives. D’après la même source, aucun navigateur ne prend en charge le push silencieux, sans notification visible.
Stores d’applications. Selon MDN, une PWA peut aussi être empaquetée pour Google Play ou l’App Store, mais la section 4.2 des règles d’Apple exige davantage qu’un simple site web réempaqueté.
Risque réglementaire. Selon TechCrunch (1er mars 2024), Apple avait, dans la bêta d’iOS 17.4, réduit les PWA à de simples raccourcis dans l’UE en invoquant le règlement sur les marchés numériques (DMA), avant de revenir sur sa décision face aux critiques. Un document de travail des services de la Commission européenne daté du 28 avril 2026 indique qu’Apple a continué à prendre en charge les applications web sur l’écran d’accueil.

Notre lecture : sur iOS, la PWA est une option exploitable, mais c’est Apple qui en fixe les limites, de même que les règles du store fixent celles d’une application native. Chaque option comporte un risque lié à la plateforme.

Outils internes versus applications clients

Contrairement au client, le salarié est conduit vers l’outil interne par le processus lui-même : un lien sur l’intranet, la connexion via le compte professionnel, un favori dans le navigateur. L’argument selon lequel l’application doit figurer dans un store pour être trouvée n’a ici plus lieu d’être.

Les outils internes servent souvent à gérer des formulaires, des circuits de validation et des tableaux de bord, sans exigence particulière en matière de matériel. Les exceptions sont l’entrepôt, le terrain ou la production, où l’appareil est un outil de travail. Sur le web, une modification parvient en outre aux utilisateurs sans qu’ils aient à installer de mise à jour. Mais aucune plateforme ne sauvera un outil qui complique le travail des équipes, comme nous l’expliquions dans l’article Le système le plus cher est celui que vos équipes n’utilisent pas.

Scénarios types

Les situations ci-dessous sont hypothétiques et servent uniquement à illustrer le raisonnement.

Technicien de terrain

Les techniciens d’une entreprise de maintenance saisissent leurs interventions même sans réseau. Si une saisie hors ligne suivie d’une synchronisation au retour du réseau suffit, une PWA constitue un pilote raisonnable, et des tests sur les téléphones des techniciens montreront si la synchronisation est fiable. Si l’entreprise a besoin de la position en continu pendant toute la journée de travail ou d’une connexion Bluetooth à un appareil de mesure, une application multiplateforme ou native est plus sûre.

Boutique en ligne

Le client achète quelques fois par an et arrive via un moteur de recherche ou une newsletter. Une application ajouterait une installation et une connexion avant l’achat. Investir dans la clarté du site rapportera davantage, car une application ne corrige pas une offre confuse, comme nous l’analysons dans l’article Quand le visiteur ne comprend pas votre site, vous payez un trafic inexploité.

Commandes B2B

Les clients professionnels d’un grossiste commandent régulièrement de longues listes de références. Les critères décisifs sont le renouvellement rapide d’une commande, l’import depuis un tableur et l’intégration à l’ERP, le progiciel de gestion intégré. Une application web y répond, mais vérifiez d’abord si le module B2B de la boutique en ligne ou de l’ERP déjà en place ne suffit pas.

Programme de fidélité

Une chaîne de cafés devrait d’abord vérifier si son système de caisse ne propose pas de fonction de fidélité. La voie intermédiaire est une PWA avec notifications push, disponibles sur iPhone uniquement après l’ajout à l’écran d’accueil. Une application native se justifie si le pilote montre que les clients utilisent souvent le programme et que c’est précisément cette étape qui les freine.

Outil interne de validation

Une entreprise valide les factures et les demandes de congés par e-mail. Il faut d’abord supprimer les étapes de validation qui ne contrôlent rien, puis vérifier si le logiciel comptable ou le SIRH déjà payé ne couvre pas le processus. Sinon, une application web avec connexion via le compte professionnel suffit, éventuellement une PWA. Deux applications natives ajouteraient ici des coûts de développement et de publication sans bénéfice suffisant pour les compenser.

Une approche progressive : le web, la mesure, puis seulement l’application native

Pour un produit sans besoin natif clairement établi, nous recommandons une démarche par étapes :

Une première version en web ou en PWA : une seule base de code, des mises à jour immédiates et une réponse rapide à la question de savoir si les gens veulent du produit.
La mesure : à quelle fréquence les utilisateurs reviennent, depuis quels appareils, combien ont installé la PWA et quelles limites se manifestent de manière récurrente.
Un seuil fixé à l’avance : la direction détermine quel résultat justifiera une application native. Sans ce seuil, la décision retombe dans le réflexe.
Une application native là où les données la justifient, souvent uniquement pour le groupe d’utilisateurs le plus actif.

Une pratique courante consiste à séparer la partie serveur, qui porte les données et la logique métier, et à l’exposer via une API, c’est-à-dire une interface convenue pour l’échange de données entre logiciels. L’application native se connecte ensuite aux mêmes données et aux mêmes règles, et le web reste un canal à part entière, comme nous le détaillons dans l’article Un site premium n’est pas une affaire d’esthétique. C’est une infrastructure commerciale. Si en revanche vous savez dès le départ que le produit repose sur une fonctionnalité que le web ne peut pas couvrir, l’approche progressive n’est qu’un détour inutile.

Quand l’application native est le bon choix

Le produit repose sur une exécution continue en arrière-plan, par exemple le suivi de la position pendant toute la journée de travail. Selon MDN, le service worker ne tourne pas en permanence ; c’est pourquoi, à notre avis, le web ne suffit pas dans ce cas.
L’application exploite en profondeur le Bluetooth, l’USB, les fichiers ou les contacts, soit des domaines que Google cite parmi les points forts des applications natives.
L’application est le produit lui-même, utilisé quotidiennement, et la performance fait partie de sa valeur.

Même dans ce cas, envisagez d’abord un développement multiplateforme avec une seule base de code. Et n’ouvrez le débat « application native ou PWA » qu’après avoir précisément défini le problème, l’utilisateur et l’environnement d’usage.

Ce qu’il faut retenir

Remplacez « il nous faut une appli » par des questions : qui utilise le produit, à quelle fréquence, où, et ce que l’appareil doit savoir faire.
Calculez les coûts sur l’ensemble du cycle de vie : chaque plateforme native ajoute une base de code, une validation et des tests, et, en cas de vente de contenus numériques, la commission du store.
Exigez que toute affirmation sur les capacités des PWA soit étayée par une source datée, en particulier pour iOS, où les conditions ont changé à plusieurs reprises depuis 2023.
Pour les outils internes, commencez par le web et n’envisagez une application native que pour le terrain, l’entrepôt ou les usages qui reposent sur du matériel.
Avant la première version, fixez un seuil mesurable qui justifiera une application native.