Transformer son site en application installable : le guide PWA avec un exemple

Installation, ouverture sans réseau, données en attente et mises à jour : une PWA doit prévoir ces situations séparément. Un cas de carnet de visite permet de comprendre ce qu’il faut demander et vérifier.

Transformer un site en application installable peut éviter de demander à chaque utilisateur de retrouver un lien. La solution web couramment utilisée s’appelle une PWA, pour application web progressive. Elle peut apparaître parmi les applications du téléphone. Mais l’installation et le fonctionnement sans connexion sont deux travaux distincts.

Nous suivons ici le carnet fictif de Nora : une liste de visites et une note à conserver pour chacune. L’objectif n’est pas de rendre tout le service utilisable sans réseau dès le premier jour. Il est de définir exactement ce que la personne peut consulter, écrire et retrouver lorsque la connexion disparaît. La ressource finale fournit les essais à réaliser sur votre propre projet.

Vérifier que l’installation résout un vrai problème

Une PWA est intéressante si l’utilisateur revient souvent et gagne à retrouver rapidement le service. Pour un devis consulté une seule fois, un lien peut suffire. Avant d’ajouter une proposition d’installation, rendez le parcours web utilisable sur un petit écran. Un site difficile à lire reste difficile à lire quand il possède une icône.

Dans le carnet de Nora, les bénévoles ouvrent leur liste plusieurs fois par semaine. Une installation peut donc simplifier leur accès. En revanche, afficher une invitation dès la première seconde, avant qu’ils sachent à quoi sert le carnet, crée une décision supplémentaire. Placez plutôt l’explication après une première consultation utile.

Écrivez le bénéfice en langage courant : « Retrouvez vos visites depuis l’écran d’accueil. » Évitez de demander aux personnes de comprendre le mot PWA. Les modalités d’installation varient selon l’appareil et le navigateur ; les conditions présentées par MDN servent à préparer des instructions adaptées.

Distinguer l’icône, les écrans et les données

Trois couches entrent en jeu. Le manifeste décrit notamment l’identité et l’ouverture de l’application. Les fichiers de l’interface permettent d’afficher les écrans. Les données sont les visites, notes ou documents propres à votre utilisateur. Avoir préparé l’une de ces couches ne prouve pas que les deux autres fonctionnent hors ligne.

Demandez une description explicite : « Que verra une personne qui ouvre pour la première fois sans réseau ? Et une personne qui a déjà consulté ses visites ? » Dans le premier cas, aucune copie utile n’est forcément disponible. Dans le second, une version conservée sur le téléphone peut l’être, si ce comportement a été développé.

Pour le premier périmètre de Nora, la liste déjà consultée peut rester visible avec sa date de mise à jour. Une note non envoyée porte l’état « Sur ce téléphone, en attente d’envoi ». Le statut « Partagée avec l’équipe » apparaît seulement après confirmation du service. Ces libellés évitent de confondre présence à l’écran et disponibilité pour les autres.

Pour comprendre · illustration du guide

Construire une première version avec un périmètre réduit

Commencez par une page adaptée au téléphone, servie en HTTPS en production. Demandez à l’assistant de préparer le manifeste, les icônes appropriées et une ouverture cohérente. Vérifiez que l’utilisateur revient au bon endroit depuis l’icône et que les liens extérieurs ne rendent pas la navigation incompréhensible.

Ajoutez ensuite un écran de repli en cas de perte de connexion. Il peut simplement expliquer que les nouvelles informations ne sont pas disponibles et permettre de réessayer. Ce premier comportement honnête est préférable à une page blanche ou à une vieille liste présentée comme actuelle. Le guide Microsoft de transformation d’un site en PWA aide à identifier les éléments techniques.

Enfin, choisissez une seule donnée à conserver pour l’usage hors ligne. Dans notre exemple, il s’agit du brouillon d’une note associée à une visite déjà chargée. Limiter la première version facilite la compréhension des conflits : vous ne tentez pas encore de réconcilier tout le planning, des fichiers et des changements de comptes en même temps.

Décider ce qui peut être conservé sur l’appareil

Un carnet de visites ne devrait pas télécharger silencieusement tout l’historique de l’association sur chaque téléphone. Sélectionnez ce qui est utile pour la tournée autorisée. Précisez une durée, un moyen de supprimer les copies et le comportement après déconnexion. Un téléphone partagé rend ce dernier point particulièrement important.

Le stockage de l’interface et celui des données privées demandent des règles distinctes. Demandez à la personne qui construit le service de vérifier qu’un cache ne sert pas le dossier du compte précédent au suivant. Les stratégies de cache décrites par MDN sont des outils de développement, pas une autorisation de tout conserver.

Rédigez votre règle sous une forme observable : « Après déconnexion du compte A, le compte B ne peut lire aucune note de A, même sans réseau. » Si cette règle ne peut pas être démontrée sur les appareils cibles, réduisez le périmètre hors ligne. Le confort d’accès ne doit pas rendre le partage des données invisible.

Prévoir le retour de la connexion

Une note peut avoir été modifiée sur le téléphone pendant qu’un collègue changeait la même visite au bureau. Choisissez la règle de résolution avant de demander une synchronisation automatique. Vous pouvez conserver les deux versions, demander un arbitrage ou limiter ce qui reste modifiable hors ligne. Le silence est le mauvais choix : il masque une possible perte de travail.

Pour Nora, chaque note possède une référence stable. Une nouvelle tentative d’envoi de la même note ne doit pas produire deux comptes rendus. Le téléphone attend un accusé de réception et conserve son état en attente tant qu’il ne l’a pas obtenu. Si l’accès au dossier a été retiré entre-temps, l’interface explique le refus au lieu de boucler indéfiniment.

Ne comptez pas uniquement sur une opération en arrière-plan. Ses possibilités varient selon l’environnement. Prévoyez une reprise lorsque l’application redevient active, ainsi qu’un bouton d’envoi manuel si nécessaire. MDN explique le fonctionnement hors ligne et en arrière-plan ; votre recette doit porter sur les téléphones effectivement utilisés.

Éprouver les situations qui cassent une démonstration

Préparez une version d’essai avec des visites inventées. Notez l’appareil, son système, le navigateur et la version de l’application. Rejouez chaque scénario sans vous contenter du message vert à l’écran. Pour vérifier une transmission, ouvrez également le dossier depuis un second appareil connecté et autorisé.

• Première visite sans chargement préalable et sans réseau : le navigateur peut seulement signaler l’absence de connexion ; aucun écran de repli de l’application n’est encore garanti.
• Réouverture hors ligne après initialisation de l’interface et de son cache : le message de repli prévu apparaît, sans présenter une ancienne donnée comme actuelle.
• Visite chargée puis mode avion : la copie accessible porte une date de fraîcheur.
• Note écrite hors ligne puis fermeture : le brouillon revient si ce comportement fait partie du périmètre annoncé.
• Retour du réseau puis deux nouvelles tentatives : une seule note apparaît dans le dossier distant.
• Modification concurrente : la règle de conflit est appliquée et le travail écarté reste explicable.
• Déconnexion puis autre compte : les dossiers privés du premier compte restent inaccessibles.

Ces vérifications sont un protocole proposé, pas des résultats déjà obtenus sur votre application. Consignez ce que vous observez et les limites restantes. Si une donnée disparaît, gardez les étapes exactes : ordre des clics, coupure du réseau, fermeture et réouverture. Ce récit permet à l’assistant de travailler sur un défaut reproductible.

Livrer les mises à jour sans perdre les brouillons

Une PWA peut conserver des fichiers anciens. Lors d’une nouvelle livraison, l’utilisateur peut encore avoir une page ouverte avec une version précédente. Demandez ce qui se passe si la mise à jour intervient pendant la rédaction d’une note. Une actualisation imposée au mauvais moment peut annuler le bénéfice du mode hors ligne.

Une approche raisonnable consiste à signaler la mise à jour et à l’appliquer à un moment où le travail est enregistré. Si le format des données locales change, prévoyez leur reprise. Le numéro de version affiché dans une petite page d’aide simplifie les échanges lorsqu’un utilisateur décrit un écran différent du vôtre.

Préparez également la sortie : comment récupérer une note restée en attente et comment supprimer les copies locales ? Une fonction d’export de brouillon, lorsqu’elle est appropriée, peut aider à résoudre un incident. Elle doit respecter les mêmes droits d’accès que le reste du carnet.

Le brief à transmettre pour votre propre PWA

La fiche PWA : installation, hors ligne et reprise contient le périmètre du carnet, les états attendus et un tableau d’essais sous forme de fiche texte. Ouvrez-la, remplacez les exemples puis demandez une livraison étape par étape : installation, écran de repli, brouillon local, envoi et mise à jour.

Vous pouvez décrire ces règles dans Maestro pour préparer le travail du projet. Gardez une distinction claire entre l’application de création sur votre ordinateur et l’application web que vous construisez pour vos utilisateurs. Le format PWA, ses services et sa publication restent des choix à réaliser et à vérifier pour ce projet précis.