La révolution des PWA
Installation, notifications et accès hors connexion : voyez ce qu’une PWA peut apporter à votre projet et les limites à tester avant de choisir.
Sur cette page4 sections
Retrouver le mail, cliquer sur le lien, rouvrir le site, chercher l'espace client. Pour une visite occasionnelle, ça passe. Pour un service qu'on utilise régulièrement sur son téléphone, on comprend vite pourquoi quelqu'un finit par demander « vous n'avez pas une application ? ».
Une PWA, pour Progressive Web App, peut répondre à une partie de cette envie. On reste sur un service web, mais on peut lui donner un accès plus proche d'une application, notamment avec une icône sur l'écran d'accueil et une fenêtre dédiée sur les appareils compatibles.
Ce qui me plaît dans cette approche, c'est qu'on peut partir du service qui existe déjà, au lieu de considérer que la demande d'une icône nous oblige à reconstruire tout le projet.
L'installation ne se présente pas de la même manière partout : les appareils et les navigateurs ont leurs propres possibilités. La documentation MDN détaille ces différences. On teste donc le parcours sur les téléphones concernés, plutôt que préparer une seule capture et supposer que tout le monde verra la même chose.
Et on soigne l'espace client lui-même. Ajouter une icône à un formulaire pénible ne le rend pas soudain agréable à utiliser. Il faut encore que les boutons soient accessibles et que la personne retrouve ce qu'elle vient faire.
Pour une réservation, la différence est facile à voir. Relire une confirmation déjà reçue sans réseau peut être pratique. Réserver une nouvelle place demande de connaître la disponibilité actuelle ; le téléphone ne peut pas la deviner depuis les informations de la veille.
On peut aussi permettre de préparer une demande hors ligne et de l'envoyer plus tard. Mais l'écran doit dire ce qui se passe. « Demande en attente d'envoi » et « réservation confirmée » ne doivent pas se ressembler, sinon le client arrive persuadé qu'on l'attend alors que personne n'a reçu sa demande.
Il faut de toute façon que la personne les accepte et que son environnement les prenne en charge. Sur iPhone et iPad, WebKit a introduit le Web Push pour les applications web ajoutées à l'écran d'accueil à partir de la version 16.4. Visiter une page dans le navigateur ne revient donc pas automatiquement à installer une application qui pourra vous notifier.
Pour une information importante, on garde un autre moyen de prévenir le client si cette possibilité manque. Le service doit rester compréhensible même pour quelqu'un qui n'a pas envie de tout autoriser sur son téléphone.
Pour choisir, j'aime partir d'un geste fréquent : consulter son dossier, suivre une demande, retrouver une réservation. On le fait fonctionner correctement et on voit si l'approche répond à l'usage. Si une fonction exige une intégration au téléphone que le web couvre mal, on étudie une application native. Ce passage éventuel demande du travail ; ce n'est pas un bouton à activer.
Si vos clients vous demandent une application, on peut regarder ensemble ce qui leur manque vraiment. Parfois, une PWA bien pensée suffira. Parfois non. Mais on aura commencé par leur faciliter la vie, plutôt que par choisir dans quel store on veut apparaître.
Une PWA, pour Progressive Web App, peut répondre à une partie de cette envie. On reste sur un service web, mais on peut lui donner un accès plus proche d'une application, notamment avec une icône sur l'écran d'accueil et une fenêtre dédiée sur les appareils compatibles.
Ce qui me plaît dans cette approche, c'est qu'on peut partir du service qui existe déjà, au lieu de considérer que la demande d'une icône nous oblige à reconstruire tout le projet.
Le même service avec une entrée plus directe
Imaginez un espace dans lequel vos clients suivent leurs réservations. S'ils y reviennent souvent, l'avoir à portée de doigt peut leur éviter de rechercher le lien à chaque fois. Le raccourci a un intérêt très concret, même si le fonctionnement reste celui d'un service web.L'installation ne se présente pas de la même manière partout : les appareils et les navigateurs ont leurs propres possibilités. La documentation MDN détaille ces différences. On teste donc le parcours sur les téléphones concernés, plutôt que préparer une seule capture et supposer que tout le monde verra la même chose.
Et on soigne l'espace client lui-même. Ajouter une icône à un formulaire pénible ne le rend pas soudain agréable à utiliser. Il faut encore que les boutons soient accessibles et que la personne retrouve ce qu'elle vient faire.
Dans le train la page peut rester mais pas le réseau
Le mode hors connexion est souvent présenté comme une propriété magique des PWA. En réalité, il se prépare : on décide ce qu'on garde sur l'appareil et ce qui a besoin de joindre le serveur. Les service workers et le cache permettent de construire ce fonctionnement.Pour une réservation, la différence est facile à voir. Relire une confirmation déjà reçue sans réseau peut être pratique. Réserver une nouvelle place demande de connaître la disponibilité actuelle ; le téléphone ne peut pas la deviner depuis les informations de la veille.
On peut aussi permettre de préparer une demande hors ligne et de l'envoyer plus tard. Mais l'écran doit dire ce qui se passe. « Demande en attente d'envoi » et « réservation confirmée » ne doivent pas se ressembler, sinon le client arrive persuadé qu'on l'attend alors que personne n'a reçu sa demande.
Une notification utile vaut mieux que dix invitations à revenir
Être prévenu qu'une demande a été acceptée, c'est utile. Recevoir un message simplement parce qu'on n'a pas ouvert le service depuis trois jours, personnellement, ça me donne surtout envie de couper les notifications.Il faut de toute façon que la personne les accepte et que son environnement les prenne en charge. Sur iPhone et iPad, WebKit a introduit le Web Push pour les applications web ajoutées à l'écran d'accueil à partir de la version 16.4. Visiter une page dans le navigateur ne revient donc pas automatiquement à installer une application qui pourra vous notifier.
Pour une information importante, on garde un autre moyen de prévenir le client si cette possibilité manque. Le service doit rester compréhensible même pour quelqu'un qui n'a pas envie de tout autoriser sur son téléphone.
Commencer par ce que les gens vont vraiment utiliser
Une PWA peut permettre de travailler sur une base web commune plutôt que multiplier immédiatement les interfaces. Ça peut simplifier un projet, mais il reste des écrans à adapter, des appareils à tester et un fonctionnement à entretenir. L'accès par un store est encore un autre chantier, avec ses règles et ses validations.Pour choisir, j'aime partir d'un geste fréquent : consulter son dossier, suivre une demande, retrouver une réservation. On le fait fonctionner correctement et on voit si l'approche répond à l'usage. Si une fonction exige une intégration au téléphone que le web couvre mal, on étudie une application native. Ce passage éventuel demande du travail ; ce n'est pas un bouton à activer.
Si vos clients vous demandent une application, on peut regarder ensemble ce qui leur manque vraiment. Parfois, une PWA bien pensée suffira. Parfois non. Mais on aura commencé par leur faciliter la vie, plutôt que par choisir dans quel store on veut apparaître.
