Choisir une PWA : guide pratique sans idées reçues
Une PWA (application web progressive) est une application construite avec les technologies du web (HTML, CSS, JavaScript) qui offre des fonctionnalités avancées comme l'installation sur l'écran d'accueil, l'accès hors-ligne partiel ou les notifications push. Mais elle ne remplace pas systématiquement une application native : ses capacités varient selon le navigateur, le système d'exploitation et l'état d'installation. Ce guide vous aide à évaluer objectivement si une PWA convient à votre projet.
Ce qu'est réellement une PWA
Pour préparer une PWA, vous utilisez un manifeste web qui décrit notamment le nom, les icônes et le mode d'affichage souhaité. Vous pouvez aussi prévoir un service worker pour gérer certaines requêtes et ressources en cache. Le service worker n'est pas obligatoire pour l'installation. Ne confondez donc pas « installable » et « utilisable hors connexion » : votre équipe doit définir et tester séparément ces deux comportements. Consultez la présentation des PWA par MDN pour cette distinction.
Contrairement à une idée répandue, une PWA n'est pas nécessairement une single-page app (SPA). Elle peut être construite avec n'importe quelle architecture web. L'important est d'adopter l'amélioration progressive : détecter les fonctionnalités supportées et prévoir des solutions de repli. Par exemple, si l'API Background Sync n'est pas disponible, l'application doit informer l'utilisateur que l'envoi d'un message a échoué et lui permettre de réessayer manuellement.
Limites connues des PWA, en particulier sur iOS
Les PWA ne donnent pas accès à toutes les capacités d'une application native. Voici les principaux points de vigilance.
Installation et mises à jour
Vérifiez le parcours d'installation sur chaque combinaison d'appareil, de navigateur et de version retenue. Les commandes et les possibilités d'installation diffèrent ; ne rédigez pas une aide universelle à partir d'un seul téléphone.
Votre équipe doit également gérer les mises à jour du code et du service worker lorsqu'elle en utilise un. Une nouvelle version peut attendre avant de prendre la main. Testez ce qui se passe avec plusieurs fenêtres ouvertes et avec un formulaire non envoyé. Prévoyez une consigne claire lorsque vous demandez de recharger, sans supprimer les données encore en attente.
Accès aux fonctionnalités matérielles
Listez précisément ce que la personne doit faire : prendre une photo, joindre un fichier, obtenir sa position ou communiquer avec un périphérique particulier. Pour chaque besoin essentiel, votre équipe doit vérifier la documentation officielle du navigateur et essayer le parcours sur les appareils cibles. Ne remplacez pas cette vérification par une affirmation générale sur « l'accès au matériel ».
Prévoyez également le refus d'une permission. Si la personne refuse l'appareil photo, peut-elle joindre un fichier existant ? Si aucune solution de repli ne répond au besoin, vous devez revoir le périmètre ou la solution technique.
Notifications push
Les notifications push pour les applications web sont disponibles sur iOS/iPadOS 16.4 et versions ultérieures, mais uniquement lorsque l'application est ajoutée à l'écran d'accueil WebKit. L'utilisateur doit donner sa permission après une interaction directe. Donc, sur un iPhone récent, une PWA installée peut recevoir des notifications push, mais le comportement exact dépend de la version du système, du navigateur et de l'état d'installation. Testez sur vos appareils cibles.
Données hors-ligne et conflits d'écriture
Le stockage local (IndexedDB, Cache API) permet de conserver des données hors-ligne, mais il faut gérer les conflits d'écriture lorsque l'utilisateur modifie des données sur plusieurs appareils ou lorsque la connexion est rétablie. Sans synchronisation robuste, des données peuvent être perdues. Par exemple, un formulaire hors-ligne enregistré localement peut être écrasé par une version plus récente du serveur si l'on applique naïvement la règle « le plus récent gagne ». Définissez une règle de résolution adaptée au métier. Pour un formulaire dont les deux versions contiennent des informations importantes, prévoyez une comparaison et un choix explicite plutôt qu'un écrasement silencieux.
Matrice de décision : évaluez les besoins, pas les architectures
Choisissez entre PWA et application native à partir des opérations indispensables, des appareils cibles et des résultats de votre prototype. Chaque projet a des besoins spécifiques. Utilisez cette matrice pour clarifier ce qui est essentiel et ce qui est optionnel, puis prouvez que la solution choisie fonctionne sur les appareils réels.
| Critère | Question à se poser | PWA à prototyper ? |
|---|---|---|
| Installation | L'utilisateur doit-il pouvoir installer l'application sur son écran d'accueil ? | Oui, via le manifeste, mais vérifiez le processus sur chaque navigateur cible. |
| Hors-ligne | L'application doit-elle fonctionner sans connexion réseau ? | Oui, si vous implémentez un service worker et un stockage local, avec gestion des conflits. |
| Notifications push | Les notifications sont-elles critiques pour l'engagement ? | Possible sur Android et sur iOS 16.4+ si l'app est installée. Testez sur vos cibles. |
| Accès matériel | Quel périphérique et quelle opération sont indispensables ? | Testez l'API requise sur chaque navigateur cible et documentez la solution de repli. |
| Distribution | Faut-il accéder au produit par lien, par un store ou par les deux ? | L'accès par URL est possible. Une distribution via un store constitue un travail distinct, avec les conditions de la plateforme à vérifier. |
| Données sensibles | L'application manipule-t-elle des données critiques hors-ligne ? | Possible, mais exige une conception prudente (chiffrement, synchronisation). |
| Mises à jour | Les utilisateurs doivent-ils toujours avoir la dernière version ? | Les mises à jour des PWA peuvent être différées ; prévoyez une stratégie. |
Mode d'emploi :
- Pour chaque critère, indiquez si la capacité est Essentielle, Optionnelle ou Non nécessaire.
- Si une capacité essentielle n'est pas supportée de manière fiable par une PWA sur un de vos appareils cibles, envisagez une autre solution (native, hybride) ou revoyez le périmètre.
- Ne concluez pas à partir d'un simple comptage de colonnes : un seul critère bloquant peut disqualifier la PWA, même si tous les autres sont favorables.
Exemple concret : formulaire de saisie sur le terrain
Contexte fictif : une entreprise de maintenance envoie des techniciens chez des clients pour remplir des formulaires d'intervention (numéro de série, photos, signature). Les techniciens travaillent parfois dans des zones sans réseau. L'équipe envisage une PWA.
Étape 1 : Analyse des besoins avec la matrice
| Capacité | Essentielle ? | Support PWA probable ? | Preuve nécessaire |
|---|---|---|---|
| Installation sur l'écran d'accueil | Oui | À vérifier pour les navigateurs et versions retenus | Tester sur les modèles de téléphones des techniciens |
| Saisie hors-ligne | Oui | Oui avec service worker et IndexedDB | Tester en mode avion |
| Synchronisation des formulaires | Oui | Possible mais nécessite une conception spécifique | Tester la reconnexion et les conflits |
| Appareil photo | Oui | Capture ou ajout de fichier à prototyper | Tester sur iOS et Android |
| Notifications push | Non | - | - |
| Distribution via store | Non (lien web interne) | - | - |
Étape 2 : Décision La PWA semble faisable, mais le point critique est la synchronisation hors-ligne. L'équipe décide de réaliser un prototype et de tester la synchronisation avant de retenir une PWA.
Étape 3 : Conception de la synchronisation Chaque formulaire local reçoit un identifiant unique stable (par exemple un UUID généré côté client). L'état du formulaire est suivi explicitement :
saved_locally: enregistré sur l'appareil, pas encore envoyé au serveur.sending: en cours d'envoi.server_acknowledged: le serveur a confirmé la réception. Lors de l'envoi, le client envoie l'identifiant et les données. Le serveur doit être idempotent : si le même identifiant est reçu deux fois (par exemple à cause d'une nouvelle tentative après une perte de connexion), il ne crée pas de doublon mais répond avec un accusé de réception. Si un conflit survient (par exemple le même formulaire a été modifié sur deux appareils différents), l'application n'écrase pas automatiquement la version plus récente. Elle présente les deux versions à l'utilisateur et lui demande de choisir ou de fusionner. Conservez les deux versions jusqu'à la résolution et testez les erreurs possibles pendant ce choix. Le simple affichage d'un conflit ne garantit pas la conservation des données.
Scénario de test : Un technicien remplit un formulaire en mode avion. L'application l'enregistre localement avec l'état saved_locally. À son retour au bureau, il se reconnecte. L'application tente l'envoi. Si le serveur répond, l'état passe à server_acknowledged. Si la connexion échoue, l'état reste saved_locally et l'application réessaie plus tard. En cas de mise à jour du code pendant qu'un formulaire est en attente, l'application doit préserver les données locales et les renvoyer après la mise à jour.
Cet exemple définit ce que le prototype doit démontrer. Il ne prouve pas encore la faisabilité sur les appareils de cette entreprise : l'équipe devra obtenir ces résultats avant de retenir la PWA.
Checklist de validation avant de vous engager
Avant de décider, testez ces points sur les appareils réels de vos utilisateurs (pas seulement sur un simulateur).
- Installation : Sur chaque navigateur cible, vérifiez que le manifeste est correct et que l'installation fonctionne. Notez les différences (bannière Android, menu Partager iOS).
- HTTPS : Le site doit être servi en HTTPS. Pour la production, vérifiez le contexte sécurisé requis par les fonctionnalités utilisées ; ne confondez pas un essai de développement local avec un déploiement public.
- Fonctionnalités matérielles : Testez chaque API nécessaire (caméra, GPS, etc.) sur tous les appareils. Si une API n'est pas supportée, affichez un message clair et proposez une alternative.
- Hors-ligne :
- Chargez l'application, puis coupez le réseau : l'application se charge-t-elle ?
- Remplissez un formulaire hors-ligne, fermez l'application, rouvrez-la : les données sont-elles toujours là ?
- Reconnectez-vous : les données sont-elles envoyées ? Y a-t-il des doublons ?
- Conflits : Simulez deux appareils modifiant le même enregistrement hors-ligne, puis synchronisez. L'application présente-t-elle le conflit à l'utilisateur au lieu d'écraser silencieusement ?
- Mise à jour avec données en attente : Ayez un formulaire non envoyé, déployez une nouvelle version du code, ouvrez l'application. Les données sont-elles préservées et renvoyées ?
- Permissions : Refusez les permissions (notifications, caméra) et vérifiez le comportement. L'application reste-t-elle utilisable ?
- Stockage : Testez le comportement si le stockage local est presque plein ou purgé par le navigateur. Prévoyez des avertissements et des sauvegardes.
- Partage d'appareil : Si plusieurs utilisateurs partagent un appareil, testez la déconnexion et la connexion d'un autre compte. Les données locales sont-elles cloisonnées ?
Décidez à partir du parcours testé
Une PWA peut être une excellente solution pour de nombreux projets, à condition de connaître ses limites et de les tester précisément. Ne vous fiez pas aux promesses générales : vérifiez chaque capacité sur les appareils de vos utilisateurs. Si un besoin essentiel n'est pas satisfait de manière fiable, explorez d'autres options.
Si vous avez besoin d'un accompagnement pour évaluer votre cas ou développer une PWA adaptée à vos contraintes, Doved Studio peut vous aider à clarifier votre parcours utilisateur et à définir une architecture réaliste. Apportez un exemple de parcours utilisateur et la liste de vos appareils cibles pour démarrer une discussion concrète.
