Un client m'a appelé l'an dernier, paniqué. Son appli mobile lui coûtait 4 000 € par an en maintenance, et personne ne la téléchargeait. « Mais elle est sur l'App Store, non ? » Oui. Sauf qu'entre le coût d'acquisition par installation et les utilisateurs qui la désinstallent après deux semaines, il brûlait du budget pour rien. On a remplacé la moitié de ses fonctionnalités par une web app progressive. Résultat : trois fois plus d'utilisateurs actifs mensuels, pour un coût de développement divisé par quatre.
C'est là que le débat sur les web apps progressives, ou PWA, devient intéressant. Pas dans les promesses marketing. Dans les chiffres réels qu'on observe quand on migre vraiment.
Points clés à retenir
- Une PWA est un site web qui se comporte comme une appli native : installation, mode hors-ligne, notifications
- Elle se distingue d'une appli native par l'absence de store, un poids réduit et des mises à jour instantanées
- Les gains mesurés portent surtout sur l'acquisition et la rétention, pas sur la puissance brute
- Les limites existent, en particulier sur iOS et pour tout ce qui touche au matériel natif
- Le choix PWA vs native dépend de votre usage réel, pas d'une mode technologique
- Un site peut devenir PWA sans être réécrit de zéro, par ajouts successifs
Les progressive web apps sont-elles vraiment l'avenir du web mobile ?
La réponse honnête : oui pour certains usages, non pour d'autres. Et le refus de trancher, c'est précisément ce qui rend le sujet flou.
Quand on me demande si les PWA vont « remplacer les applis », je réponds toujours la même chose : elles ont déjà remplacé une partie d'entre elles, discrètement, sans faire la une. Le vrai basculement n'est pas technique. Il est économique.
Qu'est-ce que le développement d'applications web et mobile ?
Le développement d'applications web et mobile regroupe l'ensemble des pratiques qui consistent à concevoir un logiciel accessible depuis un navigateur ou depuis un appareil mobile. Concrètement, cela couvre trois familles :
- le site web classique, consultable mais sans installation
- l'application native, téléchargée depuis un store et écrite pour un système précis
- et l'application web progressive, qui prend le meilleur des deux mondes précédents
La différence pratique tient à l'endroit où vit le code et à la manière dont l'utilisateur y accède. Un site web ou une PWA vivent sur un serveur et s'exécutent dans un moteur de rendu. Une appli native vit sur l'appareil, compilée pour lui.
Cette distinction paraît technique. Elle a pourtant des conséquences très concrètes sur le budget, le délai de mise sur le marché et la capacité à corriger un bug le jour même.
À quoi servent concrètement les applications web progressives ?
Elles servent à capter des utilisateurs là où ils se trouvent déjà : dans le navigateur. Pas dans un store, pas après un téléchargement de 80 Mo, pas après avoir créé un compte.
Sur un projet de e-commerce que j'ai suivi pendant huit mois, on est passés d'un tunnel d'achat mobile classique à une PWA avec mise en cache de la page produit. Ce qu'on a observé :
- Le taux de rebond sur mobile a chuté de 61 % à 38 % sur les pages produit
- Le temps de première interaction est passé de 4,2 s à moins de 2 s
- Les utilisateurs revenant dans la semaine ont augmenté d'environ un tiers
Avouons-le : tout n'était pas imputable à la seule couche PWA. On avait aussi allégé les images et viré deux scripts tiers. Mais la partie mode hors-ligne a eu un effet net sur les zones à réseau médiocre, où une simple coupure réseau faisait perdre le panier avant.
Les cas d'usage où la PWA gagne haut la main
Une PWA excelle quand l'usage est régulier mais léger. Consulter un catalogue. Passer une commande. Suivre une livraison. Remplir un formulaire terrain. Ce sont des tâches qu'on ne veut pas confier à une appli de 120 Mo.
Elle gagne aussi quand l'acquisition coûte cher. Chaque étape entre la découverte et l'usage réel tue une part de vos visiteurs. Supprimer le store, c'est supprimer une étape entière.
Les cas où elle perd, sans discussion
Tout ce qui touche de près au matériel. Bluetooth bas niveau, accès fin à la caméra, capteurs spécialisés, arrière-plan persistant. Les navigateurs brident volontairement ces accès, et c'est une bonne chose pour la sécurité.
J'ai aussi vu des équipes se casser les dents sur la monétisation. Si votre modèle repose sur l'achat intégré via un store, la PWA vous complique la vie. C'est un point qu'on oublie souvent dans les comparatifs.
Quelle est la différence entre une application mobile et une webapp ?
Le tableau ci-dessous résume ce que j'ai constaté sur le terrain après avoir livré les deux types de produits.
| Critère | Application native | Webapp / PWA |
|---|---|---|
| Distribution | App Store, Play Store | URL directe |
| Installation | Téléchargement obligatoire | Optionnelle, en un clic |
| Taille moyenne | Souvent 40 à 150 Mo | Quelques Mo, voire moins |
| Mise à jour | Validation du store requise | Immédiate côté serveur |
| Accès matériel | Complet | Restreint selon le navigateur |
| Mode hors-ligne | Natif | Partiel, via cache |
| Coût de développement | Deux bases de code minimum | Une seule |
Le point qui surprend le plus les équipes : la validation du store. Une correction urgente sur une appli native peut prendre plusieurs jours. Sur une PWA, elle est en ligne dès le déploiement.
Ce détail change complètement la façon de travailler. On itère plus vite, on teste des idées en production, on corrige sans négocier avec un intermédiaire.
Comment fonctionne une PWA, techniquement ?
Trois briques suffisent à transformer un site en PWA. Elles s'ajoutent progressivement, sans tout réécrire.
Le service worker, le vrai moteur
C'est un script qui tourne en arrière-plan, séparé de votre page, et qui intercepte les requêtes réseau. Il décide quoi servir depuis le cache et quoi aller chercher en ligne.
Le mien, sur un projet de consultation d'horaires, mettait en cache la coquille de l'application et les dernières données consultées. Un utilisateur dans le métro pouvait ouvrir l'appli et voir ses horaires périmés d'une heure, au lieu d'un écran d'erreur. Ce n'est pas parfait, mais c'est infiniment mieux que rien.
Le manifeste web
Un fichier de configuration qui décrit votre application : son nom, ses icônes, sa couleur de thème, son mode d'affichage. C'est lui qui permet l'installation sur l'écran d'accueil sans barre d'adresse.
Franchement, c'est la partie la plus simple. Une vingtaine de lignes suffisent.
Et le HTTPS, non négociable
Aucun service worker ne s'active sans HTTPS. C'est une protection : un script qui intercepte vos requêtes ne doit pas pouvoir être injecté par un intermédiaire.
Le reste, c'est du soin. Un design responsive correct, des temps de chargement maîtrisés, et une vraie réflexion sur ce qui doit fonctionner hors-ligne.
Les limites que personne ne met en avant
Les articles sur le sujet adorent lister les avantages. Voici ce qu'on découvre une fois en production.
Sur iOS, le support a longtemps été en retard. Il s'est nettement amélioré ces dernières années, mais des écarts subsistent. Les notifications push, en particulier, ont mis du temps à arriver et restent plus contraintes que sur Android.
Deuxième point : le stockage. Chaque navigateur impose ses quotas. Un cache trop gourmand se fait purger sans prévenir, et votre mode hors-ligne disparaît d'un coup.
Troisième point, plus insidieux : l'absence de store. C'est un avantage sur le coût, mais une perte sur la découverte. Un utilisateur qui cherche votre marque sur l'App Store ne vous trouvera pas. Il faut donc travailler le référencement et l'acquisition autrement.
J'ai fait cette erreur sur mon premier projet PWA. J'avais misé sur le bouche-à-oreille et l'installation depuis le site. Six mois plus tard, la moitié du trafic venait toujours de la recherche. J'aurais dû anticiper.
Alors, faut-il choisir ?
Dans la majorité des cas que j'ai croisés, la bonne réponse n'est pas binaire. Beaucoup d'équipes finissent avec les deux : une PWA pour l'acquisition et les usages légers, une appli native pour les fonctions lourdes et les utilisateurs fidèles.
Le critère de décision tient en une question : de quoi vos utilisateurs ont-ils réellement besoin pour faire le travail ? Si la réponse tient dans un navigateur, la PWA suffit. Si elle exige un accès profond au téléphone, l'appli native reste incontournable.
Ce qui a changé, c'est que le web mobile n'est plus le parent pauvre. Il a rattrapé une grande partie de son retard sur l'expérience. Et pour beaucoup d'usages, cette expérience suffit largement.
La prochaine fois qu'on vous proposera une appli native de 80 Mo pour consulter un catalogue, posez une question simple : est-ce que le navigateur ne ferait pas déjà le travail, pour un dixième du prix ? La réponse vous surprendra peut-être.
