Le WebMCP va-t-il vraiment changer les interfaces web ?

Les agents IA savent déjà ouvrir un navigateur, lire une page, cliquer sur des boutons et remplir des formulaires. Mais cette capacité reste largement fondée sur l’interprétation d’une interface conçue pour des humains : texte visible, structure HTML, libellés, positions des éléments et heuristiques. Dès que le parcours comporte plusieurs étapes, des règles métier, une confirmation ou des données ambiguës, l’agent peut se tromper.

WebMCP s’inscrit dans une autre logique. L’idée est de permettre à un site web d’exposer, de façon explicite, des actions qu’un agent peut comprendre et déclencher dans un cadre contrôlé. Au lieu de deviner comment réserver un créneau, modifier une adresse de livraison ou exporter une facture, l’agent pourrait s’appuyer sur des capacités déclarées par le site.

La promesse est intéressante, mais elle ne mérite ni enthousiasme automatique ni rejet de principe. Une interface agentique peut supprimer des frictions réelles sur quelques parcours. Elle peut aussi dupliquer une API existante, étendre inutilement la surface d’attaque ou rendre un flux critique moins prévisible. La bonne question n’est donc pas « faut-il intégrer WebMCP ? », mais : quel problème utilisateur et opérationnel cette couche résout-elle mieux que l’interface et l’API déjà en place ?

WebMCP : le problème concret qu’il cherche à résoudre

Un navigateur est un environnement particulièrement difficile pour un agent. Les pages évoluent, les composants se chargent de manière asynchrone, les interfaces réservent parfois des informations au JavaScript, et les libellés humains sont souvent ambigus. Un bouton « Continuer » peut valider un panier, passer à l’étape suivante ou accepter une modification contractuelle selon le contexte.

Les outils d’automatisation traditionnels, comme Playwright ou Selenium, répondent à une autre finalité : tester et piloter un navigateur en reproduisant des interactions. Ils sont précieux pour les tests de bout en bout, le contrôle qualité et certaines automatisations internes. En revanche, ils ne fournissent pas par eux-mêmes un contrat métier clair à un assistant.

WebMCP cherche à réduire cet écart entre l’intention exprimée par l’utilisateur et l’action exécutée sur le site. Dans un modèle idéal, une application expose des outils décrivant :

une action disponible, par exemple « rechercher une commande » ou « préparer un export » ;
les paramètres attendus ;
les préconditions et contraintes métier ;
le résultat retourné à l’agent ;
les opérations qui exigent une confirmation humaine.

Le terme WebMCP renvoie à la rencontre entre les interfaces web et la logique de Model Context Protocol (MCP), un protocole ouvert destiné à connecter des modèles à des outils et à des sources de données. Il ne faut toutefois pas transformer une intention ou une expérimentation en standard établi : avant toute intégration, une équipe doit vérifier les spécifications disponibles, le niveau de support navigateur, le modèle de permissions et les garanties de compatibilité réellement proposées.

Le gain potentiel n’est pas de permettre à une IA de « cliquer plus vite ». Il est de remplacer une succession d’interactions fragiles par une intention structurée, soumise aux mêmes règles métier que le reste du produit.

Une capacité utile pour un agent n’est pas un raccourci vers la base de données. C’est une opération métier bornée, autorisée et observable.

Ne pas confondre interface agentique, API publique et automatisation navigateur

Le premier risque consiste à exposer un outil agentique pour chaque endpoint existant. C’est rarement une bonne conception. Une API interne peut contenir des opérations trop fines, des champs techniques ou des possibilités qui ne doivent pas être accessibles à un assistant. À l’inverse, une API publique peut déjà être la bonne solution pour un intégrateur qui souhaite travailler côté serveur.

Ces trois couches ont des objectifs distincts :

L’interface web sert aux humains. Elle doit être accessible, compréhensible, réactive et sûre.
L’API sert aux systèmes. Elle offre un contrat documenté, des mécanismes d’authentification et une intégration indépendante de l’interface.
L’interface agentique sert à exprimer des tâches utilisateur de haut niveau dans un contexte de navigation, avec des limites spécifiques.

Un exemple simple : une boutique possède des endpoints permettant de modifier un panier, calculer des frais de livraison, créer un paiement et déclencher une expédition. Exposer ces endpoints séparément à un agent n’est pas forcément souhaitable. Un outil métier tel que « préparer une commande à soumettre » peut être plus cohérent. Il peut vérifier l’état du stock, calculer le total, résumer les conséquences et imposer une confirmation avant toute étape engageante.

Cette distinction protège également la maintenabilité. Un agent ne devrait pas dépendre de détails d’implémentation, comme un identifiant de composant frontend ou un champ temporaire destiné à un formulaire. Il doit dépendre d’un contrat stable, versionné et testé. C’est le même principe que pour une API : on expose une capacité, pas le fonctionnement interne.

Le sujet rejoint les arbitrages évoqués dans le choix d’un framework JavaScript sans suivre la hype. Ajouter une couche n’a de sens que si elle simplifie durablement un problème identifié. Si elle ne fait qu’ajouter des schémas, des adaptateurs et des points de défaillance, elle coûte plus qu’elle ne rapporte.

Quels parcours web gagnent réellement à exposer des outils aux agents

Les meilleurs candidats ne sont pas les pages vitrines ni les micro-interactions. Ce sont les parcours où une intention est légitime, répétée, assez structurée, mais pénible à accomplir à la main à cause du nombre d’écrans, de filtres ou de documents.

Recherche et consolidation d’informations

Dans un extranet client, un utilisateur peut vouloir retrouver une facture, vérifier le statut de plusieurs dossiers ou comparer des contrats. L’agent peut aider à formuler une recherche, croiser des critères autorisés et restituer une synthèse sourcée par les données du compte. Un outil de type « rechercher mes factures » ou « lister mes commandes en retard » est plus robuste que le parcours visuel d’un tableau complexe.

Le périmètre doit rester strict. L’agent peut accéder aux ressources auxquelles l’utilisateur connecté a déjà droit, et non effectuer une recherche globale dans les données de l’entreprise. Les contrôles d’accès ne changent pas parce que l’intermédiaire est une IA.

Préparation d’actions réversibles

Les brouillons sont un excellent terrain d’expérimentation. Préparer une demande de remboursement, créer un panier sans payer, générer un brouillon de devis ou assembler une liste de produits sont des actions utiles, mais réversibles. L’utilisateur conserve la possibilité d’inspecter et de modifier le résultat avant validation.

Cette logique évite de déléguer trop tôt une décision engageante. Un agent peut préparer une demande de congé dans un outil RH ; le système doit ensuite afficher les dates, le solde concerné et le circuit de validation. Il ne doit pas contourner les règles de l’organisation au prétexte que la demande a été formulée en langage naturel.

Configuration guidée dans les produits complexes

Les produits B2B comportent souvent des écrans d’administration difficiles à parcourir : filtres, règles de notification, exports, droits ou paramètres de facturation. Un assistant peut transformer une demande comme « crée un export mensuel des tickets ouverts pour l’équipe support » en configuration proposée.

Le bénéfice est réel si l’outil vérifie les droits, explique les paramètres retenus et laisse une validation explicite. Sans cette étape, l’agent devient une nouvelle manière de créer des erreurs de configuration à grande échelle.

Assistance et support après authentification

Le support client est un autre cas crédible. Un agent peut retrouver l’état d’une commande, proposer les options prévues par les conditions de vente ou initier un retour selon les règles applicables. Ici encore, l’outil ne doit pas inventer une exception commerciale. Il doit appeler les mêmes règles métier que le conseiller humain ou le centre d’aide.

En pratique, l’intérêt est plus fort quand la tâche possède un résultat vérifiable : un numéro de dossier, un brouillon, un document généré ou un état mis à jour. Les conversations vagues sans action claire relèvent davantage de l’assistance éditoriale que d’une interface agentique.

Les mauvais candidats : quand WebMCP ajoute une couche inutile

Toutes les interactions n’ont pas besoin d’être « agentifiées ». Un bouton de contact, une navigation de documentation ou un formulaire de newsletter n’exigent pas un contrat d’outils. Une interface simple, rapide et accessible reste l’option la plus fiable.

WebMCP est également un mauvais choix lorsqu’une API classique répond déjà au besoin. Une entreprise qui veut intégrer son ERP à un service de facturation n’a pas besoin d’un agent qui ouvre un navigateur : elle a besoin d’une API stable, authentifiée et documentée. Ajouter une étape IA entre deux systèmes peut introduire de la latence, de l’incertitude et des difficultés de diagnostic.

Les parcours très critiques demandent une prudence renforcée : paiement, changement de coordonnées bancaires, suppression de données, publication de contenu, validation juridique, attribution de droits administrateurs ou signature. Ils ne sont pas forcément exclus, mais leur automatisation ne doit jamais être le point de départ d’un projet.

Enfin, une interface agentique ne compense pas une mauvaise expérience utilisateur. Si un formulaire est incompréhensible, si les règles métier sont opaques ou si le temps de réponse est mauvais, il faut traiter ces défauts directement. Les choix de rendu et de cache restent déterminants, comme le rappelle la réflexion sur l’edge rendering et son coût réel.

Sécurité : l’agent ne doit jamais devenir un raccourci d’autorisation

Un agent peut être influencé par du contenu qu’il lit : texte d’une page, pièce jointe, message de support ou donnée récupérée dans un outil tiers. C’est le problème des injections de prompt. Une instruction malveillante peut tenter de convaincre le modèle d’ignorer la demande initiale, d’exfiltrer une information ou de déclencher une action non prévue.

La défense ne consiste pas à demander au modèle d’être prudent. Elle se place dans l’architecture :

Appliquer les autorisations côté serveur, pour chaque appel, indépendamment de la décision prise par l’agent.
Limiter la portée des outils : un outil doit accomplir une action précise et éviter les paramètres ouverts du type « exécuter n’importe quelle requête ».
Éviter les secrets dans le contexte du modèle, y compris les clés d’API, jetons de session et données qu’un utilisateur n’a pas besoin de consulter.
Prévoir une confirmation humaine avant les opérations irréversibles ou ayant un impact financier, légal, public ou sensible.
Journaliser l’identité, l’outil appelé, les paramètres pertinents, le résultat et la décision de confirmation.
Imposer des limites de fréquence, de volume, de coût et de durée afin d’empêcher une boucle d’actions.

Les recommandations de l’OWASP pour les applications basées sur les modèles de langage constituent une base utile pour cadrer les risques, notamment les injections de prompt, la divulgation d’informations sensibles et l’excès d’autonomie. Elles ne remplacent toutefois pas une analyse des menaces propre au produit.

Une règle simple est particulièrement saine : l’agent peut proposer, le backend décide, l’utilisateur confirme lorsque l’enjeu l’exige. Un modèle ne doit pas être la source d’autorité sur un remboursement, une permission ou une donnée personnelle.

Permissions, consentement et lisibilité du parcours

Un agent agit pour une personne, mais cette délégation doit rester compréhensible. L’utilisateur doit savoir quel compte est utilisé, quelles données seront consultées et quel résultat est attendu. Une confirmation utile ne se résume pas à un bouton « Autoriser ». Elle indique clairement l’action : « créer un brouillon de commande de 3 articles », « transmettre cette demande au support » ou « modifier l’adresse de livraison associée à la commande concernée ».

Il faut distinguer au moins trois niveaux :

Lecture : consulter des informations déjà accessibles dans la session.
Préparation : créer un brouillon, calculer une simulation, produire une sélection ou configurer une action non appliquée.
Exécution : modifier un état, envoyer un message, générer un paiement, supprimer une ressource ou accorder un accès.

Chaque niveau doit avoir son propre seuil de contrôle. Une consultation peut être autorisée dans une session clairement identifiée. La préparation doit être visible et modifiable. L’exécution doit être confirmée dès que l’impact est significatif.

Cette transparence bénéficie aussi à l’accessibilité. Une interface agentique ne dispense pas de respecter les standards du web. Les formulaires, erreurs, récapitulatifs et confirmations doivent rester utilisables au clavier, compatibles avec les technologies d’assistance et conformes aux principes des Web Content Accessibility Guidelines (WCAG). Une expérience agentique ne doit pas créer un second parcours, moins accessible, pour accomplir la même tâche.

Fiabilité : traiter l’agent comme un client non déterministe

Une API reçoit des paramètres suivant un contrat connu. Un agent peut fournir une date ambiguë, choisir une mauvaise variante de produit, interpréter de travers une exception métier ou appeler un outil dans un ordre inattendu. Même avec une bonne description, il reste un client non déterministe.

Les outils doivent donc être conçus défensivement. Validez tous les paramètres côté serveur. Utilisez des valeurs structurées pour les identifiants, les devises, les dates et les statuts. Retournez des erreurs exploitables, sans révéler de détails internes. Pour les écritures, prévoyez l’idempotence : une même demande rejouée ne doit pas créer deux réservations, deux tickets ou deux prélèvements.

Il est aussi important de séparer la récupération d’information et la mutation. Un outil qui à la fois recherche une commande et annule l’expédition est difficile à sécuriser, à tester et à expliquer. Deux opérations distinctes permettent une étape de revue entre le diagnostic et l’action.

La qualité d’un contrat passe enfin par les tests. Une équipe peut constituer un jeu de scénarios comprenant des entrées valides, incomplètes, contradictoires, hors périmètre et malveillantes. Les résultats attendus ne concernent pas uniquement le succès : il faut vérifier les refus, les demandes de confirmation et l’absence de fuite de données.

Cette discipline est proche de celle nécessaire pour concevoir une API web rapide sans erreurs coûteuses. Les agents changent l’interface d’appel ; ils ne suppriment ni les contraintes de cohérence, ni les exigences de sécurité.

Une stratégie pragmatique pour expérimenter sans surarchitecturer

Le plus raisonnable est de démarrer avec un seul parcours, sur un périmètre contrôlé. Cherchez une tâche fréquente, mesurable et réversible. Par exemple : retrouver une facture dans un espace client, produire un brouillon de demande de support ou configurer un export sans l’envoyer automatiquement.

Avant d’écrire une ligne d’intégration, formalisez les éléments suivants :

l’intention utilisateur exacte ;
les données nécessaires et leur niveau de sensibilité ;
les rôles autorisés à utiliser l’outil ;
les règles métier déjà existantes à réutiliser ;
la condition de confirmation ;
le comportement en cas d’erreur, de doute ou de doublon ;
le signal de succès à mesurer.

Ensuite, créez une capacité métier étroite, adossée au backend existant. N’autorisez pas un accès direct à la base de données, ne reproduisez pas toute votre API et ne mélangez pas lecture, décision et action définitive dans un unique outil. Un adaptateur fin au-dessus d’un service métier testé est souvent plus sûr qu’une exposition brute d’endpoints.

Mesurez des éléments concrets : taux de finalisation du parcours, nombre de corrections avant confirmation, taux d’échec, sollicitations du support liées au flux, durée médiane pour atteindre le résultat, et incidents de sécurité ou d’autorisation. Si l’agent ne réduit pas une friction mesurable, l’intégration n’a probablement pas de raison de survivre au prototype.

Enfin, prévoyez un repli simple. Le parcours humain classique doit rester disponible. L’utilisateur doit pouvoir terminer l’opération sans l’agent, et l’équipe doit pouvoir désactiver la capacité sans casser le produit. Cette réversibilité est particulièrement importante tant que les standards, les implémentations de navigateurs et les modèles d’interaction continuent d’évoluer.

Conclusion : une couche utile seulement lorsqu’elle porte une vraie intention métier

WebMCP peut faire évoluer certaines interfaces web en donnant aux agents un accès plus explicite à des tâches utiles. Son intérêt est tangible pour la recherche d’informations autorisées, la préparation de brouillons, la configuration guidée et les parcours de support structurés. Il est beaucoup moins évident pour les interfaces simples, les intégrations système-à-système et les opérations irréversibles.

Le critère de décision reste pragmatique : une capacité agentique doit réduire une friction vérifiable, respecter les mêmes règles métier que l’interface humaine et ne jamais contourner les permissions. Commencez par une action étroite, traçable et réversible ; si elle apporte un gain mesurable, vous aurez une base solide pour aller plus loin sans ajouter du vernis technique inutile.