L'agent, client hypermédia

Branchez un modèle de langage sur votre système, et le réflexe est de lui tendre une liste d'outils. Sur l'axe des actions, ce réflexe rebâtit du RPC — juste après quatre volets passés à comprendre pourquoi on pouvait faire mieux.

La tentation, en intégrant un agent, est de lui exposer le système comme un catalogue d'outils nommés, chacun avec sa signature. C'est, pour ses actions, la forme du MCP — le Model Context Protocol, introduit par Anthropic en novembre 2024. Un outil nommé à signature, c'est une procédure qu'on appelle à distance : du RPC. Et l'on vient de voir, sur quatre volets, pourquoi REST le surpasse pour gouverner un système. Avant de trancher, il faut pourtant être juste — avec ce que MCP fait vraiment, et avec ce que « laisser l'agent parler au Web » coûte réellement.

Le modèle connaît déjà le Web

Car c'est le fait qui change tout : un modèle de langage connaît déjà le Web. HTTP, REST, l'hypermédia, les formulaires HTML, les liens, les codes de statut — il les a rencontrés des millions de fois à l'entraînement. Voilà un vrai geste agentique (à la différence de l'architecture elle-même, qui n'est que du bon génie logiciel) : s'appuyer sur les connaissances natives du modèle. Exposer les interfaces standards qu'il parle déjà, pour que le contrat soit la technologie standard elle-même, plutôt qu'un dialecte maison.

Concrètement : avec un catalogue d'outils, vous déclarez d'avance envoyer_email(destinataire, sujet, corps) — le modèle doit l'apprendre, et vous devez avoir prévu chaque besoin. En laissant l'agent écrire du code, ou une requête HTTP, contre l'API qu'il comprend déjà, il compose librement — boucles, conditions, appels chaînés — sans qu'on ait anticipé chaque combinaison sous forme d'outil. Le coût se voit aussi dans le contexte : chaque outil déclaré occupe de la place et dégrade la sélection dès qu'ils se multiplient — le catalogue obèse. Une petite surface générique vaut mieux qu'un gros catalogue sur mesure ; Anthropic elle-même défend désormais l'exécution de code contre la multiplication des appels d'outils.

Alors, quand le système expose déjà une surface REST propre, laissons l'agent en être un client hypermédia : il navigue la même surface qu'un humain, lit des réponses auto-descriptives, découvre les affordances dans les liens et les formulaires, les suit. La découverte tombe gratuitement — l'agent interroge un index et lit le catalogue comme un humain le parcourt, ouvre la page d'une ressource et reçoit son formulaire, c'est-à-dire son schéma d'entrée. Aucune API réservée à l'agent, aucun registre d'outils séparé à tenir synchrone.

Le déroulé est limpide : l'agent fait un GET sur l'index, lit la liste des ressources, ouvre celle qui l'intéresse, y trouve le schéma de son formulaire, puis envoie sa requête — la même séquence qu'un humain qui clique de page en page. À aucun moment il n'a fallu lui décrire l'API : elle se décrit elle-même, et il sait déjà la lire.

Ce que MCP fait vraiment

Reste à ne pas caricaturer l'adversaire — une thèse ne convainc que si elle survit à sa version honnête. MCP n'est pas qu'un sac d'outils RPC. Il a trois primitives : les outils (des actions, effectivement appelées comme des procédures), les ressources (des données en lecture, adressées par URI — soit, précisément, des ressources au sens REST) et les prompts. Sa surface n'est pas un contrat figé appris hors-bande une fois pour toutes : un client l'interroge à l'exécution (lister les outils, les ressources) et le serveur peut le notifier quand elle change. Ses outils portent un schéma d'entrée typé (du JSON Schema), et son cadre d'autorisation (OAuth 2.1, avec des jetons liés à un serveur précis) sait restreindre la portée d'un agent.

La vraie différence n'est donc pas « contrat figé contre découverte ». C'est qu'un catalogue d'outils offre une liste plate d'actions, là où l'hypermédia offre les transitions pertinentes à l'état courant : « payer » n'apparaît que tant que la commande ne l'est pas. Et le revers mérite la même franchise : laisser l'agent écrire des requêtes HTTP ou du code libre, c'est un bac à sable à tenir, une surface d'attaque à surveiller, du non-déterminisme à encadrer — et une clé d'appelant trop large peut déborder là où le périmètre par-serveur de MCP borne plus serré. « Petite surface générique » est un gain pour le contexte ; « surface explicitement bornée » en est un pour la gouvernance.

Ce que l'agent hérite de REST

Deux propriétés que l'agent ne réinvente pas — elles appartiennent à REST, l'agent en bénéficie seulement :

• L'identité est dans l'URL. L'information utile au calcul d'une requête vit dans le chemin, pas lue implicitement dans « qui est connecté ». Les requêtes de l'agent sont explicites, adressables, testables — une propriété REST, pas un privilège d'agent.
• Les requêtes sont auto-suffisantes. Chacune transporte son contexte ; l'agent ne s'appuie sur aucun état caché côté serveur.

S'y ajoute un principe, lui, proprement agentique : l'agent agit avec l'autorité de l'humain qui l'appelle, sans aucun passe-droit. Ce qu'un agent peut faire, un humain doit pouvoir le faire — par la même API. Encore faut-il restreindre la portée de la clé qu'on lui confie à ce dont il a besoin : hériter des droits de l'humain ne veut pas dire hériter de tous ses pouvoirs d'un coup. Et puisqu'il passe par cette même API, l'identité dans l'URL, chacune de ses actions reste attribuable à un humain : la traçabilité découle de REST, pas d'un journal d'agent spécial. L'agent est un utilisateur du système comme un autre, ni plus ni moins doté.

Ce modèle d'autorité a un corollaire économique : passant par les clés de l'appelant — les siennes, ou celles de l'organisation qui l'emploie —, l'agent consomme les fournisseurs et porte les coûts de cet utilisateur, pas ceux de la plateforme. Le même principe qui borne ses droits borne sa dépense.

Quand l'hypermédia, quand MCP

De quoi poser une grille, plutôt qu'un camp :

• Votre système expose déjà une surface REST propre, que vous contrôlez → exposez-la. Une couche d'outils par-dessus ne ferait que rajouter le RPC et ré-introduire côté client le couplage que REST avait déplacé (dans le type de média partagé), et dédoubler une surface qu'humains et agents pourraient partager.
• Des outils tiers hétérogènes que vous ne maîtrisez pas → MCP, pour sa découverte uniforme inter-fournisseurs : une fois qu'un modèle sait parler à un serveur, il sait parler à tous.
• Des capacités hors-HTTP (le système de fichiers local, un IDE, une base sans façade web) → là encore, le modèle connaît déjà l'interface : le shell, POSIX, SQL, git. Le bon réflexe reste de la lui tendre — l'exécution de commandes ou de code contre les outils qu'il parle déjà —, pas un outil ad hoc par geste. Un protocole d'outils ne se justifie que là où aucune interface standard n'existe.
• Un catalogue d'actions volontairement borné (domaine régulé, gestes irréversibles) → une surface d'outils explicite et revue peut clarifier ce qu'on offre, mais elle ne gouverne rien : ce qui interdit un geste, c'est le système d'autorisation, pas l'ignorance du modèle. Un agent, comme un humain, est arrêté par ses droits, pas par le fait d'ignorer qu'une action existe — et compter sur une surface fermée pour l'en empêcher, c'est l'inviter à la contourner : il découvre, compose, exploite ce qui est à sa portée pour agir au-delà de ce qu'on croyait lui avoir concédé. La borne est dans l'auth, jamais dans le catalogue.

Le fil ouvert au premier volet se referme ici. REST n'a jamais été « du JSON sur HTTP » : c'était l'architecture hypermédia du Web. On a laissé l'« API REST » le rétrécir au RPC ; le renouveau hypermédia le rouvre ; et l'agent — qui parle déjà le Web couramment — est le lecteur que cette architecture attendait. Pour un système qu'on contrôle et qui s'expose proprement, le meilleur contrat à offrir à un agent n'est pas un protocole neuf : c'est le plus ancien, mené correctement.