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.
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 ?…
C’est une guerre froide au cœur de la révolution de l’intelligence artificielle. D’un côté, Anthropic, fondée par d’anciens chercheurs d’OpenAI, qui se veut le champion de l’IA « responsable ». De l’autre, Pete Hegseth, secrétaire à la Défense de Donald Trump, déterminé à placer l’IA au cœur de toutes les opérations militaires américaines.
Entre les deux, des mois de négociations tendues, un contrat à 200 millions $, et désormais une menace de rupture fracassante, révélée par Axios.
L’ultimatum Hegseth
Selon le média en ligne, Pete Hegseth est « proche » de couper les liens commerciaux avec Anthropic et d’aller beaucoup plus loin : désigner la société comme un « risque pour la chaîne d’approvisionnement ». Une mesure radicale qui contraindrait tous les sous-traitants du Pentagone à choisir leur camp et à couper à leur tour toute relation avec Anthropic s’ils veulent conserver leurs contrats militaires. Ce type de sanction est habituellement réservé aux adversaires étrangers, comme la Chine ou la Russie.
Un haut responsable du Pentagone a confié à Axios, sans prendre de gants : « It will be an enormous pain in the ass to disentangle, and we are going to make sure they pay a price for forcing our hand like this. » Traduction libre : ce sera une immense pagaille à démêler, et le Pentagone compte bien faire payer à Anthropic le fait de l’avoir contraint à agir.
Le porte-parole en chef du Pentagone, Sean Parnell, a confirmé la mise sous revue de la relation : « Notre nation exige que ses partenaires soient prêts à aider nos soldats à gagner dans n’importe quel combat. En définitive, il s’agit de nos troupes et de la sécurité du peuple américain. »
La ligne rouge de Dario Amodei
Qu’est-ce qui a bien pu provoquer une telle escalade ? Le point de friction central est simple à énoncer, mais complexe à trancher : Anthropic refuse de laisser le Pentagone utiliser Claude « à toutes fins légales (all lawful purposes) ». La formule, apparemment anodine, recouvre en réalité deux lignes rouges qu’Anthropic refuse de franchir : la surveillance de masse des citoyens américains et les armes létales entièrement autonomes, c’est-à-dire des systèmes capables de tuer sans intervention humaine.
Mais selon une source proche du dossier citée par Axios, les hauts responsables de la défense étaient frustrés par Anthropic depuis un certain temps et ont « saisi l’opportunité de déclencher un affrontement public ». Autrement dit : la crise n’est pas totalement spontanée. Elle a été, au moins en partie, délibérément orchestrée par le Pentagone.
Pour justifier sa prudence, un responsable d’Anthropic a expliqué à Axios que les lois existantes « n’ont en aucune façon rattrapé ce que l’IA peut faire ». Le risque est concret : avec Claude, le Pentagone pourrait analyser en continu l’ensemble des publications sur les réseaux sociaux de chaque Américain, croisées avec des données publiques comme les listes électorales, les permis de port d’arme ou les autorisations de manifestation, pour établir automatiquement des profils de surveillance civile. Une perspective qui alarme bien au-delà d’Anthropic.
Claude, seul modèle dans les systèmes classifiés
L’ironie de la situation, c’est qu’Anthropic occupe aujourd’hui une position stratégique unique au sein de l’appareil militaire américain. Selon Axios, Claude est le seul modèle d’IA actuellement disponible dans les systèmes classifiés de l’armée américaine. Mieux : la technologie est profondément intégrée dans les opérations militaires, et huit des dix plus grandes entreprises américaines utilisent Claude dans leurs workflows. Rompre avec Anthropic serait, admet même un haut responsable de l’administration, « une complication » : « Les modèles concurrents sont tout simplement en retard sur les applications gouvernementales spécialisées. »
C’est précisément ce levier qu’a utilisé le Pentagone pour muscler ses négociations avec OpenAI, Google et xAI. Les trois ont accepté de lever leurs garde-fous pour les systèmes non classifiés. Le Pentagone se dit confiant qu’ils accepteront également le standard « all lawful use » pour les systèmes classifiés. Mais une source proche de ces discussions tempère : beaucoup de choses restent encore à décider avec ces trois acteurs. Et aucun n’est pour l’instant présent sur les réseaux classifiés — le domaine réservé d’Anthropic.
L’ombre de l’opération Maduro
Le bras de fer a pris une tournure plus dramatique encore avec la révélation que Claude avait été utilisé lors de l’opération militaire américaine ayant conduit à la capture du président vénézuélien Nicolás Maduro en janvier dernier, via le partenariat d’Anthropic avec la société de logiciels Palantir.
Selon Axios, un cadre d’Anthropic a pris contact avec un cadre de Palantir après coup pour s’enquérir de l’usage qui avait été fait de Claude lors du raid; Une démarche interprétée par les responsables du Pentagone comme une désapprobation implicite. « Cela a été soulevé d’une manière à suggérer qu’ils pourraient ne pas approuver l’utilisation de leur logiciel, car il y a eu des tirs réels lors de ce raid, des gens ont été blessés », a déclaré le responsable américain.
Anthropic a nié avoir « discuté de l’utilisation de Claude pour des opérations spécifiques avec le Département de la guerre », selon son porte-parole.
Face à l’escalade, Anthropic reste officiellement serein. « Nous avons des conversations productives, de bonne foi, avec le Département de la guerre pour continuer notre travail et traiter correctement ces problèmes nouveaux et complexes », a indiqué un de ses porte-parole. Et d’affirmer que l’entreprise restait « engagée dans l’utilisation de l’IA de pointe au soutien de la sécurité nationale américaine » soulignant au passage qu’Anthropic a été le premier à déployer son modèle sur des réseaux classifiés.
La souveraineté numérique n’est plus seulement un objectif stratégique optionnel pour les entreprises européennes, mais une exigence de conformité. Les différents cadres réglementaires en vigueur (NIS2, DORA, Cyber Resiliency Act au niveau européen, SecNumCloud au niveau local…) incluent des exigences précises en matière de transparence, de traçabilité et de réversibilité des infrastructures numériques.
Pour les intégrer à leur stratégie et se mettre en conformité, l’open source apparaît comme l’une des approches technologiques les plus viables pour les entreprises, car elle adresse trois piliers fondamentaux de la souveraineté numérique : offrir des solutions pour s’aligner avec la conformité réglementaire, faciliter la résilience opérationnelle et favoriser l’indépendance technologique. Le choix de l’open source, en plus d’aider à protéger les entreprises des risques réglementaires actuels, constitue une solution d’avenir sur le long terme.
Conformité réglementaire et obligations légales
L’Union européenne impose désormais un cadre réglementaire qui structure les choix technologiques des entreprises : NIS2 a pour objectif de minimiser les risques pour les SI des organisations essentielles (états, fournisseurs d’énergie ou télécoms) et impose une gestion auditable de la sécurité ; DORA, sa déclinaison pour les institutions financières, met en avant la résilience tant technique que opérationnelle et impose à ce titre de diversifier les fournisseurs tout en démontrant la réversibilité des briques de son SI ; enfin, le Cyber Resiliency Act (CRA) exige une cartographie exhaustive des composants logiciels, incluant leur cycle de vie et la mise à disposition des correctifs de sécurité.
Suivant leur secteur ou leurs enjeux en termes de souveraineté, les organisations et les entreprises peuvent être tenues de permettre un basculement rapide vers un autre prestataire de services en cas d’incident – ce qui nécessite d’éviter toute concentration chez un même fournisseur – ou encore à privilégier la portabilité des données et des applications dans un souci de réversibilité.
L’open source aide à répondre à ces obligations, car le code source ouvert permet l’auditabilité par des tiers indépendants; les licences encadrant l’usage de l’open source permettent également de continuer à utiliser les technologies indépendamment de l’existence d’un contrat de support avec des éditeurs ; enfin, la nature même du logiciel open source et la mise à disposition d’outils spécifiques facilitent grandement l’inventaire et l’audit des composants logiciels fréquemment exigés dans le cadre des réglementations.
Résilience opérationnelle et indépendance technologique
Les entreprises considérées comme critiques – notamment le secteur bancaire dans le contexte de DORA – ont l’obligation d’intégrer la notion de risques liés aux fournisseurs, et donc à éviter de concentrer leurs actifs informatiques auprès d’un seul opérateur de cloud, afin d’éviter de subir une interruption de service sur leurs activités.
Les exigences peuvent parfois être plus fortes, notamment pour les secteurs sensibles et critiques comme la défense, où les contraintes de sécurité et de souveraineté peuvent imposer de pouvoir continuer à fonctionner en cas de coupure totale d’internet, ce qui signifie que les services habituellement fournis par un cloud hyperscaler doivent pouvoir être répliqués en interne (mode “air-gapped”).
Une exigence que l’open source permet d’appliquer, car il fonctionne indépendamment d’une connexion internet ou d’une relation contractuelle avec un fournisseur, peut être déployé sur des datacenters souverains opérés par des prestataires européens, et offre une disponibilité technologique même si le fournisseur cesse ses activités.
Transparence, traçabilité et auditabilité
Sur le plan technologique, la souveraineté repose sur trois piliers : la transparence, la traçabilité et la réversibilité. Si les solutions propriétaires ne donnent pas l’accès au code source, limitant ainsi l’audit aux seuls comportements observables, les fournisseurs tout comme les utilisateurs ont beaucoup plus de difficultés à détecter les vulnérabilités cachées ; une opacité qui n’est pas acceptable pour les entreprises considérées comme critiques.
De son côté, l’open source permet l’auditabilité : le code est consultable par des tiers indépendants, les modifications sont documentées et traçables, et les vulnérabilités découvertes peuvent être corrigées sans devoir attendre la réaction du fournisseur.
Grâce à l’open source, les entreprises dont l’activité commerciale est centrée sur le logiciel peuvent également générer de façon automatique une cartographie complète de leurs composants applicatifs, une responsabilité qui leur incombe vis à vis de leurs clients et leurs utilisateurs selon les exigences du Cyber Resiliency Act, et ainsi identifier systématiquement les vulnérabilités.
Face aux risques de sécurité, aux exigences réglementaires toujours plus précises et strictes, et à la menace d’amendes prononcées par les autorités pour sanctionner les cas de non-conformité, les entreprises ont encore trop souvent tendance à choisir des solutions propriétaires. Si l’approche open source représente un territoire inconnu, notamment pour les organisations qui ne l’ont pas encore déployée et qui manquent de maturité en la matière, elle offre une véritable flexibilité.
L’Union européenne soutient d’ailleurs activement cette voie par des initiatives (notamment l’European Open Digital Ecosystem Strategy). Dans ce contexte, investir dans le logiciel open source, en particulier pour les organisations critiques et d’importance stratégique, permet de faire face aux risques réglementaires actuels et de demain.
*David Szegedi est Chief Architect – Field CTO Organisation chez Red Hat
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.
Connexion
