WebMCP : préparer un site aux agents IA sans agir à l’aveugle

WebMCP est un projet d’API web qui permet à une page d’exposer certaines fonctions sous forme d’outils décrits par un nom, une intention et un schéma d’entrée. Un agent présent dans ou autour du navigateur peut alors demander une action structurée plutôt que de deviner où cliquer à partir d’une capture, du DOM ou de l’arbre d’accessibilité.

Au 1er août 2026, le texte publié par le Web Machine Learning Community Group est un brouillon de rapport. Il n’est ni un standard W3C, ni une technologie disponible de façon uniforme dans les navigateurs. Chrome documente une expérimentation avec une API déclarative pour les formulaires et une API impérative en JavaScript. Les signatures, les permissions et les comportements peuvent encore changer.

La bonne décision n’est donc pas « ajouter WebMCP partout ». Elle consiste à identifier une tâche simple, réversible et déjà correctement gérée dans l’interface, puis à tester si un contrat d’outil améliore réellement son exécution. Le contenu visible, l’accessibilité, l’authentification et les règles métier doivent rester la source de vérité.

Réponse en bref

WebMCP peut être pertinent si votre site est une application et qu’un utilisateur doit accomplir une tâche précise, comme filtrer une liste, préparer un formulaire ou consulter un état. Commencez par un outil en lecture seule ou par le préremplissage visible d’un formulaire.

Ne l’implémentez pas comme une balise SEO. Le brouillon ne promet ni exploration, ni indexation, ni citation, ni meilleur classement. Il ne remplace pas un serveur MCP, une API métier, les données structurées schema.org, robots.txt ou l’interface humaine.

Avant un pilote :

confirmez que la tâche fonctionne déjà sans agent ;
choisissez le niveau lire, préparer ou agir ;
décrivez une seule intention par outil ;
limitez le schéma aux paramètres nécessaires ;
réutilisez les contrôles d’authentification et d’autorisation existants ;
gardez l’effet visible et réversible ;
exigez une confirmation séparée pour toute conséquence externe ;
testez les entrées invalides, l’état périmé, les changements de page et l’annulation ;
mesurez le résultat métier, pas le nombre d’appels ;
conservez une voie humaine complète et prévoyez le retrait du prototype.

Ce que WebMCP change dans l’interaction

Un agent de navigateur peut aujourd’hui observer une page puis simuler des actions humaines. Cette approche est générale, mais fragile : un bouton change de place, un libellé est ambigu, une modale masque le contenu ou un état n’est pas visible dans la capture.

WebMCP propose une autre surface. La page enregistre un outil avec :

un nom stable ;
une description destinée à l’agent ;
un schéma d’entrée ;
une fonction d’exécution ou un formulaire annoté ;
un résultat renvoyé après l’appel.

Le navigateur intervient entre l’agent et la page. Le brouillon prévoit aussi des concepts liés à l’origine, aux permissions et à l’exposition des outils. Il ne prescrit toutefois pas le format exact utilisé entre le navigateur et son agent. Malgré son nom, WebMCP ne rend donc pas chaque page identique à un serveur MCP distant.

Le bénéfice potentiel est un contrat plus explicite. Le risque est d’ajouter une nouvelle voie d’action qui contourne les contrôles conçus uniquement pour les clics humains.

Ne pas confondre cinq mécanismes

Mécanisme	Rôle principal	Ce qu’il ne prouve pas
WebMCP	exposer des outils actifs dans une page	visibilité dans un moteur de recherche
serveur MCP	relier un client IA à des outils ou ressources, souvent côté service	compatibilité native avec le navigateur
API métier	fournir un contrat serveur authentifié	capacité d’un agent à comprendre l’interface
schema.org	décrire des entités et contenus dans une page	permission d’exécuter une action
robots.txt	publier des préférences d’exploration pour les robots qui les suivent	contrôle d’un agent agissant pour un utilisateur

Cette séparation évite deux raccourcis. Le premier consiste à présenter WebMCP comme du balisage GEO. Le second consiste à exposer directement une API interne au motif qu’un outil possède déjà un schéma.

Le choix entre MCP et API directe concerne l’architecture de connexion. WebMCP ajoute une question côté page : quelle fonction active doit devenir compréhensible et appelable dans le contexte du navigateur ?

Préserver l’interface et l’accessibilité

Une fonction exposée à un agent doit d’abord rester utilisable par une personne. Les libellés, erreurs, états de chargement, confirmations et résultats ne doivent pas disparaître dans un canal réservé au modèle.

L’approche déclarative dépend directement de formulaires bien construits : étiquettes associées, champs nommés, contraintes compréhensibles et ordre de navigation cohérent. L’approche impérative ne doit pas servir à masquer une interface incomplète. Si un agent réussit une tâche que l’utilisateur ne peut plus accomplir seul, le produit a créé une dépendance et un problème d’accès.

Testez au clavier, avec le zoom, sur un petit écran et avec les technologies d’assistance utilisées par le public. La recette d’accessibilité d’un chatbot IA détaille ce contrôle pour une interface conversationnelle. Vérifiez aussi que l’état produit par l’outil apparaît dans la page. Une action invisible est difficile à comprendre, corriger ou annuler.

Choisir entre lire, préparer et agir

Classez chaque candidat dans l’un de ces niveaux.

Niveau 1 : lire

L’outil renvoie ou organise une information que l’utilisateur est déjà autorisé à consulter. Exemples : filtrer des ressources visibles, retrouver une aide ou lire l’état d’un objet courant.

Le risque principal concerne la confidentialité de l’information retournée et la portée de l’authentification. C’est le meilleur point de départ.

Niveau 2 : préparer

L’outil remplit une interface, construit un brouillon ou prépare un panier sans finaliser. L’utilisateur voit le résultat et peut le corriger.

Le contrôle porte sur la fidélité des paramètres, l’état actuel de la page et la séparation entre préparation et validation.

Niveau 3 : agir

L’outil envoie, commande, paie, publie, supprime ou modifie une donnée persistante. La conséquence peut toucher une autre personne ou un système extérieur.

Ce niveau ne doit pas être le premier pilote. Il exige authentification, autorisation serveur, confirmation claire, idempotence, journalisation, gestion des erreurs et stratégie d’annulation lorsque celle-ci est possible. Une description rassurante dans le schéma ne remplace aucun de ces contrôles.

Quand préférer l’API déclarative

Chrome documente une approche déclarative où un formulaire HTML reçoit des annotations. Les champs deviennent les paramètres de l’outil et le navigateur synthétise une représentation structurée.

Exemple pédagogique :

<form
  action="/support/prepare"
  method="post"
  toolname="prepare_support_request"
  tooldescription="Prépare une demande de support visible avant son envoi."
>
  <label for="topic">Sujet</label>
  <select id="topic" name="topic" required
    toolparamdescription="Catégorie générale de la demande.">
    <option value="billing">Facturation</option>
    <option value="access">Accès</option>
    <option value="technical">Problème technique</option>
  </select>

  <label for="summary">Résumé</label>
  <textarea id="summary" name="summary" required></textarea>

  <button type="submit">Préparer la demande</button>
</form>

Le serveur doit traiter cette soumission comme toute autre. Il valide le jeton de session, les champs, la longueur, les droits et la protection contre les requêtes abusives. L’annotation ne crée pas une voie privilégiée.

L’approche déclarative convient lorsqu’un formulaire accessible, bien étiqueté et progressif existe déjà. Elle est moins adaptée à une opération complexe qui dépend de plusieurs états JavaScript ou qui doit orchestrer plusieurs lectures avant de préparer le résultat.

Quand utiliser l’API impérative

L’API impérative enregistre un outil en JavaScript avec document.modelContext.registerTool(). Elle peut réutiliser la logique présente dans l’application et suivre son cycle de vie.

Exemple de lecture seule :

const controller = new AbortController();

await document.modelContext.registerTool({
  name: 'filter_public_resources',
  description: 'Filtre les ressources publiques affichées selon un thème connu.',
  inputSchema: {
    type: 'object',
    additionalProperties: false,
    properties: {
      topic: {
        type: 'string',
        enum: ['formation', 'automatisation', 'seo-geo']
      }
    },
    required: ['topic']
  },
  execute: async ({ topic }) => {
    return filterVisibleResources(topic);
  }
}, { signal: controller.signal });

// Retrait lorsque le composant ou l’état n’est plus valable.
controller.abort();

Cet exemple reste incomplet pour une production. Il montre seulement trois principes : valeurs bornées, fonction étroite et retrait lié au cycle de vie. Toute donnée privée ou action persistante demande des contrôles supplémentaires côté serveur.

La documentation Chrome actuelle indique que l’ancienne surface navigator.modelContext est abandonnée au profit de document.modelContext. Cette évolution récente illustre pourquoi le prototype doit isoler WebMCP derrière un adaptateur facile à retirer.

Le contrat d’outil à dix champs

Avant le code, remplissez cette fiche :

nom stable
intention unique
utilisateur et état requis
données lisibles
paramètres autorisés
résultat renvoyé
effet maximal
confirmation nécessaire
erreurs et annulation
propriétaire et date de revue

Ajoutez une phrase négative : « cet outil ne peut pas… ». Par exemple : « il ne peut pas envoyer la demande, changer le destinataire ni lire l’historique des tickets ».

Si cette phrase est difficile à garantir dans le code, le périmètre est trop large.

Réutiliser les contrôles serveur

Un appel initié par un agent reste une requête d’un utilisateur dans un contexte donné. Le serveur doit vérifier :

identité et session ;
droits sur la ressource ;
origine et protection contre les requêtes forgées ;
format et longueur des paramètres ;
état courant de l’objet ;
limite de débit ;
unicité de l’opération ;
confirmation encore valide ;
journal adapté ;
comportement en cas de dépendance indisponible.

Ne placez jamais un secret dans le schéma, la description, le DOM ou le résultat de l’outil. Une propriété masquée par l’interface reste accessible au code de la page et peut être exposée à une surface non prévue.

Les fonctions WebMCP doivent appeler les mêmes services métier que l’interface, pas copier leur logique dans un second chemin. Sinon une correction de permission peut protéger le bouton sans protéger l’outil.

Garder une confirmation compréhensible

Pour une action qui dépasse la lecture, la confirmation doit nommer :

l’action ;
la cible ;
les champs déterminants ;
la conséquence ;
le moyen d’annuler ou l’absence d’annulation.

« Continuer ? » n’est pas suffisant. Préférez « Préparer une demande au support pour le dossier 481, sans l’envoyer ». Si l’étape suivante envoie réellement, elle possède sa propre confirmation et sa propre autorisation.

Le modèle ne doit pas pouvoir modifier silencieusement le résumé présenté entre la confirmation et l’effet. Conservez une empreinte ou une version de la charge approuvée.

Concevoir le pilote

Un pilote défendable comporte une seule tâche et trois voies :

parcours humain normal ;
parcours agentique avec WebMCP ;
retour au parcours humain après échec.

Mesurez :

réussite de la tâche ;
temps jusqu’au résultat ;
corrections humaines ;
appels inutiles ;
paramètres refusés ;
états périmés ;
annulations ;
divergences entre interface et outil ;
incidents de permission ;
compréhension de la confirmation.

Ne mesurez pas seulement le nombre d’outils découverts. Un agent peut découvrir parfaitement un mauvais contrat.

Les seize tests avant élargissement

la tâche reste possible sans agent ;
l’outil n’existe que dans l’état où il est utile ;
son nom et sa description ne promettent pas plus que le code ;
une propriété inconnue est refusée ;
une valeur hors liste est refusée ;
un texte trop long est bloqué ;
un utilisateur non authentifié n’accède à rien de privé ;
un utilisateur authentifié ne lit pas la ressource d’un autre ;
l’origine non prévue ne découvre pas l’outil ;
un état de page périmé provoque un arrêt ;
une navigation pendant l’appel est traitée ;
l’annulation interrompt l’opération attendue ;
deux appels identiques ne produisent pas deux effets ;
la confirmation affiche la charge réellement exécutée ;
une erreur renvoie vers un parcours humain compréhensible ;
le retrait de WebMCP ne casse pas la fonction principale.

Ajoutez des tests de prompt injection si l’outil retourne ou consomme du contenu contrôlé par un tiers. Le brouillon de spécification consacre une partie importante aux risques de descriptions malveillantes, de sorties non fiables, de confusion d’intention et de fuite liée à des paramètres trop larges.

WebMCP, SEO et GEO

WebMCP n’est pas documenté comme un facteur de classement ou une condition de citation. Sa fonction est de rendre certaines actions d’une application plus explicites pour des agents compatibles dans le navigateur.

Pour une page éditoriale, les priorités restent : contenu visible, réponse utile, sources, accessibilité, liens internes, données structurées fidèles, canonical et indexabilité. Ajouter un outil ne compense pas une page vide ou un contenu accessible seulement après une interaction opaque.

Pour une application, WebMCP peut devenir une couche d’utilisabilité agentique. Cette valeur doit être mesurée par la réussite d’une tâche avec l’accord de l’utilisateur, pas par une promesse de présence dans ChatGPT, Gemini ou Google.

Le terme « GEO » ne doit donc pas servir à transformer chaque nouveau protocole agentique en hack de visibilité.

Décider maintenant ou attendre

Situation	Décision raisonnable
site éditorial sans fonction interactive	attendre et investir dans le contenu et l’accessibilité
formulaire simple déjà accessible	prototype déclaratif local possible
application avec filtre ou lecture d’état	pilote impératif en lecture seule
action externe ou transaction	attendre ou limiter à la préparation visible
logique métier dupliquée dans le front	corriger l’architecture avant WebMCP
équipe sans tests de permissions	ne pas exposer de nouvel outil
besoin de compatibilité multi-navigateurs immédiate	conserver l’API et l’interface comme contrats principaux

Un prototype est justifié s’il apprend quelque chose que l’équipe ne peut pas vérifier sur papier : qualité de découverte, compréhension du schéma, cohérence avec l’état de page ou clarté de la confirmation.

Checklist de publication d’un prototype

Limites

WebMCP est au 1er août 2026 un rapport de Community Group qui n’appartient pas à la voie normative du W3C. L’implémentation Chrome est expérimentale, les autres navigateurs peuvent ne pas prendre en charge l’API et la surface peut évoluer rapidement.

Les exemples sont pédagogiques. Ils ne couvrent pas tous les contrôles d’une application réelle, notamment les politiques de permission, les iframes, les origines croisées, l’authentification, la protection des données, l’accessibilité et les transactions.

Un outil déclaré ne garantit ni compréhension correcte par un agent, ni exécution sûre, ni résultat métier. Les descriptions et sorties peuvent elles-mêmes devenir des entrées non fiables. Les tests doivent couvrir l’ensemble du chemin jusqu’au système cible.

Enfin, aucun élément officiel consulté ne permet de présenter WebMCP comme un signal de classement, d’indexation ou de citation. Toute observation future devra distinguer compatibilité technique, usage réel par un agent et visibilité dans un moteur.

À propos de l’auteur

Je suis Ayoub Kahouadji, consultant SEO/GEO, développeur Python et formateur IA. J’analyse les nouvelles interfaces agentiques en séparant leur utilité opérationnelle, leurs permissions et les affirmations de visibilité que les preuves ne permettent pas encore de faire.

Prochaine étape

Choisissez une fonction en lecture seule déjà présente dans votre application. Écrivez son contrat à dix champs, simulez les tests 7, 9, 10 et 16, puis décidez si un prototype local apporte une information utile. Pour relier cette couche à vos workflows et à vos APIs, consultez la page automatisation IA et Python.

Sources vérifiées

WebMCP, Draft Community Group Report du 28 juillet 2026 , consultée le 1 août 2026
WebMCP explainer and specification repository , consultée le 1 août 2026
WebMCP Declarative API , consultée le 1 août 2026
WebMCP Imperative API , consultée le 1 août 2026
Web Platform Tests, WebMCP , consultée le 1 août 2026