Résumé

  • Le premier projet public du W3C, en décembre 2013, rassemblait dans un fichier JSON lié au site son nom, ses icônes et l’adresse souhaitée pour son lancement.
  • Le projet de travail d’octobre 2026 précise le nom court, l’URL de départ, le périmètre de navigation, le mode d’affichage et une identité stable; le navigateur interprète ces informations dans sa propre interface.

Dans un onglet, un site sait déjà se faire appeler par son titre. Il possède souvent une petite icône. Sur l’écran d’accueil d’un téléphone, ces fragments ne composent pas forcément une présentation cohérente. Quel nom tient sous le carré? Quelle image reconnaîtra le lecteur demain? Quelle page doit s’ouvrir quand il touche ce carré? Voilà des questions de concierge; elles deviennent des questions d’architecture quand des milliers de sites demandent une clé.

Un navigateur aime lire les pages et leurs ressources tôt. Un éditeur, lui, souhaite que l’apparence de son service reste reconnaissable d’un contexte à l’autre. Mettre ces décisions dans un seul document relié au HTML évitait de disperser noms, images et adresses dans plusieurs mécanismes. Le site pouvait remettre une fiche claire à l’agent utilisateur, comme un nouveau locataire qui arrive avec son nom et son numéro d’appartement correctement écrits.

Le premier projet public du W3C, daté du 17 décembre 2013, portait le titre Manifest for web apps and bookmarks. Il proposait un fichier JSON central pour les métadonnées d’une application web et un lien HTML rel="manifest" pour l’associer à la page. Son résumé citait le nom, les icônes et l’URL de lancement souhaitée. Ses exemples imaginaient l’ajout d’un site à l’écran d’accueil et une icône visible parmi les logiciels de l’appareil. Une page commençait à fournir une carte de visite utilisable par une machine.

Cette première carte avait ses propres mots. L’exemple de 2013 employait name, url, mode: standalone et icons. Le vocabulaire a changé au fil du travail, mais l’intention ressort nettement de la page ancienne: identifier le site hors de l’onglet et proposer une porte d’entrée. Le W3C publiait alors un projet ouvert. La valeur historique du texte tient à la simplicité du problème qu’il mettait sur le bureau du navigateur.

Le projet de travail du 16 octobre 2026 présente une fiche plus complète. Le manifeste peut contenir name et short_name, des icônes, start_url, scope, display, ainsi qu’un id. Les deux noms répondent aux espaces différents d’une interface. L’icône aide le lecteur à retrouver le service. start_url indique l’endroit où le site préférerait commencer. scope dessine les limites de l’expérience. display exprime la présentation souhaitée. Le id sert à reconnaître l’application indépendamment de sa porte de départ.

La différence entre nom et nom court est presque comique dans sa modestie. Un titre majestueux entre dans une page « À propos »; sous une icône, il déborde. Le manifeste permet de fournir une forme adaptée à l’espace disponible. Les icônes suivent le même raisonnement: elles donnent au navigateur des ressources choisies par l’éditeur, que celui-ci devra maintenir lorsque son identité visuelle évoluera. Une enseigne qui dit une chose et un pictogramme qui en dit une autre demandera au lecteur de faire le travail à leur place.

start_url est une préférence de lancement. Le projet de 2026 laisse à l’agent utilisateur la possibilité de la traiter autrement ou de laisser le lecteur modifier l’adresse. Le site peut écrire « entrez par ici » sur sa fiche; la gestion de l’entrée appartient à l’interface qui accueille le lecteur. L’existence d’un id distinct rend cette séparation pratique: la page de départ peut changer au cours de la vie d’un service tandis que son identité reste reconnaissable.

scope trace une frontière de navigation. Il décrit les URL qui appartiennent au contexte de l’application. Quand un lien conduit au-delà, le navigateur peut marquer ce changement dans sa façon de présenter la destination. Cette frontière oblige aussi une équipe à répondre à une question concrète: où finit le service lancé par son icône? Un domaine entier peut héberger une aide, une boutique, un forum et un compte; les mettre tous dans la même chambre est une décision à prendre, pas une fatalité.

Le champ display exprime un mode d’affichage préféré, parmi des possibilités que l’agent utilisateur gère selon son environnement. Il relie la fiche de l’éditeur à la présentation que le lecteur verra réellement. Le manifeste fournit des préférences lisibles et une identité suivie; le navigateur choisit son interface, et le lecteur choisit sa place sur l’écran d’accueil lorsque cette possibilité lui est offerte.

L’historique officiel des publications du W3C relie le premier projet de décembre 2013 au projet d’octobre 2026. La longue suite de versions montre le soin apporté à des champs qui paraissent minuscules. Le nom, l’icône et la porte d’entrée sont de petites choses jusqu’au jour où un site change l’un des trois sans prévenir ceux qui l’avaient installé.

Le manifeste a donc une fonction très terre à terre. Il évite au navigateur de deviner comment présenter le site au moment où celui-ci sort de l’onglet. Le site arrive avec ses papiers. Le lecteur peut reconnaître le visiteur et décider s’il lui donne une case chez lui.