Applications Web Progressives : Quand La PWA Bat Le Natif

Le développement d’applications web progressives est l’option que les acheteurs britanniques écartent dans les dix premières minutes d’un projet et redécouvrent dix-huit mois plus tard, quand la deuxième base de code native a discrètement dévoré le budget. On l’écarte parce que presque tout ce qui s’écrit dessus tient de deux camps, un plaidoyer qui saute ce qu’iOS refuse de faire, ou un scepticisme hérité de 2019, quand la plateforme en était vraiment incapable.

Les deux ont tort aujourd’hui, et cela change le calcul. Safari gère les notifications push dans les web apps d’écran d’accueil depuis iOS 16.4. Chrome a abandonné l’exigence du service worker pour l’installation. En octobre 2025, le régulateur britannique a reconnu à Apple et Google un statut de marché stratégique sur leurs navigateurs et moteurs mobiles. Et iOS refuse toujours l’exécution en arrière-plan, évince les données stockées selon des règles hors de votre contrôle, et ne listera jamais une web app dans l’App Store.

C’est la version que je donnerais à un client hésitant entre une base de code et trois. Chaque capacité citée ici a été vérifiée en septembre 2026 dans la documentation de l’éditeur, car les idées reçues y ont fiablement deux ans de retard.

Quand une PWA bat-elle une application native ? Quand vos utilisateurs sont autant sur Android et ordinateur que sur iPhone, quand l’application sert de façade à un serveur plutôt qu’à l’appareil, et quand on vous trouve par la recherche, pas en magasin. Une PWA perd s’il vous faut la géolocalisation en arrière-plan, des widgets d’écran d’accueil, le Bluetooth sur iPhone ou la facturation du magasin. L’économie : une base de code au lieu de trois, soit environ £40 000 à £120 000 de construction au Royaume-Uni, et une facture nettement plus légère chaque année ensuite.

Ce qu’est vraiment une application web progressive

Le terme s’emploie assez librement pour que deux personnes d’une même réunion n’entendent pas la même chose. La définition technique est étroite et il vaut la peine de s’y tenir.

MDN décrit une application web progressive comme une application construite avec les technologies de la plateforme web qui offre une expérience proche d’une application spécifique à la plateforme. Elle tourne sur plusieurs plateformes depuis une seule base de code, et elle peut s’installer, fonctionner hors ligne et s’intégrer au système d’exploitation.

En pratique, cela veut dire trois artefacts, et un site auquel il en manque un est un site avec des ambitions plutôt qu’une PWA.

Le manifeste d’application web

Le manifeste est un fichier JSON qui indique au système d’exploitation le nom de l’application, les icônes à utiliser, l’URL à ouvrir au lancement, et s’il faut tourner dans un cadre de navigateur ou en mode autonome. Sans lui, le navigateur n’a rien à installer. Il est petit, il est statique, et c’est la partie la moins chère de tout l’exercice.

Le service worker

Un service worker est un script qui tourne séparément de la page, se place entre l’application et le réseau, et peut répondre aux requêtes depuis un cache. C’est lui qui rend le comportement hors ligne possible et qui reçoit les messages push. C’est aussi la partie qui déraille, car un cache mal délimité sert du code périmé aux utilisateurs pendant des semaines.

HTTPS

Les service workers, le push, la géolocalisation et l’accès à la caméra sont tous réservés aux contextes sécurisés. Sur un hébergement moderne, c’est gratuit et automatique, donc une contrainte plutôt qu’un coût.

Ce que veut dire installée, plateforme par plateforme

Les acheteurs supposent que l’installation est un seul comportement. Il y en a trois, et les différences comptent commercialement.

Android

Chrome sur Android offre ce qui se rapproche le plus de la parité. L’application obtient une icône sur l’écran d’accueil, sa propre entrée dans le sélecteur d’applications, son propre stockage, et elle peut être listée sur le Play Store via un conteneur. Les invites d’installation se déclenchent depuis votre propre interface une fois que le navigateur a émis l’événement voulu, vous maîtrisez donc le moment où vous posez la question.

iOS et iPadOS

Safari installe via la feuille de partage et l’entrée d’ajout à l’écran d’accueil. Il n’existe aucune invite d’installation dans la page que vous puissiez déclencher, aucune bannière qu’Apple affichera pour vous, et aucun moyen fiable de détecter qu’un utilisateur l’a fait. Cet unique écart d’interaction est la plus grande différence pratique entre les plateformes, et c’est un problème de conception plutôt que d’ingénierie : il faut enseigner un geste à l’utilisateur.

Ordinateur de bureau

Chrome, Edge et Safari sur macOS installent tous les applications web dans le dock ou la barre des tâches, avec leur propre fenêtre. Le bureau est l’endroit où les PWA sont les moins contestées et les plus sous-utilisées, en particulier pour les outils internes où l’alternative est un build Electron que personne ne veut maintenir.

Chrome a changé les règles d’installabilité et la plupart des guides ne l’ont pas vu

Pendant des années, chaque article répétait la même liste : manifeste, icônes, HTTPS, et un service worker avec un gestionnaire fetch. Ce dernier point n’est plus vrai pour l’installation depuis le menu.

Google a retiré l’exigence d’un service worker implémentant fetch pour l’installation depuis le menu, en version 108 sur mobile et 112 sur ordinateur, et fournit désormais une page hors ligne par défaut aux sites qui n’en proposent pas. L’algorithme de l’invite d’installation veut toujours un gestionnaire fetch, mais l’installabilité elle-même n’en dépend plus.

L’effet a atteint l’outillage. Lighthouse a supprimé entièrement sa catégorie PWA en version 12.0.0, publiée en avril 2024, parce que ces audits existaient pour tester des critères qui ne s’appliquaient plus. Si votre chaîne de build échoue encore sur un score PWA manquant, elle teste quelque chose que Google a retiré.

La lecture pratique est que l’installation et la capacité hors ligne sont découplées. Vous pouvez livrer une application installable sans aucune histoire hors ligne, ce qui est souvent la bonne première version, et ajouter le cache une fois que vous savez quels écrans les gens utilisent réellement sans réseau.

Le hors ligne est une décision de conception qui a un coût

Le mot hors ligne cache une gamme de périmètres énorme. Une coquille en cache qui montre les dernières données connues, c’est une semaine de travail. Une application vraiment pensée hors ligne d’abord, qui met les écritures en file, résout les conflits et réconcilie à la reconnexion, c’est un autre produit.

Les stratégies de cache

Le cache d’un service worker se ramène à quatre motifs et à une décision par type de ressource. Cache first sert la copie stockée sans jamais vérifier, ce qui convient aux polices et aux fichiers de build hachés. Network first tente le serveur et se rabat sur le cache, ce qui convient aux données qui doivent être à jour. Stale while revalidate sert le cache instantanément et rafraîchit en arrière-plan, choix habituel pour le contenu. Network only s’emploie pour tout ce qui ne doit pas être servi depuis une copie périmée, comme les paiements.

Se tromper là-dessus est l’échec de PWA le plus courant que je rencontre. Une politique cache first appliquée à la coquille de votre application servira le JavaScript du mois dernier aux visiteurs de retour jusqu’à ce que quelque chose force une mise à jour, et les rapports de bugs décriront des symptômes qui n’existent pas dans votre code actuel.

La synchronisation en arrière-plan

Mettre les écritures en file hors ligne et les vider au retour de la connectivité, c’est l’objet de la Background Synchronization API. MDN la classe en disponibilité limitée et explicitement hors Baseline, ce qui veut dire qu’elle ne fonctionne pas dans certains des navigateurs les plus utilisés.

Sur iOS, vous écrivez donc le repli vous-même : conserver la file dans IndexedDB, et la vider à la prochaine ouverture de l’application. Cela marche, les utilisateurs l’acceptent, et c’est peut-être trois à cinq jours d’ingénierie au lieu de l’après-midi qu’aurait coûté l’API.

Les notifications push décident plus de projets que tout le reste

Si une seule capacité coule une proposition de PWA, c’est celle-là, en général sur des faits qui étaient vrais en 2022.

Android et ordinateur

Le push web sur Chrome Android, Chrome de bureau, Edge et Firefox fonctionne depuis des années grâce à la Push API, à la Notifications API et à un service worker agissant de concert. La livraison est assurée par le service push de l’éditeur du navigateur, la permission est une invite standard, et il n’y a pas d’écart notable avec une application native pour le cas courant d’un serveur qui envoie un message à un utilisateur abonné.

iOS et iPadOS

Apple a ajouté le push web dans iOS et iPadOS 16.4. La condition attachée est la partie qu’on oublie : WebKit précise que l’application web doit avoir été ajoutée à l’écran d’accueil, et la permission doit être demandée en réponse à une interaction directe de l’utilisateur, par exemple un appui sur un bouton d’abonnement. Le push web ne fonctionne pas pour un site posé dans un onglet Safari.

Le manifeste doit fixer display à standalone ou fullscreen, et les notifications se comportent alors comme celles de n’importe quelle application : écran verrouillé, centre de notifications, Apple Watch appairée, et réglage par application dans les Réglages. Les badges fonctionnent aussi.

Apple a ensuite ajouté une voie plus simple. Declarative Web Push est arrivé dans Safari 18.4, disponible sur iOS et iPadOS 18.4 pour les applications web ajoutées à l’écran d’accueil, et affiche une notification depuis une charge utile JSON normalisée sans qu’un service worker ait besoin de tourner. Cela retire du travail. Cela ne retire pas l’exigence de l’écran d’accueil.

L’écart iOS, énoncé précisément

L’écart est réel et il est plus petit que sa réputation. L’énoncer avec exactitude sert davantage que s’en plaindre ou faire comme s’il s’était refermé.

L’éviction du stockage

WebKit évince les données de site selon le principe du moins récemment utilisé, la dernière utilisation étant mesurée depuis la dernière interaction de l’utilisateur ou opération de stockage. Sa documentation de politique de stockage fixe un quota par origine allant jusqu’à 60 % du disque pour les applications de navigation et jusqu’à 15 % pour les autres applications, avec des quotas globaux de 80 % et 20 % respectivement, et confirme qu’une application web autonome de l’écran d’accueil obtient les mêmes quotas que le navigateur.

Deux choses en découlent. Le stockage n’est pas la contrainte qu’on imagine, et l’éviction est un risque de calendrier plutôt que de capacité. Traitez l’appareil comme un cache et le serveur comme le registre, et l’éviction cesse d’être un défaut produit.

L’exécution en arrière-plan

Il n’existe pas d’équivalent d’une tâche native en arrière-plan sur iOS. Pas de récupération périodique, pas de géolocalisation en arrière-plan, pas de traitement silencieux quand l’application est fermée. Tout ce qui doit se produire selon un calendrier se produit sur votre serveur, et atteint l’appareil par un message push que l’utilisateur voit.

Aucune présence dans l’App Store

Une PWA ne peut pas être listée dans l’App Store. Si une part significative de vos clients s’attend à chercher votre marque dans le magasin et à vous y trouver, ce n’est pas un problème d’ingénierie que vous puissiez résoudre sur le web.

Les moteurs de navigateur, le DMA et la CMA

C’est la partie où les commentaires dépassent les sources primaires, il vaut donc mieux rester étroit sur ce qui est réellement documenté.

Apple autorise désormais d’autres moteurs de navigateur, et il est explicite que cela s’applique dans l’Union européenne uniquement, sur iOS 17.4 ou ultérieur et iPadOS 18 ou ultérieur, via deux habilitations accordées aux développeurs qui satisfont des critères publiés de sécurité, de confidentialité et de suites de tests. Apple exige que 90 % des Web Platform Tests et 80 % de Test262 passent, un fonctionnement sans JIT, et la résolution de la plupart des vulnérabilités sous 30 jours.

Pour une entreprise britannique, rien là-dedans ne change quoi que ce soit aujourd’hui. Les habilitations sont liées à la juridiction, et un utilisateur britannique sur un opérateur britannique fait tourner WebKit, quelle que soit l’icône de navigateur qu’il a touchée.

La position britannique évolue séparément. Le 22 octobre 2025, la CMA a désigné Apple et Google comme détenant un statut de marché stratégique sur leurs plateformes mobiles, couvrant les systèmes d’exploitation, la distribution d’applications, les navigateurs et les moteurs de navigateur, pour une durée de cinq ans. La désignation est le pouvoir d’imposer des obligations de conduite, pas les obligations elles-mêmes. Planifiez avec la plateforme telle qu’elle se comporte aujourd’hui et traitez tout assouplissement comme un bonus.

Matériel et API d’appareil, vérifiés plutôt que supposés

Le web ne peut pas accéder au matériel est l’objection que j’entends le plus, et celle qui est le plus souvent fausse dans un cas précis.

Ce qui marche pratiquement partout

L’accès à la caméra et au micro via getUserMedia est Baseline sur MDN et fonctionne d’un navigateur à l’autre depuis 2017. La géolocalisation, l’orientation de l’appareil, l’envoi de fichiers y compris la capture par caméra sur mobile, l’accès au presse-papiers, la Web Share API sur mobile, et les passkeys via WebAuthn avec Face ID ou une empreinte comme authentificateur fonctionnent tous dans les navigateurs mobiles actuels. La lecture de codes-barres et de QR codes depuis le flux caméra est de la routine.

Pour la grande majorité des applications métier, cette liste est tout le besoin matériel.

Ce qui est réservé à Chromium, et en mobile à Android

Web Bluetooth est documenté par Google comme disponible sur ChromeOS, Chrome pour Android 6.0, macOS depuis Chrome 56 et Windows 10 depuis Chrome 70, sans prise en charge iOS listée, et MDN le marque en disponibilité limitée plutôt qu’en Baseline. Web NFC est encore plus étroit : Google le documente comme disponible sur Android dans Chrome 89.

La File System Access API, pour lire et écrire des fichiers choisis par l’utilisateur, est de même du territoire Chromium, même si l’origin private file system couvre l’essentiel des besoins de stockage interne d’une application d’un navigateur à l’autre.

La distribution en magasin est une question commerciale, pas technique

Les équipes discutent de la distribution en magasin comme s’il s’agissait de capacité. Il s’agit de quatre variables commerciales, et une seule favorise le magasin sans ambiguïté.

La découverte est l’avantage honnête. Les consommateurs cherchent bel et bien dans l’App Store et sur Play par marque et par catégorie, et une entreprise sans présence en magasin renonce à ce canal. Cela compte énormément pour un produit grand public au nom reconnaissable, et très peu pour un outil utilisé par 200 salariés d’une seule société.

La confiance est réelle et asymétrique selon le public. Les utilisateurs plus âgés et moins techniques lisent une fiche de magasin comme un signal de sécurité. Les plus jeunes de moins en moins, et le même utilisateur ira volontiers sur le site d’une banque depuis le même téléphone.

En face, un magasin ajoute une file de validation entre vous et vos utilisateurs, un risque de rejet sur des règles qui changent, et une commission sur tout ce que vous vendez dans l’application. Une PWA n’a rien de tout cela. Vous déployez quand vous le décidez, et un correctif critique atteint chaque utilisateur au chargement suivant plutôt qu’après une revue.

Ce que les magasins prélèvent vraiment

Les taux de commission bougent assez souvent pour qu’il soit imprudent de les citer de mémoire. Voici les conditions publiées par les éditeurs eux-mêmes, vérifiées en septembre 2026.

Apple prélève 30 % de commission standard sur les biens et services numériques. Le App Store Small Business Program ramène cela à 15 % pour les développeurs ayant jusqu’à 1 000 000 USD de produits sur l’année civile précédente, les nouveaux développeurs étant éligibles, et le taux standard reprend sur les ventes futures une fois le seuil dépassé dans l’année.

Google publie des frais de service pour Google Play par paliers : 15 % sur le premier million USD de revenu développeur chaque année, 30 % au-dessus, et 15 % sur les abonnements à reconduction automatique quel que soit le revenu. La même page expose une structure différente entrant en vigueur le 30 juin 2026 pour l’EEE, le Royaume-Uni et les États-Unis, fondée sur 10 % ou 20 % plus des frais de facturation de 5 %, selon que l’installation est nouvelle ou existante.

Les deux éditeurs publient en USD. Vendre un abonnement mensuel à £9,99 via un magasin coûte environ £18 par an et par abonné à 15 %, et environ £36 à 30 %. Multipliez par votre nombre d’abonnés avant de juger le magasin gratuit.

Vous pouvez toujours publier une PWA sur Google Play

Android vous donne les deux options à la fois, ce qui est une vraie asymétrie de la comparaison entre plateformes, et c’est rarement mentionné.

Une Trusted Web Activity est une application Android qui ouvre votre propre PWA en plein écran sans habillage de navigateur, vérifiée comme vôtre par les Digital Asset Links. Elle exige Chrome sur Android 72 ou supérieur, et l’application hôte n’a aucun accès aux cookies ni au stockage du contenu web. En pratique, c’est un conteneur mince généré depuis votre manifeste et soumis à Play comme n’importe quelle application.

Sur Android, le choix n’est donc pas magasin ou web. Vous publiez la PWA, vous l’emballez, et vous obtenez la fiche de magasin en plus, depuis la même base de code, pour quelques jours d’empaquetage et les frais annuels de compte développeur.

Il n’y a pas d’équivalent sur iOS. Les règles de validation d’Apple traitent depuis longtemps un conteneur autour d’un site comme insuffisant en soi, la voie du magasin iOS suppose donc de construire quelque chose de vraiment natif. Cette asymétrie, plus que tout écart d’API, façonne le tableau de coûts ci-dessous.

Coût du développement d’applications web progressives face à deux bases natives

La comparaison que les gens font, c’est le coût de construction, et c’est la plus petite moitié. Celle qui décide de l’issue, c’est le coût total sur trois ans, car la dépense du natif se répète.

Lisez ces chiffres comme des fourchettes d’agences britanniques pour une application métier de complexité moyenne, pas comme un devis. Une PWA de cette forme, c’est typiquement une équipe de deux ou trois ingénieurs pendant trois à cinq mois. Deux bases natives plus une présence web, c’est trois équipes, trois processus de livraison et trois lots de montées de version de plateforme chaque année.

L’écart entre la première et la troisième ligne, environ £75 000 à £175 000 en construction, puis £27 000 à £60 000 par an, est ce que vous achetez quand vous achetez du natif. Parfois c’est de l’argent bien dépensé. Cela devrait être une décision, pas un réflexe. Nos pages développement de site web et développement logiciel exposent comment nous cadrons les deux voies.

Où part vraiment l’argent de la maintenance

Le coût de construction se négocie. Le coût de maintenance se découvre, et c’est là que les projets à plusieurs bases de code échouent en silence plutôt qu’avec fracas.

Les plateformes natives vous imposent du travail chaque année. Les nouvelles versions majeures du système déprécient des API, la signature et le provisionnement changent, les niveaux de SDK minimum montent, et les règles des magasins ajoutent des exigences comme les manifestes de confidentialité et les déclarations de sécurité des données. Rien de tout cela ne livre une fonctionnalité. Sur deux plateformes, vous la payez deux fois, à un calendrier fixé par quelqu’un d’autre.

Ensuite vient la dérive. Deux bases de code qui implémentent la même fonctionnalité divergent, et la divergence remonte en tickets de support qui ne se reproduisent que sur une plateforme. Chaque décision produit doit être prise deux fois puis réconciliée, et le coût de coordination n’apparaît sur aucune facture.

Une PWA remplace tout cela par l’évolution des navigateurs, qui est continue, rétrocompatible et ne casse presque jamais du code qui marche. Le travail récurrent, ce sont vos propres mises à jour de dépendances, les correctifs de sécurité et l’hébergement, soit la maintenance dont toute application web sur mesure a déjà besoin.

La comparaison qui compte n’est pas deux chiffres sur une proposition. C’est une équipe contre trois, chaque année, aussi longtemps que le produit vit.

Performance et Core Web Vitals pour une PWA

Une application installée est jugée face au natif, la barre de performance est donc plus haute que pour un site, pas plus basse. La bonne nouvelle, c’est que les métriques sont publiques et les seuils fixes.

Les Core Web Vitals comptent actuellement trois métriques, chacune évaluée au 75e centile des chargements de page et séparée entre mobile et ordinateur. Largest Contentful Paint est bon à 2,5 secondes ou moins et mauvais au-dessus de 4,0. Interaction to Next Paint, qui a remplacé First Input Delay quand il est devenu stable en 2024, est bon à 200 millisecondes ou moins et mauvais au-dessus de 500. Cumulative Layout Shift est bon à 0,1 ou moins et mauvais au-dessus de 0,25.

Une PWA a ici un avantage structurel. Un service worker qui sert la coquille depuis le cache rend les visites répétées quasi instantanées, ce qui est précisément le motif que produit une application installée, si bien que les données terrain d’une PWA installée sont en général meilleures que celles du même code visité à froid dans un navigateur.

Elle a aussi un risque structurel. Les frameworks de page unique poussent le travail vers le client, et INP est la métrique qui le sanctionne. Si vous vous battez déjà avec ces chiffres, notre guide pour réussir les Core Web Vitals traite le diagnostic plus en profondeur que ce billet ne le peut.

Le SEO est l’avantage que personne ne chiffre

C’est l’argument que je placerais en premier dans la plupart des dossiers commerciaux, et il est presque toujours absent de la comparaison.

Une PWA est un site web. Chaque écran a une URL, chaque URL peut être explorée, indexée, liée et partagée, et chacune peut se positionner. Une application native n’a rien de tout cela. Les fiches de magasin sont indexées superficiellement et se classent dans un jardin clos sur des signaux entièrement différents, et le contenu à l’intérieur de l’application est invisible pour la recherche.

La conséquence se cumule. Le budget marketing d’une application native achète des installations et s’arrête le jour où la dépense s’arrête. Le même budget consacré au contenu et à la qualité technique d’une PWA achète une page qui continue de se positionner. Sur trois ans, cet écart dépasse fréquemment le coût de construction complet de l’une ou l’autre voie.

Cela ne paie que si l’implémentation est explorable, et c’est là que les applications rendues côté client se trompent : tout rendre en JavaScript avec une seule URL et sans HTML rendu côté serveur perd complètement l’avantage. Le rendu serveur ou le prérendu des routes indexables est le remède, et un audit SEO technique avant lancement coûte bien moins cher que de découvrir six mois plus tard que rien n’a été indexé.

Les exigences disqualifiantes

La décision est plus facile sous forme de liste de veto que de liste d’avantages, parce que les veto sont objectifs.

Il vous faut du natif si l’un des points suivants est un vrai besoin plutôt qu’un souhait. Le suivi de position en arrière-plan quand l’application est fermée. Les widgets d’écran d’accueil, les applications de montre, ou l’intégration CarPlay et Android Auto. Le Bluetooth ou le NFC sur iPhone. HealthKit, Apple Pay dans l’application, ou toute intégration profonde au système qu’Apple n’a pas ouverte au web. La facturation du magasin pour des biens numériques, là où la règle du magasin l’impose. Le calcul lourd et soutenu, comme le traitement vidéo en temps réel ou le rendu 3D à des fréquences d’images natives. La présence dans l’App Store comme exigence marketing dont votre activité dépend vraiment.

Si aucun de ces points ne s’applique, une PWA est très probablement la bonne réponse, et la charge de la preuve revient à qui veut trois bases de code.

Deux considérations penchent encore plus loin. Si vos utilisateurs sont majoritairement sur ordinateur ou Android, les écarts iOS touchent une minorité de votre audience. Et si l’application est une façade vers votre propre serveur plutôt que vers l’appareil, ce qui décrit la plupart des logiciels métier, les capacités de l’appareil comptent à peine.

Scénario un : le service terrain d’un prestataire de facility management

Deux cents techniciens, des fiches d’intervention, des photos de travaux terminés, la capture de signature, un réseau capricieux dans les locaux techniques et les sous-sols. C’est le cas dont on suppose qu’il exige du natif, et c’est celui où une PWA gagne le plus nettement.

Chaque besoin est couvert. La caméra passe par getUserMedia. Les signatures sont un élément canvas. Les données d’intervention se mettent en cache dans IndexedDB et la file d’écriture se vide à la reconnexion, écrite à la main parce que Background Sync n’est pas fiable d’un navigateur à l’autre. Les alertes de répartition partent en push web, qui fonctionne sur Android et sur iOS pour les techniciens ayant ajouté l’application à leur écran d’accueil, et l’installation est un point de cinq minutes en formation d’intégration plutôt qu’un problème d’acquisition.

Il n’y a aucun besoin de découverte en magasin, puisque les utilisateurs sont des salariés. Il n’y a pas de facturation, donc la commission est sans objet. Le parc mélange Android et iOS, ce qui est exactement le cas qui pénalise le plus deux bases natives.

Construisez une PWA pour peut-être £45 000 à £70 000 au lieu de deux applications natives à £120 000 à £200 000, livrez les correctifs l’après-midi même plutôt qu’après une revue, et mettez la différence dans le back-end de répartition, qui détermine réellement si la chose fonctionne.

Scénario deux : une chaîne de salons qui veut réservations et rappels

Quatorze succursales, grand public, prise de rendez-vous, rappels, un programme de fidélité, des paiements encaissés en caisse plutôt que dans l’application. L’instinct dit application native parce que les concurrents en ont une.

La liste de besoins n’a rien de remarquable : formulaires de réservation, un calendrier, des rappels, un espace compte. Les rappels sont le seul point intéressant, et ils sont mieux servis par SMS et e-mail que par push sur ce marché, car une cliente qui réserve deux fois par an n’aura rien installé.

La découverte est le facteur décisif, et elle favorise le web sans appel. Les gens trouvent les salons par la recherche et les cartes, pas en parcourant un magasin d’applications, donc les pages qui décrivent les prestations et prennent les réservations doivent se positionner. Une application native y est totalement invisible. Le coût du site lui-même est la vraie ligne de budget, la couche application venant s’ajouter comme installabilité.

Construisez correctement le site de réservation, rendez-le installable pour que les habituées le gardent sur leur écran d’accueil, et ajoutez le push web pour la minorité qui l’accepte. Un projet natif dépense ici £80 000 ou plus pour toucher moins de clients que le site n’en touche déjà.

Scénario trois : un produit de fitness par abonnement

Séances guidées, contenu vidéo, une intégration de montre connectée, £12,99 par mois, en vente directe, croissance financée par l’acquisition payante. Ce scénario penche dans l’autre sens, et il vaut la peine de montrer pourquoi.

La découverte en magasin compte ici, car le fitness est une catégorie que l’on parcourt et une fiche est un vrai canal d’acquisition. L’intégration de la montre veut dire HealthKit, hors de portée du web. L’audio en arrière-plan et le maintien de l’écran allumé pendant une séance sont meilleurs en natif. Le téléchargement de vidéos pour l’usage hors ligne à grande échelle est faisable sur le web, mais pas confortable.

La facturation est la partie intéressante. La commission de magasin sur £12,99 par mois représente environ £23 par an et par abonné à 15 % et £47 à 30 %, ce qui, à 20 000 abonnés, fait £460 000 à £940 000 par an. C’est un argument fort pour encaisser sur le web et traiter l’application comme un client, ce que plusieurs grands produits par abonnement font désormais.

La réponse, ce sont des applications natives pour le produit et une PWA ou une application web standard pour l’inscription, la facturation et le marketing de contenu. Les deux existent, et la séparation est délibérée plutôt qu’accidentelle.

Comment décider en un après-midi

La décision ne demande pas de phase de cadrage. Elle demande quatre réponses, écrites.

Premièrement, listez les capacités d’appareil dont vous avez vraiment besoin, puis vérifiez chacune dans la documentation de l’éditeur plutôt que dans un résumé. La plupart des listes raccourcissent nettement à cette étape. Deuxièmement, établissez d’où viennent vos utilisateurs : si la réponse est la recherche, le web a déjà l’avantage, et si c’est le parcours en magasin, il ne l’a pas.

Troisièmement, chiffrez les trois voies sur trois ans plutôt que sur un, en incluant les montants de maintenance ci-dessus, et intégrez la commission du magasin sur tout ce que vous comptez vendre. Quatrièmement, soyez honnête sur votre équipe. Une base de code maintenue par trois ingénieurs livre plus que trois bases maintenues par trois ingénieurs, à chaque fois.

Si la réponse reste ambiguë après cela, construisez d’abord la PWA. C’est l’option la moins chère à inverser. Passer d’une PWA au natif plus tard, c’est écrire les clients natifs contre une API qui existe déjà et a fait ses preuves, et faire l’inverse, c’est repartir de zéro. Cette asymétrie vaut plus que la plupart des comparaisons de fonctionnalités ci-dessus.

Ce que cela implique pour vous

Le développement d’applications web progressives n’est pas un compromis pour ceux qui ne peuvent pas se payer du natif, et ce n’est pas non plus une réponse universelle. C’est la bonne architecture pour une catégorie définie et vaste de produits : logiciels métier, outils internes, systèmes de réservation et de compte, produits de contenu, et tout ce dont les clients arrivent par la recherche.

Les écarts iOS sont réels, précis et le plus souvent contournables plutôt que fatals. Le push fonctionne si l’utilisateur installe. Le stockage est généreux mais évincible. L’exécution en arrière-plan n’existe pas et a de toute façon sa place sur votre serveur. Le Bluetooth et le NFC ne fonctionnent pas sur iPhone, et aucune ingénierie n’y change rien.

Mecanik construit les deux voies et vous dira quand la réponse est le natif. Si vous voulez la comparaison faite sur vos besoins réels plutôt que sur une liste générique, nos pages développement de site web et développement logiciel décrivent comment nous cadrons cela, et notre guide pour construire une application web en 2026 traite les choix de stack qui en découlent.

Questions fréquentes

Qu’est-ce qu’une application web progressive ? Une application web progressive est une application construite avec des technologies web qui se comporte comme une application spécifique à la plateforme. Techniquement, c’est une application web servie en HTTPS avec un manifeste décrivant son nom, ses icônes et son comportement au lancement, plus un service worker capable de servir des requêtes depuis un cache et de recevoir des messages push. MDN la définit comme un logiciel qui tourne sur plusieurs plateformes depuis une seule base de code tout en restant installable et utilisable hors ligne.

Une PWA peut-elle envoyer des notifications push sur iPhone ? Oui, à une condition. Apple a ajouté le push web dans iOS et iPadOS 16.4, mais WebKit exige que l’application web ait d’abord été ajoutée à l’écran d’accueil, et que la permission soit demandée en réponse à une interaction directe de l’utilisateur, par exemple un appui sur un bouton d’abonnement. Le push ne fonctionne pas pour un site qui tourne dans un onglet Safari. Declarative Web Push, ajouté dans iOS et iPadOS 18.4, simplifie la mise en oeuvre mais conserve la même exigence d’écran d’accueil.

Combien coûte le développement d’une application web progressive au Royaume-Uni ? Pour une application métier de complexité moyenne, comptez £35 000 à £75 000 pour construire une base de code PWA unique et £8 000 à £20 000 par an pour la maintenir. La voie native comparable, avec des applications iOS et Android séparées plus un site vitrine, coûte £110 000 à £250 000 à construire et £35 000 à £80 000 par an ensuite. Ce sont des fourchettes d’agences britanniques et non des devis, et l’écart récurrent pèse en général plus lourd que l’écart de construction.

Peut-on mettre une PWA sur l’App Store ou Google Play ? Google Play oui, l’App Store non. Sur Android, une Trusted Web Activity emballe votre PWA dans une coquille native mince vérifiée par les Digital Asset Links, si bien que la même base de code obtient une fiche Play pour quelques jours d’empaquetage. Apple n’a pas d’équivalent et ses règles de validation traitent un conteneur autour d’un site comme insuffisant, donc une présence sur l’App Store suppose de construire quelque chose de vraiment natif.

Quand faut-il choisir une application native plutôt qu’une PWA ? Choisissez le natif quand il vous faut le suivi de position en arrière-plan alors que l’application est fermée, des widgets d’écran d’accueil, des intégrations montre ou voiture, le Bluetooth ou le NFC sur iPhone, HealthKit ou Apple Pay dans l’application, du calcul lourd et soutenu comme le traitement vidéo en temps réel, ou la présence sur l’App Store comme véritable canal d’acquisition. Si rien de cela ne s’applique, une PWA est très probablement le bon choix et la charge de la preuve revient à qui veut maintenir trois bases de code.