Notifications de navigateur : prévenir sans solliciter à chaque visite

Un client revient dans son espace pour consulter une réponse. Dès l’ouverture, une fenêtre lui demande d’autoriser les notifications, avant même qu’il sache ce qu’il recevra. Il ferme la demande. À la visite suivante, le site insiste avec un nouveau bandeau.

Une notification peut pourtant rendre service : signaler une réponse attendue ou un document disponible, sans obliger la personne à surveiller une page. Pour une PME, la bonne question est donc précise : quel événement mérite d’interrompre le client, et comment lui laisser la main ? Voici une méthode de conception, illustrée par des situations fictives.

Partir d’un événement utile

Avant de choisir un outil d’envoi, écrivez la promesse de chaque notification. « Être prévenu quand une réponse arrive dans mon dossier » est compréhensible. « Rester informé » laisse trop de questions ouvertes.

Pour chaque cas, notez le destinataire, l’événement déclencheur, l’action attendue et la durée pendant laquelle le message reste pertinent. Une réponse à une demande et une nouvelle offre commerciale devraient avoir des réglages distincts. Le bouton choisi par le client doit décrire ce qu’il active réellement.

Commencez par un seul usage. Vous pourrez vérifier si le parcours est utile sans créer immédiatement une série de sollicitations. Une notification qui ne mène à aucune action peut souvent être remplacée par une information visible lors de la prochaine connexion.

Expliquer avant de demander la permission

Les notifications système s’affichent en dehors de la page web. Leur affichage nécessite une permission de l’utilisateur. MDN recommande de déclencher cette demande après une action explicite, comme un clic sur un bouton, plutôt qu’au chargement du site. Guide MDN sur les notifications.

Dans l’espace client, proposez par exemple « M’avertir des nouvelles réponses », accompagné d’une phrase expliquant le contenu envoyé. Le clic peut alors déclencher la demande du navigateur. Évitez les fausses fenêtres imitant cette demande ou les textes qui présentent le refus comme une erreur.

La documentation distingue trois états : permission accordée, refusée, ou décision inconnue. Dans ce dernier cas, l’application doit se comporter comme si l’affichage n’était pas autorisé. La fonction de demande s’utilise dans un contexte sécurisé, généralement HTTPS, et sa disponibilité varie selon les navigateurs. Référence MDN sur requestPermission.

Prévoyez donc une interface pour chaque situation. Après un refus, gardez l’accès au dossier et laissez une rubrique de réglages disponible. Une invitation fermée ne doit pas devenir une relance à chaque page. Si une modification des permissions du navigateur est nécessaire, expliquez-la seulement lorsque la personne cherche à réactiver les notifications.

Prévoir le fonctionnement lorsque la page est fermée

Afficher une notification depuis une page et recevoir un événement envoyé par le serveur sont deux étapes techniques. Pour le second besoin, la Push API permet de recevoir des messages même lorsque l’application web n’est pas au premier plan ou chargée. Elle repose sur un service worker, un composant du navigateur qui peut traiter ces événements, et sur un abonnement push. Documentation MDN de la Push API.

Demandez une démonstration sur les appareils réellement utilisés. Un essai dans un seul navigateur de bureau ne valide pas le parcours mobile. Les conditions d’installation, les permissions et les réglages du système doivent être vérifiés pour chaque environnement retenu.

Dans le cahier des charges, séparez les états « autorisé dans le navigateur », « abonnement enregistré » et « notifications activées pour ce type d’événement ». Afficher un bouton vert dès la première étape peut faire croire que tout le circuit fonctionne alors que l’enregistrement côté serveur a échoué.

L’adresse technique de l’abonnement doit aussi être protégée. MDN la décrit comme une URL donnant une capacité d’accès, à garder secrète. Elle n’a pas sa place dans une page publique ou un journal librement consultable.

Garder le dossier comme point de référence

Le protocole Web Push prévoit une durée de conservation des messages, appelée TTL. Le service peut retenir un message moins longtemps que demandé, et ne doit plus tenter de le livrer après son expiration. Cette durée concerne la livraison du message, pas la suppression d’une notification déjà affichée. RFC 8030, section 5.2.

Choisissez cette durée selon l’événement. Un créneau proposé qui n’est plus disponible ne devrait pas produire une invitation trompeuse plusieurs jours plus tard. Au clic, ouvrez le dossier et affichez son état actuel, même si celui-ci a changé depuis l’envoi.

Nous recommandons de conserver les informations importantes dans l’espace client. Le client doit pouvoir les retrouver sans avoir reçu ou ouvert l’alerte. Pour une démarche essentielle, définissez séparément le canal de suivi et la règle d’escalade nécessaires. Un compteur de notifications envoyées ne prouve pas que les personnes ont lu leur contenu.

Limitez aussi le texte affiché en dehors de l’application. Une formule comme « Une réponse est disponible dans votre espace » peut suffire. Les détails du dossier restent derrière la connexion et les contrôles d’accès. Un clic sur l’alerte ne doit pas dispenser de vérifier quel compte est connecté.

Donner une sortie aussi claire que l’entrée

Prévoyez des réglages accessibles depuis le compte : catégories activées, appareil concerné si votre application le gère, et moyen de désactiver les envois. Après une désactivation dans l’application, le serveur doit respecter ce choix, même si le navigateur conserve sa permission technique.

Testez également la déconnexion et le changement de compte sur un ordinateur partagé. L’abonnement ne doit pas continuer à recevoir les informations d’un ancien utilisateur parce qu’il a été associé au navigateur une fois pour toutes. Définissez avec votre prestataire quand cette association est retirée ou renouvelée.

Évitez de mesurer uniquement le nombre d’autorisations obtenues. Examinez surtout les problèmes rencontrés : sollicitations répétées, messages inutiles, lien qui ouvre le mauvais dossier ou réglage de désactivation difficile à retrouver.

La recette à demander avant lancement

Avec des comptes et des événements de test, vérifiez les parcours suivants :

• première visite sans demande de permission automatique ;
• activation volontaire, puis réception d’un événement prévu ;
• refus ou fermeture de la demande, sans relance insistante ;
• navigateur non compatible, avec accès normal au dossier ;
• page fermée, appareil momentanément hors ligne, puis retour ;
• clic sur un ancien message dont le dossier a changé ;
• désactivation, déconnexion et changement de compte ;
• consultation au clavier des explications et des réglages.

Pour chaque essai, comparez le choix enregistré, le message réellement reçu et la page ouverte. Le résultat attendu est simple : une personne comprend ce qu’elle active, retrouve l’information même sans alerte et peut arrêter les sollicitations sans perdre l’accès au service.