PWA (progressive web app) : définition, fonctionnement et cas où elle remplace une application native

Une PWA est un site web qui se comporte comme une application sur trois points : une icône sur l’écran d’accueil du téléphone, un fonctionnement hors ligne et l’envoi de notifications. Cela ressemble à une façon d’obtenir une application sans store, sans deux bases de code et sans qu’Apple et Google examinent chaque version — et c’est souvent le cas.

Il y a toutefois une condition qui se perd dans la plupart des discussions sur les PWA. Sur ces trois points, ce qui est possible dépend du navigateur de l’appareil, et non de celui qui développe l’application. Sur Android, Chrome fait presque tout ce dont une PWA a besoin. Sur iPhone, quel que soit le navigateur, les applications ajoutées à l’écran d’accueil reposent sur le moteur WebKit d’Apple, et WebKit ne prend pas en charge une partie de cette liste — et n’a pas l’intention de le faire. C’est donc l’iPhone, et non Android, qui détermine si une PWA suffit, et cet article montre précisément où passe cette limite.

Si vous vous demandez encore si vous avez besoin d’une application — un site, une PWA ou une application de store — commencez par notre article sur ce qu’est une application mobile et quand elle a du sens pour une entreprise. Ici, nous partons du principe que la PWA est déjà envisagée et nous vérifions ce qu’elle sait vraiment faire.

Qu’est-ce qu’une PWA (progressive web app)

PWA signifie progressive web app — un site web construit pour pouvoir être installé sur un appareil et utilisé comme une application. Elle s’ouvre depuis une icône, sans barre d’adresse, peut fonctionner sans connexion internet et recevoir des notifications. Mais sous le capot, cela reste un site : il a une adresse, se met à jour dès qu’une nouvelle version est mise en ligne sur le serveur, et ne passe jamais par un store.

Il vaut la peine de la distinguer de deux notions voisines. Une application native est écrite séparément pour chaque système d’exploitation, avec les outils d’Apple et de Google, et parvient à l’utilisateur par un store. Une application hybride est en général un site web enfermé dans une « coquille » native — une fenêtre de navigateur intégrée dans une application — et elle aussi distribuée via un store. Les applications multiplateformes comme React Native ou Flutter sont encore autre chose : un seul code, mais des éléments d’interface natifs. Nous comparons ces trois voies, avec leurs coûts de store, dans notre article sur les applications mobiles.

La PWA se distingue des trois par le fait qu’il n’y a rien à installer depuis un store. C’est un avantage — pas d’examen de version, pas de frais de compte, pas d’attente d’approbation — et c’est aussi la source de toutes les limites décrites ci-dessous.

Comment fonctionne une PWA : manifeste et service worker

Techniquement, une PWA est un site web ordinaire avec deux éléments en plus. Vous n’avez pas besoin de connaître leur code, mais il est utile de savoir à quoi ils servent, car ce sont eux qui déterminent ce qu’une PWA peut faire ou non.

Le manifeste est un petit fichier qui décrit l’application : son nom, des icônes en plusieurs tailles, la couleur de la barre, l’adresse à partir de laquelle elle doit s’ouvrir, et la façon dont elle s’affiche — en plein écran, par exemple, sans éléments du navigateur. C’est grâce à lui que le système sait comment afficher la PWA sur l’écran d’accueil et comment la lancer.

Le service worker est un script qui tourne en arrière-plan, entre l’application et le réseau. Il peut enregistrer sur l’appareil les fichiers et données dont l’application a besoin, pour qu’elle s’ouvre sans connexion, puis synchroniser les changements une fois la connexion revenue. Il reçoit aussi les notifications push lorsque l’application n’est pas ouverte. Les deux grandes plateformes le prennent en charge — Safari sur iPhone depuis iOS 11.3 (WebKit, 2018).

Le fonctionnement hors ligne ne se fait toutefois pas tout seul. Le service worker fait exactement ce pour quoi on l’a programmé : quels écrans doivent fonctionner sans réseau, quoi enregistrer localement et que faire des données saisies hors ligne. C’est une décision de conception à prendre avec votre prestataire dès l’étape du brief, pas à découvrir après la mise en ligne.

Installation : Android et « Sur l’écran d’accueil » sur iPhone

C’est là que les plateformes commencent à diverger. Sur Android, Chrome propose lui-même d’installer l’application dès qu’un site remplit les critères : il fonctionne en HTTPS, possède un manifeste avec un nom, des icônes et une adresse de démarrage, et l’utilisateur y a passé un moment (web.dev, Install criteria). Depuis la version 108, Chrome sur Android n’exige plus de service worker pour cela (Chrome for Developers).

Sur iPhone, aucune proposition n’apparaît. L’installation est manuelle : dans Safari, il faut ouvrir le menu Partager et choisir « Sur l’écran d’accueil » (Apple, Guide de l’utilisateur de l’iPhone). L’utilisateur doit donc savoir qu’il peut le faire — et c’est à vous de l’en informer : quelques lignes d’explication sur le site ou dans le premier e-mail au client.

Dans iOS 26, annoncé en juin 2025, Apple a changé un point en faveur des PWA. Tout site ajouté à l’écran d’accueil s’ouvre désormais par défaut comme une application web, et non comme un onglet du navigateur ; l’utilisateur peut désactiver ce comportement (WebKit, WWDC25). L’installation elle-même reste toutefois une étape qu’il faut accomplir consciemment.

Notifications push sur iPhone

Pendant des années, l’absence de notifications sur iPhone a été le principal argument contre les PWA. Cela a changé en 2023 : depuis iOS et iPadOS 16.4, les applications web peuvent envoyer des notifications push (WebKit, 16 février 2023). Sur Android, Chrome prend en charge les notifications push depuis la version 42, soit depuis 2015.

Sur iPhone, il y a toutefois une condition qui change la donne. Les notifications ne fonctionnent que pour une application ajoutée à l’écran d’accueil — pas pour un site ouvert dans le navigateur. Avant de recevoir sa première notification, l’utilisateur doit donc d’abord installer la PWA manuellement, puis accepter les notifications. Une partie des utilisateurs sautera l’une de ces deux étapes.

D’où une règle pratique. Si les notifications sont un complément — un rappel de rendez-vous, une information sur le statut d’une commande qui pourrait aussi partir par e-mail — une PWA sur iPhone suffit. Si elles sont le cœur du produit, et que la majorité de vos utilisateurs ont un iPhone, testez sur un petit groupe avant de vous engager sur une PWA : vérifiez combien d’entre eux vont jusqu’au bout de l’installation et acceptent les notifications.

L’épisode européen : quand Apple a annoncé la suppression des PWA dans l’Union européenne

Il y a aussi une raison de considérer une PWA sur iPhone comme une dépendance envers une seule entreprise. Début 2024, en adaptant iOS au Digital Markets Act (DMA) de l’UE, Apple a annoncé qu’il supprimait les applications web de l’écran d’accueil dans l’Union européenne — indiquant directement aux développeurs que « to comply with the DMA’s requirements, we had to remove the Home Screen web apps feature in the EU » (« pour respecter les exigences du DMA, nous avons dû supprimer la fonctionnalité des applications web sur l’écran d’accueil dans l’UE » — traduction de notre part).

Après une vague de critiques, la décision a été annulée. Dans une version mise à jour de la même communication, Apple a annoncé qu’il continuerait à proposer cette fonctionnalité dans l’UE et qu’elle reviendrait avec iOS 17.4 début mars 2024 (Apple, page archivée le 5 mars 2024). Dans la même communication, Apple a précisé que les applications ajoutées à l’écran d’accueil restent construites directement sur WebKit et son architecture de sécurité — y compris dans l’UE, où d’autres navigateurs peuvent désormais utiliser leurs propres moteurs.

La Suisse n’est pas membre de l’UE, et le Digital Markets Act ne s’y applique pas. Tout cet épisode concernait les utilisateurs à l’intérieur de l’Union européenne. Cela ne fait pas disparaître le fond du problème pour autant — cela signifie seulement que le déclencheur était une loi de l’UE, pas une loi suisse.

La leçon pour une entreprise est simple. Une PWA fonctionne sur iPhone parce qu’Apple l’autorise, et l’étendue de cette autorisation peut changer avec une seule mise à jour système. Ce n’est pas une raison de renoncer aux PWA — mais c’est une raison de ne pas construire dessus une fonctionnalité sans laquelle votre entreprise cesse de fonctionner, et d’avoir un plan en cas de changement.

Une PWA dans un store d’applications

Parfois, une PWA doit tout de même arriver dans un store — parce que les clients y cherchent des applications, ou parce que le donneur d’ordre l’exige. Sur Android, il existe une voie officielle : Trusted Web Activity, la technique de Google qui ouvre une PWA à l’intérieur d’une application de store, sans barre de navigateur. Elle exige la preuve que l’application et le site appartiennent au même propriétaire (un fichier Digital Asset Links sur le serveur), et le paquet destiné à Google Play peut être préparé avec Bubblewrap (Chrome for Developers, Trusted Web Activity).

Il n’existe pas d’équivalent sur l’App Store. Les règles d’Apple indiquent clairement qu’une application doit comporter des fonctionnalités, un contenu et une interface qui vont « au-delà d’un site web reconditionné » (App Store Review Guidelines, 4.2). Le simple emballage d’une PWA pour iOS ne passe en général pas l’examen — et si vous y ajoutez des fonctionnalités natives, vous construisez déjà une application hybride, avec un examen à chaque version et les coûts que nous détaillons dans notre article sur la création d’applications mobiles.

Quand une PWA a du sens pour une entreprise

La matrice de capacités ci-dessus fait apparaître quelques cas où une PWA fonctionne bien — et quelques-uns où elle perd d’avance.

Un outil pour vos propres collaborateurs. Techniciens sur le terrain, personnel d’entrepôt, commerciaux. C’est le meilleur cas pour une PWA : il y a quelques dizaines d’utilisateurs, pas des dizaines de milliers, donc l’installation sur iPhone peut se faire avec un guide court ou lors d’une formation. Le fonctionnement hors ligne résout le problème de la couverture réseau, et une mise à jour atteint tout le monde au moment de sa mise en ligne, sans attendre d’examen en store. La limite : si l’outil doit dialoguer avec une imprimante, un scanner ou une balance en Bluetooth, cela ne fonctionnera pas sur iPhone.

Un portail pour des clients réguliers. Un client B2B qui commande chaque semaine, consulte le statut d’une commande ou télécharge des documents revient régulièrement — et pour lui, une icône sur l’écran d’accueil est un confort, pas un obstacle. Les notifications de statut peuvent être un complément, puisque la même information peut partir par e-mail.

Un produit pour un large public, qui doit être trouvé. Ici, la PWA perd en général. Quelqu’un qui ne vous connaît pas cherche une application dans un store, il n’installe pas un site depuis le menu Partager. Si la visibilité dans l’App Store et Google Play fait partie de votre stratégie pour toucher des clients, il vous faut une application de store.

Paiements intégrés et abonnements. Si votre modèle économique repose sur des paiements intégrés sur iPhone, la PWA n’est pas la bonne voie — ce chemin passe par le store et ses règles.

Ce qu’une PWA change dans votre budget et votre calendrier

La plus grande économie d’une PWA ne se trouve pas dans le taux horaire, mais dans le nombre de choses à faire deux fois, ou pas du tout. Il y a une seule base de code au lieu de deux applications, une seule mise en ligne au lieu de deux examens en store, et aucun compte développeur à entretenir. Chaque correctif atteint les utilisateurs dès sa mise en ligne sur le serveur, et non après des heures ou des jours d’examen.

La deuxième différence est moins évidente. Une application de store a quand même besoin d’un serveur qui conserve les données et d’une interface pour dialoguer avec lui. Selon les règles que nous utilisons pour planifier nos projets, la seule préparation de l’API pour une application mobile ajoute trois à six semaines. Une PWA utilise la même infrastructure qu’un site ou qu’une application web, donc cette ligne n’apparaît tout simplement pas — à condition que la PWA remplace une application de store plutôt que de coexister avec elle.

Nous ne donnons pas de chiffres ici, car la différence dépend du périmètre, pas de la technologie. Ce qui compose le prix d’une application, et comment lire un devis, est traité dans notre article sur le coût de développement d’une application. Une comparaison honnête entre une PWA et une application native porte toujours sur le même périmètre de fonctionnalités, chiffré dans les deux cas — en vérifiant que chaque fonctionnalité de ce périmètre se trouve du côté « oui » de la matrice ci-dessus.

Les questions à poser à un prestataire qui propose une PWA

La PWA est souvent présentée comme « une application moins chère », et souvent à juste titre. Cinq questions permettent de vérifier si le prestataire la conçoit comme une application, ou comme un site avec une icône.

1. Quels écrans fonctionneront sans réseau, et que deviennent les données saisies hors ligne ? Une bonne réponse nomme des écrans précis et indique quand les données seront envoyées. « Ça marchera hors ligne », sans détail, signifie que personne n’a encore conçu cela.
2. Comment un utilisateur d’iPhone saura-t-il qu’il peut ajouter l’application à son écran d’accueil ? Puisque Safari ne le propose pas, quelqu’un doit préparer une instruction ou un écran d’aide — et cela doit faire partie du périmètre du projet.
3. Sur quelles versions d’iOS et d’Android allez-vous tester ? Les notifications fonctionnent sur iPhone depuis iOS 16.4, et la façon dont les applications s’ouvrent depuis l’écran d’accueil a changé avec iOS 26. Un test sur un seul téléphone du prestataire ne suffit pas.
4. Comment une mise à jour atteindra-t-elle les utilisateurs qui ont déjà installé l’application ? Le service worker stocke des fichiers sur l’appareil, et, s’il est mal configuré, il peut continuer à servir une ancienne version pendant longtemps. Votre prestataire doit savoir comment contrôler cela.
5. L’une des fonctionnalités demandées nécessite-t-elle du Bluetooth, du NFC ou un store ? Si oui, et que l’application doit tourner sur iPhone, mieux vaut le savoir avant de signer qu’à la livraison.

Ce qu’une PWA ne fait pas

Les limites les plus importantes concernent l’iPhone et l’accès au matériel. WebKit, le moteur de Safari, s’oppose formellement à deux technologies qui fonctionnent sur Android : le Web Bluetooth — connecter un site à des appareils en Bluetooth, disponible dans Chrome sur Android — et le Web NFC — lire des tags de proximité, disponible dans Chrome sur Android depuis la version 89. WebKit invoque la confidentialité, la sécurité et l’indépendance vis-à-vis d’un matériel précis comme raisons (WebKit, standards positions). Si votre application doit se connecter à une imprimante d’étiquettes, un scanner ou une balance, ou lire des tags NFC dans un entrepôt, une PWA sur iPhone ne le fera pas.

Pour d’autres technologies, WebKit n’a pas pris position. La synchronisation en arrière-plan en est un exemple : elle permet de terminer l’envoi de données une fois l’application fermée — sur iPhone, on ne peut pas s’y fier. En pratique, cela signifie que les données saisies hors ligne sont envoyées lorsque l’utilisateur rouvre l’application, pas silencieusement en arrière-plan.

Reste enfin tout ce qu’apporte un store : la visibilité dans la recherche de l’App Store, les paiements intégrés, et la confiance qu’une partie des utilisateurs accorde à une « vraie application ». Si l’un de ces éléments compte pour vous, la PWA n’est pas la bonne voie, quel qu’en soit le coût.

PWA, application native ou hybride : comment choisir

Après cette liste, le choix se résume en général à deux questions. Première question : devez-vous être présent dans un store — parce que c’est un canal de distribution, une exigence du client, ou que vous avez besoin de paiements intégrés ? Si oui, il vous faut une application native ou multiplateforme. Deuxième question : avez-vous besoin d’un fonctionnement hors ligne, de fonctionnalités matérielles et de notifications, avec des utilisateurs qui reviennent chaque jour ? Si oui — une PWA, avec les réserves de cet article. Si non — une application web bien construite dans le navigateur suffit, et c’est aussi le chemin le plus court vers une première version de votre produit.

Si vous hésitez entre une PWA et une application native, ajoutez une vérification à ces questions : quelle part de vos utilisateurs a un iPhone, et la fonctionnalité qui compte le plus pour vous se trouve-t-elle du côté « oui » de la matrice ci-dessus. Si c’est le cas, une PWA vous donne un seul code, des mises à jour sans examen et pas de frais de compte. Sinon, mieux vaut le savoir avant de construire qu’après.

Vous ne savez pas encore quelle option convient à votre cas ? Le quiz : site, application web ou mobile vous guide à travers quelques questions sur vos clients, votre budget et l’usage prévu — et se termine par une recommandation précise plutôt qu’un « ça dépend ».