Le retour de l'hypermédia — et la couche vue comme moteur

Le remède au REST du pauvre n'est pas une invention récente : c'est la plus vieille idée du Web, qui revient. Et elle a un domicile qu'on regardait sans le voir — la couche vue.

Pendant une décennie, le client riche a gagné. Le serveur s'est réduit à un robinet de JSON — un niveau 2 honnête — pendant que la logique et l'état de l'application migraient dans un client JavaScript étroitement couplé à cette API. La contrainte hypermédia n'a pas été affaiblie : elle a été abandonnée en bloc, et l'évolutivité avec elle. Chaque changement de serveur exigeait un client redéployé, et toute application se traînait deux modèles de données à tenir d'accord.

L'hypermédia revient par le HTML

Un contre-mouvement a pris forme. Le mouvement htmx (né d'intercooler.js en 2013, stabilisé en 2020) et le livre Hypermedia Systems (2023) remettent au centre les applications pilotées par l'hypermédia : le serveur renvoie du HTML — de l'hypermédia — plutôt que des données, et pilote l'interface par ce qu'il envoie. HATEOAS rentre alors chez lui, dans le HTML, où les liens et les formulaires sont les affordances, nativement, sans qu'on ait à les réinventer.

Concrètement, htmx étend le HTML de quelques attributs qui disent : « à tel événement, va chercher tel fragment et remplace telle partie de la page ». Le serveur ne renvoie plus du JSON à recoller côté client, mais des morceaux de page prêts à l'emploi. On obtient l'interactivité d'une application monopage — rien ne recharge entièrement — avec le modèle mental, bien plus simple, d'une application multi-pages. Le comportement reste lisible dans le balisage, à l'endroit où il agit, au lieu d'être éparpillé dans un code client.

L'intérêt n'est pas nostalgique. Le couplage tombe parce qu'il n'y a plus qu'une seule source de vérité — le HTML que produit le serveur — au lieu de deux à tenir synchrones. Le navigateur redevient le client générique du deuxième volet ; le serveur reprend la main sur les transitions. Honnêtement, ce n'est pas une réponse universelle : une application très interactive — édition hors-ligne, temps réel, dessin sur toile — a de bonnes raisons de garder un client riche. Autre limite à nommer : une application hypermédia ne fournit pas, à elle seule, d'API programmatique pour des tiers — sa sortie, c'est du HTML pour des humains. Si l'on a aussi besoin d'un accès machine, on l'expose — et la négociation de contenu permet justement à la même ressource de servir l'un et l'autre.

Le mouvement dépasse d'ailleurs htmx. Le même livre décrit Hyperview, qui porte le modèle aux applications natives mobiles : le serveur y envoie une représentation hypermédia que le client natif rend — preuve que la contrainte tient hors du navigateur. Côté Web, les composants serveur (les React Server Components, par exemple) traduisent la même bascule : rapatrier vers le serveur ce que la SPA avait emporté. Au passage, le rendu serveur sert le premier affichage et le référencement, là où une application monopage doit d'abord télécharger et exécuter son client avant de rien montrer.

La couche vue comme moteur

Ce renouveau redonne son vrai rôle à une couche qu'on croyait connaître. La couche vue, c'est la part du serveur qui traduit l'état du domaine en ce que reçoit le client — du HTML pour un navigateur, du JSON pour un programme (rien à voir avec la « vue » d'un framework front comme React, qui vit, elle, dans le client). Sa responsabilité n'est pas de « produire un joli HTML » : c'est de transformer l'état du domaine en hypermédia. Au niveau du principe, cela tient en quelques gestes, qui valent bien au-delà d'une implémentation particulière :

• Elle expose les transitions possibles comme des liens (porteurs d'un rel, le rôle du lien) et les actions possibles comme des formulaires — en HTML comme en JSON.
• Un formulaire n'est pas un écran figé dans un client : c'est la projection d'un contrat d'entrée — un schéma que le serveur publie. Qui le reçoit, humain ou programme, sait quoi remplir et comment soumettre. Et il porte sa propre méthode : le formulaire déclare le verbe de l'action qu'il amorce — POST pour une création, PUT pour une édition, DELETE pour une suppression. On récupère ce formulaire par un GET sur son URL d'étape, puis on le soumet à ce verbe terminal : l'affordance dit elle-même comment l'actionner.
• La même ressource se sert en HTML ou en JSON, depuis un seul contrat — la négociation de contenu, le mécanisme de l'en-tête Accept vu au deuxième volet : la discipline hypermédia n'est pas liée au HTML, une représentation JSON peut porter ses liens, elle aussi.
• L'état reste hors du serveur : l'identité utile à une requête vit dans l'URL, pas dans une session cachée. Une même URL veut alors dire la même chose pour tout le monde — c'est le principe stateless du premier volet.

Le tout dessine un triptyque régulier : un catalogue cherchable, puis la page propre d'une ressource qui vous tend son formulaire d'amorçage, puis son exécution sans état. On ne quitte jamais la surface pour aller lire une documentation externe : la page vous remet l'affordance, et l'on découvre le système en le parcourant, de lien en formulaire.

Rien là-dedans n'est une « fonctionnalité pour agents ». C'est de la bonne architecture, antérieure à l'agentique : du REST mené à son niveau 3, à l'endroit où le Web l'avait toujours placé — la vue. Mais une surface qui tend à chaque visiteur ses propres affordances a un lecteur idéal, et pas seulement humain. C'est l'objet du dernier volet.