De la destination à la délégation

Pendant des décennies, le Web a d'abord été un espace de navigation directe. On s'y rendait en personne, on ouvrait des pages, on comparait des sources, on passait d'un onglet à l'autre et on assemblait des fragments d'information à la main. C'est notre routine quotidienne depuis les années 1990 ; je sais que ça l'a été pour moi.

Avec la généralisation de l'agent personnel, ce modèle décline vite.

De plus en plus, l'entrée dans le Web ne commencera pas par la navigation, mais par la délégation à un agent, qu'il s'appelle ChatGPT, Claude ou Gemini.

En mode délégué, on ne visite plus les sites pour rassembler de l'information ; on demande simplement à un agent de le faire à sa place. Le Web cesse d'être d'abord un lieu que l'on visite et devient un territoire que l'on traverse par procuration.

Le passage à la délégation peut sembler un petit changement de comportement, mais il est structurellement décisif. Dans le Web actuel, une grande part de la valeur d'un site tenait à sa capacité à attirer, retenir et convaincre les humains qui le visitaient. Dans un Web délégué, la valeur se déplace vers la capacité d'une source, d'un service ou d'une surface de connaissance à être lus, extraits, reliés, interprétés et recomposés par des agents.

La page vue perd son monopole d'événement économique, puisque consommer un contenu et le lire en tant qu'humain deviennent de plus en plus dissociables.

#Devenir agent-friendly

La délégation change la raison d'être d'une source, et donc les incitations. La monétisation cesse d'être liée uniquement au fait d'être vu et commence à dépendre du fait d'être sélectionné, jugé digne de confiance et intégré dans des chaînes d'action déléguée.

Éditeurs, plateformes, places de marché, institutions, marques et prestataires de services ont de bonnes raisons de se rendre agent-friendly. Les acteurs en place s'empressent d'exposer des couches lisibles par machine plus propres, de meilleures API, des flux structurés, des métadonnées plus riches, des manifestes de capacités et des surfaces opérationnelles plus rigoureuses.

Le mécanisme est déjà visible au sein de la recherche classique. Google propose désormais AI Overviews et AI Mode en plus de la recherche classique. Cela permet de poser une question à Google, c'est-à-dire aux millions de sites que Google a indexés. Google appelle ce mécanisme « query fan-out » : une question complexe est décomposée en plusieurs recherches connexes, sur des sous-thèmes et des sources de données. Le moteur assemble ensuite une réponse et y attache des liens vers les pages qui l'étayent. Un site peut donc être retenu pour une sous-question à l'intérieur d'une réponse sans être premier pour la phrase tapée dans la barre de recherche.

Imaginez quelqu'un qui cherche un vélo de trajet quotidien assez léger pour être monté à l'étage, fiable sous une forte pluie, disponible en France et réparable localement. La réponse peut s'appuyer sur une source pour le poids du cadre, une autre pour la protection contre la pluie, un détaillant pour le stock actuel et un réseau de réparateurs local pour l'entretien. Il n'existe pas de position unique dans un classement pour cette réponse. Il existe un champ de sources, chacune apportant une pièce de la décision.

Cela change ce que « visibilité » veut dire. Une marque peut être mentionnée sans être liée, ou une recommandation peut produire une vente sans générer de visite sur la page citée.

Pour les éditeurs, toutefois, l'enjeu est bien plus exigeant que l'ajout de quelques mots-clés.

Pour être agent-friendly, une source utile doit être exploitable par un agent. Elle doit dire ce qu'elle sait, dans quelles conditions, avec quelle date, quel périmètre et quelles preuves. La page d'un musée qui distingue clairement sa collection, son emplacement, ses fonds et ses conditions d'accès est plus utile sur le plan opérationnel qu'une page qui se contente de répéter une affirmation générale sur son importance culturelle. Un atelier de réparation qui publie les marques prises en charge, sa zone d'intervention, ses horaires d'ouverture et ses contraintes du moment donne à un agent une matière qu'il peut réellement utiliser.

#Des sites web opérables par les agents

Être lu n'est que la moitié du chemin. Quand un agent doit agir sur un site plutôt que simplement le lire, réserver une table, commander une pièce ou remplir un formulaire, il le fait encore comme le ferait une personne, mais sans yeux à lui : il inspecte la page, devine à quoi sert chaque champ et chaque bouton, clique, tape et vérifie ce qui s'est passé. La documentation de Google appelle cela l'actuation, et chacune de ces étapes est une occasion de se tromper. L'étape suivante, pour être Agent-Friendly, c'est un site qui dit à l'agent ce qu'il peut faire, au lieu de le lui laisser deviner.

C'est l'objet de WebMCP, un projet de standard du web porté par Google et Microsoft. Une page déclare elle-même ses outils, soit en annotant un formulaire HTML ordinaire, soit en enregistrant des actions en JavaScript, chacune avec ses paramètres et le résultat qu'elle renvoie. Un site de voyage peut exposer un outil qui cherche les vols disponibles et un autre qui en réserve un ; l'agent les appelle directement et reçoit des données structurées plutôt qu'un écran à interpréter. Pour l'agent qui tourne dans le navigateur, la page se comporte comme un petit serveur MCP, et le site garde la main sur ce qu'il propose et à quelles conditions.

WebMCP ne livre pas à l'agent l'interface du site pour qu'il la redessine à sa guise : les outils appartiennent au site, et l'agent ne peut que les appeler. Ce qui change, c'est pour qui l'interface travaille. Quand l'agent appelle un outil, la page se met à jour sous les yeux de la personne : une boutique de vêtements resserre son catalogue sur les robes demandées, un outil de design fait apparaître les mises en page qui correspondent, une page de revue de code affiche le correctif proposé sous forme de différences, sans rien valider tant que quelqu'un ne l'a pas accepté. L'interface devient un espace partagé entre la personne et son agent, où l'utilisateur voit, et peut corriger, ce qui se fait en son nom ; les auteurs de la proposition le disent explicitement, l'interface humaine reste première. Recomposer l'interface elle-même, une surface assemblée pour une personne au moment de l'usage, est une étape de plus, et l'objet du chapitre suivant.

Où en est-on (automne 2026)

Chrome a ouvert une avant-première de WebMCP en février 2026, derrière une option expérimentale de Chrome 146. À Google I/O, le 19 mai 2026, Google l'a fait passer en phase d'essai publique (origin trial) de Chrome 149 à Chrome 156 : n'importe quel site peut l'activer pour ses vrais visiteurs sans leur demander de modifier un réglage. Une sortie générale est prévue pour Chrome 157. Le projet de spécification est incubé ouvertement au sein de la communauté Web Machine Learning du W3C. Ses limites sont celles du navigateur : un onglet doit être ouvert, ce qui exclut les agents sans interface, et un agent ne découvre ce qu'un site propose qu'en le visitant, ce qui laisse la question de la découvrabilité là où la retrouve le reste de ce livre.

Sources : Chrome for Developers, documentation WebMCP, 18 mai 2026 ; Chromium, Intent to Experiment: WebMCP, 15 mai 2026.

L’autre voie va dans le sens inverse : au lieu de s’adapter aux agents venus de l’extérieur, le site fournit le sien. Un agent intégré répond à l’intérieur du site ou de l’appli, avec un accès privilégié au catalogue, au compte et à l’historique des commandes, comme Rufus répond aux clients à l’intérieur d’Amazon. Il garde le client chez soi, mais c’est aussi une forme primitive de ce que cette partie appellera plus loin une présence : une entreprise qui, plutôt que d’être parcourue, répond elle-même. À mesure que les agents de passage se multiplient, les deux se rencontrent, et l’agent intégré finit par parler à d’autres agents autant qu’à des personnes.