Résumé

  • Une règle de remplacement autorise la disparition d’informations en attente. Sa validité dépend du travail à accomplir, pas seulement de l’égalité entre deux étiquettes.
  • Web Push remplace aussi la durée de conservation, l’urgence et la demande d’accusé de réception associées au message. Une ancienne tentative de livraison peut pourtant avoir déjà commencé.
  • Le gain doit se mesurer après la reprise d’activité de l’utilisateur : état retrouvé, obligations encore visibles et effort de reconstitution, autant que messages évités.

Dans une réunion consacrée aux coûts d’exploitation, supprimer les notifications devenues inutiles paraît difficile à contester. Un téléphone revient en ligne ; pourquoi lui envoyer les six états successifs d’un dossier si le septième décrit correctement la situation ? Le débat technique peut alors se réduire au choix d’une étiquette commune et d’une durée de conservation.

Il manque pourtant quelqu’un autour de la table : la personne capable d’affirmer que ces six états ne portent aucune obligation encore valable. L’équipe de livraison sait les faire disparaître de sa file. Elle ne sait pas nécessairement si l’un d’eux demandait une validation distincte, signalait une action déjà engagée ou constituait la seule trace accessible d’un changement.

Ce scénario est une illustration, non le récit d’un incident. Il situe le véritable objet de la décision. Le remplacement n’est pas un défaut du transport. C’est une capacité utile qui suppose que l’application ait défini, en amont, ce qu’un message peut représenter à la place d’un autre.

Une économie qui suppose une équivalence

La RFC 8030, publiée en décembre 2016, décrit le mécanisme Web Push. Pour un même abonnement, un nouveau message peut remplacer un message encore en attente portant la même valeur de Topic. Le service crée une nouvelle ressource de message et supprime simultanément l’ancienne ressource correspondante. L’étiquette établit une corrélation ; elle ne tranche pas le sens du contenu.

Cette limitation est raisonnable. Un service de distribution n’a pas à connaître les règles de chaque application. Il peut reconnaître une valeur identique sans comprendre les dossiers, les personnes ou les engagements auxquels le message fait référence. L’application conserve ainsi la maîtrise de son vocabulaire métier.

Mais une égalité facile à calculer ne constitue pas une équivalence fonctionnelle. Deux changements concernant le même dossier peuvent être substituables pour afficher son état actuel et indispensables l’un comme l’autre pour exécuter des tâches distinctes. La bonne unité dépend de ce que le destinataire doit savoir ou faire.

Prenons une application de suivi interne. Une notification peut présenter la liste complète des actions encore ouvertes. Une autre peut simplement annoncer qu’une action supplémentaire vient d’être attribuée. Remplacer une ancienne liste exhaustive par une liste réellement à jour peut préserver l’information utile. Remplacer une attribution par la suivante peut faire disparaître une obligation de l’interface si aucun autre chemin ne la restitue. Le nom du dossier, identique dans les deux cas, ne résout rien.

Une troisième conception consiste à demander au destinataire de consulter l’état de référence. Plusieurs changements peuvent alors justifier un seul appel à cette consultation. L’économie provient du fait qu’un autre système conserve et restitue ce que le message n’emporte pas. Elle ne provient pas d’une propriété miraculeuse de la notification.

Il faut donc examiner la disponibilité de cette autre source, les droits d’accès au retour de l’utilisateur et la capacité à retrouver ce que sa tâche exige. Un écran affichant uniquement la situation présente peut être suffisant pour reprendre une lecture. Il peut être insuffisant si le travail nécessite de comprendre une transition intermédiaire. Conserver des données ne signifie pas encore les rendre utilisables au moment pertinent.

L’étiquette est une délégation précise

Choisir un Topic trop large revient à autoriser des remplacements entre changements qui n’ont peut-être rien de substituable. Choisir une valeur nouvelle pour chaque occurrence neutralise, à l’inverse, l’intérêt du regroupement. Entre les deux se trouve une politique de produit : quels messages, sur cet abonnement, peuvent tenir lieu les uns des autres ?

La RFC limite la valeur à trente-deux caractères de l’alphabet Base64 adapté aux URL et aux noms de fichiers ; une valeur invalide appelle une réponse 400. Ce cadre syntaxique permet de contrôler un en-tête. Il ne peut pas certifier que le groupe choisi correspond à une unité de travail cohérente.

Le problème devient plus délicat lorsque plusieurs producteurs utilisent la même convention. Une équipe peut interpréter l’étiquette comme le dossier entier ; une autre comme son résumé ; une troisième comme la dernière tâche attribuée. Chacune peut envoyer un message valide, et l’ensemble appliquer une règle que personne n’a réellement décidée. Ce risque est une conséquence analytique du partage d’une clé de corrélation, pas une défaillance observée chez un fournisseur.

La responsabilité devrait donc porter sur la définition commune et sur ses exceptions, non seulement sur la bibliothèque qui écrit l’en-tête. Quand le contenu passe d’une description complète à une modification partielle, une règle auparavant acceptable peut cesser de l’être sans que le format du Topic change.

Le chiffrement n’apporte pas cette compréhension manquante. La RFC 8291 protège le contenu Web Push de bout en bout, mais laisse les en-têtes HTTP hors de cette protection du contenu. Le destinataire doit les considérer comme provenant du service push. TLS demeure obligatoire pour le transport : il ne s’agit pas de prétendre que les tiers extérieurs peuvent lire librement ces échanges.

Cette séparation a deux implications pratiques. Le service n’a pas à lire le texte chiffré pour constater une correspondance. Et l’application ne devrait pas traiter un en-tête de livraison comme la preuve authentifiée de sa propre intention métier. Les identifiants et versions nécessaires à l’interprétation peuvent relever du contenu protégé ou de l’état de référence.

Elle invite également à ne pas donner à l’étiquette un nom inutilement révélateur. Faciliter un diagnostic peut exposer au service une information sur les activités corrélées. Ce choix mérite une appréciation explicite, sans transformer toute corrélation en menace ni confondre confidentialité du contenu et invisibilité des métadonnées.

Ce qui remplace le message remplace aussi son régime de livraison

L’ancienne ressource ne conserve pas ses paramètres comme une enveloppe autour du nouveau texte. La RFC prévoit également le remplacement de sa durée de vie, de son urgence et de l’abonnement aux accusés de réception. L’opération porte donc sur un ensemble, pas sur une simple correction éditoriale.

Un producteur peut envoyer une description plus récente avec une durée plus courte. Un autre peut utiliser une urgence plus faible par défaut. Si ces messages appartiennent au même groupe de remplacement, l’amélioration apparente de l’actualité du texte s’accompagne d’un changement de ses conditions d’attente et de livraison.

Une baisse d’urgence peut être justifiée : la situation a pu se normaliser. Elle peut aussi refléter une divergence de configuration entre producteurs. Pour le destinataire qui filtre les messages selon leur urgence, cette différence importe. Comparer uniquement deux contenus ne permet pas de distinguer les deux cas.

La durée demandée ne constitue pas davantage une réservation absolue de stockage. Le service peut la réduire ; aucune nouvelle tentative de livraison ne doit commencer après son expiration. Le temps de transit n’est pas entièrement couvert par ce calcul. La spécification prévoit aussi qu’un message accepté puisse expirer plus tôt pour des raisons opérationnelles, avec un signal d’échec lorsqu’un accusé a été demandé.

L’application doit donc déterminer ce qui reste faisable au retour du destinataire, plutôt que déduire d’une durée configurée une garantie générale de récupération. Une politique qui ne fonctionne qu’à condition que chaque notification survive jusqu’au prochain passage de l’utilisateur demande une justification que l’en-tête, seul, ne fournit pas.

La file ne gouverne ni le passé ni l’écran

Le remplacement a une portée temporelle limitée. Une tentative de livraison de l’ancien message peut déjà avoir eu lieu. La RFC envisage un accusé qui arrive après le remplacement et recommande de supprimer les accusés destinés à l’émetteur pour le message supprimé. L’absence d’un tel retour ne démontre donc pas que l’ancien contenu n’a jamais atteint son destinataire.

Il serait particulièrement trompeur d’en déduire une fonction de retrait. Si le premier message a provoqué une action, supprimer sa ressource d’attente ne l’annule pas. Retrait d’une instruction, compensation d’un effet ou rejet d’une version obsolète demandent une logique propre à l’application.

Même le mot « récent » requiert une définition. Un producteur retardé peut envoyer après un autre une description plus ancienne du travail. Une corrélation identique ne permet pas au service de comparer les versions métier contenues dans les messages. L’ordre d’arrivée et l’ordre des changements ne deviennent pas identiques par convention de nommage.

L’affichage constitue encore un autre espace. Le standard Notifications de WHATWG décrit un remplacement fondé sur un tag non vide identique et une même origine, avec un traitement qui dépend des capacités de remplacement de la plateforme. Ce n’est pas le Topic de la file : la RFC impose de ne pas transmettre ce dernier à l’agent utilisateur.

L’application peut coordonner ses choix de file et d’affichage, mais elle doit construire cette coordination. Un seul élément visible peut représenter un résumé de plusieurs actions ouvertes ; il ne prouve pas que ces actions ont cessé d’exister. À l’inverse, conserver plusieurs notifications à l’écran ne garantit pas que leur contenu est encore actuel.

Le Working Draft Push API de W3C daté du 1er décembre 2025 distingue notamment la réception ordinaire par service worker et un parcours de notification déclarative. Son algorithme prévoit aussi des accusés dans certaines situations d’échec, dont un déchiffrement infructueux ou des échecs répétés de traitement. Un accusé technique n’est donc pas une mesure d’accomplissement de la tâche.

Ce texte est un projet de spécification ; aucune généralisation sur son déploiement dans tous les navigateurs n’est établie ici. L’analyse ne repose ni sur une campagne d’interopérabilité ni sur un incident mesuré. Elle repose sur les opérations distinctes que les textes permettent de décrire.

La sobriété se juge après la reprise

La section 7.4 de la RFC 8030 met en balance l’efficacité radio et les coûts de retransmission, d’interrogation et de resynchronisation. L’exemple des compteurs de messages non lus, rapidement dépassés, montre pourquoi conserver toutes les valeurs intermédiaires peut être inutile. La spécification n’impose pas pour autant un journal exhaustif à toute application.

Le bon résultat peut parfaitement être une notification unique, un état courant suffisant et aucune reconstitution supplémentaire. Il peut aussi exiger que les événements importants soient conservés ailleurs, tout en limitant ce qui interrompt l’utilisateur. La conservation et l’affichage ne sont pas obligés de suivre la même granularité.

Le mauvais critère consiste à s’arrêter au nombre de messages évités. Il ignore le temps passé à rechercher une tâche disparue, à interpréter un ancien état arrivé tard ou à consulter manuellement une application devenue peu fiable aux yeux de son utilisateur. Ces coûts possibles doivent être étudiés, non présentés comme des pertes déjà constatées.

Décider qu’une information peut disparaître exige finalement une phrase assez précise pour être mise à l’épreuve : après ce remplacement, voici ce que le destinataire pourra encore connaître et accomplir. La file exécute la règle. La qualité de cette phrase appartient à l’organisation qui conçoit le travail.