Trois façons de piloter une page web avec l'IA

Trois, en août 2026. Une extension ou un navigateur agentique lit la page rendue et agit dans la session de l'utilisateur. WebMCP permet à la page de déclarer des outils typés qu'un navigateur compatible appelle directement. Un SDK place l'agent dans le produit, où il utilise vos routes, votre état et les fonctions que vous exposez. Les trois coexistent, et une même page peut être atteignable par toutes.

WebMCP et l'agent dans le produit sont tous deux rapides, parce qu'un appel de fonction typé remplace la boucle capture, raisonnement, clic, relecture. Les extensions et navigateurs agentiques sont les plus lents des trois, pour la même raison : chaque changement d'écran coûte une nouvelle lecture.

En partie. WebMCP est un draft publié par le W3C Web Machine Learning Community Group, daté du 28 juillet 2026, et Chrome a ouvert un origin trial depuis Chrome 149, avec un flag de test local sur chrome://flags/#enable-webmcp-testing. À considérer comme un pari sur les prochaines années plutôt que comme un moyen de toucher tous vos utilisateurs ce trimestre.

Quand l'agent doit travailler sur un site que vous ne contrôlez pas, quand vous voulez que l'utilisateur amène et paie son propre modèle, ou quand la tâche dépend d'un état visuel qu'aucune API n'expose, comme un bouton grisé ou un bandeau. C'est aussi la seule approche qui porte le contexte de l'utilisateur à travers plusieurs sites dans une même tâche.

Seulement l'agent intégré au produit. Avec une extension ou avec WebMCP, l'échange a lieu dans un produit qui ne vous appartient pas : vous voyez l'action qui en résulte, jamais la question, la formulation ni l'hésitation derrière. Si comprendre ce que demandent vos utilisateurs fait partie de l'objectif, c'est ce point qui tranche.

Ils reconstruisent leur compréhension de la page à chaque tour. Une modale, une liste chargée à la volée ou un bouton renommé change ce qu'ils lisent, donc l'agent doit relire et peut se tromper d'élément. Le modèle n'est pas en cause, c'est la cible qui a bougé.

Oui, et les deux partagent l'essentiel du travail. L'agent dans le produit sert les utilisateurs que vous avez aujourd'hui, dans n'importe quel navigateur. Les outils WebMCP serviront les navigateurs agentiques qui arriveront ensuite. Les deux peuvent s'appuyer sur les mêmes fonctions, donc la partie coûteuse, décider quelles actions un agent peut exécuter, ne se fait qu'une fois. Avec le SDK AGO, passer webmcp: true fait automatiquement des fonctions que vous avez enregistrées des outils WebMCP, et les analytics AGO montrent lesquelles les agents externes appellent. Voir comment le SDK AGO expose des fonctions

Vous exposez les actions une par une. Avec WebMCP vous enregistrez un outil par action, avec un SDK vous décrivez une fonction et son schéma, et dans les deux cas l'agent ne peut appeler que ce que vous avez déclaré. Le SDK va un cran plus loin : un appel marqué comme nécessitant une approbation reste en attente jusqu'à ce que l'utilisateur accepte ou refuse. L'extension est l'exception, puisqu'elle atteint tout ce que l'utilisateur peut atteindre à l'écran et que ce n'est pas vous qui décidez.