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.

EC2 gère désormais officiellement la virtualisation imbriquée.

L’option est activable dans toutes les régions commerciales AWS ; pour le moment sur trois familles d’instances en CPU Intel : les C8i, M8i et R8i. Elle donne le choix entre KVM et Hyper-V. Avec quelques limites, dont :

• Pas d’hibernation des instances
• Désactivation du mode VSM (Virtual Secure Mode) sur les instances Windows
• Absence de gestion des instances Windows à plus de 192 CPU

La virtualisation imbriquée constitue une alternative économique au bare metal pour exécuter des micro-VM (par exemple avec la technologie Firecracker d’AWS, qui nécessite KVM). Ou des outils de développement et de test logiciel – WSL2, émulateurs, pipelines CI/CD manipulant des images de VM…

La virtualisation imbriquée, apparue sur Azure et Google Cloud en 2017

Intégrée dans Windows Server 2022, la virtualisation imbriquée avait été lancée sur Azure dès 2017. Elle ne gère officiellement qu’Hyper-V, sur les processeurs Intel avec extensions VT-x ainsi que sur les EPYC et Ryzen d’AMD. Entre autres limites, elle ne gère pas la mémoire dynamique (obligation d’éteindre la VM hôte pour ajuster sa mémoire).

Google aussi avait commencé à intégrer la virtualisation imbriquée dans son cloud public en 2017, à base de KVM. Initialement, c’était pour les VM Linux reposant sur des CPU Intel de génération Haswell et ultérieures. Elle est maintenant généralisée, mais toujours pas gérée sur les processeurs AMD ou Arm – et pas utilisable avec les VM E2 et H4D, ainsi que celles à mémoire optimisée.

Google donne une estimation de la surcharge qu’implique la virtualisation imbriquée. Il annonce une baisse potentielle de performance d’au moins 10 % pour les workloads liés au CPU. Et éventuellement davantage pour ceux orientés I/O.
AWS a potentiellement attendu que le hardware permette de minimiser ces pertes… et de garantir un niveau de sécurité conforme à ses standards.

OCI gère aussi la virtualisation imbriquée, à base de KVM.

Illustration principale générée par IA

The post AWS rejoint Azure et Google Cloud sur la virtualisation imbriquée appeared first on Silicon.fr.