TL;DROpenAI a ajouté le support de WebMCP au navigateur intégré de son application ChatGPT pour ordinateur : une page web peut désormais déclarer elle-même les actions qu'un agent a le droit d'exécuter, au lieu de le laisser cliquer à l'aveugle dans l'interface. Pour un site e-commerce ou un site de prise de rendez-vous, c'est un nouveau chantier technique de visibilité, au même titre que les données structurées il y a dix ans.

Ce que WebMCP change dans le navigateur de ChatGPT#

Selon Search Engine Journal, OpenAI ajoute la prise en charge de WebMCP au navigateur intégré de l'application ChatGPT pour ordinateur. Concrètement, une page web peut enregistrer des fonctions JavaScript comme outils, avec un nom, une description et un schéma d'entrée structuré. ChatGPT et Codex peuvent alors appeler ces outils directement depuis la page, sans avoir à simuler des clics et des saisies dans l'interface.

C'est différent du Model Context Protocol côté serveur, que ChatGPT prend en charge depuis 2025. Le MCP serveur relie une application IA à un serveur local ou distant et fonctionne sans page ouverte. WebMCP, lui, vit dans l'onglet : les outils sont rattachés à la page qui les déclare, ils disparaissent quand vous fermez cette page, et ils ne se propagent pas automatiquement aux autres pages du site. Une flèche apparaît dans la barre d'adresse quand des outils sont disponibles, en indiquant si l'outil se contente de lire des données ou s'il peut en modifier.

La citation d'OpenAI dans son annonce du WebMCP Challenge résume l'intention :

" Au lieu de laisser les agents deviner comment se servir de votre interface, vous définissez exactement comment ils peuvent utiliser votre application. "

Ce qu'un site peut réellement exposer aux agents IA#

OpenAI cite des cas d'usage concrets : rechercher dans des documents, éditer des fichiers, explorer un tableau de bord, comparer des options de voyage, mettre à jour un panier. La sélection d'outils varie d'un site à l'autre et d'une page à l'autre : c'est l'éditeur du site qui décide.

Pour un site marchand ou un site de services, la liste des candidats naturels est courte et facile à prioriser :

  • Recherche produit : un outil qui prend une requête, des filtres (taille, couleur, prix, marque) et renvoie une liste structurée avec URL, prix et disponibilité. C'est l'outil de lecture le plus rentable, parce qu'il évite à l'agent d'interpréter votre moteur de recherche à facettes.
  • Disponibilité et stock : réponse par référence et par déclinaison, éventuellement par point de vente. Lecture seule, risque faible.
  • Panier : ajout, retrait, modification de quantité. Action d'écriture, donc à traiter avec des confirmations explicites.
  • Prise de rendez-vous : consultation des créneaux libres, puis réservation. Là encore, lecture d'un côté, écriture de l'autre, et il vaut mieux séparer les deux outils.
  • Suivi de commande : dans un espace client authentifié, retour du statut et du numéro de suivi.

Le principe à retenir pour arbitrer : commencez par les outils de lecture, qui n'engagent rien, et n'ouvrez les outils d'écriture qu'une fois les garde-fous en place. Un outil mal décrit est pire qu'un outil absent, parce que l'agent l'appellera dans un contexte inadapté.

Implémentation : à quoi ressemble le chantier sur PrestaShop ou Symfony#

Sur le papier, WebMCP est une couche JavaScript côté page. Dans la pratique, l'essentiel du travail est côté serveur, et c'est là que se joue la qualité du résultat. Sur une boutique PrestaShop, l'approche que nous privilégions consiste à créer un module dédié qui fait trois choses : exposer des points d'entrée applicatifs propres (recherche, disponibilité, panier), injecter sur les pages concernées le script qui déclare les outils correspondants, et centraliser les contrôles de droits et la journalisation. Le module ne réécrit pas le thème : il s'appuie sur les contrôleurs et les services existants du cœur, ce qui limite la dette au moment des montées de version.

Sur une application Symfony sur mesure, le raisonnement est le même mais plus simple à cadrer. Les actions exposées correspondent à des services applicatifs déjà écrits, appelés derrière des contrôleurs dédiés, avec la validation des entrées confiée au composant Validator et les autorisations gérées par des voters. Le schéma d'entrée déclaré côté WebMCP doit refléter exactement la contrainte serveur : si l'outil accepte une quantité entre 1 et 10, le contrôleur doit refuser 11. Ne faites jamais confiance au schéma déclaré côté navigateur, il est modifiable par quiconque ouvre la console. En développement Symfony comme en PrestaShop, la règle est identique : le navigateur décrit, le serveur décide.

Point de méthode important : les outils fonctionnent dans la page courante et dans la session connectée. Il n'y a donc pas de nouvelle authentification à inventer. Un agent qui agit dans le navigateur d'un utilisateur connecté hérite de ses droits, ni plus ni moins. Cela simplifie beaucoup l'architecture, mais cela déplace la question de la sécurité vers la granularité des permissions existantes.

Mettre en place WebMCP pas à pas#

Voici la méthode que nous avons appliquée sur websource.fr puis sur plusieurs boutiques PrestaShop. Elle tient en quatre étapes, de la plus simple à la plus fine : annoter les formulaires, enregistrer quelques outils en JavaScript, publier un catalogue lisible par machine, puis tester.

Étape 1 : annoter vos formulaires (API déclarative)#

C'est la voie la plus rapide : vous ajoutez des attributs HTML à un formulaire existant, sans écrire de JavaScript. Le navigateur en déduit un outil que l'agent peut appeler.

  • toolname : l'identifiant de l'outil, en minuscules et underscores (par exemple contact_websource).
  • tooldescription : une phrase qui explique à quoi sert le formulaire et dans quel cas l'utiliser.
  • toolparamdescription, sur chaque champ : ce que le champ attend.
  • toolautosubmit : facultatif. Il autorise l'envoi sans validation humaine ; à réserver aux actions sans conséquence, comme une recherche.
<form action="/contact" method="post"
      toolname="contact_websource"
      tooldescription="Écrire à l'agence : décrire un projet ou une demande.">
  <input type="email" name="mail"
         toolparamdescription="Adresse email de réponse">
  <textarea name="message"
            toolparamdescription="Message ou description du besoin"></textarea>
  <button type="submit">Envoyer</button>
</form>

Sur notre formulaire de contact, nous n'avons volontairement pas mis toolautosubmit : l'agent pré-remplit les champs, et c'est la personne qui valide l'envoi. C'est aussi ce qui évite de contourner le reCAPTCHA.

Étape 2 : enregistrer des outils en JavaScript (API impérative)#

Pour une action qui n'est pas un formulaire (ouvrir une page, lancer une recherche, lire une information), on enregistre l'outil avec navigator.modelContext.registerTool(). Chaque outil a un nom, une description, un schéma JSON des paramètres et une fonction execute qui renvoie un contenu texte.

if (navigator.modelContext && navigator.modelContext.registerTool) {
  navigator.modelContext.registerTool({
    name: 'open_page',
    description: 'Ouvre une page clé du site (accueil, contact, blog, FAQ).',
    inputSchema: {
      type: 'object',
      properties: {
        page: { type: 'string', enum: ['accueil', 'contact', 'blog', 'faq'],
                description: 'Page à ouvrir' }
      },
      required: ['page']
    },
    annotations: { readOnlyHint: true },
    execute: function (args) {
      var pages = { accueil: '/', contact: '/contact', blog: '/blog', faq: '/faq' };
      var path = pages[args.page];
      if (!path) { return { content: [{ type: 'text', text: 'Page inconnue.' }] }; }
      window.location.assign(path);
      return { content: [{ type: 'text', text: 'Ouverture de ' + path }] };
    }
  });
}

Quelques règles qui comptent plus que la syntaxe :

  • Détection de fonctionnalité d'abord : la plupart des navigateurs n'exposent pas encore navigator.modelContext. Le test if ci-dessus garantit que la page reste inchangée pour tous les autres visiteurs.
  • Une liste fermée plutôt qu'un champ libre : avec enum, l'agent ne peut pas inventer une destination. Validez aussi les arguments côté execute, car le schéma n'est qu'une aide.
  • Marquer les outils en lecture seule avec readOnlyHint: true, pour que l'agent et le navigateur distinguent consulter et agir.
  • Des descriptions précises : l'agent choisit son outil d'après le texte. « Recherche dans le catalogue produits » est utile, « Recherche » ne l'est pas.
  • Ne pas exposer d'achat, de connexion ou de paiement tant que vous n'avez pas défini les permissions et la journalisation décrites plus bas.

Étape 3 : l'intégrer proprement dans votre CMS#

Le script doit être présent sur toutes les pages publiques, chargé en defer.

  • Symfony : un partial Twig inclus dans le base.html.twig, avec les attributs ajoutés directement dans les templates des formulaires (c'est ce que nous avons fait pour le contact et la newsletter).
  • PrestaShop : un fichier webmcp.js à la racine, appelé depuis le head.tpl du thème enfant avec <script src="{$urls.base_url}webmcp.js" defer></script>. Le script repère les formulaires de recherche, de newsletter et de contact et leur ajoute les attributs au chargement, ce qui évite de modifier les modules. Pensez à vider le cache Smarty avec l'utilisateur du site, jamais en root, sinon vous cassez les permissions du cache.
  • Boutique qui a déjà un module SEO ou IA : vérifiez d'abord qu'elle n'expose pas déjà ses propres outils, pour ne pas enregistrer deux fois le même nom.

Étape 4 : publier un catalogue ai-catalog.json#

Pour que les agents découvrent vos ressources sans deviner leurs adresses, publiez un fichier JSON sur /.well-known/ai-catalog.json. Il décrit votre site (host) et liste vos ressources (entries), chacune avec un identifiant, un nom, une description, un type de média et une URL.

{
  "specVersion": "1.0",
  "host": { "displayName": "Mon site", "identifier": "https://www.exemple.fr" },
  "entries": [
    { "identifier": "urn:exemple:llms-txt", "displayName": "llms.txt",
      "description": "Présentation du site pour les LLM.",
      "mediaType": "text/plain", "url": "https://www.exemple.fr/llms.txt" },
    { "identifier": "urn:exemple:sitemap", "displayName": "Sitemap XML",
      "description": "Plan du site.",
      "mediaType": "application/xml", "url": "https://www.exemple.fr/sitemap.xml" }
  ]
}

Ne listez que des URL qui répondent réellement en 200 : vérifiez chaque entrée avec curl avant de publier. Ce format est encore jeune et évolue, donc contrôlez-le avec l'outil d'audit de votre choix plutôt que de vous fier à une version figée.

Étape 5 : tester#

  1. Vérifiez que le catalogue est servi en JSON valide : curl -s https://www.exemple.fr/.well-known/ai-catalog.json | python3 -m json.tool.
  2. Vérifiez que le script est bien dans le HTML servi (et pas seulement dans votre fichier local) : curl -s https://www.exemple.fr/ | grep webmcp. Sur un site en production, un cache de templates périmé est la cause la plus fréquente d'un script « invisible ».
  3. Ouvrez la page dans un navigateur qui prend en charge WebMCP et regardez la console : aucune erreur ne doit apparaître, et vos outils doivent être listés.
  4. Lancez un audit de navigation agentique (par exemple celui de Lighthouse) : il contrôle la couverture des formulaires, la liste des outils enregistrés et la validité de leurs schémas.

Dernier point : ces outils s'exécutent dans la session du visiteur. Commencez par des actions de lecture et de navigation, mesurez l'usage, puis ouvrez progressivement des actions plus sensibles avec les garde-fous détaillés dans la section suivante.

Garde-fous : authentification, limites de droits, journalisation#

OpenAI demande l'autorisation de l'utilisateur avant que ChatGPT n'interagisse avec un site, et fait confirmer les actions sensibles : achats, suppression de données, modification de paramètres de compte, envoi de messages, partage d'informations personnelles. Chaque appel d'outil fait l'objet d'une revue de sécurité, mais OpenAI précise que ces contrôles ne garantissent ni la fiabilité du site ni celle de ses réponses. L'éditeur cite explicitement deux risques : l'exfiltration de données et l'injection de prompt. Search Engine Journal rappelle que les recommandations de Chrome identifient les descriptions d'outils malveillantes et les sorties contaminées comme des vecteurs d'injection de prompt pour les agents de navigation.

Traduit en règles d'exploitation, cela donne quatre exigences non négociables avant de mettre une couche agent en production :

  • Séparer lecture et écriture dans des outils distincts, et documenter cette distinction dans la description de chaque outil.
  • Limiter les droits au strict nécessaire : pas d'outil qui modifie une adresse de facturation ou déclenche un paiement tant que le parcours de confirmation côté site n'est pas explicite.
  • Limiter la cadence : un agent appelle vite et souvent. Sans limitation de débit par session et par IP, un outil de recherche produit devient une charge serveur imprévisible.
  • Journaliser tous les appels : horodatage, outil appelé, paramètres, résultat, identifiant de session. C'est indispensable pour diagnostiquer un comportement anormal et pour répondre à une réclamation client sur une commande passée par agent.

Ajoutez une règle de sortie : ne renvoyez jamais dans la réponse d'un outil des données que l'utilisateur connecté n'a pas le droit de voir dans l'interface. Le canal agent ne doit pas devenir une porte dérobée sur des données internes.

Disponibilité réelle : ce qui est utilisable aujourd'hui#

La fonctionnalité est limitée, et il faut le dire clairement avant d'engager un budget. Selon la documentation d'OpenAI, les outils de site sont accessibles dans le navigateur intégré de l'application ChatGPT pour ordinateur, quand le compte y a droit. Ils requièrent GPT-5.6 Sol ou Terra ; GPT-5.6 Luna a WebMCP désactivé. Les espaces de travail Enterprise et Edu n'y ont pas accès. Le déploiement est progressif, certains sites ne prennent pas en charge les outils, et les contenus embarqués peuvent en être dépourvus.

Côté navigateur, la fonctionnalité ne fonctionne pas dans Chrome via ChatGPT, mais les développeurs peuvent tester WebMCP dans Chrome en activant un indicateur expérimental ou en rejoignant l'origin trial. OpenAI qualifie WebMCP de standard ouvert expérimental : la spécification est un brouillon du W3C Web Machine Learning Community Group et n'est pas sur le Standards Track du W3C. Enfin, la documentation n'explique pas si WebMCP a un effet sur le classement, les citations ou la découvrabilité : à ce stade, aucun gain SEO n'est démontré et personne ne peut en promettre un.

Par où commencer lundi matin#

Voici l'ordre de travail que nous recommandons pour ne pas transformer un sujet expérimental en chantier coûteux.

  1. Cartographiez trois actions maximum qui ont une valeur métier évidente sur votre site : recherche produit, disponibilité, créneaux de rendez-vous. Écartez tout ce qui touche au paiement pour cette première itération.
  2. Vérifiez que ces actions existent déjà côté serveur sous forme de service propre. Si votre recherche produit est enfouie dans un contrôleur de 800 lignes, l'extraire est le vrai chantier, pas WebMCP.
  3. Écrivez les schémas d'entrée et les descriptions d'outils comme vous écririez une documentation d'API : nom explicite, description sans ambiguïté, types et bornes des paramètres. La qualité de la description conditionne le bon appel par l'agent.
  4. Doublez chaque contrôle côté serveur : validation, autorisation, limitation de débit. Considérez le schéma déclaré dans la page comme une simple indication.
  5. Activez la journalisation dédiée avant la première mise en ligne, pas après. Sans trace, aucun diagnostic n'est possible.
  6. Testez dans Chrome via l'indicateur expérimental ou l'origin trial, puis dans l'application ChatGPT pour ordinateur avec un compte éligible, en environnement de préproduction.
  7. Mesurez la charge générée par les appels d'outils sur une semaine avant d'ouvrir la fonctionnalité à tout le trafic.

Nous exploitons et hébergeons des sites en production, et l'expérience des vagues précédentes (données structurées, AMP, API headless) donne une ligne de conduite simple : investir sur la partie qui reste utile même si le standard évolue. Ici, cette partie est le nettoyage de vos actions métier en services serveur clairs, validés et journalisés. Cette base sert vos applications mobiles, vos intégrations partenaires et vos agents internes, quel que soit le sort de WebMCP. Si vous voulez faire évaluer la faisabilité sur votre boutique ou votre application métier, notre équipe intervient sur ce type de développement sur mesure.

Un dernier point d'arbitrage budgétaire : tant que WebMCP reste un brouillon de communauté W3C, limité à certains modèles et exclu des espaces Enterprise et Edu, l'audience réellement adressable est étroite. Un pilote cadré sur deux ou trois outils de lecture est raisonnable. Une refonte complète de l'expérience pour les agents ne l'est pas encore.

Questions fréquentes#

WebMCP remplace-t-il les données structurées et le SEO classique ?#

Non. Les données structurées servent à décrire un contenu pour l'indexation, WebMCP sert à exposer des actions exécutables à un agent présent sur la page. Selon la documentation d'OpenAI relayée par Search Engine Journal, rien n'indique un effet de WebMCP sur le classement, les citations ou la découvrabilité. Les deux chantiers sont complémentaires, pas substituables.

Quel est le risque de sécurité principal si j'expose des actions à un agent IA ?#

OpenAI cite explicitement l'exfiltration de données et l'injection de prompt. Un agent peut être manipulé par une description d'outil malveillante ou par un contenu contaminé présent dans la page. La parade tient en trois points : valider et autoriser côté serveur sans jamais faire confiance au schéma déclaré dans le navigateur, limiter les droits des outils d'écriture, et journaliser chaque appel.

Combien coûte la mise en place d'une couche WebMCP sur une boutique existante ?#

Le coût dépend beaucoup moins de WebMCP que de l'état de votre code. Si vos actions métier (recherche, disponibilité, panier) existent déjà sous forme de services serveur propres, la déclaration des outils est un travail court. Si elles sont enchevêtrées dans des contrôleurs monolithiques, le vrai chantier est leur extraction, et c'est lui qui pilote le budget.

Faut-il attendre que le standard soit stabilisé avant d'investir ?#

WebMCP est qualifié par OpenAI de standard ouvert expérimental ; sa spécification est un brouillon du W3C Web Machine Learning Community Group et n'est pas sur le Standards Track. Un pilote sur deux ou trois outils de lecture est raisonnable dès maintenant. Une refonte globale de l'expérience pour les agents ne l'est pas, tant que l'audience éligible reste limitée à certains modèles et exclut les espaces Enterprise et Edu.

Mes clients doivent-ils être connectés pour que les outils fonctionnent ?#

Pas nécessairement pour les outils de lecture publics, comme une recherche produit ou une consultation de disponibilité. En revanche, les outils qui touchent à un panier, à un compte ou à un rendez-vous s'appuient sur la session déjà ouverte dans le navigateur. OpenAI demande l'autorisation de l'utilisateur avant toute interaction et fait confirmer les actions sensibles comme les achats ou les modifications de compte.

Article publié le 28/08/2026 sous la signature de Jonathan Gutierrez, rédigé à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.