Pourquoi une PWA plutôt qu'une application native

Porter une expérience « application » au-delà du navigateur n'est pas une question technique isolée : c'est un arbitrage entre portée, coût, maintenance et accès aux capacités de l'appareil. Cette page raconte comment cette décision a été prise pour Telaria : quelles options ont été étudiées, quels compromis chacune imposait, et pourquoi la PWA a été retenue.

Ce n'est pas un tutoriel ni une recette. Pour le quoi et le comment de la PWA elle-même (manifeste, service worker, stratégies de cache), voir la référence dédiée : ../reference/pwa.md. Ici, on s'intéresse au raisonnement de décision.

Le problème à résoudre

L'expérience de base est déjà une application web. La question posée était : faut-il aller plus loin, et si oui, comment offrir une expérience « installée » avec un accès hors ligne, sans reconstruire ce qui existe ?

Cinq besoins ont structuré l'analyse :

• Accès hors ligne — consulter le contenu sans réseau fiable.
• Installation — lancer depuis une icône, comme une application.
• Qualité perçue — fluidité, rapidité, stabilité.
• Coût et délai — l'effort de développement et de maintenance dans la durée.
• Distribution — web ouvert, stores mobiles, ou déploiement interne.

Un besoin transverse traverse tous les scénarios : ne pas régresser sur l'accessibilité ni le référencement acquis côté web. Ce point a été traité comme une contrainte, pas comme une variable d'ajustement.

Le panorama des options

Cinq approches couvrent l'espace des solutions. Elles ne s'opposent pas frontalement : elles occupent des points différents sur le même axe coût / richesse d'expérience.

Applications natives (une par plateforme)

Deux bases de code distinctes, construites avec les outils officiels de chaque plateforme mobile.

• Ce qu'on gagne : l'expérience la plus fluide, l'accès le plus complet aux capacités de l'appareil (notifications, capteurs), un hors-ligne robuste.
• Ce qu'on paie : deux applications à développer et à maintenir en parallèle, des délais plus longs, et un cycle de publication en store contraignant. Le coût de possession est le plus élevé du panorama.

Cross-platform natif (une base pour plusieurs plateformes)

Une seule base de code qui se déploie sur plusieurs plateformes mobiles, avec un rendu proche du natif.

• Ce qu'on gagne : une bonne part de la richesse mobile pour un coût inférieur à deux applications séparées.
• Ce qu'on paie : une courbe d'apprentissage propre à l'outillage mobile, une refonte partielle de l'existant web, et une dépendance à un écosystème de modules tiers pour les fonctions natives.

Hybride WebView (le web encapsulé)

L'application web existante est enveloppée dans une coque mobile publiable en store.

• Ce qu'on gagne : une réutilisation maximale de l'existant, une présence en store sans tout réécrire, un effort de développement réduit.
• Ce qu'on paie : une performance variable selon les appareils, un hors-ligne fragile si le cache est mal maîtrisé, une dépendance à des modules externes. L'expérience peut sembler moins fluide qu'attendu.

Desktop wrapper (le web en application de bureau)

L'application web est empaquetée en application de bureau installable multi-systèmes.

• Ce qu'on gagne : un usage confortable et stable sur poste de travail, un hors-ligne fiable, une intégration possible avec des fichiers locaux.
• Ce qu'on paie : des applications lourdes, un cycle de publication et de signature dédié, un support multi-systèmes à organiser dans la durée.

PWA (Progressive Web App)

L'application web elle-même devient installable et fonctionne hors ligne, via des mécanismes standard du navigateur.

• Ce qu'on gagne : l'installation et le hors-ligne sans quitter le web, une seule base de code, un déploiement inchangé, aucune dépendance à un store.
• Ce qu'on paie : un stockage local limité (surtout sur mobile), un accès aux capacités de l'appareil plus restreint que le natif, et la nécessité de gérer soigneusement la fraîcheur du cache pour ne pas servir de contenu obsolète.

Lire le compromis : un seul axe, plusieurs curseurs

Les cinq options se rangent sur un continuum. À une extrémité, le web pur (coût minimal, capacités natives minimales). À l'autre, le natif dédié (capacités maximales, coût maximal). Les autres approches sont des points intermédiaires : le cross-platform rapproche du natif à coût moindre, l'hybride et le desktop wrapper réutilisent le web en le déplaçant vers un autre canal de distribution.

Le point clé de lecture : la richesse native ne se justifie que par un besoin d'usage réel. Payer le coût du natif pour des fonctions qu'aucun usage ne réclame, c'est acheter de la capacité inemployée et une dette de maintenance.

Pourquoi la PWA a été retenue

La décision découle d'une confrontation entre les besoins prioritaires et les compromis de chaque option, pas d'une préférence pour une technologie.

1. L'objectif dominant est l'accès rapide au contenu, pas l'exploitation du matériel. Les fonctions qui justifieraient le natif (capteurs, intégrations système avancées) ne correspondaient à aucun besoin d'usage établi. Sans ce besoin, le surcoût du natif ou du cross-platform n'était pas justifiable.

2. La PWA couvre les deux besoins réellement prioritaires — installation et hors-ligne — avec les mécanismes standard du navigateur, sans store ni seconde base de code.

3. Elle ne remet pas en cause l'architecture existante. Contrairement à l'hybride ou au cross-platform, aucune refonte n'est nécessaire : la PWA augmente l'application web au lieu de la déplacer. C'est le compromis le plus économe en risque.

4. Elle préserve la contrainte transverse. Rester dans le web signifie conserver l'accessibilité et le référencement acquis — là où une bascule vers un canal store les remettrait partiellement en jeu. La qualité était une contrainte non négociable ; la PWA est la seule option qui la garantit sans effort supplémentaire.

En résumé : la PWA maximise la valeur d'usage pour un coût et un risque maîtrisés, en réutilisant l'existant plutôt qu'en le reconstruisant.

Ce que la décision n'affirme pas

Retenir la PWA n'est pas déclarer les autres options mauvaises. C'est un arbitrage contextuel et daté, pas une vérité générale. La décision resterait à réexaminer si le contexte d'usage changeait :

• Le natif ou le cross-platform deviendraient pertinents si l'usage mobile passait au premier plan et réclamait des fonctions avancées de l'appareil.
• Le desktop wrapper deviendrait pertinent pour un usage bureau intensif en environnement sans réseau fiable.
• L'hybride resterait un candidat si une présence en store devenait nécessaire à budget contraint, en acceptant une expérience moins fluide.

Ces options ont été évaluées et documentées, puis écartées pour la V1 — pas ignorées. C'est précisément ce qui rend la décision solide : elle peut être rejouée avec de nouvelles hypothèses sans repartir de zéro.

À retenir

Le choix multiplateforme se résout en confrontant des besoins hiérarchisés à un axe coût / richesse native. Pour Telaria, les besoins prioritaires — accès rapide, installation, hors-ligne, préservation de la qualité web — sont tous satisfaits par la PWA, sans le coût des approches natives ni la refonte des approches hybrides. La bonne décision d'ingénierie n'est pas la plus riche techniquement : c'est celle qui répond aux besoins réels au meilleur rapport valeur / coût / risque, et qui reste réversible quand le contexte évolue.