PWA ou application native : comment choisir

Le socle technique est stable depuis plusieurs années et couvre l'essentiel de ce qu'attend un utilisateur d'une application.

• Installation sur l'écran d'accueil, avec sa propre icône et son écran de lancement, sans passer par un magasin.
• Fonctionnement hors connexion ou en réseau dégradé, grâce au service worker qui met en cache l'interface et les données.
• Notifications poussées, y compris sur iPhone depuis iOS 16.4, avec des conditions que nous détaillons plus bas.
• Accès à l'appareil photo, à la géolocalisation, au micro et au partage natif.
• Mise à jour instantanée : vous publiez, tout le monde a la nouvelle version au prochain lancement.

Ce dernier point est sous-estimé. Sur une application native, une correction urgente demande une nouvelle version, une revue par Apple et Google, puis l'attente que les utilisateurs mettent à jour. Sur une PWA, le correctif est en ligne en quelques minutes. Pour un produit qui bouge beaucoup, cette différence de rythme pèse plus lourd que la plupart des comparatifs de fonctionnalités. Les critères d'installabilité sont documentés sur web.dev et MDN.

C'est là que se jouent la plupart des mauvaises surprises, et là que circulent le plus d'informations périmées. Trois faits vérifiés valent mieux qu'un avis. D'abord, les notifications poussées fonctionnent sur iPhone depuis iOS 16.4, mais à une condition stricte : l'application web doit avoir été ajoutée à l'écran d'accueil. Un site consulté dans un onglet Safari ne recevra jamais de notification. Apple précise aussi que la demande d'autorisation doit répondre à une action volontaire, un bouton sur lequel on appuie, pas un déclenchement automatique à l'arrivée.

Ensuite, l'installation reste manuelle sur iPhone. Safari ne propose pas la bannière d'installation en un geste que connaît Android : l'utilisateur doit ouvrir le menu de partage et choisir « Sur l'écran d'accueil ». Autrement dit, si votre PWA dépend des notifications, votre parcours doit expliquer cette manipulation, sans quoi une grande partie de vos utilisateurs iPhone ne sera jamais joignable.

Enfin, un épisode a semé une confusion durable. En février 2024, Apple a annoncé retirer les applications web de l'écran d'accueil en Europe, au nom du règlement sur les marchés numériques. Devant la réaction, l'entreprise est revenue sur sa décision avant la sortie d'iOS 17.4. Les PWA fonctionnent donc normalement en France. Beaucoup d'articles en ligne décrivent encore l'ancienne annonce comme la situation actuelle, méfiez-vous des comparatifs non datés.

Une comparaison honnête suppose de nommer les vraies frontières. Ces limites ne se contournent pas avec du budget.

• Aucune présence dans l'App Store ni sur Google Play, sauf à l'emballer dans une coquille native, ce qui vous ramène aux contraintes de publication.
• Pas de synchronisation en arrière-plan fiable sur iPhone : votre application ne travaille pas pendant qu'elle est fermée.
• Pas d'accès aux capteurs les plus fins, ni au Bluetooth sur iPhone, ni aux fonctions système avancées comme les widgets ou les raccourcis.
• Les paiements intégrés au magasin, obligatoires pour vendre du contenu numérique dans une application native, ne s'appliquent pas, ce qui est un avantage économique mais ferme la porte aux abonnements gérés par la plateforme.
• Le stockage local est plus contraint que sur Android, et le système peut le récupérer après une longue période d'inactivité.

Un dernier point vaut d'être connu : sur iPhone, tous les navigateurs reposent sur le moteur de Safari. Utiliser Chrome sur iOS ne contourne donc aucune de ces limites, c'est le même moteur en dessous.

Une PWA est un seul produit, une seule base de code, un seul cycle de tests. Une application native pour les deux plateformes, c'est deux exécutions et deux publications, même en cross-platform où le partage de code n'est jamais total. Dans nos projets, une première version de PWA bien cadrée démarre autour de 8 000 à 15 000 euros, là où un MVP mobile publié sur les deux magasins commence plutôt à 15 000 euros et grimpe vite avec les fonctions natives. Le détail de ce qui fait bouger un budget mobile est développé dans notre page agence de développement d'application mobile.

L'écart ne s'arrête pas à la mise en ligne. Une application native se maintient au rythme des systèmes : chaque version majeure d'iOS ou d'Android peut demander une mise à jour, et les magasins retirent les applications qui ne suivent plus leurs règles. Une PWA se maintient comme un site. Sur trois ans, cette différence de charge courante dépasse souvent l'écart initial de développement.

Plutôt qu'un tableau de fonctionnalités, quatre questions suffisent à trancher la grande majorité des cas.

• Avez-vous besoin d'être trouvé dans l'App Store ou sur Google Play ? Si votre acquisition passe par la recherche dans les magasins, c'est natif, la question est close.
• Vos notifications sont-elles vitales, et vos utilisateurs sont-ils majoritairement sur iPhone ? Si oui, le passage obligé par l'installation manuelle est un risque réel sur votre taux de couverture.
• Avez-vous besoin de fonctions que le web ne fournit pas, Bluetooth, travail en arrière-plan, widgets, intégrations système ? Si oui, c'est natif.
• Votre produit va-t-il beaucoup évoluer dans les douze prochains mois ? Si oui, la PWA vous fait gagner un temps considérable, et rien ne vous empêche de passer au natif ensuite.

La bonne question n'est pas laquelle est la meilleure, mais laquelle suffit à ce que vous devez prouver dans les six prochains mois.

Commencer en PWA quand le produit doit d'abord faire ses preuves, puis basculer en natif quand l'usage le justifie. Ce n'est pas du travail jeté : le back-end, les interfaces de programmation, la logique métier et une bonne partie du design se réutilisent. Ce qui se refait, c'est la couche d'affichage. Cette bascule se décide sur des signaux concrets, une rétention qui tient, un besoin de notification devenu central, une fonction native réclamée par les utilisateurs. C'est exactement le genre d'arbitrage que nous posons pendant un cadrage produit, avant d'engager la première ligne de code.

Le scénario inverse existe aussi, et il est plus rare qu'on ne le croit : un produit lancé en natif, dont on s'aperçoit qu'il n'utilise aucune capacité native. On a alors payé deux exécutions et deux publications pour afficher des écrans qu'un navigateur rendait très bien.

Une PWA ratée l'est rarement à cause de la technologie. Quatre causes reviennent.

• Un site classique qu'on décore d'un fichier de configuration en espérant qu'il devienne une application : sans travail sur la vitesse, le hors-ligne et la navigation, le résultat reste un site.
• Aucune explication de l'installation sur iPhone, alors que c'est la seule porte vers les notifications.
• Un service worker mal réglé qui sert indéfiniment une version en cache, le grand classique de l'utilisateur bloqué sur du contenu périmé.
• Des interfaces pensées pour la souris, transposées telles quelles sur un écran tactile.

La PWA est un excellent choix quand la présence dans les magasins n'est pas votre canal d'acquisition, quand votre produit évolue vite, et quand le budget doit servir la valeur plutôt que la double exécution. Le natif s'impose dès que les magasins, le travail en arrière-plan ou les capacités matérielles font partie de la promesse. Entre les deux, il n'y a pas de bonne réponse universelle, seulement une bonne réponse pour votre projet et votre échéance. Si vous hésitez, notre équipe de développement web sur mesure construit les deux et n'a donc aucun intérêt à vous pousser vers l'un ou vers l'autre.