À première vue, WebMCP ressemble à une API de plus dans la longue liste des technologies qui apparaissent autour des agents IA. Son objectif est assez concret : permettre à un site web de déclarer explicitement les actions qu’un agent peut accomplir sur ses pages.
Un site pourrait par exemple exposer des outils permettant de rechercher un produit, filtrer des résultats, remplir une demande ou choisir une date. Au lieu d’observer une interface conçue pour un humain, d’identifier les boutons puis de simuler des clics, l’agent reçoit une description structurée de ce qu’il peut faire.
C’est ainsi que Google présente WebMCP dans la documentation de Chrome consacrée au projet : le site déclare l’objectif de certaines fonctions et fournit à l’agent les informations nécessaires pour les utiliser correctement. WebMCP permet aussi de transmettre l’état courant de la page et de décrire les entrées et sorties des outils avec des schémas structurés.
Le gain immédiat est technique. L’automatisation devient moins dépendante de l’interprétation visuelle d’une page et donc potentiellement plus fiable.
Mais WebMCP pose surtout une question stratégique.
Pourquoi Google travaille-t-il à rendre les sites plus faciles à utiliser par des agents en général, alors qu’il pourrait se contenter d’améliorer Gemini pour qu’il navigue mieux que ses concurrents ?
Une réponse possible est que la compétition pour construire le meilleur agent ne représente qu’une partie du pari de Google. WebMCP suggère une stratégie plus large : construire suffisamment de l’environnement dont les agents auront besoin pour que Google reste incontournable, quel que soit l’agent utilisé.
Le Web n’a pas été conçu pour les agents
Le Web que nous utilisons repose encore largement sur une convention ancienne : les applications présentent une interface à un humain, et l’humain comprend comment agir.
Un bouton « Réserver » n’est pas seulement un élément technique. Sa couleur, sa position, le texte qui l’accompagne et l’écran dans lequel il apparaît permettent à l’utilisateur de comprendre sa fonction.
Les agents capables d’utiliser un ordinateur ont longtemps dû reproduire ce raisonnement.
Ils examinent une page, interprètent ses éléments, choisissent une action, cliquent, puis observent le résultat avant de décider de l’étape suivante. Chaque étape ajoute une possibilité d’erreur.
WebMCP introduit une autre logique.
Le site peut déclarer directement : voici un outil permettant de réserver, voici les paramètres qu’il accepte, voici le contexte dans lequel il peut être utilisé.
La différence paraît modeste, mais elle change la relation entre le Web et les machines.
Le Web actuel expose principalement une interface à l’utilisateur :
site → interface → humain
WebMCP ajoute une autre couche :
site → capacités structurées → agent
Google précise d’ailleurs que son objectif est de créer des API que « n’importe quel navigateur doté de capacités agentiques » pourrait implémenter. WebMCP est encore une proposition expérimentale, disponible via un Origin Trial dans Chrome, et sa spécification continue d’évoluer.
Il ne faut donc pas confondre une direction technique avec un standard déjà adopté.
Mais la direction est claire : le Web commence à être pensé non seulement comme quelque chose que les agents doivent comprendre, mais comme quelque chose qui peut leur expliquer directement comment agir.
L’explication évidente : Google veut construire le meilleur agent
La première lecture de la stratégie de Google est la plus simple.
L’entreprise dispose de Gemini. Elle l’intègre à ses produits. Chrome dispose désormais de fonctions capables de résumer des pages, travailler sur plusieurs sources et automatiser certaines tâches.
En août 2026, Google a par exemple étendu sur Android les capacités d’ »auto browse » de Gemini in Chrome aux abonnés AI Pro et Ultra aux États-Unis. Google cite des tâches comme réserver une place de parking, modifier une commande récurrente ou organiser un voyage. Certaines actions sensibles demandent une confirmation de l’utilisateur.
À Google I/O 2026, Sundar Pichai a également présenté Gemini Spark, un agent personnel intégré à Gemini. Spark fonctionne sur des machines virtuelles dans Google Cloud, peut exécuter des tâches en arrière-plan et doit progressivement se connecter à des outils tiers via MCP. Google a aussi annoncé son intégration à Chrome.
La stratégie pourrait donc simplement être :
Gemini → comprend l’intention → utilise Chrome → accomplit la tâche
Dans cette lecture, WebMCP serait une technologie destinée à rendre Gemini plus efficace lorsqu’il utilise des sites.
Mais cette explication laisse quelque chose de côté.
Si le seul objectif était d’améliorer Gemini, Google pourrait privilégier une infrastructure étroitement liée à ses propres modèles. Or WebMCP est présenté comme une primitive du Web destinée à être implémentable par d’autres navigateurs. Ailleurs dans sa stratégie agentique, Google suit une logique comparable d’interopérabilité.
C’est là qu’une autre lecture apparaît.
Améliorer l’environnement plutôt que seulement l’agent
Un agent dépend de deux choses différentes.
Il lui faut une intelligence capable de comprendre une intention, planifier et décider.
Mais il lui faut également un environnement dans lequel ses décisions peuvent devenir des actions.
C’est ce deuxième problème que WebMCP attaque.
Prenons un site de réservation. Sans interface dédiée aux agents, chaque modèle doit apprendre à manipuler son formulaire. Si l’interface change, les stratégies d’automatisation doivent s’adapter.
Avec WebMCP, le site peut exposer la fonction elle-même.
Le problème n’est plus seulement : « quel modèle comprend le mieux cette page ? »
Il devient : « comment les applications web déclarent-elles leurs capacités aux agents ? »
Cette différence est stratégique.
Si Google contribue à définir la couche utilisée pour répondre à cette deuxième question, l’entreprise peut bénéficier du développement du Web agentique même lorsqu’un autre modèle effectue le raisonnement.
Un agent concurrent pourrait, en principe, bénéficier d’un site rendu plus facilement actionnable grâce à WebMCP.
Google aurait alors contribué non pas seulement à améliorer son agent, mais à modifier l’environnement dans lequel tous les agents évoluent.
WebMCP n’est qu’une couche de la pile
Pris isolément, WebMCP pourrait encore être considéré comme une expérimentation de Chrome.
Le tableau change lorsqu’on le rapproche d’autres protocoles sur lesquels Google travaille ou auxquels il contribue.
En mars 2026, Google a publié un guide présentant plusieurs protocoles destinés à résoudre différentes étapes d’un système agentique : MCP pour connecter les agents à des outils et des données, A2A pour permettre à des agents distincts de communiquer, UCP pour les interactions commerciales et AP2 pour l’autorisation et la traçabilité des paiements agentiques.
Ces protocoles ne sont ni identiques ni tous contrôlés de la même manière par Google.
MCP vient d’Anthropic. A2A a été lancé par Google puis transféré en 2025 à un projet hébergé par la Linux Foundation, avec notamment AWS, Microsoft, Salesforce et SAP.
UCP, de son côté, a été développé par Google avec des acteurs du commerce comme Shopify, Etsy, Target, Walmart et Wayfair. Il est conçu pour fonctionner avec plusieurs mécanismes d’intégration, dont MCP et A2A, et pour se combiner avec AP2 pour les paiements.
Il serait donc faux de présenter cet ensemble comme une série de protocoles propriétaires Google.
C’est justement ce qui le rend intéressant.
Google semble participer à la construction d’une pile dans laquelle chaque problème dispose progressivement d’une interface standardisée :
agent ↔ outils
agent ↔ agent
agent ↔ site web
agent ↔ marchand
agent ↔ paiement
Le Web agentique commence à ressembler moins à un produit unique qu’à un ensemble de couches interopérables.
Et Google est présent dans beaucoup d’entre elles.
Les actifs historiques de Google prennent alors une autre valeur
Cette stratégie est particulièrement adaptée à la position de Google.
Un nouvel acteur qui veut construire un agent doit résoudre plusieurs problèmes à la fois : développer le modèle, distribuer le produit, accéder aux applications de l’utilisateur, exécuter les tâches, gérer l’identité, obtenir des autorisations et disposer d’une infrastructure informatique.
Google possède déjà une grande partie de cet environnement.
Gemini fournit le modèle et l’interface conversationnelle.
Chrome fournit le navigateur et les sessions web.
Android fournit une présence au niveau du système mobile.
Google Cloud fournit l’infrastructure d’exécution. Spark y fonctionne déjà en permanence sur des machines virtuelles dédiées.
Gmail, Calendar, Maps ou Search fournissent des données et des services avec lesquels les agents peuvent interagir. Gemini in Chrome est déjà intégré à plusieurs de ces produits.
À cela s’ajoutent les protocoles permettant aux agents de communiquer avec des outils, des sites, des entreprises ou d’autres agents.
Aucune de ces positions ne garantit à elle seule que Google dominera l’ère agentique.
Leur combinaison réduit en revanche l’importance d’une victoire absolue de Gemini.
Si Gemini devient l’agent dominant, Google gagne directement.
Mais si plusieurs agents coexistent, Google peut encore occuper certaines des infrastructures qu’ils utilisent pour accéder au Web, au cloud, aux applications ou au commerce.
La question stratégique n’est alors plus seulement de savoir qui possède l’agent.
Elle devient : qui possède suffisamment de couches autour de lui ?
Du moteur des intentions à l’infrastructure de leur exécution
Cette hypothèse fait écho à la position historique de Google sur le Web.
Google n’a jamais eu besoin de posséder la majorité des contenus accessibles sur Internet pour devenir l’un de ses principaux intermédiaires.
Search s’est placé entre une intention et un ensemble de destinations :
intention → recherche → sites
Le rôle du moteur consistait à organiser ce passage.
Les agents peuvent modifier cette chaîne.
Un utilisateur ne demande plus nécessairement une liste de sites où il pourra résoudre son problème. Il peut demander directement que le problème soit résolu.
intention → agent → action
« Trouve-moi un hôtel répondant à ces critères et réserve-le. »
« Modifie cette commande. »
« Compare ces offres et remplis le formulaire. »
Dans ce modèle, l’agent peut absorber une partie des interactions auparavant réparties entre moteur de recherche, navigateur et site.
Pour Google, c’est à la fois une opportunité et un risque.
Si l’agent devient le principal point d’entrée vers le numérique, le contrôle de la page de résultats devient moins déterminant.
Une réponse consiste évidemment à faire de Gemini ce nouveau point d’entrée.
Une autre consiste à déplacer la position stratégique plus profondément dans la chaîne : aider à définir les mécanismes par lesquels les agents découvrent les capacités, accèdent aux services et exécutent les actions.
Google ne cherche pas seulement à construire le meilleur agent, mais à s’insinuer dans tous les environnements dont les agents auront besoin.
Renaud Joly
WebMCP prend alors un sens différent.
Il ne sert plus seulement à faciliter quelques clics automatisés dans Chrome. Il participe à la construction d’une couche entre l’intention exprimée à un agent et les applications web capables de la satisfaire.
Le paradoxe des standards ouverts
Cette stratégie comporte pourtant une contradiction.
Plus ces standards sont ouverts, plus ils peuvent également bénéficier aux concurrents de Google.
A2A en fournit un exemple clair. Google a transféré le protocole à la Linux Foundation pour favoriser une gouvernance indépendante et un écosystème interopérable. Un protocole de ce type n’a d’intérêt que s’il permet précisément à des agents provenant de fournisseurs différents de communiquer.
WebMCP suit la même logique déclarée : Google souhaite que d’autres navigateurs agentiques puissent l’implémenter.
Un Web plus facilement actionnable pourrait donc aider Gemini, mais aussi les agents d’OpenAI, d’Anthropic, de Microsoft ou d’acteurs encore inconnus.
C’est le coût de l’interopérabilité.
Mais l’ouverture peut également être le mécanisme qui permet à une infrastructure de devenir commune.
Un protocole propriétaire maximise le contrôle de son concepteur mais limite les raisons qu’ont les autres acteurs de l’adopter. Un standard ouvert abandonne une partie de ce contrôle en échange d’une diffusion potentiellement beaucoup plus large.
Pour Google, ce compromis peut avoir du sens si l’adoption de l’infrastructure augmente parallèlement la valeur de Chrome, Android, Cloud, Gemini ou de ses services.
L’entreprise n’a alors pas besoin de posséder chaque protocole.
Elle a besoin que l’écosystème qui se construit autour de ces protocoles soit compatible avec les positions qu’elle possède déjà.
Si l’agent devient l’interface, qui possédera l’environnement ?
La course actuelle à l’IA encourage à observer le marché comme une compétition entre produits : Gemini contre ChatGPT, Claude ou le prochain agent capable de réaliser davantage de tâches.
Cette compétition existe. Google investit massivement pour y participer.
Mais WebMCP laisse entrevoir une autre bataille, moins visible.
À mesure que les agents passent de la production de réponses à l’exécution d’actions, leur efficacité dépend moins du modèle seul que du harnais qui l’entoure : navigateur, outils, protocoles, mémoire, identité, permissions, services, paiement, cloud. C’est ce harnais qui transforme une capacité de raisonnement en capacité d’action.
Google est déjà positionné dans une grande partie de cette chaîne.
La stratégie qui se dessine ne consiste donc peut-être pas à choisir entre posséder le meilleur agent et construire son infrastructure. Google peut poursuivre les deux objectifs simultanément.
Gemini lui donne une chance de contrôler l’interface.
Chrome, Android, Cloud et les protocoles agentiques lui donnent plusieurs chances de rester présent même si cette interface devient concurrentielle.
C’est ce que WebMCP révèle de plus intéressant.
Pendant l’ère du moteur de recherche, Google est devenu incontournable sans posséder les pages du Web. Dans l’ère agentique qui commence, son pari pourrait être comparable : ne pas avoir besoin de posséder tous les agents, à condition d’occuper suffisamment de l’environnement dans lequel ils transforment une intention en action.