Les quatre articles précédents de cette série parlaient de lecture. Celui-ci parle d’action — un agent qui réserve, achète, envoie un formulaire ou récupère une valeur. J’ai vérifié où en sont réellement les standards, et le tableau est net : WebMCP est un brouillon de Community Group du W3C, il est en essai d’origine dans Chrome et Edge, et Apple a déposé une objection formelle. Le protocole de commerce d’OpenAI et Stripe exige du marchand qu’il implémente cinq points de terminaison et il est en bêta — et son propre site officiel indique que les mécanismes de découverte sont encore en construction. Le groupe de travail de l’IETF sur l’identité des agents a été constitué, mais il n’a encore adopté aucun document. Et sur le principal benchmark indépendant d’exécution de tâches de bureau, le meilleur résultat vérifié a accompli 42,9 % des tâches.
Les trois couches qui doivent toutes exister
Pour qu’un agent accomplisse une tâche sur votre site, trois conditions doivent être réunies en même temps : il doit savoir ce qu’il a le droit de faire, il doit disposer d’une interface pour le faire, et vous devez savoir qu’il s’agit vraiment de cet agent et non de quelqu’un qui l’usurpe. Le tableau résume où en est chaque couche aujourd’hui.
| Couche | Mécanisme principal | Statut réel |
|---|---|---|
| Déclaration de capacités | WebMCP | Brouillon de Community Group ; essai d’origine dans Chrome et Edge ; WebKit opposé |
| Finaliser un achat | ACP d’OpenAI et Stripe | Bêta ; cinq points de terminaison marchands ; aucun mécanisme de découverte |
| Autorisation de paiement | AP2 de Google | Version 0.2 ; contribué à la FIDO Alliance ; ne demande aucun changement du site |
| Agent à agent | A2A | Version 1.0.1 ; stable, mais résout un autre problème |
| Identité de l’agent | Web Bot Auth | Groupe de travail constitué à l’IETF ; aucun document adopté ; Cloudflare a implémenté |
| Identification des navigateurs agentiques | — | Aucun user-agent documenté pour un quelconque navigateur agentique |
WebMCP : où en est-il vraiment
WebMCP, c’est l’idée qu’un site puisse déclarer, à l’intérieur de la page elle-même, quelles actions il propose à un agent — au lieu que l’agent devine où cliquer. C’est la bonne approche, et c’est pourquoi elle fait beaucoup de titres. Mais il faut connaître son statut formel.
Le document est publié par le W3C Web Machine Learning Community Group, et son en-tête précise explicitement qu’il ne s’agit pas d’un standard du W3C et qu’il n’est pas sur la voie de la normalisation. Les éditeurs viennent de Microsoft et de Google. La version du brouillon que j’ai lue est datée du 26 août 2026.
Les implémentations : Chrome a ouvert un essai d’origine dans la version 149, selon un billet du blog développeurs publié le 9 juin 2026. Edge a ouvert un essai d’origine dans la version 150, Brave l’exécute à titre expérimental dans Leo, et l’application de bureau ChatGPT le prend en charge. De l’autre côté, WebKit a déposé une position d’opposition assortie d’une liste de réserves qui inclut le choix même de l’instance de normalisation, et Mozilla a déposé une position neutre.
Deux erreurs qui reviennent dans tous les guides : l’API ne s’appelle pas navigator.modelContext — le mot Navigator n’apparaît pas une seule fois dans le texte de la spécification. Et Chrome n’a pas livré cela dans la version 146 en février 2026 ; le blog officiel parle d’un essai d’origine dans la version 149. Si un guide vous dit le contraire, il n’a pas lu la source.
À quoi cela ressemble en code
La vraie API est document.modelContext.registerTool. L’idée est simple : la page enregistre un outil avec un nom, une description, un schéma d’entrée et une fonction qui l’exécute. L’agent qui parcourt la page voit l’outil sans avoir à deviner ce que fait chaque bouton.
document.modelContext.registerTool({
name: « book_appointment »,
description: « Book an appointment on a given date »,
inputSchema: {
type: « object »,
properties: { date: { type: « string » } },
required: [« date »]
},
async execute({ date }) {
const result = await bookOnServer(date);
return { content: [{ type: « text », text: result.confirmation }] };
}
});
Ce qui compte ici n’est pas la syntaxe mais l’implication : l’action passe par votre code. C’est vous qui décidez ce qui est exposé, vous qui validez l’entrée et vous qui contrôlez les effets de bord. C’est fondamentalement différent d’un agent qui essaie de cliquer sur l’interface visuelle en espérant que ça marche. À ce stade, toute implémentation de ce type est une expérimentation — pas une infrastructure de production.
Commerce agentique : trois protocoles, trois problèmes différents
Il est facile de s’y perdre parce que les trois noms apparaissent dans les mêmes articles, alors qu’ils résolvent des choses complètement différentes.
ACP — l’Agentic Commerce Protocol, maintenu par OpenAI et Stripe, se définit lui-même comme étant en bêta, sous licence Apache-2.0. La version la plus récente de la spécification que j’ai vue est datée du 17 avril 2026. Du point de vue d’un marchand, l’exigence est concrète : implémenter cinq points de terminaison REST pour gérer une session de paiement — créer, mettre à jour, finaliser, annuler et récupérer — plus des webhooks pour les événements de commande. Le site officiel indique qu’ils travaillent encore à créer des mécanismes de découverte qui permettront aux plateformes d’IA d’identifier les entreprises. Ce qui signifie que même si vous implémentez tout, il n’existe aujourd’hui aucun moyen standard de déclarer que vous l’avez fait — exactement la lacune que j’ai décrite dans l’article sur la couche de découverte.
AP2 — l’Agent Payments Protocol de Google, en version 0.2, annoncé en septembre 2025 et depuis contribué à la FIDO Alliance pour poursuivre la normalisation. Il est construit comme une extension d’A2A et traite de l’autorisation de paiement : des mandats vérifiables prouvant que l’utilisateur a réellement autorisé l’agent à payer. Il ne demande aucun changement dans le HTML de votre site : ce n’est donc pas un remplaçant d’ACP mais une couche en dessous.
UCP — l’Universal Commerce Protocol qui, selon une annonce de Shopify datée du 24 mars 2026, est développé conjointement avec Google et bénéficie du soutien de Walmart, Target, Etsy, American Express, Mastercard, Stripe et Visa. Je n’ai pas ouvert la spécification elle-même, je ne citerai donc pas de version.
Une remarque qui évite les déceptions : cette même annonce de Shopify décrit son intégration à ChatGPT comme fonctionnant via un navigateur interne, et sur ordinateur en redirigeant directement vers la boutique du marchand. Autrement dit, « acheter dans ChatGPT » n’est pas nécessairement un paiement ACP natif. Et la documentation d’OpenAI indique qu’Instant Checkout est disponible pour des partenaires approuvés — pas pour tous les marchands.
A2A résout un autre problème
A2A a atteint la version 1.0.0 en mars 2026 et la version 1.0.1 en mai 2026, et c’est le protocole le plus mature du groupe. Il définit une agent card — un document JSON décrivant l’identité, les capacités, les compétences, le point de terminaison de service et les exigences d’authentification d’un serveur d’agents — et la publie à /.well-known/agent-card.json. C’est aussi la seule entrée du monde des agents enregistrée dans le registre de l’IANA.
Et justement pour cette raison il faut être précis : son domaine est la communication entre systèmes d’agents indépendants, pas entre un site et un agent. Publier ce fichier sur un site vitrine ne sert à rien, sauf si vous faites vraiment tourner un serveur A2A derrière. J’ai déjà vu pas mal de recommandations qui ratent cette distinction.
Comment identifie-t-on un agent, au juste
C’est la couche qui manque le plus, et la conclusion la plus nette de cette recherche est négative : il n’existe aucun user-agent documenté pour un quelconque navigateur agentique. La page des bots d’OpenAI liste OAI-SearchBot, OAI-AdsBot, GPTBot et ChatGPT-User — et ne contient aucune entrée pour ChatGPT Atlas. La page des bots d’Anthropic liste ClaudeBot, Claude-User et Claude-SearchBot — et ne contient aucune entrée pour Claude in Chrome. Si vous voyez dans vos journaux une chaîne qui ressemble à un navigateur agentique, elle n’est pas documentée et peut changer sans préavis.
La réponse qui se dessine est Web Bot Auth : une signature cryptographique sur la requête elle-même. Un groupe de travail portant ce nom a été constitué à l’IETF, mais à ce jour il n’a adopté aucun document — tous les brouillons pertinents sont encore des soumissions individuelles. Le brouillon du protocole central a été mis à jour le 19 août 2026.
Cloudflare a déjà implémenté le mécanisme : un annuaire de clés à /.well-known/http-message-signatures-directory et les en-têtes Signature-Agent, Signature-Input et Signature sur la requête. Sa documentation note aussi que depuis le 1er juillet 2026 il existe un nouveau champ de métadonnées distinguant un agent direct d’un intermédiaire, et que les catégories de comportement incluent explicitement le fait de transiger pour le compte d’un utilisateur. Une réserve à connaître : Cloudflare implémente des versions de brouillon antérieures à la dernière, il faut donc s’attendre à des décalages entre implémentations à ce stade.
Dans quelle mesure les agents accomplissent-ils réellement les tâches
Ici je veux donner un chiffre réel plutôt qu’une impression. Le benchmark indépendant le plus sérieux que j’ai trouvé est TheAgentCompany, développé entre autres à l’université Carnegie Mellon, qui comprend 175 tâches simulant le travail dans une entreprise logicielle. Les résultats du classement sont marqués comme vérifiés de manière indépendante.
- Le meilleur résultat du classement : 42,9 % des tâches accomplies, une entrée enregistrée le 10 novembre 2025.
- OpenHands-Versa avec Claude Sonnet 4 a accompli 33,1 %, en juin 2025.
- OpenHands avec GPT-4o a accompli 8,6 %, en décembre 2024.
Une réserve que je dois formuler : l’entrée la plus récente du classement date de novembre 2025, et elle ne contient aucun modèle de pointe de 2026. Ne présentez donc pas 42,9 % comme « l’état de l’art en 2026 » mais comme le meilleur résultat vérifié de manière indépendante sur ce benchmark. Ce que le chiffre dit malgré tout, même en supposant une amélioration significative, c’est qu’il n’existe pas encore de réalité dans laquelle vous confiez une tâche complexe à un agent en vous attendant à ce qu’il la termine.
Que faire concrètement aujourd’hui
La recommandation honnête est de ne pas se précipiter pour implémenter des brouillons. Mon ordre des opérations, fondé sur ce qui est documenté et stable : d’abord s’assurer que le site est lisible tout court — permissions correctes, contenu présent dans le HTML initial, et des pages qui peuvent être citées. Ensuite vérifier que votre blocage ne rejette pas des agents légitimes agissant pour le compte d’un utilisateur : c’est une erreur courante, et le seul mécanisme d’approbation explicite que j’ai trouvé documenté est celui de Cloudflare, qui permet aux fournisseurs de bots de candidater et aux propriétaires de sites d’activer des réglages par catégorie.
Et seulement ensuite, si votre modèle d’affaires en tire vraiment bénéfice, envisagez un pilote : un essai d’origine WebMCP pour une action bien définie, ou une implémentation ACP si vous vendez des produits et disposez de ressources de développement. Dans les deux cas, traitez cela comme une expérimentation, parce que c’en est une.
La lacune qui reste ouverte est exactement celle que j’ai décrite tout au long de cette série : il n’existe aucun moyen standard pour un site de déclarer ce qu’il propose à un agent. ACP l’admet lui-même, MCP ne le couvre pas et A2A résout un autre problème. C’est pour cela que je travaille sur la spécification AX. Mais tant qu’il n’y a pas de standard convenu, ma recommandation n’est pas d’inventer une voie privée en espérant que ça marche — mais de construire ce qui fonctionne déjà.
Questions fréquentes
Dois-je implémenter WebMCP sur mon site aujourd’hui ?
Uniquement à titre d’expérimentation. Le document est un brouillon de Community Group du W3C, et il indique explicitement qu’il n’est pas un standard et qu’il n’est pas sur la voie de la normalisation. Chrome et Edge ont ouvert des essais d’origine, WebKit a déposé une opposition et Mozilla une position neutre. Ce n’est pas là-dessus qu’on construit une infrastructure de production.
Comment s’appelle réellement l’API WebMCP ?
document.modelContext.registerTool. Le nom navigator.modelContext, qui apparaît dans de nombreux guides, est faux — le mot Navigator n’apparaît pas du tout dans le texte de la spécification.
Que dois-je exactement implémenter pour prendre en charge le commerce agentique d’OpenAI ?
Selon la spécification ACP, un marchand doit implémenter cinq points de terminaison REST pour gérer une session de paiement — créer, mettre à jour, finaliser, annuler et récupérer — plus des webhooks pour les événements de commande. Le protocole se définit comme étant en bêta, et Instant Checkout est documenté comme disponible pour des partenaires approuvés.
Dois-je publier agent-card.json sur mon site ?
Uniquement si vous faites vraiment tourner un serveur A2A. La carte décrit l’identité, les capacités, le point de terminaison de service et les exigences d’authentification d’un serveur d’agents, et A2A traite de la communication entre systèmes d’agents — pas entre un site et un agent. Sur un site vitrine, le fichier ne sert à rien.
Comment identifier le trafic des navigateurs agentiques dans mes journaux ?
À ce jour, il n’existe aucun moyen documenté. Les pages de bots d’OpenAI et d’Anthropic ne contiennent aucune entrée pour leurs navigateurs agentiques. Le mécanisme qui se dessine est Web Bot Auth, fondé sur la signature de la requête ; un groupe de travail à ce sujet a été constitué à l’IETF mais n’a pas encore adopté de document, et Cloudflare en a déjà implémenté des versions de brouillon.
Pour aller plus loin
Le protocole AX : déclarer à un agent ce que votre site sait faire – L’étape suivante, une fois qu’un agent peut agir sur votre site, est de lui dire ce qui est disponible. C’est exactement la lacune qu’aucun protocole existant ne comble aujourd’hui.