Avec les IA, mieux vaut parler Markdown que HTML.

Cloudflare, comme bien d’autres, invite à privilégier ce format. Tant pour la lisibilité que pour les économies de tokens. Jusque-là, il proposait une API de conversion intégrée notamment dans son offre Workers AI*.

S’y ajoute désormais une fonctionnalité « automatisée » intégrée à la console. Dite « Markdown for Agents », elle est en bêta, sans surcoût, pour les abonnés Pro, Business et Enterprise – ainsi que sur SSL for SaaS.

Sur les zones qui utilisent des en-têtes de négociation de contenu, elle déclenche – au possible – une conversion des pages HTML à la volée lorsqu’une IA exprime sa préférence pour le format Markdown. Cela passe par l’en-tête Accept et le paramètre text/markdown. Un système qu’exploitent déjà des agents tel Claude Code.

La réponse inclut systématiquement des en-têtes x-markdown-tokens et Content-Signal. Le premier donne une estimation du poids du document Markdown en tokens. Le second signale, par défaut, que le contenu peut être utilisé pour l’entraînement d’IA comme pour l’input (inférence) et pour les résultats de recherche.

* Cette option gère la conversion d’autres formats que le HTML, ainsi que le résumé du contenu.

À consulter en complément :

De l’UX à l’AX : penser les interfaces pour les agents IA
A2A, ACP, agents.json… Que deviennent ces protocoles agentiques ?
ROI de l’IA générative : la tentation du prisme court-termiste
Les acquisitions de Cloudflare sous l’ère ChatGPT

Illustration générée par IA

The post Les IA préfèrent Markdown : Cloudflare expérimente une conversion à la source appeared first on Silicon.fr.

Ajoutez une cinquantaine de lignes de code à votre site… et il devient un serveur MCP.

À l’été 2025, un développeur, ancien d’Amazon, avait lancé un projet open source portant cette promesse : MCP-B (« MCP for the Browser »). L’idée était d’exploiter JavaScript pour exposer les fonctionnalités de pages web aux agents IA directement dans les navigateurs. Le protocole sous-jacent s’appelait WebMCP. Il reposait notamment sur un mécanisme de transport permettant la communication client-serveur au sein d’un même onglet.

Un premier brouillon de spécification W3C

L’initiative existe toujours. Mais elle est aujourd’hui emmenée par Google et Microsoft, sous la bannière WebMCP et sous l’aile du W3C. Le fondement demeure : exposer des « outils » sous forme de fonctions JavaScript, avec des schémas structurés et des descriptions en langage naturel.

Une première ébauche de spécification vient d’être publiée. Elle introduit une interface window.navigator.modelContext. Et avec elle, plusieurs méthodes pour gérer la liste des outils :

• provideContext, pour l’actualiser intégralement
  Idéal pour les applications monopage, où il peut être souhaitable de présenter des outils différents en fonction de l’état de l’UI.
• registerTool et unregisterTool, respectivement pour ajouter et supprimer des outils sans réintialiser toute la liste

Les fonctions peuvent éventuellement être asynchrones. Il est possible d’en dédier la gestion à des workers.

Google propose depuis peu de tester WebMCP dans le programme EPP de Chrome, à travers deux API. Une déclarative pour permettre aux agents d’effectuer des actions standards définissables dans les formulaires HTML. Une impérative pour les interactions dynamiques nécessitant JavaScript.

La sécurité, pas encore au cœur des travaux

Sur le papier, WebMCP ouvre la voie à une codebase unique pour l’UI et l’intégration des agents. Tout en favorisant la confidentialité (traitement local) et la collaboration homme-machine (même interface, avec davantage de visibilité sur les actions).
L’arbitrage des accès est laissé au navigateur, qui peut appliquer ses propres politiques de sécurité. Cette intermédiation du flux de contrôle assure par ailleurs une rétrocompatibilité entre les versions de WebMCP.

Dans la pratique, il n’existe pas de mécanisme intégré pour synchroniser l’UI et l’état de l’application. Il n’en existe pas non plus pour découvrir les outils d’un site sans le visiter. Sur ce dernier point, le projet a exploré l’utilisation d’un manifeste que les agents récupéreraient en HTTP GET. Il l’a complété par un mécanisme d’exécution alternatif séparant la définition d’un outil et la fonction d’implémentation, en traitant les appels comme des événements.

La section sécurité/confidentialité de la spec est actuellement vide. Sur ce sujet, il y a, en l’état, bien plus de questions que de réponses. Des domaines d’attaque existants (CSRF, XSS…) s’appliqueraient-ils de façon spécifique à WebMCP ? Quels risques si on l’associe à d’autres fonctionnalités émergentes comme Web AI et la Prompt API ?…

Illustration générée par IA

The post Qu’est-ce que WebMCP, qui vise la standardisation W3C ? appeared first on Silicon.fr.