Written by:
Last Published:
6 août 2026
•
Une progressive web app (PWA) est une application web qui utilise les fonctionnalités modernes des navigateurs, principalement les service workers et un manifeste d'application web, pour se comporter comme une application native installée. Vous cliquez sur un lien, et ce qui s'ouvre ressemble à une application, fonctionne hors ligne et s'ajoute ensuite à votre écran d'accueil, sans que vous ayez eu à passer par une boutique d'applications ou à accepter une installation. Imaginez une application native comme un magasin qui vous demande de remplir un formulaire d'adhésion à l'entrée. Une PWA est ce même magasin, mais avec la porte déjà ouverte.
Cependant, ce n'est pas toujours la solution idéale. La prise en charge des applications web installées par Apple est en retard sur celle de Google, l'accès au matériel est plus limité que pour une application native, et aucune boutique d'applications ne répertorie les PWA par défaut. La question n'est donc pas de savoir si les PWA fonctionnent, mais quand elles sont adaptées à votre entreprise. C'est ce que nous allons aborder : ce qu'une PWA permet de faire, ce qu'elle coûte, ses limites et comment faire le bon choix.
La vision de la plateforme web sur ce qu'est une PWA, ainsi que les standards qui la régissent, sont documentés par MDN Web Docs et le parcours d'apprentissage PWA de web.dev.
Les applications mobiles sont essentielles car elles permettent de créer une expérience plus pratique et plus personnelle qu'une page web classique. Il existe trois grandes méthodes pour en développer une.
Les applications natives sont conçues pour une plateforme spécifique. Elles utilisent le langage propre à chaque plateforme, Swift pour iOS et Kotlin pour Android, et permettent d'accéder à toutes les fonctionnalités de celle-ci. Deux plateformes impliquent deux bases de code distinctes.
Les applications hybrides combinent code natif et code web, ce qui permet de déployer une base de code unique sur plusieurs plateformes au sein d'une enveloppe native. Selon le framework et les plugins disponibles, les applications hybrides peuvent ne pas accéder à toutes les fonctionnalités spécifiques d'une plateforme. Vérifiez donc la compatibilité des notifications push et de l'accès au matériel (GPS, appareil photo, etc.) avec vos besoins avant de vous lancer.
Les Progressive Web Apps (PWA) sont des sites web conçus avec des technologies web modernes que les utilisateurs peuvent installer sur leur écran d'accueil et utiliser hors ligne. Bien qu'elles soient moins puissantes que les applications natives, elles offrent bon nombre des mêmes avantages à partir d'une base de code et d'un pipeline de déploiement uniques.
En savoir plus sur Application native vs hybride vs PWA : avantages et inconvénients. Si vous souhaitez d'abord avoir une vue d'ensemble, notre guide complet du développement d'applications web pose les bases sur lesquelles s'appuie cet article.
Une application web est un logiciel accessible via un navigateur comme Chrome, Safari ou Firefox. Les applications web gagnent du terrain sur les logiciels de bureau traditionnels pour trois raisons pragmatiques : elles ne nécessitent aucune installation, se mettent à jour de manière centralisée et fonctionnent partout où un navigateur est présent.
Une progressive web app va encore plus loin. Elle utilise des API de navigateur pour maintenir une expérience utilisateur fluide même en cas de connexion lente ou inexistante, et s'adapte à l'appareil utilisé plutôt que de supposer une connexion rapide sur un téléphone performant. Une seule version suffit pour toutes les plateformes, évitant ainsi de devoir développer des fonctionnalités distinctes selon le système d'exploitation.
Les PWA empruntent également des comportements aux applications mobiles : notifications push lorsque la plateforme le permet, fonctionnement hors ligne et installation sur l'écran d'accueil. Et comme l'application est diffusée plutôt que distribuée, les utilisateurs accèdent instantanément à la version la plus récente. Plus besoin d'accepter de mises à jour via une boutique, ni de gérer des utilisateurs restés sur une ancienne version.
Techniquement, une PWA repose sur le HTML, le CSS et le JavaScript, ce qui lui permet de bénéficier de tout l'écosystème web : bibliothèques, outils, vivier de talents et processus de déploiement déjà maîtrisés par votre équipe. C'est la raison concrète pour laquelle une PWA est mise en ligne plus rapidement qu'une application native. Ce n'est pas de la magie, mais une infrastructure que vous possédez déjà.
Cependant, la barre est placée haut par les applications natives. Alors, de quoi une bonne PWA a-t-elle réellement besoin ?
Six éléments distinguent une PWA d'un site web mobile, et chacun d'eux relève d'un choix stratégique plutôt que d'un simple paramètre.
Le seuil minimal pour l'installabilité, à savoir une origine HTTPS et un manifeste valide, est détaillé dans le guide sur l'installabilité des PWA de MDN. Le support des service workers selon les navigateurs est suivi sur caniuse.
Moins que vous ne le pensez. Trois des prérequis sont techniques, deux relèvent du jugement.
HTTPS, car les service workers l'exigent. Votre site doit être servi via HTTPS. Cela protège les données des utilisateurs lors de leur transfert, et les navigateurs n'enregistreront pas de service worker sur une origine non sécurisée ; sans cela, il n'y a pas de PWA. Ce point n'est pas négociable.
Un service worker, pour le mode hors ligne et la mise en cache. Un service worker est un script d'arrière-plan que le navigateur exécute indépendamment de votre page. Il prend en charge l'utilisation hors ligne, met en cache les ressources et les données, gère les opérations en arrière-plan et peut terminer des tâches même lorsque votre PWA n'est pas ouverte, ce qui rend possibles les notifications push et la synchronisation en arrière-plan.
Un manifeste d'application web. Ce fichier JSON indique au navigateur comment votre PWA doit apparaître et se comporter une fois installée : nom, nom court, description, icônes, couleurs de thème et d'arrière-plan, mode d'affichage et URL de démarrage. C'est ce qui transforme un onglet en application. MDN propose une référence complète des membres du manifeste, et web.dev offre un guide pratique sur le manifeste d'application web.
Frameworks et outils. N'importe quel framework JavaScript moderne fera l'affaire, et la plupart proposent désormais une documentation dédiée aux PWA : React, Angular, Vue, Svelte, ainsi que les méta-frameworks comme Next.js, Nuxt et SvelteKit. Pour le service worker lui-même, la plupart des équipes privilégient Workbox plutôt que d'écrire manuellement des stratégies de mise en cache. Les anciennes recommandations mentionnant AngularJS ou Polymer sont obsolètes et ces deux outils sont retirés ; considérez donc tout tutoriel qui les recommande encore comme un signal d'alerte concernant la fiabilité du reste de ses conseils.
Un premier chargement qui en vaut la peine. C'est sur ce premier écran que les utilisateurs vous jugent, alors mesurez-le plutôt que de deviner. Lighthouse, l'outil d'audit open source de Google, génère des rapports sur les performances, l'accessibilité, le SEO et l'installabilité, et s'exécute dans les outils de développement de Chrome pour n'importe quelle URL.
Une mise en garde avant d'aborder les chiffres, car elle modifie leur portée. Chaque résultat ci-dessous provient des rapports techniques des entreprises elles-mêmes, rassemblés dans la bibliothèque d'études de cas web.dev, et la plupart ont été publiés vers 2016 et 2017.
C'était une époque où les PWA étaient nouvelles et où les sites mobiles qu'elles remplaçaient étaient souvent médiocres. Considérez-les donc comme la preuve que ce modèle peut être rentable, et non comme une prévision pour votre propre développement. Le résumé de Google sur les attentes des utilisateurs en matière d'expérience mobile repose sur les mêmes travaux : l'acronyme FIRE (Fast, Installable, Reliable, Engaging), soit rapide, installable, fiable et engageant.
La réussite commerciale varie selon ce que vous vendez ; choisissez donc l'indicateur qui correspond à votre modèle : temps passé sur le site, taux de rebond, taux de conversion ou visiteurs récurrents. Et comme une PWA se déploie de manière incrémentale, vous pouvez lancer en priorité les fonctionnalités les plus rentables et ajouter le reste par la suite.
Pinterest a refondu son expérience web mobile en PWA pour soutenir sa croissance internationale. Seul 1 % des utilisateurs mobiles se convertissaient en inscriptions, connexions ou installations d'applications, et les mauvaises performances mobiles en étaient la cause ; l'équipe a donc tout repris à zéro.
La refonte a produit trois résultats, selon le rapport technique de Pinterest : une augmentation de 40 % du temps passé sur le web mobile par rapport à la version précédente, une hausse de 60 % des interactions principales et une progression de 44 % des revenus publicitaires générés par le contenu des utilisateurs, ce qui constitue le modèle de monétisation du flux Pinterest.
Avec plus de 80 % de ses utilisateurs sur mobile, Twitter souhaitait une expérience web mobile plus rapide, plus fiable et moins gourmande en données. Twitter Lite est devenu l'expérience web mobile par défaut pour tous les utilisateurs dans le monde, axée sur le chargement instantané, l'engagement et la réduction de la consommation de données.
L'équipe technique de Twitter a rapporté 65 % de pages vues en plus par session, 75 % de tweets envoyés en plus et 20 % de rebonds en moins. Twitter Lite se chargeait en moins de trois secondes, même sur des connexions lentes.
Uber a refondu son application web en PWA pour offrir une expérience de réservation comparable à celle de l'application native, alors que l'entreprise s'implantait sur de nouveaux territoires. La PWA permet de réserver sur les réseaux 2G et fonctionne dans n'importe quel navigateur moderne, ce qui permet d'atteindre les utilisateurs disposant d'appareils d'entrée de gamme incapables de faire tourner l'application native Uber.
Selon le rapport technique d'Uber, le résultat est une application web légère qui se charge en trois secondes sur le réseau 2G, quel que soit l'emplacement, la vitesse du réseau ou l'appareil.
Starbucks a créé une PWA de son système de commande pour égaler l'expérience de son application native. Les clients peuvent parcourir le menu, personnaliser leurs commandes et ajouter des articles à leur panier sans connexion stable, puis consulter les prix spécifiques à chaque établissement et valider leur commande une fois reconnectés.
Comme une grande partie de l'application fonctionne hors ligne, elle est parfaitement adaptée aux clients dont la connexion est intermittente au cours de la journée. L'application pèse moins de 0,15 Mo et Starbucks a rapporté que, depuis son lancement, le nombre d'utilisateurs actifs quotidiens a doublé, les commandes sur ordinateur atteignant un volume proche de celui des navigateurs mobiles.
Trivago, l'un des plus grands moteurs de recherche d'hôtels, a investi dans une PWA pour offrir une expérience mobile plus stable. L'équipe a donné la priorité à l'accès hors ligne, aux notifications push et à l'ajout sur l'écran d'accueil, jugeant ces fonctionnalités comme les plus précieuses pour ses utilisateurs.
Les chiffres rapportés par Trivago : les actions d'ajout à l'écran d'accueil ont augmenté de 150 % et les clics sortants — ceux qui redirigent l'utilisateur vers l'offre d'un hôtel et génèrent les revenus de Trivago — ont progressé de 97 %. Les utilisateurs qui perdent leur connexion peuvent continuer à naviguer, et 67 % d'entre eux le font effectivement une fois reconnectés.
Les chiffres originaux de ces cinq cas proviennent des rapports techniques de chaque entreprise, rassemblés dans la bibliothèque de Google Bibliothèque d'études de cas web.dev. Considérez-les comme des témoignages d'une époque plutôt que comme des références actuelles.
Au-delà du marketing, trois avantages font tout le travail.
Une base de code, plusieurs plateformes. Une PWA fonctionne sur n'importe quel appareil et navigateur compatible web. Vous développez et maintenez donc une seule solution au lieu d'une application web, d'une application iOS et d'une application Android. C'est là que se situent les économies, et elles se cumulent : chaque fonctionnalité, chaque correctif et chaque mise à jour de sécurité ne sont déployés qu'une seule fois.
Le comportement d'une application, sans les contraintes. L'accès hors ligne, les notifications push (lorsque la plateforme les prend en charge), une faible consommation de données et l'installation sur l'écran d'accueil sont désormais accessibles à une application web. La baisse de 20 % du taux de rebond de Twitter Lite et la hausse de 150 % des installations chez Trivago illustrent le même avantage mesuré de deux manières différentes. Les utilisateurs qui n'auraient jamais rempli le formulaire d'adhésion finissent tout de même par épingler la boutique sur leur écran d'accueil.
Plus rapide à lancer, moins coûteuse à entretenir. Les API web et les outils existants permettent à une équipe de mettre en ligne un service client sans avoir à développer des applications mobiles et de bureau distinctes. Il n'y a qu'un seul processus de déploiement au lieu de deux files d'attente de validation sur les stores. La maintenance est plus légère pour la même raison structurelle : moins de bases de code, moins de pipelines et aucune fragmentation de version chez les utilisateurs qui n'ont jamais effectué de mise à jour.
Une mise en garde s'applique à ces trois points. Une PWA est adaptée lorsque vos besoins correspondent aux capacités du navigateur ; si ce n'est pas le cas, rien de tout cela ne pourra vous sauver.
Les taux d'engagement mentionnés plus haut ne constituent que la partie la plus simple de l'analyse de rentabilité. Les quatre questions suivantes complètent le tableau et sont celles qui méritent d'être prises en compte pour décider.
Coût de développement. La réponse honnête est une fourchette, pas un chiffre précis, et elle dépend du périmètre plutôt que de la technologie. Le point structurel est simple : une PWA repose sur une base de code unique là où le natif en exige deux. Vous comparez donc un développement à deux, en plus du travail de conception et de back-end nécessaire dans les deux cas. Obtenez une estimation détaillée avant de baser votre planification sur un chiffre arbitraire.
Délai de mise sur le marché. Une PWA est disponible dès son déploiement. Pas de soumission aux stores, pas de file d'attente de validation, ce qui élimine à la fois l'attente avant le lancement et les contraintes liées à chaque mise à jour ultérieure. Pour une équipe qui publie chaque semaine, cet argument suffit souvent à trancher.
Maintenance. Une base de code, un pipeline, une version en production. Le natif implique deux bases de code suivant les calendriers de mise à jour de deux systèmes d'exploitation différents, sans oublier la gestion des utilisateurs restés sur d'anciennes versions. Une PWA n'est pas exempte d'entretien : le support des navigateurs évolue et la logique de mise en cache doit être révisée au fil des changements de l'application.
Risques liés à la plateforme. Le support des applications web installables par Apple a longtemps été en retrait par rapport à celui de Google, avec quelques turbulences : début 2024, Apple a brièvement supprimé les web apps sur écran d'accueil pour les utilisateurs de l'UE afin de se conformer au Digital Markets Act, avant de faire marche arrière quelques semaines plus tard face aux critiques. Cet épisode est clos et la tendance est depuis clairement à l'amélioration. Les notifications push fonctionnent sur les PWA installées depuis iOS 16.4, et depuis iOS 26, tout site ajouté à l'écran d'accueil s'ouvre par défaut en tant qu'application web, supprimant une étape que les utilisateurs devaient auparavant connaître. Ce qui n'a pas changé, ce sont les aspects les plus complexes. L'accès au matériel et au système d'exploitation reste plus limité qu'en natif : le Bluetooth, la synchronisation en arrière-plan, l'intégration profonde au système et certains capteurs peuvent être inaccessibles, et iOS peut supprimer les données en cache d'une PWA après une longue période d'inactivité. Si une grande partie de vos utilisateurs est sur iOS, testez vos fonctionnalités critiques sur la version actuelle de Safari avant de vous engager.
Risques liés à la distribution et à la sortie. Aucun des deux app stores ne référence les PWA par défaut. Si la présence sur les stores fait partie de votre stratégie d'acquisition, vous devrez prévoir un canal distinct. Et si vous découvrez plus tard que le natif est finalement indispensable, vous devrez financer un second développement plutôt que d'étendre le premier.
Apple documente la position actuelle sur les web apps pour écran d'accueil dans l'UE dans sa FAQ développeurs sur le DMA et les applications dans l'UE , et l'arrivée des notifications push web sur iOS est décrite sur le blog WebKit.
Nous posons ces quatre mêmes questions pour chaque projet où une PWA est envisagée. Elles permettent de trancher la plupart de ces décisions en une seule discussion.
D'où viennent vos utilisateurs ? S'ils arrivent via la recherche, des publicités ou un lien partagé, une PWA permet de maintenir tout le parcours sur le web sans rien avoir à installer. S'ils passent par les boutiques d'applications, cet argument perd toute sa pertinence.
De quoi l'application a-t-elle besoin sur l'appareil ? Dressez la liste des fonctionnalités matérielles et du système d'exploitation indispensables, puis vérifiez chacune d'elles par rapport à la prise en charge des navigateurs sur les appareils réellement utilisés par vos clients. Une seule lacune incontournable suffit à trancher la question.
Que doit faire le mode hors ligne ? « Fonctionne hors ligne » peut signifier tout et n'importe quoi, de l'affichage de contenu en cache à la mise en file d'attente de transactions. Plus votre réponse est complexe, plus le développement reposera sur le service worker.
Que se passera-t-il dans 18 mois ? Si votre feuille de route prévoit des fonctionnalités uniquement réalisables en natif, commencer par une PWA peut rester un choix judicieux, à condition d'accepter de payer pour les deux plutôt que de le découvrir sur le tard. Parfois, le natif est tout simplement la réponse honnête dès le premier jour. Lorsque nous avons conçu Jinga Life, une plateforme numérique de santé familiale, les exigences pointaient vers iOS dès le départ. C'est donc ce que nous avons construit, plutôt que de forcer une application web à accomplir une tâche pour laquelle elle n'était pas adaptée. L'objectif de ces quatre questions n'est pas de vous convaincre de choisir une PWA, mais de déterminer laquelle des deux solutions vous est réellement nécessaire.
Répondez à ces quatre questions et le choix s'imposera généralement de lui-même. Si le doute persiste, la stratégie hybride est tout à fait légitime : lancez la PWA, apprenez de l'usage réel, puis passez au natif ultérieurement pour les fonctionnalités qui le nécessitent.
Trois éléments distinguent une PWA robuste d'une application qui ne fonctionne que sur votre ordinateur.
Oui, et bien mieux que leur réputation ne le laisse penser. Safari prend en charge les service workers, la mise en cache hors ligne et l'ajout à l'écran d'accueil ; le cœur d'une PWA fonctionne donc sur iPhone et iPad. Les notifications push sont disponibles pour les PWA installées depuis iOS 16.4, et à partir d'iOS 17.4, un site enregistré sur l'écran d'accueil s'ouvre par défaut comme une application à part entière plutôt que comme un raccourci de navigateur.
Les réserves concernent la profondeur des fonctionnalités, pas leur exécution. Il n'existe toujours pas d'invite d'installation automatique sur iOS comme sur Android ; l'utilisateur doit donc appuyer sur Partager puis sur Ajouter à l'écran d'accueil. Il est préférable de concevoir une incitation à l'installation plutôt que de supposer que les utilisateurs la trouveront d'eux-mêmes. Les notifications push ne se déclenchent qu'une fois l'application installée et l'autorisation accordée ; elles ne permettent donc pas de réengager quelqu'un qui n'a jamais installé l'application. De plus, la synchronisation en arrière-plan, la plupart des fonctionnalités Bluetooth et capteurs, ainsi que le stockage persistant à grande échelle sont soit absents, soit peu fiables. Si une part significative de vos utilisateurs est sur iOS, testez vos fonctionnalités indispensables sur la version actuelle de Safari avant de baser votre planification sur celles-ci. La FAQ développeurs d'Apple sur les applications dans l'UE est la référence pour confirmer la position la plus récente.
La différence réside dans le nombre de bases de code, et non dans la technologie elle-même. Une PWA est une construction unique desservant toutes les plateformes, alors qu'une approche native nécessite une application iOS et une application Android, chacune avec son propre cycle de publication et sa propre maintenance. Le travail de conception et de back-end coûte à peu près la même chose dans les deux cas. Demandez une estimation détaillée basée sur votre propre liste de fonctionnalités plutôt que de vous fier à une moyenne publiée.
Pas par défaut. Une PWA est distribuée via le web ; les utilisateurs la trouvent donc par recherche, lien ou publicité plutôt qu'en parcourant une boutique. Si la présence sur les stores est importante pour vous, vous pouvez encapsuler l'application pour la publier : sur Android via une Trusted Web Activity, le mécanisme de Google pour distribuer une PWA dans un package natif léger, et sur iOS via un wrapper natif, une application native minimale dont le seul rôle est d'afficher votre application web. Ces deux méthodes ajoutent une étape de construction et un processus de révision que vous n'auriez pas eus autrement.
Oui. Les technologies sous-jacentes, comme les service workers, le manifeste d'application web et l'invite d'installation, sont désormais des composants standards de la plateforme et non plus une expérimentation. Les frameworks que la plupart des équipes utilisent déjà les prennent en charge nativement. Ce qui a changé, c'est l'approche : une PWA n'est plus une catégorie de produit distincte, mais un ensemble de fonctionnalités que vous activez pour une application web lorsqu'elles apportent une réelle valeur ajoutée.
Tout ce qui nécessite un accès approfondi à l'appareil ou au système d'exploitation. La localisation en arrière-plan, la plupart des fonctionnalités Bluetooth et capteurs, l'intégration étroite avec les fonctions système et tout ce qui nécessite un processus en arrière-plan permanent sont soit indisponibles, soit inégalement pris en charge. La disponibilité variant selon le navigateur et la plateforme, basez votre décision sur votre propre liste d'exigences en vérifiant chacune d'elles par rapport à Référence PWA de MDN, plutôt qu'une réponse générale.
Cela dépend de l'envergure du projet, mais deux facteurs permettent systématiquement de gagner du temps par rapport au natif : une base de code unique et l'absence de validation par les stores avant la publication. Si vous disposez déjà d'une application web bien conçue, l'ajout d'un service worker, d'un manifeste et d'une stratégie hors ligne représente un travail ciblé plutôt qu'une refonte complète. Si le problème réside dans l'application existante, comme ce fut le cas pour Pinterest, alors vous devrez envisager une refonte, et le calendrier sera celui de cette reconstruction.
En résumé : une progressive web app est la solution idéale si vos besoins correspondent aux capacités du navigateur, si vos utilisateurs viennent du web et si vous préférez maintenir une seule base de code plutôt que deux. Elle est inadaptée si une fonctionnalité indispensable dépend du système d'exploitation ou si votre distribution repose sur les app stores. Gardez toutes les options ouvertes tant que vous le pouvez. Optez pour une application native uniquement lorsque c'est nécessaire.
Nous avons développé les deux types d'applications, des web apps installables sur l'écran d'accueil aux produits natifs comme Jinga Life, afin de vous proposer la recommandation la plus adaptée à votre projet. Découvrez notre approche du développement web et du développement mobile, ou contactez-nous pour que nous puissions analyser vos besoins à travers les quatre questions ci-dessus.
Alexandra Mendes est Senior Growth Specialist chez Imaginary Cloud et possède plus de 3 ans d'expérience dans la rédaction sur le développement logiciel, l'IA et la transformation numérique. Après avoir suivi une formation en développement frontend, Alexandra a acquis des compétences pratiques en programmation et travaille désormais en étroite collaboration avec les équipes techniques. Passionnée par la manière dont les nouvelles technologies façonnent les entreprises et la société, Alexandra aime transformer des sujets complexes en contenus clairs et utiles pour les décideurs.
Inês Silva est cheffe de projet avec plus de quatre ans d'expérience dans la rédaction sur la livraison de logiciels, les méthodologies agiles et le leadership technologique. Ayant débuté sa carrière en tant que développeuse, Inês apporte une compréhension technique réelle et approfondie à la gestion de projet. Elle aime faire le pont entre la stratégie commerciale globale et l'exécution technique au quotidien, et elle a à cœur de partager des conseils pratiques pour aider les équipes à mieux collaborer et à concevoir des produits de qualité.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
