WebMCP : ce que dit vraiment la spec, et ce que nous avons implémenté

Ce que WebMCP change, concrètement

Un site parle aujourd'hui à deux publics : des humains, et des robots qui lisent. Pour les seconds, le travail est connu — balisage structuré, contenu propre, fichiers de contexte. L'agent lit, interprète, résume, et se trompe parfois. WebMCP introduit un troisième public : des agents qui n'interprètent plus, ils appellent. Le site déclare des fonctions typées, l'agent les exécute et reçoit une réponse structurée. La différence n'est pas cosmétique. Quand un agent lit une page de tarifs, il produit une paraphrase dont personne ne contrôle l'exactitude. Quand il appelle une fonction, il obtient la valeur exacte, avec sa source.

• Lecture : l'agent devine à partir du texte, et la marge d'erreur est la vôtre à assumer.
• Appel : l'agent reçoit la valeur que vous calculez, avec l'origine qui l'a produite.
• L'API est purement additive — un navigateur qui ne la connaît pas affiche le site à l'identique.

Trois erreurs qu'on lit partout

La spécification bouge vite : environ un changement cassant par trimestre depuis 2025. La conséquence est que la majorité des guides publiés en 2026 sont déjà faux sur au moins un point structurant. Nous avons relevé les trois plus fréquents en lisant la spécification et la documentation Chrome directement, plutôt qu'en recopiant des articles.

Le cycle de vie, en une capture

L'enregistrement tient en un appel. Ce qui compte n'est pas sa longueur mais ce qu'il implique : les outils sont attachés au document, pas au site. Ils disparaissent à chaque navigation et doivent être réenregistrés. Le désenregistrement, lui, ne passe plus par une méthode dédiée — unregisterTool a été retiré en avril 2026 au profit d'un signal d'abandon, après la suppression de provideContext un mois plus tôt.

• Un appel registerTool par outil : l'enregistrement en lot n'existe plus.
• Un AbortController partagé, dont l'abandon désenregistre tout au démontage.
• Le navigateur ne valide pas les entrées contre votre schéma : la validation vit dans votre code.
• Les descriptions ont un budget : 30 caractères pour un nom, 500 pour une description, 1 500 pour une sortie.

Ce que nous exposons, et pourquoi ces quatre-là

Nous avons choisi quatre fonctions qui partagent trois propriétés : elles calculent, elles ne modifient rien, et elles reposent sur des données que nous publions déjà. Aucune ne touche à une donnée personnelle, aucune ne déclenche d'action. C'est le profil le plus sûr qu'un site puisse exposer, et il correspond exactement à ce que la spécification recommande d'annoter en lecture seule.

• benchmark-cpl-maroc — les coûts médians par lead, par mille impressions, par clic et le retour sur dépense d'un secteur.
• simuler-budget-google-ads — clics, conversions et coût par acquisition attendus pour un budget mensuel.
• comparer-seo-google-ads — le coût du même trafic acheté ou construit, avec le point de bascule.
• calculer-roi-leads — leads, clients et chiffre d'affaires projetés à partir d'un trafic et d'un taux de conversion.

La règle que nous nous sommes imposée : jamais deux vérités

Le risque principal d'une implémentation WebMCP n'est pas technique, il est éditorial. Si l'outil exposé à l'agent et l'interface visible ne partagent pas le même calcul, ils divergeront un jour — et vous aurez deux chiffres officiels contradictoires sur le même site, l'un affiché à vos visiteurs, l'autre récité par un assistant. Nous avons donc extrait les calculs dans un module unique, consommé à la fois par l'interface et par les outils. La divergence n'est pas surveillée : elle est rendue impossible par construction.

• Une seule implémentation du calcul, partagée entre l'écran et l'agent.
• Toute la surface d'API instable est isolée dans une façade unique, pour que le prochain changement de spec ne touche qu'un fichier.
• Les valeurs affichées après refactorisation ont été comparées à celles d'avant : identiques.

Le piège qui aurait tout rendu inerte

Le jeton d'origin trial se transmet par une balise meta dans le HTML. Nous l'avons donc placé dans une variable d'environnement de build — et c'est précisément là que la mise en place échoue silencieusement chez la plupart de ceux qui la tentent. Notre chaîne d'intégration continue construit le site sans injecter de variables : le jeton présent en local aurait disparu en production, sans message d'erreur, sans build cassé, sans rien d'observable. La fonctionnalité aurait simplement été absente. Un jeton d'origin trial étant public par nature — il est servi à tous les visiteurs — nous l'avons versionné avec le code, en documentant sa date d'expiration.

• Vérifiez toujours la présence de la balise dans le HTML livré en production, pas seulement en local.
• Un jeton d'origin trial n'est pas un secret : le traiter comme tel crée le bug plutôt qu'il ne l'évite.
• Notez la date d'expiration quelque part : la nôtre tombe le 17 novembre 2026.

Faut-il s'y mettre maintenant ?

Soyons clairs sur le rendement. Aucun agent grand public ne consomme aujourd'hui les outils WebMCP : ni les assistants conversationnels, ni les moteurs de recherche génératifs. Le consensus du secteur situe l'usage réel à douze ou dix-huit mois. Implémenter aujourd'hui n'apporte aucun trafic, aucun classement, aucun lead. Ce que cela apporte est différent et se mesure autrement : la connaissance de première main d'une interface que vos concurrents découvriront plus tard, et la position de celui qui a déjà résolu les problèmes que les autres rencontreront. Si votre métier est la technique, cet argument suffit. Si votre métier est ailleurs, attendez.

• Aucun gain de trafic ni de position à court terme : l'annoncer autrement serait malhonnête.
• La spécification reste un brouillon hors voie des standards — elle peut encore changer ou être abandonnée.
• Le coût d'entrée est faible si vos fonctions existent déjà ; il est élevé s'il faut les inventer pour l'occasion.