OpenAI 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.

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.

Sources#

Article rédigé le 28/08/2026 par l'équipe Websource à partir des sources citées ci-dessus, puis relu avant publication. Une information vous semble inexacte ou datée ? Signalez-le nous, nous corrigeons.