Depuis six mois, il existe une façon normalisée pour une page web de dire à une IA « voici ce que je sais faire », au lieu de la laisser deviner en lisant du texte. Elle est signée par les deux fabricants de navigateurs qui comptent. Nous avons mesuré qui s'en sert.
Par Marc, équipe marketing et marché d'Isoligne
Le 10 février 2026, le groupe communautaire Web Machine Learning du W3C a publié une proposition appelée WebMCP. Elle tient en une phrase : une page web peut déclarer des fonctions JavaScript qu'une IA appelle directement, au lieu de lire le texte de la page et d'essayer d'en déduire quoi faire.
Techniquement, la page appelle navigator.modelContext.registerTool()
et décrit chaque fonction, ses paramètres, ce qu'elle rend. Un agent qui visite la
page reçoit cette liste et peut s'en servir. La proposition est signée par des
ingénieurs de Microsoft et de Google, et elle est en essai grandeur nature dans
Chrome depuis mai 2026.
Ce qui nous intéresse ici n'est pas l'API. C'est ce qu'elle admet, et qui ressemble beaucoup à ce que nous mesurons depuis un an : un site n'est plus seulement un ensemble de pages à lire. C'est un ensemble de choses qu'on peut lui demander de faire.
Il faut être précis, parce que la confusion est facile et coûteuse.
Un outil WebMCP n'existe que dans un onglet ouvert. Il naît au chargement de la page, il meurt à la navigation, et aucun serveur ne peut le découvrir. Il n'y a pas de plan de site des outils, pas d'adresse à demander, rien à indexer.
Or les IA qui décident aujourd'hui d'un achat ne rendent pas les pages. ChatGPT, Claude, Perplexity et les résumés de Google vont chercher le HTML depuis leurs propres serveurs, sans exécuter le JavaScript. Pour eux, un site entièrement WebMCP est exactement aussi muet qu'avant.
WebMCP couvre donc un public réel mais différent : les agents qui naviguent, à la place de quelqu'un, dans un navigateur. C'est un public qui grandit. Ce n'est pas celui qui, cette année, envoie du chiffre d'affaires.
Nous publions depuis des mois un constat qui gêne : dans chaque marché que nous mesurons, une part des questions qui décident d'un achat n'a pas de réponse publiable. Pas parce que l'entreprise se cache : parce que la réponse dépend de celui qui demande. Un tarif pour un volume. Un délai pour un territoire. Une éligibilité pour une situation.
« J'ai une Renault d'occasion, j'habite à Paris, combien me coûterait une assurance de base incluant le vol ? » Aucune page ne portera jamais cette réponse, et ce n'est le défaut de personne. Une page publie d'avance ; cette réponse se calcule à la demande.
WebMCP est la première forme normalisée qui porterait ces réponses là. Un outil calcule. C'est exactement la différence.
Sur les marchés de ce relevé, 50 % des questions d'achat que nous avons posées sont dans ce cas. Ce sont, une par une, celles qu'un outil déclaré traiterait et qu'aucune amélioration de page ne traitera.
Nous avons relevé 70 domaines français au 30 août 2026, sur quatre marchés : assurance, énergie, enseignement supérieur et commerce. Soixante-cinq d'entre eux ont rendu un verdict ferme.
Un seul déclare un outil. C'est le nôtre.
Le détail : 61 sites ne déclarent rien, 3 n'ont pas pu être conclus parce que des scripts leur appartenant n'ont pas pu être lus, 1 déclare. Aucune banque, aucun assureur, aucun fournisseur d'énergie, aucune école du panel n'expose la moindre fonction appelable.
Ce n'est pas un reproche, et la date l'explique : la proposition a six mois et son essai grandeur nature en a trois. Le chiffre a une autre valeur. Il fixe un point de départ. Quand l'adoption bougera, on saura de combien, parce que ce relevé existe.
Nous lisons le JavaScript que le site sert, sans l'exécuter, et nous y cherchons
la marque d'entrée de la proposition : navigator.modelContext. C'est
la seule chaîne qui établisse quelque chose. Nous ne retenons pas
registerTool seul : c'est aussi le nom d'une méthode du kit de
développement MCP côté serveur, présente dans quantité de fichiers qui n'ont rien
à voir avec un navigateur. Le retenir aurait félicité des sites qui ne déclarent
rien.
Le verdict a trois états, et le troisième est le plus important :
Deux choses nous échappent par construction, et nous préférons les écrire que les laisser deviner. Un module chargé après coup, par import dynamique, n'est pas dans le code servi : nous ne le voyons pas. Et la proposition prévoit une forme déclarative, qui annoterait des formulaires HTML plutôt que d'appeler une fonction ; le nom de l'attribut n'étant pas encore stabilisé, nous ne le cherchons pas. Deviner un nom aurait produit des absences fausses, affirmées avec aplomb.
Les scripts hébergés chez des tiers ne sont pas lus, et ne comptent pas contre le site. Une régie d'analytique n'enregistrera jamais les outils de son client : c'est hors sujet, pas « non lu ».
Ce paragraphe existe parce que le chiffre de cet article a changé deux fois avant d'être juste, et que la raison n'était pas dans les sites mesurés.
Notre première mesure lisait au plus huit scripts par site. Presque tous les sites sont sortis « non concluant ». Nous avons porté la limite à vingt : presque tous sont restés « non concluant ». Le verdict était devenu un mot fixe, qui répondait sans informer.
La cause n'était pas la limite, c'était le critère. Un site mesuré sert quatre-vingt-seize scripts à lui seul, tous entre zéro et vingt kilo-octets : un gestionnaire de contenu qui ne regroupe pas ses fichiers. Un demi-méga-octet en tout, et nous refusions de conclure. Compter des fichiers n'a jamais mesuré ce qui coûte. Ce qui coûte, c'est la bande passante et le temps.
La mesure borne donc désormais des octets et des secondes, pas un nombre de fichiers. Les quatre-vingt-seize scripts se lisent en une seconde sept, et le verdict devient un constat au lieu d'un aveu. Une limite qu'on s'impose à soi-même et qu'on présente comme un résultat est le défaut le plus facile à commettre dans ce métier.
isoligne.com déclare ses outils depuis le 30 août 2026. Le script ne les définit pas : il demande la liste à notre propre serveur MCP au chargement et enregistre ce qu'il reçoit. Ajouter un outil au serveur l'ajoute au navigateur, en retirer un l'y retire. Une source, deux prises.
Notre propre mesure, appliquée à notre propre site, rend d'ailleurs un résultat qui mérite d'être cité : « le site appelle navigator.modelContext, mais les noms d'outils ne sont pas lisibles dans le code servi ». C'est exact, et c'est la conséquence directe du choix ci-dessus. Nous le laissons tel quel plutôt que d'inscrire les noms en dur pour faire meilleure figure.
Rien d'urgent, et surtout rien d'exclusif.
Adopter WebMCP aujourd'hui ne fera pas apparaître une entreprise dans une réponse de ChatGPT, et quiconque le promet se trompe ou trompe. La surface qui compte pour les moteurs de réponse reste ce qui se lit côté serveur : des pages qui disent quelque chose sans JavaScript, un fichier de déclaration, une carte d'agent, un point d'accès interrogeable.
Mais deux fabricants de navigateurs viennent d'écrire, dans un document du W3C, que le web a besoin de sites qui exposent des fonctions et pas seulement des textes. C'est la même phrase que celle qui ouvre nos relevés depuis un an, signée par d'autres. Une entreprise qui construit sa couche de réponse pour les moteurs d'aujourd'hui la branchera sur WebMCP en un après-midi le jour où ce sera utile. L'inverse n'est pas vrai : déclarer des outils quand on n'a rien à répondre revient à enregistrer un bouton « chercher sur le site », qui rend les mêmes pages qui ne répondaient déjà pas.
C'est l'ordre qui compte, et il n'a pas changé : d'abord avoir une réponse, ensuite multiplier les prises.
Nous lisons vos pages comme le fait un robot d'assistant, nous posons les questions de votre marché, et nous vous montrons ce qu'une IA répond à votre place.