Entre 2017 et 2020, la PWA a connu son pic de hype technologique. Conférences, articles de blog, prise en charge officielle par Google et Microsoft. Puis est venue la déception : iOS bloquait l'accès à des API clés, les invites d'installation se sont révélées déroutantes, et le poids marketing des applications natives restait supérieur. La communauté s'est alors tournée vers Flutter, React Native et Capacitor.
Mais autre chose s'est tramé en coulisses. La stack PWA a continué de mûrir. Ces dernières années, Apple a ajouté les API manquantes, les navigateurs ont amélioré le parcours d'installation, et la spécification des service workers s'est stabilisée. Et pour les équipes produit aux budgets limités, la PWA est devenue une option étonnamment solide.
Cet article est un retour d'expérience transparent sur trefa.app — un concours de pronostics d'entreprise développé en PWA — après un an en production. Ce qui a marché, ce qui n'a pas marché, et à qui je recommanderais la PWA aujourd'hui.
Contexte : présentation de trefa.app
Trefa.app est une application web dédiée aux concours de pronostics en entreprise. L'utilisateur se connecte avec Google, crée une ligue pour son entreprise, invite ses collègues via un lien ou un QR code, et ils pronostiquent ensemble les résultats des matchs. L'application synchronise les données depuis des API sportives (NHL, Premier League, championnats du monde) et recalcule les points en temps réel.
Le frontend repose sur Next.js 16 + React 19 + Tailwind, hébergé sur Vercel. Le backend tourne sous Django 5 + DRF + Channels chez Hetzner. Entre les deux, PostgreSQL sur Supabase et Redis pour les communications en temps réel.
Un détail appréciable : il n'existe aucune application native iOS ou Android. La PWA est le seul client. Les utilisateurs sur iPhone, Android, Windows et macOS utilisent exactement la même chose.
Pourquoi nous avons préféré la PWA au natif
La décision était avant tout économique. Une application native aurait impliqué :
- Développer deux clients en parallèle (iOS en Swift + Android en Kotlin), ou un framework cross-platform (Flutter, React Native).
- Le processus de soumission sur l'App Store + Google Play — frais de soumission, délais de validation, republications périodiques à chaque changement de l'API backend.
- Des notifications push via APNs et FCM, deux infrastructures distinctes, deux processus de certification.
- Le flux de mises à jour via les stores — l'utilisateur doit mettre à jour activement, et une partie d'entre eux reste sur une version plus ancienne pendant des mois.
Pour un produit avec un public cible relativement restreint (équipes en entreprise, pas le grand public), le coût du développement natif était nettement supérieur au bénéfice. La PWA a tout balayé d'un coup.
Les avantages techniques que les utilisateurs ne remarqueront jamais
C'est la partie que j'aurais sous-estimée avant de passer en production. D'un point de vue développement, la PWA apporte plusieurs avantages concrets qui font gagner des semaines de travail par an :
Le déploiement est instantané. Push sur main → Vercel build → en 2 minutes la nouvelle version est devant tous les utilisateurs. Pas de soumission, pas d'attente, pas de jonglage de compatibilité entre les versions du client et du backend. Si je fais un changement d'API non rétrocompatible, je peux livrer un correctif dès le lendemain et tout le monde l'a immédiatement.
Une seule base de code pour tout. iOS, Android, Windows, macOS, Linux — la même application partout. Aucun bug spécifique à une plateforme (« ça ne casse que sur iPhone 13 en mode sombre »), aucune implémentation à dupliquer.
Un chemin court jusqu'à l'utilisateur. On envoie un lien, on clique, on est dans l'application. Pas de « téléchargez notre application sur l'App Store, inscrivez-vous, puis connectez-vous ». Pour des produits B2B à usage peu fréquent (un concours de pronostics ne tourne que pendant un tournoi sportif), c'est un énorme atout de conversion.
Les notifications push fonctionnent même sans installation. Le service worker enregistre l'abonnement push. Une fois que l'utilisateur clique sur « Autoriser les notifications », il commence à recevoir des alertes avant les matchs, qu'il ait ajouté l'application à son écran d'accueil ou qu'il l'ouvre seulement de temps en temps dans Safari.
Ce que la PWA ne permet pas de faire (en toute transparence)
Ici, la transparence compte plus que le marketing. La PWA a de vraies limites que nous avons rencontrées en production.
Les notifications push sur iOS ont des contraintes. Le Web Push d'Apple existe depuis iOS 16.4, mais ne fonctionne que si l'utilisateur a ajouté la PWA à son écran d'accueil. S'il utilise l'application via les onglets Safari, l'abonnement push ne tient pas. C'est une friction que les applications natives n'ont pas.
L'absence sur l'App Store. Pour certains profils d'acheteurs (services RH, responsables informatiques en entreprise), « pas sur l'App Store » équivaut à « pas sérieux ». C'est subjectif, mais bien réel.
Certaines API du système ne sont pas disponibles. Bluetooth Low Energy, NFC, accès complet au système de fichiers — pour une application classique ce n'est pas un problème, mais si vous avez besoin de ces fonctionnalités, la PWA vous limite.
Le mode hors ligne est possible, mais pas automatique. Il faut configurer le service worker à la main, concevoir les stratégies de cache, implémenter les files de synchronisation. Pour une application entièrement offline-first, c'est plus de travail que les développeurs ne l'imaginent.
Benchmark de performance face au natif : la PWA est ~15–25 % plus lente au premier chargement (parsing du bundle JS) et ~5–10 % sur les interactions du quotidien. Pour la plupart des applications c'est imperceptible, mais pour du jeu vidéo exigeant ou du montage vidéo, c'est rédhibitoire.
Bilan après un an en production
Des données concrètes de trefa.app après un an d'exploitation :
- Stabilité cross-platform — une équipe de développement d'une seule personne maintient l'application sur tous les systèmes d'exploitation sans bugs spécifiques à une plateforme. Le même cycle de tests pour tous.
- Fréquence de déploiement — en moyenne 3 à 5 déploiements par semaine via Vercel. Aucun ne devant composer avec les délais de soumission de l'App Store.
- Notifications push — ~70 % des utilisateurs actifs, taux de remise des push ~95 % sur Android, ~85 % sur iOS (à cause de l'obligation d'installer sur l'écran d'accueil).
- Aucuns frais d'App Store — environ 65 € par an économisés sur les comptes développeurs, plus environ 30 % de commission sur les transactions (qui s'appliqueraient sinon aux achats in-app).
Le principal bénéfice métier n'était toutefois pas technique. C'était la vitesse d'itération. Si un client écrivait « cette fonctionnalité m'aiderait », je m'y mettais généralement le jour même et je la livrais dans la semaine. C'est tout simplement impossible avec une application native.
À qui je recommande la PWA aujourd'hui
La PWA est un bon choix si au moins deux des points suivants sont réunis :
- Vous avez des ressources limitées et ne pouvez pas vous offrir deux applications natives en plus d'une version web.
- Vos utilisateurs se servent de l'application de manière occasionnelle (pas tous les jours), donc une friction minimale à la première ouverture compte.
- Votre application n'a pas besoin d'API système exigeantes (Bluetooth, NFC, accès complet au système de fichiers).
- Vous voulez déployer sans que les stores se mettent en travers.
- Votre public est mixte — iOS et Android, mobile et desktop.
La PWA n'est probablement pas le bon choix si :
- Votre application tourne quotidiennement, plusieurs heures par jour, et les utilisateurs s'en servent de façon intensive (réseaux sociaux, messagerie).
- Vous avez besoin d'intégrations système avancées.
- Vos acheteurs attendent une présence sur l'App Store.
- La performance est critique (jeu vidéo, vidéo, AR).
Conclusion
L'engouement autour de la PWA est peut-être retombé, mais la technologie a discrètement atteint un point où, pour de nombreux produits, c'est un meilleur choix que de partir sur du natif. Trefa.app est en PWA depuis un an et je ne vois aucune raison d'en changer. Au contraire — si je recommençais aujourd'hui, je foncerais encore plus vite.
Si vous hésitez entre la PWA et une application native pour votre projet, prenez en compte une chose au-delà des arguments techniques : la PWA vous amène en production plus vite. Et dans les premiers temps, la vitesse d'itération vaut plus que tout le reste.
Au passage, vous pouvez essayer trefa.app vous-même — pas d'installation, juste un clic et vous pronostiquez.