Construire pour le hors-ligne : pourquoi les Progressive Web Apps comptent encore

En décembre dernier, je faisais une démo de l'application web d'un client à des investisseurs potentiels lors d'une conférence à Lomé. Le WiFi de la salle a plié sous la charge de 300 participants, et ma belle SPA a affiché un écran blanc et un spinner qui aurait tourné jusqu'à la mort thermique de l'univers.

L'investisseur a souri poliment et est passé au stand suivant.

Cet échec de dix secondes — causé par rien de plus exotique qu'un réseau WiFi congestionné — a coûté à mon client une conversation qui aurait pu valoir six chiffres. Et c'était complètement évitable.

Le mythe de la connectivité

Les développeurs dans des villes bien connectées conçoivent pour un internet permanent. C'est une hypothèse inconsciente intégrée dans chaque appel fetch().

Mais la réalité est plus rude :

• 1,4 milliard de personnes ont des connexions mobiles plus lentes que 2 Mbps
• Même dans les centres urbains, la connectivité mobile chute régulièrement
• La connexion mobile moyenne mondiale connaît 15-20 % de perte de paquets aux heures de pointe
• L'Afrique et l'Asie du Sud ont les connectivités les plus variables

Ce qu'une PWA fait réellement

Une Progressive Web App n'est pas un framework ou une bibliothèque. C'est un ensemble de capacités :

Service Workers — Un fichier JavaScript qui agit comme proxy réseau programmable. Il intercepte chaque requête réseau et décide comment la gérer : servir depuis le cache, récupérer depuis le réseau, ou retourner un fallback.

Manifeste d'application web — Un fichier JSON qui dit au navigateur comment votre app devrait se comporter quand installée.

HTTPS — Requis pour les service workers. Non optionnel.

Ces trois ingrédients produisent une app qui :

• Charge instantanément lors des visites répétées
• Fonctionne sans connexion internet
• Peut être installée sur l'écran d'accueil
• Envoie des notifications push (quand supporté)

Stratégies de cache pour différents contenus

Shell de l'application (Cache-First)

Navigation, layout, CSS, JavaScript et polices changent rarement. Cachez-les agressivement.

Articles de blog (Stale-While-Revalidate)

Servez la version en cache immédiatement pour un chargement instantané, mais récupérez une copie fraîche en arrière-plan. La prochaine visite obtient la version mise à jour. Le meilleur des deux mondes.

Données API (Network-First)

Les données spécifiques à l'utilisateur essaient d'abord le réseau. Fallback au cache quand hors ligne.

Images (Cache-First avec limite de taille)

Cachez les images agressivement mais fixez une limite de stockage.

Patterns UX hors-ligne

Communiquez l'état clairement

Quand l'utilisateur est hors-ligne, dites-le — mais sans être dramatique. Un bandeau subtil disant « Vous êtes hors-ligne — contenu sauvegardé affiché » est plus utile que bloquer tout l'écran.

Mettez les actions en file d'attente

Si un utilisateur essaie de soumettre un formulaire hors-ligne — ne montrez pas d'erreur. Mettez l'action en file d'attente dans IndexedDB et synchronisez quand la connectivité revient.

Pré-cachez intelligemment

Si un utilisateur lit l'article #3, il voudra probablement l'article #4 ensuite. Pré-chargez-le pendant qu'il lit encore.

Pourquoi les PWA plutôt que le natif

L'économie n'est même pas comparable pour la plupart des applications business :

Le principal écart restant est iOS, où Apple a historiquement limité les capacités PWA. Mais même ça s'améliore — iOS 16.4 a ajouté les notifications push pour les PWA installées.

Quand les PWA ne suffisent pas

• Calcul intensif : Jeux, montage vidéo, rendu 3D — le natif est encore plus fort.
• Intégration OS profonde : Widgets, assistants vocaux, données de santé.
• Produits consommateurs iOS-first : L'App Store reste le canal de découverte principal.

Pour tout le reste — tableaux de bord, plateformes de contenu, e-commerce, outils SaaS, apps d'entreprise internes — une PWA bien construite offre une excellente expérience à une fraction du coût.

Commencer

Si vous construisez avec Next.js :

1. Créez un public/manifest.json avec les métadonnées de votre app
2. Enregistrez un service worker dans votre layout racine
3. Implémentez des stratégies de cache appropriées
4. Ajoutez une page de fallback hors-ligne
5. Testez sur un vrai appareil en mode avion

L'investissement est de 2-3 jours de développement. Le retour est une application qui fonctionne partout où vont vos utilisateurs — y compris les endroits où internet ne va pas.

Dans un monde qui construit pour la fibre gigabit, construire pour l'absence totale de connectivité est peut-être la chose la plus avant-gardiste que vous puissiez faire.