Ne cherchez plus le VDDK (Virtual Disk Development Kit) sur le portail développeurs de Broadcom : les liens de téléchargement publics sont morts.
Cette bibliothèque permet d’accéder aux disques virtuels VMware en dehors de l’hyperviseur. Elle alimente quantité d’outils de migration de VM.
Après des années de disponibilité ouverte, Broadcom explique désormais que le VDDK ne se destine pas aux clients finaux. Il dit le réserver à ses partenaires technologiques, pour le développement de solutions de sauvegarde.
En conséquence, les modos du subreddit VMware ont supprimé des messages, au motif que le règlement interdit de discuter de sujets qui touchent au programme partenaires. Le groupe américain a fait la chasse aux liens de téléchargement externes, entre autres sur Internet Archive.
De Red Hat à Nutanix, apprendre à faire sans VDDK
L’initiative a des répercussions sur les outils qui demandent à l’utilisateur d’apporter sa propre copie du VDDK. AWS Transform MGN (ex-Application Migration Service) en fait partie. La documentation invite en tout cas encore à télécharger la bibliothèque via le portail Broadcom. Ce n’est toutefois nécessaire que pour une migration sans agent. Une option qu’AWS ne recommande que pour des cas particuliers. Par exemple l’existence d’OS non gérés ou de politiques interdisant l’installation d’agents.
Red Hat est aussi concerné avec son Migration Toolkit. L’éditeur affirme œuvrer à éliminer la dépendance au VDDK. En attendant, il conseille d’utiliser la fonction dite storage copy offload. Elle exploite la commande XCOPY du protocole SCSI pour transmettre les données directement entre baies de stockage.
Même solution de repli (clonage entre baies) pour l’outil Nutanix Move. La méthode par défaut utilise le VDDK. Nutanix appelle sa communauté à s’abstenir de distribuer des copies de la bibliothèque et des liens de téléchargement non officiels.
ShapeBlue est un intégrateur Apache CloudStack britannique. Son outil de migration vers KVM exploite le VDDK à travers le moteur virt-v2v. Plus précisément, deux des quatre méthodes prises en charge… dont la plus efficace, qui élimine la phase d’export OVF en diffusant directement les blocs depuis l’hyperviseur vers le pipeline de conversion. La redistribution étant interdite, aucune distro Linux, aucune image de conteneur n’embarque le VDDK, note-t-il.
Avec l’accord de Broadcom, les fournisseurs de solutions de sauvegarde peuvent intégrer la bibliothèque dans leurs installeurs. Parmi eux, Veeam, dont les ISO suscitent ainsi quelque convoitise…
Plutôt que de charger les skills d’un seul coup, divulguons-les progressivement.
Le standard Agent Skills, publié fin 2025 par Anthropic, met en œuvre ce principe. Il utilise un frontmatter YAML pour les métadonnées (nom + description) et un corps Markdown pour les instructions. Un agent ne récupère ces dernières que lorsque c’est pertinent pour lui. Idem pour les ressources additionnelles (scripts, documentations API…), qu’on place dans des sous-dossiers. Principal bénéfice : optimiser l’occupation de la fenêtre de contexte.
VMware le prend désormais en charge dans son harnais agentique pour Tanzu Platform. Ce harnais fait partie d’un buildpack lancé au printemps avec une promesse : favoriser le développement d’agents, en y associant modèles, skills, serveurs MCP et autres services.
La VMware Explore 2026 a été l’occasion de mettre en avant quelques évolutions fonctionnelles du buildpack depuis son lancement (officiellement, il reste en « aperçu technique »). En particulier, l’ajout d’un module de mémoire courte et longue fondé sur du stockage durable. Sur la roadmap, il y a, entre autres, un mécanisme de réglage du niveau d’autonomie des agents.
Des « fondations agentiques », puis des « fondations data »
Tanzu Platform s’enrichit sur d’autres fronts. Sa passerelle MCP, par exemple, accueille des capacités de filtrage d’outils à base de regex.
Cette passerelle est l’une des briques que VMware a réunies sous la bannière des « fondations agentiques » pour Tanzu Plaform. Elles trouvent un prolongement avec les « fondations data ». Dans les grandes lignes, une boîte à outils MLOps allant de l’ingestion multimodale avec requête fédérée à la création de produits de données – à l’aide d’un éditeur SQL avec flux de type notebook – puis leur publication sur la marketplace Tanzu.
Depuis début 2026, on peut publier des serveurs MCP sur cette marketplace. Les agents suivront, promet VMware. En attendant, l’éditeur rappelle avoir étendu le catalogue de services disponibles, avec des références comme Cassandra, Neo4j et OpenSearch.
L’AI Factory… avec AMD
Ainsi doté, Tanzu Platform peut se superposer à VCF dans le cadre d’une plate-forme d’inférence : VMware Private AI Cloud.
Il ne s’agit pas tant d’une offre que d’une marque ombrelle. Elle se trouve au croisement de VCF et du portefeuille Private AI Services qui y a été intégré (on ne peut plus l’acheter séparément).
Une autre marque émerge pour couvrir la partie infra : VMware AI Factory. Elle est dans la continuité de l’add-on Private AI Foundation with NVIDIA lancé en 2024… sauf que c’est AMD qui est dans la boucle. Ses GPU Instinct sont déjà officiellement pris en charge sur VCF depuis quelques mois. Mais avec AI Factory, VMware les intègre dans un système automatisé, à commencer par le provisionnement des clusters vSphere et des VKS. Il développe surtout une logique de model-as-a-service, en prévoyant notamment :
Centralisation de catalogues externes (Hugging Face, NGC…)
Partage des modèles entre locataires
Gateway
Sandbox de code
Autoscaling vertical sur seuils de latence et de sessions
Prise en compte de la topologie dans les DRA vSphere et le planificateur K8s
VMware rappelle proposer un catalogue de « plus de 150 » modèles open source validés pour VCF. À l’occasion de l’Explore 2026, il en a mis quelques-uns en avant : GLM 5.2, Qwen3.8-27B et les familles Nemotron 3 (NVIDIA), Gemma 4 (Google) et cotomi (NEC ; LLM optimisés pour le japonais).
Broadcom rejoint la bataille des plans de contrôle agentiques
Entre l’infrastructure et la plate-forme agentique, VMware intecale une couche de sécurité. Parmi les nouveautés promises, du virtual patching avec vDefend à base de génération automatisée de signatures IDPS.
La maison mère Broadcom dégaine quant à elle son propre plan de contrôle, conteneurisé : AgentMinder. Elle affirme que son propre déploiement gère plus de 40 millions d’appels API par jour sur 20 millions d’identités. Elle annonce également une offre qui dépasse le cadre des projets IA : TrueSource, segmentée en trois produits axés sur la sécurité de la chaîne d’approvisionnement open source :
Spring Enterprise (dont Broadcom assure la maintenance)
Trusted Artifacts (bibliothèques Java, Python et Node.js de niveau 3 SLSA + le catalogue d’images de conteneurs de Bitnami)
TrueSource pour les moteurs de bases de données (PostgreSQL, MySQL, Valkey et RabbitMQ, avec automatisation du déploiement)
Microsoft s’apprête à retirer la version « licences incluses » de son service Azure VMware Solution (AVS). C’était l’une des toutes dernières solutions permettant d’acquérir des produits VMware en dehors des offres groupées imposées par Broadcom.
Jusqu’à présent, AVS représentait une alternative de choix pour les organisations souhaitant conserver leurs environnements VMware dans le cloud sans avoir à basculer vers VMware Cloud Foundation (VCF), la grande suite cloud hybride de Broadcom.
L’offre cloud de Microsoft comprenait ainsi les licences pour vCenter, vSAN, vSphere et NSX, mais n’intégrait pas le Software-Defined Datacenter Manager, l’outil utilisé par Broadcom pour centraliser la gestion de son offre phare VCF.
Depuis son acquisition de VMware, Broadcom a misé toute sa stratégie sur VCF et a mis fin à la vente de produits de virtualisation de serveurs d’entrée de gamme de manière isolée.
À titre d’exemple, les licences pour vSphere Foundation ne sont presque jamais vendues seules, à moins d’être intégrées dans un accord plus vaste comprenant VCF.
Déterminé à imposer l’ensemble du bundle VCF, Broadcom a procédé à des modifications contractuelles empêchant désormais ses partenaires hyperscalers de revendre des licences VMware. Les clients sont par conséquent tenus d’apporter leurs propres licences VCF (BYOL) pour accéder aux services VMware hébergés dans le cloud.
« Bring Your Own License » (BYOL), la nouvelle norme
D’autres géants du cloud avaient d’ailleurs déjà dû s’adapter à cette exigence, annoncée par Broadcom à la fin de l’année dernière.
Microsoft a clarifié le calendrier d’arrêt de son service historique:
> 31 octobre 2026 : arrêt de la commercialisation de la version d’AVS incluant les licences. > 30 août 2027 date limite pour les clients actuels, qui devront avoir acquis une licence VCF et effectué leur transition.
Microsoft appelle ses utilisateurs à anticiper cette migration au plus vite. « Prévoyez suffisamment de temps pour acheter les licences VCF auprès de Broadcom et achever la transition vers AVS VCF BYOL », prévient l’éditeur.
Les clients évaluant des opportunités de modernisation sont invités à analyser leurs environnements AVS immédiatement et à élaborer une feuille de route pour éviter toute interruption de service le 31 août 2027, date à laquelle leurs installations actuelles cesseront de fonctionner.
Pour certains clients, il ne s’agira pas de leur première migration VMware récente, Broadcom ayant déjà poussé par le passé de petits fournisseurs cloud à interrompre leurs services.
Une situation assumée par Broadcom, qui cible ouvertement les grands comptes susceptibles de tirer un bénéfice maximal de VCF, soulignant que l’augmentation des revenus de VMware valide aujourd’hui sa stratégie.
L’IA ne mobilise plus seulement des ingénieurs et des puces électroniques. Elle est aussi un terrain d’innovation financière.
Le Financial Times ( FT) révèle que Google a mis en place un dispositif de financement d’une ampleur inédite, représentant près de 200 milliards $ de contrats, afin de soutenir le déploiement massif de ses puces spécialisées en IA, connues sous le nom de Tensor Processing Units (TPU), historiquement réservées à ses propres usages et développées avec Broadcom..
L’opération dépasse largement le cadre d’une simple relation commerciale entre le troisième hyperscaler mondial et l’inventeur de Claude. Outre Google, elle associe Broadcom, la banque Morgan Stanley et les fonds Apollo et Blackstone. On retrouve aussi plusieurs opérateurs de centres de données dans une architecture financière destinée à financer les infrastructures nécessaires à l’entraînement des modèles d’IA de nouvelle génération.
Selon le quotidien britannique, environ 150 milliards $ du dispositif concernent directement les TPU.
Un modèle inspiré du financement dans l’aéronautique
Le défi est autant financier qu’industriel. Anthropic affiche des besoins de calcul comparables à ceux des plus grands hyperscalers sans disposer de leur capacité financière ni d’une notation de cré
Pour éviter que Google ou Broadcom n’inscrivent des dizaines de milliards de dollars d’équipements à leur bilan, les partenaires ont retenu un modèle inspiré du financement des avions commerciaux.
Le principe est le suivant : Google vend les TPU à Broadcom qui les revend ensuite à un véhicule financier (SPV). Ce dernier est financé par de la dette privée apportée principalement par Apollo et Blackstone. Le SPV loue ensuite les équipements à Anthropic.
Ce mécanisme permet de transformer un investissement massif en contrat de location, tout en répartissant les risques entre plusieurs acteurs financiers.
D’après le FT, la solidité du montage repose précisément sur cette répartition des engagements.
Google garantit les contrats de location des centres de données destinés à accueillir les TPU. Broadcom apporte une garantie sur la valeur résiduelle des équipements. Cela implique que si Anthropic cessait de payer ses loyers et que les puces perdaient de la valeur lors de leur revente, Broadcom couvrirait une partie des pertes des investisseurs les plus exposés.
Morgan Stanley a structuré les véhicules de financement, tandis qu’Apollo et Blackstone apportent l’essentiel des capitaux via des fonds spécialisés dans la dette privée.
Les mineurs de cryptomonnaies changent de métier
L’enquête du quotidien britannique décrit une première opération portant sur 35 milliards $ d’équipements, représentant environ un million de TPU, soit près d’un gigawatt de puissance informatique.
Une seconde vague de déploiement atteindrait 3,5 gigawatts supplémentaires.
Broadcom fait par ailleurs état, dans ses documents financiers, de 128 milliards $ d’engagements d’achat, dont 55,2 milliards doivent être livrés en 2027 et 72,9 milliards en 2028. Des montants qui correspondent aux TPU destinés à Anthropic.
Le financement des puces ne résout toutefois qu’une partie de l’équation. Encore faut-il disposer de centres de données alimentés en électricité pour les exploiter.
Pour accélérer les déploiements, Google s’appuie sur plusieurs entreprises historiquement spécialisées dans le minage de cryptomonnaies, dont TeraWulf, Cipher Digital et Hut 8 qui disposent déjà de capacités électriques importantes, désormais reconverties vers les infrastructures IA.
Selon le FT, Google garantit les loyers des centres de données construits pour Anthropic, permettant d’obtenir des financements obligataires ou bancaires à de meilleures conditions.
Le quotidien identifie cinq projets totalisant 1,4 gigawatt de capacité ayant déjà levé 15 milliards $ de dette, tandis que Google aurait accordé des garanties sur dix projets représentant 2,4 gigawatts.
Chaque acteur prend sa part du risque
Au-delà des volumes de calcul, ce montage pourrait également constituer un avantage concurrentiel pour Google Cloud.
Le FT cite une analyse de Jefferies selon laquelle les projets bénéficiant des garanties de Google empruntent à un taux médian de 7,1 %, contre 9,3 % pour les opérateurs de centres de données bâtissant leurs infrastructures autour des GPU Nvidia.
Cette différence de coût du capital pourrait, selon la banque, devenir un avantage structurel pour l’écosystème Google.
L’enquête met en lumière la financiarisation des infrastructures d’IA. Pour absorber l’explosion des besoins de calcul, les hyperscalers s’appuient désormais sur des montages associant banques, fonds de dette privée, industriels et opérateurs de centres de données.
En attendant d’ouvrir une enquête formelle contre Broadcom, prière d’imposer des mesures intérimaires.
La Commission européenne a reçu, la semaine passée, une lettre à ce sujet. Signataires : le Cigref et trois de ses homologues (en Allemagne, en Belgique et aux Pays-Bas), ainsi que l’association CISPE, qui défend les intérêts des fournisseurs cloud européens.
Voilà des mois que cette dernière sollicite les mesures en question. Elles consisteraient principalement à :
Geler la suspension du programme VCSP (VMware Cloud Service Partner) en Europe et y réintégrer les clouders européens
Réintroduire le programme de marque blanche qui permettait aux plus petits CSP de proposer les solutions VMware
Établir des protections explicites contre d’éventuelles représailles de la part de Broadcom
L’association vise plus globalement l’obtention de conditions commerciales plus raisonnables. Et leur maintien pour au moins 3 ans, le temps de s’adapter… ou d’aller voir ailleurs.
La piste du DMA, vite évoquée, vite écartée
Broadcom avait bouclé l’acquisition de VMware en novembre 2023. Avec les chamboulements que l’on sait, CISPE n’avait pas tardé à lever la voix. Au printemps 2024, il avait appelé régulateurs, législateurs et tribunaux européens à s’enquérir de la situation. Ses principales doléances portaient alors sur :
Résiliation unilatérale de contrats de licence avec seulement quelques semaines de préavis
Suppression de centaines de produits sans préavis
Regroupement des autres en des bundles faisant exploser la facture sans amélioration fonctionnelle
Flou sur les conditions d’admission dans les nouveaux programmes partenaires
Estimant que Broadcom « [prenait] le secteur en otage », CISPE avait suggéré de le désigner contrôleur d’accès dans le cadre du DMA (législation sur les marchés numériques). Il avait aussi demandé la suspension des résiliations de contrats. Et la possibilité, pour les clients, de sortir des engagements pluriannuels une fois que des solutions alternatives viables seraient disponibles.
La Commission européenne avait finalement entrepris de réunir des témoignages. Peu après l’ouverture de cette RFI (request for information), Broadcom avait fait quelques concessions. Dont la promesse de continuer à corriger les failles critiques dans ses produits sous licences perpétuelles.
Non sans dénoncer une démarche opportuniste, CISPE avait qualifié les changements de « mineurs » : ils ne résolvaient rien des problèmes précédemment soulevés. L’association en avait ajouté un : la modification de la base de facturation. Au lieu d’un modèle pay-as-you-go basé sur la mémoire utilisée, les partenaires devaient s’engager pour 3 ans sur une capacité prévisionnelle de cœurs CPU.
Un « observatoire » aux conclusions lapidaires
En novembre 2024, CISPE avait monté un observatoire chargé d’examiner la concurrence sur le marché du cloud en Europe. Il devait, en premier lieu, superviser les engagements de Microsoft. Il a toutefois aussi inclus Broadcom dans son périmètre.
Son premier rapport, tombé en février 2025, fut lapidaire : pas de perspectives de négociation avec Broadcom. À ce moment-là, des procédures avaient été engagées auprès de tribunaux de commerce, notamment en France (Orange, Thales). Eles visaient en général à préserver des conditions de licence antérieures… en attendant la négociation de nouvelles conditions « plus justes ». Ou bien à obtenir un délai pour migrer vers des solutions alternatives.
L’observatoire avait fait remarquer les « tactiques dilatoires » employées par Broadcom dans le cadre de ces litiges afin de retarder les décisions sur le fond. Dans la plupart des cas, avait ajouté CISPE, les parties concernées n’avaient pas osé aller en justice par peur de représailles. D’autant plus que, prétendait-il, la pression ne se limitait pas aux licences VMware – elle s’étendait aussi, notamment, aux logiciels mainframe.
Les programmes partenaires, progressivement intégrés au cahier de doléances
Le deuxième rapport, en mai 2025, ne fut pas plus reluisant. Les charges s’alourdirent même. Entre autres parce que depuis peu, les CSP partenaires de VMware devaient choisir entre les statuts de fournisseur de services et de revendeur, en conséquence d’une modification des structures d’incitation.
CISPE avait admis que depuis la publication du premier rapport, la majorité de ses membres avaient signé de nouveaux accords de licence. Mais on leur avait largement forcé la main, clamait l’association, faute d’un préavis suffisant.
Pour la plupart des cas d’usage, il n’existe pas d’alternative fonctionnellement équivalente, constatait-elle. Quant à celles qui s’en approchaient, elles induiraient la nécessité de déplacer les workloads chez des hyperscalers américains… et le risque de voir les prix augmenter encore plus.
Dans ce contexte, il était demandé à Broadcom :
Au moins 6 mois de préavis pour toute modification des conditions contractuelles ou des structures tarifaires
Une négociation contractuelle des frais applicables lors des pics d’utilisation, et l’absence de pénalités pour les CSP en cas de sur- ou sous-utilisation
Des options de licensing flexibles permettant des réductions sur engagement de volume
Un accès facilité aux plus hauts niveaux de partenariat pour les petits CSP
La possibilité d’être à la fois revendeur et fournisseur de services
Un recours au Tribunal de l’UE…
En juillet 2025, CISPE avait déposé un recours auprès du Tribunal de l’UE. Objectif : faire annuler la décision par laquelle Bruxelles avait autorisé l’acquisition de VMware par Broadcom.
À l’en croire, la Commission européenne aurait omis d’examiner le risque de renforcement de la position dominante de VMware sur les logiciels de virtualisation, alors même qu’elle disposait d’un faisceau d’éléments de preuve. Son examen s’était effectivement centré sur les effets de conglomérat en relation avec des produits matériels de Broadcom (contrôleurs hôtes de bus Fibre Channel et adaptateurs de stockage). Et sur le risque d’exclusion du principal concurrent, à savoir Marvell.
… puis des plaintes auprès du Médiateur européen…
Le troisième rapport de l’observatoire était tombé en octobre 2025. Broadcom venait d’officialiser la refonte de son programme VCSP, sans clarifier si elle s’appliquerait en Europe. Les clients ne pourraient en tout cas plus, à partir du 1er novembre, porter leurs licences existantes vers un autre CSP. En parallèle, les clouders qui ne feraient pas partie du programme ne pourraient plus héberger de solutions VMware – ils ne pourraient que revendre des licences. Pour ceux qui en feraient partie, ce serait le contraire. Bilan : il leur faudrait effectivement choisir entre les rôles de revendeur et de fournisseur de services, même s’ils ont des contrats sur les deux fronts.
Ce troisième volet fut l’occasion, pour CISPE, de dénoncer la rigidité sur les dates de début et de fin des licences VMware. Et de souligner la fin du modèle permettant aux CSP d’exploiter des cœurs supplémentaires ensuite payés en arriérés.
Fin 2025, la Commission européenne ayant défendu sa décision de valider la fusion Broadcom-VMware, le CISPE en avait remis une couche. Il avait clamé que la structure de financement de l’opération et les engagements de croissance associés auraient dû alerter Bruxelles. Hock Tan avait effectivement promis de faire augmenter l’EBITDA de VMware de 60 à 80 % en 3 ans… sur un marché qui croissait de moins de 10 % par an.
En parallèle, l’association avait déposé plainte auprès du Médiateur européen. Motif : Bruxelles a pris beaucoup trop de temps (672 jours) pour publier sa décision, qui n’a été attaquable qu’à partir de ce moment-là.
… et de la DG Concurrence
Une autre plainte a suivi en mars 2026, cette fois auprès de la direction générale de la concurrence de la Commission européenne. Broadcom avait alors confirmé la fin de VCSP en Europe. C’est dans ce cadre que CISPE avait réclamé les mesures intérimaires sus-évoquées.
Depuis, l’association a dénoncé la « conduite très inquiétante » du groupe américain vis-à-vis du Tribunal de l’UE. Il lui aurait à la fois intimé de ne pas divulguer un certain nombre de ses correspondances… et de divulguer celles de membres du CISPE contenant pourtant des informations confidentielles.
Broadcom a aussi eu droit à des attaques sur le terrain de la souveraineté. CISPE fait valoir le framework qu’il a développé et prétend que VCF n’en remplit pas les critères, y compris au niveau de base. Avant tout parce qu’il s’agit d’une stack propriétaire émanant d’un éditeur exposé, entre autres, au CLOUD Act et aux restrictions à l’export que décrète Washington. Mais aussi parce que Broadcom garde un contrôle unilatéral en tant que seule source de correctifs, de mise à jour et de maintenance. CISPE rappelle aussi l’existence d’un mécanisme de reporting de conformité qu’il assimile à un « kill switch », au sens où une non-conformité peut résulter en une dégradation ou un blocage du plan de contrôle.