Résumé

  • La pile réseau de CoreWeave couvre les couches scale-up, scale-out, stockage, locataires, gestion, backbone et connexions privées; c’est une architecture d’exploitation, pas un produit à part entière.
  • Les réseaux NVIDIA et les DPU, associés aux logiciels de CoreWeave, servent à ordonnancer les accélérateurs, isoler les locataires et transporter les données dans le cloud dédié.
  • CoreWeave déclare 43 centres de données, plus de 850 MW en service et environ 3,1 GW sous contrat; Microsoft représente 67 % du chiffre d’affaires 2025, illustrant à la fois l’échelle et la concentration.
  • Le test décisif: transformer les mégawatts sous contrat et les commandes en services fiables et diversifiés avant que les coûts de financement, les baux, l’obsolescence matérielle et la complexité opérationnelle ne s’accumulent.

La croissance physique dépasse ce qu’une carte de régions cloud ordinaire peut exprimer

Au 31 décembre 2025, CoreWeave a déclaré 43 centres de données, plus de 850 MW en service et environ 3,1 GW sous contrat. Le chiffre en service représente l’infrastructure mise en exploitation selon la définition de la société à cette date; le chiffre sous contrat représente des droits et engagements de déploiement futurs, et ne doit pas être présenté comme une capacité installée.

La croissance est très rapide: fin 2023, 10 centres de données et environ 70 MW; fin 2024, 32 et plus de 360 MW; fin 2025, 43 et plus de 850 MW. Au premier trimestre 2026, la société a déclaré plus de 1 GW en service et plus de 3,5 GW sous contrat. Cela montre un rythme d’expansion industrialisé et à quelle vitesse les anciennes architectures deviennent minoritaires.

L’électricité n’est qu’un prérequis, pas un produit fini. Les mégawatts sous contrat exigent encore l’accès au réseau, la production ou la fourniture d’électricité, la distribution haute densité, le refroidissement, les bâtiments, les chemins réseau, la livraison des accélérateurs et la validation opérationnelle. Tout retard dans une couche peut reporter les revenus, alors qu’une partie des coûts et engagements a déjà commencé.

Le modèle de datacenters est hybride. CoreWeave possède des équipements et contrôle une grande partie des déploiements, tout en utilisant des installations louées et des prestataires tiers. Cela accélère l’expansion géographique, mais rend aussi la performance des bailleurs, l’avancement des constructions, la fourniture d’électricité et les conditions contractuelles parties prenantes de la fiabilité de la plateforme.

Un GPU n’est pas encore un cloud

Un accélérateur dans un rack sous tension peut exécuter du code, mais il ne fournit pas automatiquement ce que les clients achètent d’un service cloud.

Une équipe d’entraînement a besoin que de nombreux accélérateurs fonctionnent comme un pool de ressources unifié; les données doivent passer du stockage au calcul à une vitesse suffisante; les communications collectives ne doivent pas laisser les tâches en attente la plupart du temps; les différents locataires doivent être isolés entre eux; l’ordonnanceur doit savoir quels nœuds, liens et équipements sont sains; les points de contrôle doivent survivre aux pannes; les ingénieurs ont besoin d’un accès à l’environnement, et les utilisateurs de chemins de connexion vers d’autres clouds, aux réseaux d’entreprise et à des services externes.

Ce n’est que lorsque ces chemins sont reproductibles et stables qu’un produit cloud existe véritablement.

Dans un cloud d’IA, le réseau ne doit donc pas être traité comme un accessoire du calcul. Dans une architecture d’entreprise classique, le réseau est souvent présenté comme le système qui relie les serveurs; dans l’IA distribuée, le réseau participe directement au calcul effectif. Une tâche synchrone peut être ralentie par un module optique dégradé, un accélérateur aux performances anormales, un rail encombré ou un chemin de stockage trop lent. Pendant que la tâche attend, les coûts de financement et d’utilisation du matériel coûteux continuent de courir.

La conception du réseau influence donc à la fois les benchmarks et la question de savoir si chaque heure de GPU financée produit de la valeur.

CoreWeave mérite l’étude parce qu’elle illustre particulièrement bien cette relation. La société se concentre sur l’infrastructure d’accélérateurs, plutôt que de traiter les GPU comme un petit service d’un catalogue cloud généraliste; ses documents publics détaillent donc les réseaux de rack, les DPU, l’orchestration bare-metal, les supercalculateurs managés, les connexions dédiées et la réparation des pannes. Ces documents attestent de l’intention de conception et de l’architecture produit, mais ne constituent pas une carte complète de chaque site, de chaque génération de matériel et de chaque déploiement client.

La question vraiment utile n’est pas de savoir si CoreWeave dispose abstraitement d’un « réseau plus rapide », mais combien de réseaux doivent fonctionner ensemble pour qu’une charge de travail d’IA devienne un service fiable, et qui contrôle chaque couche.

Ce que recouvre exactement la « pile réseau CoreWeave »

Cette appellation est un terme éditorial générique: ce n’est ni une entité juridique distincte ni un SKU vendu séparément. L’entité juridique et économique est CoreWeave, Inc., une société du Delaware dont le siège est à Livingston, dans le New Jersey, cotée au Nasdaq sous le symbole CRWV. La pile réseau fait partie de la CoreWeave Cloud Platform, qui comprend aussi le calcul, le stockage, l’orchestration et les services managés.

Chaque nom correspond à une couche différente. Nimbus est l’architecture de réseau virtuel de CoreWeave basée sur les DPU. CoreWeave Kubernetes Service (CKS) fournit un Kubernetes managé bare-metal. SUNK regroupe l’infrastructure et les opérations en un service de supercalculateur managé. Mission Control ajoute la supervision, la réparation et la gestion du cycle de vie. Direct Connect fournit des connexions dédiées aux clients. NVLink, NVSwitch, Quantum, Spectrum-X et BlueField sont des technologies NVIDIA intégrées par CoreWeave, et non des protocoles ou du matériel inventés par CoreWeave.

Distinguer ces couches évite deux erreurs courantes. La première consiste à attribuer à CoreWeave chaque protocole et équipement de la plateforme; la contribution de la société porte principalement sur l’intégration système, la qualification, les opérations et la construction de logiciels cloud autour de technologies de fournisseurs. La seconde consiste à imaginer un réseau unique allant de chaque GPU à chaque client.

Les liaisons scale-up intra-rack, le réseau d’entraînement inter-racks, le réseau de stockage, les overlays VPC, les chemins de gestion et le backbone transatlantique remplissent des rôles différents, avec des objectifs de latence et des domaines de panne distincts; ils ne peuvent pas être résumés par un seul chiffre de bande passante.

La même distinction vaut pour la propriété des actifs. CoreWeave déploie et exploite une grande partie des équipements, mais les documents de la société décrivent aussi des baux, des centres de données tiers, des engagements d’électricité, des partenariats fibre et des financements d’équipements. Un service peut être fortement intégré sur le plan opérationnel sans que CoreWeave possède les bâtiments, les services publics, chaque liaison longue distance ou chaque composant du rack. « Intégration verticale » n’a de sens qu’en termes de coordination entre couches; cela ne signifie pas une autosuffisance totale.

D’Atlantic Crypto au cloud de calcul dédié

CoreWeave a été fondée en 2017 sous le nom de The Atlantic Crypto Corporation et utilisait à l’origine des GPU pour des charges de travail de cryptomonnaie. La société est passée du statut de LLC à celui de corporation du Delaware en septembre 2018, puis a changé de nom en décembre 2019 pour devenir CoreWeave et se tourner vers le cloud de calcul dédié.

Cette histoire est parfois résumée comme un passage spectaculaire du minage à l’IA, mais la continuité la plus importante tient aux capacités opérationnelles. Les deux activités exigent d’acheter des accélérateurs, d’obtenir de l’électricité, de maintenir du matériel haute densité et d’orienter les tâches vers des ressources sous-utilisées. Avant de constituer une plateforme cloud complète, CoreWeave a d’abord appris l’économie d’acquisition et d’utilisation d’un parc d’accélérateurs.

Cette distinction est essentielle, car un changement de demande ne crée pas automatiquement une plateforme cloud. Les charges de minage sont généralement relativement répétitives et tolèrent un ordonnancement simple des actifs; les effets visuels, l’apprentissage automatique et le HPC exigent des logiciels, des mouvements de données, une isolation et des garanties de service différents. CoreWeave a dû ajouter toute une couche de contrôle pour que des clients externes puissent faire confiance à des ressources qui ne leur appartiennent pas et qu’ils ne peuvent pas inspecter directement.

Au début des années 2020, la société a mis en place des services de calcul dédié, de stockage et Kubernetes. Kubernetes bare-metal est devenu l’une des principales interfaces: les clients peuvent ordonnancer des conteneurs directement sur des serveurs accélérateurs, sans passer par une couche de machines virtuelles classique. Fin 2023, CoreWeave déclarait 10 centres de données et environ 70 MW en service; fin 2024, le chiffre passait à 32 centres de données et plus de 360 MW.

L’expansion a changé la nature des problèmes réseau. Un opérateur de dix sites peut encore s’appuyer largement sur l’expertise et les exceptions locales; un cloud de trente ou quarante sites exige des conceptions reproductibles, des politiques contrôlées par logiciel, une qualification uniforme, une supervision partagée et la capacité de faire migrer des clients entre générations de matériel sans casser la cohérence opérationnelle.

L’échelle transforme les choix d’ingénierie en questions de gouvernance: qui approuve les changements, combien de temps une exception reste-t-elle invisible, chaque nouveau site reproduit-il réellement les frontières de contrôle prévues.

CoreWeave a réalisé son introduction en Bourse en mars 2025. L’IPO a apporté des fonds propres, mais aussi un prospectus et des documents déposés auprès de la SEC, permettant au public de voir les installations, la concentration des clients, la dette, les baux, l’architecture d’interconnexion et les risques. La pile réseau peut donc être analysée à la fois comme un système technique et comme un ensemble d’engagements financiers d’une société cotée.

La charge de travail détermine l’architecture

L’entraînement de grands modèles répartit le calcul entre plusieurs accélérateurs et échange en permanence des résultats partiels. Les schémas de communication précis dépendent de l’architecture du modèle, du parallélisme et du logiciel, mais les questions d’infrastructure restent relativement stables: la vitesse effective d’un pool de ressources dépend à la fois du calcul local et des communications collectives. Même si un réseau a un débit global très élevé, une congestion, une topologie ou une latence de queue qui ralentissent les points de synchronisation gaspillent une puissance de calcul coûteuse.

La plateforme doit aussi transporter des flux qui n’ont pas les caractéristiques des communications collectives. Les jeux de données entrent dans l’environnement, les points de contrôle passent de la mémoire GPU au stockage, les systèmes de contrôle distribuent tâches et politiques, les ingénieurs extraient des journaux, les services d’inférence exposent des points de terminaison, les sauvegardes et les réplicas peuvent se déplacer entre régions. Ces flux tolèrent différemment latence et pertes. À les traiter comme un réseau indifférencié, la performance devient difficile à prévoir et les pannes difficiles à isoler.

D’où une conception en couches: les liaisons scale-up créent des domaines fortement couplés à l’intérieur des systèmes au niveau du rack; le fabric scale-out relie les racks entre eux; les chemins de stockage alimentent les charges de travail et conservent leur état; le réseau des locataires fournit des adresses privées et des politiques; le réseau de gestion permet aux opérateurs de contrôler les hôtes, les DPU, les commutateurs et les processus de réparation; le backbone relie les sites à l’écosystème externe; les connexions dédiées relient CoreWeave à d’autres domaines d’administration.

Ces couches interagissent sans pouvoir se remplacer. La fibre longue distance ne remplace pas un fabric GPU local, car la latence de propagation limite intrinsèquement l’entraînement fortement synchronisé entre sites éloignés; un domaine NVLink n’est pas un VPC client; un overlay peut masquer les différences d’adresses mais ne répare pas un module optique défectueux dans l’underlay; sans plugins de périphériques ni informations de topologie, Kubernetes ne comprend pas automatiquement chaque rail et chaque chemin de commutation.

Cette architecture est donc essentiellement une chaîne de traduction des intentions. Le client demande un cluster, un namespace, un réseau ou une tâche; les systèmes de contrôle de CoreWeave mappent la demande vers les serveurs, le fabric, le stockage et les politiques disponibles; Nimbus convertit l’intention VPC en état des DPU et de l’underlay; les services liés à Kubernetes et à Slurm transforment l’intention de charge de travail en allocation de nœuds et d’accélérateurs; Mission Control transforme les signaux de santé en actions de réparation.

Le client voit un service; la plateforme doit maintenir la cohérence entre toutes ces traductions.

Le réseau scale-up dans le domaine du rack

Le réseau scale-up connecte les accélérateurs à l’intérieur d’un système hautement intégré. Dans les conceptions rack-scale de NVIDIA, NVLink assure une communication à haute bande passante entre GPU et NVSwitch assure la commutation dans le domaine local. CoreWeave intègre ces technologies dans des systèmes et générations spécifiques.

L’essentiel n’est pas seulement la marque, mais la proximité physique. Le domaine scale-up permet au partitionnement de modèle et aux communications collectives de ne pas traverser le réseau de centres de données classique à chaque étape, faisant d’un rack un grand système d’accélérateurs plutôt qu’un ensemble de serveurs indépendants. Il forme en même temps un domaine de panne distinct: un problème de commutateur, de câble, de refroidissement ou de composant dans le rack peut affecter simultanément plusieurs GPU que l’ordonnanceur pensait faire travailler ensemble.

Le prospectus de CoreWeave a décrit certaines configurations de cluster offrant jusqu’à 3 200 Gbps de bande passante d’interconnexion GPU non bloquante. « Certaines configurations de cluster » est la réserve la plus importante. Ce chiffre n’est pas un SLA universel et ne décrit pas tous les sites ni toutes les générations. La bande passante réellement obtenue par une charge de travail dépend aussi du logiciel, de la topologie, des schémas de messages et de l’état de santé du chemin complet.

Le scale-up soulage un goulot d’étranglement tout en augmentant la densité ailleurs. Davantage d’accélérateurs et une bande passante locale plus élevée accroissent les exigences de puissance, de refroidissement et de maintenabilité du rack. Si la densité de calcul augmente sans que la conception thermique et opérationnelle suive, le système peut devenir plus difficile à réparer et déplacer le goulot vers le scale-out et le stockage. L’architecture doit être comprise comme un équilibre entre composants, et non comme une liste de spécifications maximales.

Fabric scale-out: InfiniBand et Ethernet coexistent

Quand une tâche sort du domaine scale-up, elle entre dans le fabric scale-out. Les documents et contenus techniques de CoreWeave mentionnent NVIDIA Quantum-2 InfiniBand, le fabric Quantum-X800 XDR 800G et Spectrum-X Ethernet avec RoCE et RDMA. La coexistence d’InfiniBand et d’Ethernet est importante: CoreWeave n’enferme pas sa plateforme dans une seule famille de protocoles.

InfiniBand pour les clusters fortement couplés

L’InfiniBand est conçu pour les communications à faible latence et à accès mémoire direct à distance, avec un long historique dans le HPC. Dans les clusters d’IA, il réduit la surcharge de traitement des hôtes standard et déplace les données entre hôtes d’accélérateurs. Les systèmes NVIDIA Quantum apportent en outre des capacités de commutation et liées aux communications collectives. CoreWeave intègre ces fabrics dans ses services de cluster, plutôt que de vendre l’InfiniBand comme un service télécom autonome.

Les documents publics ne détaillent pas toutes les topologies, taux de sursouscription, stratégies de routage adaptatif ou frontières de service client. « Non bloquant » peut ne valoir que pour une conception donnée, pas pour l’ensemble de la flotte. Même un réseau bien conçu peut être dégradé par un module optique en fin de vie, un placement de tâches inadapté, un trafic déséquilibré ou des points chauds logiciels. L’acheteur doit demander quelle génération de matériel, quelle topologie et quelle qualification s’appliquent réellement au cluster qui lui est fourni.

Spectrum-X et RoCE constituent le chemin Ethernet

Spectrum-X est la plateforme réseau Ethernet d’IA de NVIDIA. RoCE transporte des sémantiques RDMA sur Ethernet, permettant aux applications de communiquer directement en mémoire tout en conservant un fabric Ethernet pour les opérateurs. CoreWeave utilise Spectrum-X pour offrir un autre chemin scale-out aux charges de travail et générations matérielles conçues autour de cet écosystème.

Connaître Ethernet ne signifie pas une exploitation simple. Les performances de RoCE dépendent du contrôle de congestion, de la conception des files d’attente, du comportement en cas de perte, de la télémétrie et du réglage de bout en bout. Un réseau peut utiliser des trames Ethernet familières tout en exigeant une ingénierie spécialisée pour éviter la tête de ligne bloquante, l’incast ou l’instabilité des communications collectives. La valeur d’un cloud intégré est de transférer une grande partie du réglage au fournisseur; le risque correspondant est le manque de visibilité directe du client sur ces choix.

Topologies optimisées par rail et placement des tâches

Les systèmes multi-rails regroupent les NIC et accélérateurs correspondants afin que le trafic collectif emprunte des chemins parallèles relativement réguliers. L’optimisation par rail réduit le trafic inter-switch inutile et rend la bande passante plus prévisible, mais elle exige que l’ordonnanceur comprenne la topologie physique; une mauvaise combinaison de nœuds annule l’avantage de conception.

Le rail concentre aussi les pannes. Si un rail se dégrade, chaque nœud qui l’utilise peut devenir un nœud lent (straggler), même si les autres interfaces restent saines. Les systèmes d’exploitation doivent distinguer une panne de serveur individuel d’une panne réseau partagée. C’est pourquoi la télémétrie de topologie, la qualification et la réparation comptent autant que le débit des ports.

Nimbus déplace la frontière du cloud vers le DPU

Un fabric de cluster haute performance ne forme pas automatiquement un cloud multi-locataires. Les clients ont aussi besoin d’adresses privées, de contrôle de routage, d’accès Internet et d’isolation. La réponse de CoreWeave est Nimbus: une architecture de réseau virtuel qui décharge les fonctions VPC sur des DPU. Les documents publics mentionnent le DPU NVIDIA BlueField-3 et décrivent le routage VRF, VXLAN et EVPN Type 5 dans l’architecture de sécurité.

Le DPU occupe une position très sensible, entre le calcul contrôlé par le client et l’infrastructure contrôlée par le fournisseur. Il peut traiter le trafic de réseau virtuel, appliquer la segmentation et laisser le CPU de l’hôte aux charges de travail; il peut aussi placer la frontière d’isolation des locataires en dehors du système d’exploitation que le client pourrait contrôler. C’est donc un choix à la fois de performance et de sécurité.

Comment se compose l’overlay VPC

Le VRF sépare un domaine de routage d’un autre; VXLAN transporte les segments de réseau des locataires sur un underlay physique partagé; EVPN distribue l’accessibilité, et les routes de type 5 peuvent annoncer des préfixes IP et pas seulement des adresses MAC. Combinés, ces mécanismes permettent à CoreWeave de fournir des réseaux privés sur une infrastructure physique partagée.

L’overlay n’élimine pas la dépendance à l’underlay. Si la connectivité physique tombe, le réseau virtuel tombe aussi; une erreur de distribution de routage peut détruire l’isolation ou la connectivité à grande échelle; un défaut dans l’image du DPU ou dans le système de politiques peut propager rapidement un mauvais état à des milliers d’hôtes. L’abstraction cloud déplace la complexité du côté du fournisseur, mais ne la fait pas disparaître.

Le DPU fait partie de la racine de confiance

Nimbus améliore la séparation entre les fonctions réseau du fournisseur et les hôtes clients, mais renforce aussi l’importance du firmware du DPU, du démarrage sécurisé, des clés, de la distribution des politiques, des journaux et de la récupération. Un équipement qui applique l’isolation doit être observable et corrigeable, sans devenir un chemin incontrôlé vers l’environnement des locataires.

Cette frontière de contrôle affecte aussi le dépannage. Un problème de connectivité peut venir de la charge cliente, des politiques Kubernetes, de la configuration VPC, du logiciel DPU, du plan de contrôle EVPN ou du fabric physique. L’équipe de support a besoin de preuves transversales sans permettre à un locataire de voir les données d’un autre. Les documents publics expliquent la conception prévue, mais ne fournissent pas d’enregistrements indépendants, à l’échelle de la flotte, des pannes d’isolation et des délais de réparation.

Kubernetes bare-metal est le plan de contrôle du client

CoreWeave Kubernetes Service fournit un Kubernetes managé sur infrastructure bare-metal, évitant d’intercaler une couche classique de machines virtuelles entre la plateforme de conteneurs et les serveurs GPU. Chaque cluster dispose d’un VPC indépendant et d’un réseau et stockage haute performance intégrés pour les charges de travail distribuées.

Le bare-metal supprime une couche d’abstraction, mais cela ne signifie pas la simplicité. Kubernetes doit toujours découvrir les GPU, exposer les périphériques, appliquer les quotas, placer les pods et coopérer avec les plugins réseau et stockage. La plateforme doit coordonner les images de nœuds, les pilotes, le firmware, les runtimes de conteneurs et les mises à niveau de cluster avec les générations matérielles sous-jacentes. Le client retrouve des API familières; CoreWeave assume une matrice de compatibilité plus complexe.

Ce que Kubernetes peut ou ne peut pas décider

Kubernetes peut décider du placement des pods en fonction des informations et politiques dont dispose l’ordonnanceur, mais il ne comprend pas automatiquement l’état de chaque rail, module optique, chemin de commutation ou communication collective. CoreWeave doit ajouter des plugins de périphériques, des operators, des informations de topologie et des contrôles opérationnels pour aligner l’ordonnancement logique sur les ressources physiques réalisables.

Les politiques réseau ont aussi leur périmètre. Les politiques Kubernetes peuvent limiter le trafic entre charges de travail; le VPC et le DPU fournissent des frontières plus larges de locataires et de routage. L’existence d’un objet de politique ne signifie pas que le chemin réel des paquets applique les règles prévues; configuration, implémentation et observation doivent concorder.

SUNK transforme les clusters en supercalculateur managé

SUNK est positionné comme un service de supercalculateur managé de niveau production, combinant infrastructure, fabric haute performance, orchestration des charges de travail et exploitation par CoreWeave pour les clients qui veulent un grand environnement dédié sans construire eux-mêmes l’installation complète ni l’équipe d’exploitation.

Cela modifie le partage des responsabilités. Les clients restent responsables de l’architecture du modèle, du code, des données et de la stratégie de tâches; davantage de cycle de vie matériel, de qualification des clusters et de traitement des pannes revient à CoreWeave. C’est davantage une installation HPC managée livrée via des contrats et des logiciels de l’ère cloud qu’un pool d’instances entièrement interchangeables.

Mission Control transforme l’exploitation en produit

Mission Control ajoute supervision, maintenance, réparation et support du cycle de vie. Plus les tâches sont grandes, plus il compte: remplacer un composant dans un petit pool de serveurs a un impact limité; diagnostiquer une liaison dégradée dans un pool hautement synchronisé peut décider si des milliers d’heures d’accélérateurs produisent de la valeur.

Les contenus de CoreWeave décrivent une supervision proactive et des interventions opérationnelles, ce qui atteste du modèle prévu, mais pas d’une disponibilité vérifiée de manière indépendante, ni de distributions publiques des temps moyens de réparation. Comme la fiabilité est une raison majeure pour laquelle les clients choisissent un fournisseur plutôt qu’un cluster maison, l’absence d’historique complet d’incidents est en soi une limite d’information importante.

Le stockage fait partie du calcul en réseau

Les données d’entraînement, les points de contrôle et les artefacts de modèle passent par les chemins de stockage, qui peuvent limiter toute la charge de travail. Même avec une bande passante inter-GPU très élevée, le cluster s’arrête si la lecture des entrées, l’écriture des checkpoints ou la récupération d’état n’est pas assez rapide. La plateforme CoreWeave comprend du stockage objet et fichier, et décrit le déplacement de données haute performance comme un composant du service.

Le trafic de points de contrôle a un schéma particulier. De nombreux workers peuvent sauvegarder leur état en même temps, créant des rafales différentes des communications collectives. Si le stockage partage des ressources physiques avec le fabric d’entraînement, il faut de l’isolation ou une planification de capacité; s’il utilise un réseau séparé, la plateforme doit quand même coordonner les pannes et la récupération sur les deux chemins.

Le stockage affecte aussi la portabilité. Migrer un modèle vers CoreWeave peut exiger de transférer de grandes quantités de données depuis d’autres clouds ou environnements privés; la sortie peut entraîner coûts, délais et frictions contractuelles. « Zero Egress Migration » est un mécanisme commercial de CoreWeave pour réduire certains coûts d’entrée; ce n’est pas une garantie de performance technique, ni une promesse que tout le trafic sortant est gratuit ou que le déplacement de données n’a pas de coût opérationnel.

Les clients doivent donc exiger des preuves de bout en bout. Les pics d’accélérateurs ou de réseau ont de la valeur, mais une tâche de production inclut aussi la préparation des données, les points de contrôle, le registre de modèles, les journaux et la récupération. Un benchmark ne testant qu’une seule couche ne peut pas dire quand la tâche complète se termine ni quel est son coût total.

Le backbone relie les régions, ce n’est pas un supercalculateur synchrone

CoreWeave décrit un backbone carrier-grade reliant les centres de données d’Amérique du Nord et d’Europe par de la fibre terrestre et sous-marine, avec peering direct et connexions dédiées. Les documents de la société listent des connexions Direct Connect à 10, 100 et 400 Gbps selon les sites et la disponibilité.

Le backbone n’a pas le même rôle qu’un fabric scale-out local. Il peut transporter des jeux de données, des réplicas, des points de contrôle, du trafic de contrôle et d’inférence, connecter les utilisateurs et d’autres clouds, soutenir la reprise et la distribution. La latence de propagation longue distance fait qu’il ne peut pas transformer une installation distante en réseau de cluster à faible latence pour l’entraînement fortement synchronisé.

Les connexions dédiées réduisent une incertitude

Les circuits dédiés peuvent réduire la variabilité du routage Internet public et offrir des frontières de capacité et de support plus claires, mais ils ne créent pas un monde de bout en bout totalement privé. L’accès côté client peut dépendre d’opérateurs, de cross-connects et d’opérateurs de datacenters; l’on-ramp cloud a ses propres validations et configurations; la diversité de routage et la propriété des actifs de chaque site ne sont pas entièrement divulguées.

On ne peut donc pas qualifier CoreWeave de carrier Tier-1. La société opère un backbone et participe au peering, mais les preuves disponibles ne démontrent pas une accessibilité sans frais de transit à l’échelle mondiale ni la propriété de tous les chemins de fibre. Son avantage est une connexion profonde avec ses propres ressources de calcul, pas le remplacement de l’écosystème télécom mondial.

La conception régionale crée des disponibilités différentes

Fin 2025, CoreWeave avait des installations dans six pays. Ce chiffre ne signifie pas que chaque génération d’accélérateurs, chaque fabric, chaque service ou chaque débit de connexion dédiée est disponible dans chaque pays. Les régions sont mises en service par phases, car l’électricité, le refroidissement, le réseau, le matériel et la validation opérationnelle ne sont pas prêts au même moment.

La géographie n’affecte pas seulement la latence: elle touche aussi la gouvernance des données, la proximité avec d’autres clouds, les personnels, les sources d’électricité, la corrélation des pannes et la question de savoir qui contrôle les chemins locaux. Pour CoreWeave, chaque entrée dans un pays ajoute de la coordination juridique, des services publics et de la chaîne d’approvisionnement. L’expansion réseau est un modèle opérationnel, pas une carte de boîtes homogènes.

La fiabilité transforme le capital en temps utile

Que les tâches s’exécutent ou attendent, les coûts de financement du matériel de CoreWeave continuent. La fiabilité est donc une variable financière. Une panne de fabric, un GPU dégradé, un arrêt du stockage ou une erreur d’ordonnancement réduisent la production facturable et effective, tandis que les intérêts, les loyers et les obligations d’électricité ne s’arrêtent pas.

Les nœuds lents sont plus difficiles à traiter que les pannes franches

Un nœud totalement en panne est facile à détecter; un nœud lent peut rester marqué comme en ligne tout en ralentissant chaque point de synchronisation. Les grandes tâches ont besoin de télémétrie qui détecte la dégradation des performances, pas seulement un état de santé binaire. L’ordonnanceur et l’équipe d’exploitation doivent décider de purger, remplacer ou continuer à utiliser un composant.

Les informations publiques ne divulguent pas complètement les taux d’échec des tâches, les latences de queue ou la distribution des nœuds lents. Cela ne prouve pas une mauvaise fiabilité, mais limite les comparaisons indépendantes. Les clients doivent s’appuyer sur les contrats, les tests de charge et leurs propres preuves opérationnelles, et non tirer des conclusions directes du schéma d’architecture.

La qualification est un test système

Avant d’ouvrir un cluster aux clients, CoreWeave doit valider conjointement serveurs, commutateurs, modules optiques, câbles, firmware, pilotes, stockage et orchestration. Démarrer ne suffit pas; le test pertinent est de savoir si la topologie complète peut soutenir durablement les charges attendues, récupérer après une panne et être réparée sans créer de nouvelles incohérences.

La qualification évolue aussi dans le temps. Une combinaison logiciel-firmware validée ne signifie pas que tout reste identique après une mise à niveau. L’arrivée rapide de nouvelles générations NVIDIA oblige CoreWeave à supporter davantage de combinaisons tout en continuant à servir des environnements sous contrat plus anciens. La maturité opérationnelle consiste à maintenir la cohérence dans ces chevauchements, plutôt que de faire de chaque site un cas particulier.

Le financement est aussi une couche de l’architecture

CoreWeave a enregistré en 2025 un chiffre d’affaires de 5,1 milliards de dollars, une perte nette de 1,2 milliard, des dépenses d’investissement en espèces de 10,3 milliards sur l’année et une obligation de performance restante de 60,7 milliards en fin d’année. Le même document révèle d’importants financements d’équipements, de la dette, des baux et des engagements d’infrastructure.

Ces chiffres ne veulent pas dire la même chose. Le chiffre d’affaires est le revenu de services comptabilisé; le flux de trésorerie d’achat d’immobilisations est une dépense d’investissement, pas une valorisation de toute la flotte; la perte nette indique que la croissance rapide n’a pas encore produit de rentabilité consolidée; l’obligation de performance restante représente des obligations contractuelles futures selon les règles comptables, pas de l’argent en banque ni des services déjà livrés.

Le premier trimestre 2026 montre à la fois la demande et le coût de détention

Pour le trimestre clos le 31 mars 2026, CoreWeave a déclaré un chiffre d’affaires de 2,078 milliards de dollars, une perte nette de 740 millions, des charges d’intérêts de 536 millions et un backlog de 99,4 milliards selon sa propre définition. La visibilité de la demande et le lourd coût de financement apparaissent dans le même trimestre.

Le backlog et l’obligation de performance restante de fin d’année ne sont pas directement interchangeables: définitions et dates sont différentes. Les deux reflètent une demande contractuelle future, mais pour les transformer en revenus, CoreWeave doit d’abord mettre en service installations, électricité, matériel et réseau, puis exécuter les contrats. Plus le backlog est important, plus les obligations de livraison associées sont lourdes.

Le financement adossé aux GPU relie actifs et contrats

CoreWeave se développe avec des prêts garantis, des financements d’équipements et des structures soutenues par les clients. En juin 2026, la société a annoncé un dispositif de financement de 8,5 milliards de dollars, qualifié de GPU-backed et noté investment grade. Il élargit sa capacité de déploiement, mais ce n’est pas du revenu et cela ne signifie pas que toute sa dette a une note investissement.

Le financement d’actifs peut aligner dette, matériel et flux de trésorerie contractuels, mais il restreint aussi les garanties, les déploiements et l’usage des fonds. Accélérateurs, commutateurs et modules optiques se déprécient plus vite que l’infrastructure classique. Le modèle est le plus solide quand l’utilisation est élevée et que les contrats clients couvrent la période de plus forte valeur économique des équipements.

La conception réseau affecte donc la qualité du crédit. Une topologie qui améliore l’utilisation augmente la production des actifs financés; les retards de site, les problèmes persistants de nœuds lents ou les échecs de migration la réduisent. Pour CoreWeave, l’ingénierie système et l’ingénierie de bilan sont un seul et même problème.

La concentration des clients est aussi une dépendance d’infrastructure

Microsoft représente 67 % du chiffre d’affaires 2025 de CoreWeave. Un client d’ancrage prouve la demande, soutient le financement et permet au fournisseur d’acheter à l’avance, mais il renforce aussi le pouvoir de négociation du client et rend l’utilisation très sensible à une relation commerciale.

CoreWeave a aussi divulgué ou annoncé des relations avec des clients comme Meta et Anthropic. Flow Traders a choisi CoreWeave en juillet 2026 pour entraîner des modèles de fondation; Leidos a annoncé un partenariat pour fournir de l’IA aux missions de défense, de sécurité nationale et de renseignement. Les sources pertinentes attestent des contrats, choix ou partenariats décrits, mais ne prouvent pas que la concentration a disparu, ni que toute la capacité annoncée est en production.

Les contrats take-or-pay transfèrent le risque, sans le supprimer

Les contrats take-or-pay pluriannuels améliorent la visibilité de la demande et peuvent soutenir le financement. Ils transfèrent une partie du risque d’utilisation au client, car les paiements ne dépendent pas entièrement de la consommation à court terme; mais les risques de construction, d’électricité, de livraison, de performance, de crédit et de renégociation demeurent.

Pour le client, ce type de contrat inverse une partie de la promesse du cloud. Le cloud public classique met l’accent sur l’élasticité et les engagements faibles; un cluster d’IA dédié peut exiger une relation plus longue, proche d’un projet d’infrastructure, parce que le fournisseur construit ou réserve une capacité spécifique pour le client. L’interface ressemble à un logiciel cloud; l’économie sous-jacente ressemble davantage à du financement de projet.

Les charges de défense et réglementées relèvent le niveau d’exigence

Le partenariat Leidos annoncé le 30 juillet 2026 oriente la plateforme vers des missions de défense et de renseignement. Il ne prouve pas à lui seul que toutes les autorisations, certifications et autorisations de déploiement sont obtenues, mais il montre que le contrôle de la chaîne d’approvisionnement, l’audit, la sécurité de l’information et la continuité opérationnelle peuvent devenir des composants plus importants du produit.

Le VPC appliqué par les DPU, les connexions dédiées et l’exploitation managée peuvent soutenir une conception à haute assurance, mais ne remplacent pas les contrôles spécifiques au projet, les exigences de personnel, les règles de traitement des données et les approbations gouvernementales. Plus la charge est sensible pour la mission, plus les frontières de responsabilité doivent être transparentes.

Les acquisitions logicielles étendent le périmètre vers le haut; l’échec de la fusion pointe vers l’infrastructure en aval

En 2025, CoreWeave a acquis Weights & Biases, OpenPipe, marimo et Monolith AI. Weights & Biases ajoute des outils de développement de modèles et d’observabilité; les autres transactions étendent l’inférence, les notebooks et l’IA industrielle. La société s’étend ainsi de l’infrastructure vers le haut du cycle de vie des développements.

La logique stratégique est claire: un fournisseur qui comprend mieux les workflows de modèles peut mieux prévoir la demande, réduire la difficulté d’utilisation de l’infrastructure et fidéliser les clients à davantage d’étapes. Les risques d’intégration sont tout aussi clairs: cycles de publication, structures de marge et culture du logiciel diffèrent d’un centres de données à forte intensité capitalistique. Si CoreWeave cherche à posséder des outils que les clients obtenaient auparavant auprès de fournisseurs indépendants, des chevauchements de produits et des conflits de partenaires peuvent apparaître.

Le projet d’acquisition de Core Scientific, lui, visait la couche physique. CoreWeave a annoncé un accord de fusion en juillet 2025, cherchant à renforcer son contrôle sur la capacité des centres de données et l’économie des baux. Core Scientific a résilié l’accord le 30 octobre 2025 après un vote des actionnaires. CoreWeave n’a pas acquis Core Scientific.

Ces deux types de transactions montrent une intégration dans les deux sens: vers le haut, dans les logiciels pour développeurs; vers le bas, dans le contrôle de la capacité physique. L’échec de la fusion montre aussi que le contrôle de l’infrastructure ne s’achète pas toujours à la vitesse souhaitée par une plateforme technologique; actionnaires, régulateurs, financements et structures contractuelles peuvent empêcher l’intégration verticale.

Ce que CoreWeave peut contrôler, et ce qu’elle ne peut pas contrôler

CoreWeave contrôle la plateforme client, de nombreux choix de conception, la qualification des équipements, l’orchestration et les processus d’exploitation. Elle peut décider comment Nimbus mappe les VPC, comment les clusters sont présentés, quels services la société héberge, comment les incidents sont traités; elle peut aussi acheter du matériel à l’avance et organiser les installations autour de la densité d’accélérateurs.

NVIDIA contrôle les feuilles de route clés des GPU, NVLink, InfiniBand, Spectrum-X et BlueField. Les services publics et partenaires de datacenters contrôlent une partie de l’électricité et de la livraison des installations; les opérateurs fibre, les exchanges et les clouds contrôlent les connexions externes; prêteurs et financiers d’équipements contraignent le capital; les grands clients influencent la planification des capacités par leurs contrats.

Ce n’est pas une faiblesse propre à CoreWeave: tous les clouds dépendent de chaînes d’approvisionnement. C’est particulièrement important ici parce que la différenciation de CoreWeave est liée au déploiement rapide des nouveaux systèmes NVIDIA et que les engagements financiers sont très importants au regard de l’histoire opérationnelle de l’entreprise. Un retard ou un changement de feuille de route d’un fournisseur peut se répercuter sur les livraisons client et le financement.

L’avantage de la plateforme est de coordonner ces frontières; le risque est la dépendance corrélée: une même génération de produits fournisseur, une même conception de site ou un même plan client peut affecter plusieurs couches en même temps. L’intégration réduit le nombre de contrats à gérer pour le client, mais peut amplifier l’impact d’une panne au niveau du fournisseur.

Position concurrentielle: le cloud dédié est un choix de répartition des responsabilités

CoreWeave est en concurrence avec les clouds hyperscale, d’autres clouds dédiés aux GPU, les clusters construits par les clients, ainsi que des combinaisons de colocation, de colocation managée et d’intégration. La comparaison ne peut pas se limiter au nombre de GPU ou à un seul benchmark; les acheteurs comparent génération matérielle, fabric, stockage, ordonnancement, connexions dédiées, support, durée des contrats, géographie et coût total du déplacement des données.

Comparaison avec les clouds hyperscale

AWS, Microsoft Azure, Google Cloud et Oracle proposent des services plus larges, un écosystème mondial et des bilans plus importants; ils peuvent combiner infrastructure d’IA, bases de données, sécurité, analyses et achats d’entreprise. La réponse de CoreWeave est la spécialisation: introduire plus vite certaines générations NVIDIA, utiliser l’orchestration bare-metal et concevoir la plateforme autour de charges d’accélérateurs haute densité.

La spécialisation peut réduire l’abstraction et accélérer la validation, mais elle crée aussi un profil fournisseur et de panne plus étroit. Le client obtient un fournisseur plus focalisé, en acceptant une moindre largeur de services et un bilan plus jeune. La bonne comparaison porte sur une charge de travail précise, pas sur des étiquettes de secteur.

Comparaison avec d’autres clouds dédiés

Des fournisseurs comme Lambda, Nebius et Crusoe se chevauchent sur les accélérateurs, les clusters et les services managés, mais géographie, stratégie énergétique, portefeuille logiciel, propriété, financement et contrôle des installations diffèrent. « Neocloud » n’est qu’une étiquette de marché, pas une architecture commune.

Les documents d’une société cotée rendent l’échelle et les risques de CoreWeave plus transparents que ceux de nombreux concurrents, mais ne prouvent pas automatiquement un avantage technique ou économique. Un concurrent qui divulgue moins peut être plus petit, plus efficace, ou simplement plus opaque. On ne doit pas transformer la transparence en classement de performance.

Comparaison avec les clusters privés construits en interne

Un cluster maison donne au client un contrôle direct sur le matériel, les données et l’exploitation, mais exige achats, électricité, installations, réseau, stockage, sécurité, firmware, pièces détachées et talents spécialisés. Ce que vend CoreWeave, c’est le transfert d’une grande partie de ces responsabilités au fournisseur.

Le transfert n’est pas complet. Les clients doivent encore concevoir la charge de travail, gérer les données, fixer les politiques et évaluer le risque fournisseur; les engagements longs réduisent la flexibilité de migration. Le risque du cluster maison est la sous-utilisation interne; celui du contrat cloud est la dépendance au fournisseur. Le choix économique dépend de la partie la mieux placée pour absorber la volatilité et garder un système coûteux en production.

Les commutateurs refroidis par liquide montrent où peut se déplacer le prochain goulot d’étranglement

En juillet 2026, CoreWeave a présenté une architecture de commutateurs refroidis par liquide, affirmant pouvoir augmenter la densité de bande passante réseau par rack. Ce chiffre provient d’une conception et de calculs propres à l’entreprise, pas d’un benchmark indépendant sur toute la flotte, mais le mécanisme est important: quand la densité d’accélérateurs augmente, la consommation et la chaleur des commutateurs et modules optiques deviennent une limite du rack.

Refroidir les commutateurs par liquide permet d’accueillir plus de capacité réseau dans une puissance et un espace de rack limités, et peut raccourcir le câblage; en contrepartie, la maintenance réseau est plus étroitement couplée au système de refroidissement liquide. Une fuite, une panne de pompe ou une procédure de maintenance peuvent affecter des composants réseau autrefois traités comme du matériel refroidi par air classique.

Cela montre que les goulots d’étranglement de l’infrastructure IA se déplacent. Des GPU plus rapides exigent une bande passante scale-up plus élevée; une bande passante par rack plus élevée exige une commutation scale-out plus dense; une commutation plus dense entraîne des besoins accrus en électricité et refroidissement; les nouvelles installations doivent adopter une conception électromécanique différente. Une mise à niveau produit peut devenir une refonte du centres de données entier.

Vera Rubin est une transition future, pas une description de la flotte installée

Les documents de CoreWeave de juillet 2026 décrivent la préparation de la NVIDIA Vera Rubin NVL72 et avancent des mesures de tokens par mégawatt par rapport à Blackwell, ou des déclarations prospectives. Ces affirmations doivent être attribuées à CoreWeave et à des configurations précises; elles ne doivent pas être lues comme une disponibilité de toute la flotte à la date de la recherche.

Une nouvelle génération change à la fois les accélérateurs, le scale-up, le scale-out, la puissance des racks, le refroidissement, le firmware, les pilotes, l’orchestration et la qualification. Elle peut améliorer la production par MW, mais aussi rendre les anciennes installations inadaptées ou moins compétitives. L’introduction rapide de nouveau matériel n’est un avantage pour CoreWeave que si elle sait gérer la migration, l’utilisation et la dépréciation des anciens actifs.

Cela renforce aussi la dépendance à NVIDIA. L’accès anticipé attire des clients et des contrats à forte valeur, mais expose CoreWeave aux décisions de calendrier, de prix et d’architecture du fournisseur. La diversification des clients ou de la couche logicielle ne produit pas automatiquement une diversification de la pile physique.

Les implications pour l’infrastructure numérique au sens large

L’expansion de CoreWeave dépasse de loin la location de GPU. Les engagements de l’ordre du GW accroissent la demande de production d’électricité, d’accès au réseau, de transformateurs, de refroidissement, de foncier et de construction; les fabrics à radix élevé augmentent la demande de commutateurs, de modules optiques et de fibre; les connexions dédiées accroissent la demande d’opérateurs, d’exchanges et d’on-ramps cloud; le financement oblige les prêteurs à évaluer des actifs technologiques à obsolescence rapide avec des contrats de long terme.

La plateforme change aussi l’endroit où le trafic Internet apparaît. L’entraînement fortement couplé reste principalement dans le fabric local, mais les jeux de données, points de contrôle, artefacts de modèle, requêtes d’inférence et flux de développement circulent en continu entre clouds, centres de données et utilisateurs. L’impact visible sur Internet n’est peut-être pas un flux d’entraînement géant, mais un déplacement de données permanent autour des environnements d’entraînement.

Pour les communautés d’accueil et les réseaux électriques, c’est une décision d’électricité et de foncier. Les matériaux de recherche manquent de données au niveau des sites; ils ne permettent pas de conclusions environnementales sur toute l’entreprise, mais ils montrent que l’électricité en service et sous contrat est un indicateur central de croissance, et que les retards d’électricité et d’installations sont des risques métier.

Pour les ingénieurs réseau, cette architecture montre que l’infrastructure IA devient une spécialité à part entière. Les connaissances en routage et commutation restent nécessaires, mais elles croisent désormais bibliothèques de communications collectives, topologies d’accélérateurs, refroidissement liquide, ordonnancement et financement de projet. Ceux qui règlent la congestion protègent aussi le taux de complétion des tâches et la capacité de remboursement de la dette.

Ce que les preuves publiques ne montrent pas

CoreWeave publie des documentations produit, des blogs techniques et des documents financiers, mais la pile réseau reste en partie opaque. Les matériaux fournis ne contiennent pas de topologie temps réel complète, d’inventaire de fabric par site, de tableaux de sursouscription, de carte de propriété de la fibre, d’historique complet des incidents ni de référentiel indépendant de benchmarks par charge de travail.

Cette limite doit influencer la rédaction. Les documents d’architecture peuvent prouver des mécanismes, les fichiers SEC des finances consolidées et des risques, les annonces clients des choix ou partenariats; ils ne peuvent pas prouver des résultats universels sur toutes les charges, une disponibilité de toute la flotte ni un coût total plus bas pour tous les acheteurs.

Il faut la même prudence sur les chiffres: la puissance en service ne vaut pas la puissance sous contrat; le backlog n’est pas du revenu; un appel résultats programmé n’est pas un résultat publié; un accord client annoncé n’est pas une utilisation constatée; une acquisition proposée n’est pas une propriété; un matériel futur n’est pas la flotte actuelle.

Ces distinctions n’affaiblissent pas l’article; elles définissent l’écart d’information que le lecteur professionnel doit gérer. CoreWeave demande aux clients et aux capitaux de faire confiance à un système très intégré dont les détails critiques sont nécessairement privés. La réponse rationnelle n’est pas de supposer l’excellence ou l’échec, mais d’exiger des preuves au niveau des contrats, des clusters et des sites concernés.

Le jugement central

Le produit de CoreWeave est souvent décrit comme de la capacité de calcul; le produit plus profond est en réalité de la coordination: entre les feuilles de route des fournisseurs et la construction des datacenters, entre scale-up et scale-out, entre politiques DPU et intentions des locataires, entre ordonnancement Kubernetes et topologie physique, entre stockage et points de contrôle, entre backbone et accès client, entre financement long terme et cycles matériels courts.

Cette coordination peut constituer un avantage réel. Un fournisseur spécialisé peut prendre des décisions autour d’une charge de travail complète, sans obliger le client à assembler plusieurs fournisseurs; il peut valider des systèmes, réparer des pannes et introduire de nouvelles générations plus vite que beaucoup d’entreprises. La croissance rapide montre que de grands clients valorisent effectivement ce transfert de responsabilité.

La même intégration concentre aussi les conséquences. Une conception de fabric, un retard fournisseur, une erreur de politique, une contrainte de financement ou un changement de client d’ancrage peut affecter l’essentiel du système. L’avenir de CoreWeave ne dépend pas d’un chiffre de bande passante spectaculaire, mais de la capacité de toutes les couches à convertir durablement la capacité financée en travail client fiable.