PWA ou application native : cinq questions pour choisir avant de payer deux développements

La réponse courte

Pour une application de gestion, de réservation, de suivi ou de communauté, une PWA suffit presque toujours : une seule base de code, installable sur iPhone, sur Android et sur ordinateur, mise à jour sans passer par une boutique. Le natif s'impose dans deux cas : quand l'application doit parler au matériel du téléphone au-delà de l'ordinaire, et quand sa présence sur l'App Store fait partie du produit.

Entre les deux, il y a cinq questions. Les voici dans l'ordre où je les pose.

1. Votre application a-t-elle besoin du matériel du téléphone ?

Appareil photo, géolocalisation, partage, notifications : une PWA sait faire. Ce qui reste hors de sa portée, c'est l'accès fin au matériel : un objet connecté piloté en Bluetooth, des capteurs lus en continu, du traitement vidéo lourd sur l'appareil, un travail qui doit tourner en arrière-plan pendant des heures.

Si une fonction centrale de votre produit tombe dans cette liste, n'allez pas plus loin : c'est du natif, et une PWA serait une fausse économie.

2. Devez-vous être dans les boutiques ?

Une PWA s'installe depuis votre site, sans commission ni validation par un tiers. Mais certains publics ne cherchent une application que dans une boutique, et certains acheteurs l'exigent.

• Google Play accepte une PWA empaquetée : c'est le rôle des Trusted Web Activities, que Google documente pour publier une application web dans une application Android. L'application affiche votre PWA en plein écran, et le lien entre les deux se prouve par un fichier posé sur votre domaine. Je l'ai fait : même base de code, pas de réécriture.
• L'App Store est une autre affaire. La règle 4.2 d'Apple demande qu'une application aille « au-delà d'un site web reconditionné ». Une PWA glissée telle quelle dans une coque iOS risque le refus.

Si l'App Store est indispensable dès le premier jour, le calcul change. S'il ne l'est pas, une PWA installée depuis votre site fait très bien le travail.

3. Vos utilisateurs sont-ils sur iPhone ?

C'est là que se jouent la plupart des déceptions, et elles se préviennent. Depuis iOS et iPadOS 16.4, une PWA ajoutée à l'écran d'accueil reçoit les notifications push, comme une application native, et elle s'ouvre dans sa propre fenêtre, hors du navigateur. Depuis la même version, les autres navigateurs que Safari peuvent aussi proposer l'ajout à l'écran d'accueil.

Deux conditions à connaître avant de décider :

• L'installation est un geste que personne ne trouve seul : menu Partager, puis « Sur l'écran d'accueil ». Il faut l'expliquer dans l'interface, au bon moment.
• Les notifications exigent une application installée, et la demande d'autorisation doit suivre un geste de l'utilisateur, comme un appui sur un bouton « Me prévenir ». Une demande affichée à l'ouverture ne passe pas.

Aucune des deux ne bloque un projet. Les deux font échouer celui qui les découvre après la mise en ligne.

4. Les notifications sont-elles le cœur du produit ?

Les notifications d'une PWA fonctionnent sur Android comme sur iPhone : j'en envoie en production sur les deux. Sur iPhone, avec les deux conditions ci-dessus.

Si votre modèle repose sur des rappels envoyés à des utilisateurs qui n'ont jamais installé l'application, par exemple des clients de passage, aucune des deux solutions ne les atteindra par push : il faudra un e-mail ou un SMS. Ce n'est donc pas un argument pour le natif, c'est une question de parcours.

5. Combien sur trois ans, et pas sur la première version ?

Deux applications natives, ce sont deux bases de code, souvent deux compétences, deux passages en validation à chaque correction, et deux jeux de tests. Une PWA, c'est une base de code, déployée comme un site : une correction est en ligne dans l'heure, sur tous les appareils.

L'écart ne se voit pas sur le devis de la première version. Il se voit la deuxième et la troisième année, quand chaque évolution se paie une fois au lieu de deux.

Le tableau, pour décider vite

Et si vous hésitez encore

Une PWA n'enferme pas : si le produit trouve son public et qu'un jour le natif devient nécessaire, l'application web et son serveur restent, et l'application native vient se brancher sur la même API. L'inverse est plus rare et plus cher.

Je construis des PWA en production, dont une publiée sur Google Play par-dessus la même base de code. Si votre projet coche les cas du natif, je vous le dis au premier échange. Sinon, voici comment se passe le développement de votre application installable avec moi : ce qu'« installable » demande vraiment, iPhone compris, et comment se chiffre le travail.