Les puces ARM sur mesure pour serveurs grignotent la domination d'x86 dans les data centers cloud

Pendant deux décennies, « serveur » rimait avec x86 — une puce Intel ou AMD, exécutant le même jeu d'instructions qu'elle se trouve dans la salle des machines d'une banque ou dans le rack d'une startup hébergée en colocation. Cette évidence est en train de voler en éclats chez les trois plus grands fournisseurs cloud. AWS, Google Cloud et Microsoft Azure ont chacun consacré ces dernières années à concevoir leurs propres CPU serveur basés sur Arm, et à mi-2026, ces puces représentent une part suffisamment importante des nouvelles capacités de calcul hyperscaler pour que le x86 ne soit plus la valeur par défaut automatique qu'il était autrefois.

Les chiffres derrière ce basculement

La pénétration de Arm dans les expéditions de CPU serveur est passée d'environ 5 % en 2020 à quelque 15-23 % en 2025, selon les analystes en semi-conducteurs qui suivent ce segment. Le chiffre le plus frappant est apparu lors des sessions du Computex 2026 : les recherches présentées y situent les puces basées sur Arm à près de la moitié de la capacité de calcul hyperscaler — non pas en nombre d'unités expédiées, mais en capacité effectivement déployée chez AWS, Google et Microsoft réunis. Le marché des serveurs basés sur Arm lui-même est passé d'environ 5,8 milliards de dollars en 2023 à une estimation de 8,2 milliards de dollars en 2026.

Cette croissance ne s'est pas faite aux dépens d'AMD, fait notable. Les estimations de croissance des expéditions de CPU serveur pour AMD ont été revues à la hausse, passant de 14 % à 23 % pour 2026, et la propre projection d'Intel est passée d'un recul de 3 % à une croissance de 3 %. Le marché croît suffisamment vite pour que les gains de Arm et ceux d'AMD se produisent simultanément — c'est la part historique du x86 Intel, et non l'architecture x86 dans son ensemble, qui cède le plus de terrain.

Trois puces, trois paris différents

AWS est allé le plus loin en premier. Graviton5, disponible en disponibilité générale depuis le 10 juin 2026, intègre 192 cœurs Arm Neoverse V3 répartis sur quatre chiplets fabriqués en procédé 3nm chez TSMC, avec 192 Mo de cache L3, de la mémoire DDR5 et PCIe Gen 6 — soit une augmentation quintuplication du cache par rapport au Graviton4 et une amélioration des performances revendiquée de 25 %. AWS l'a conçu explicitement autour des charges de travail de « l'ère de l'IA agentique » : service d'inférence, pipelines de récupération d'information, et les schémas de requêtes en rafale et gourmands en mémoire que génèrent les agents IA plutôt que le calcul par lots classique.

Google Axion adopte une approche différente, positionné comme la moitié CPU d'une paire assortie avec les racks TPU v8 de Google. Google revendique qu'Axion offre 30 % de meilleures performances que les instances cloud Arm concurrentes et 60 % de meilleure efficacité énergétique que les instances x86 comparables — l'efficacité étant le maître mot, puisque le rôle d'Axion consiste en grande partie à alimenter les TPU en données et à en extraire les résultats, sans devenir le goulot d'étranglement thermique ou énergétique de ce pipeline.

Le Cobalt de Microsoft est le plus discret des trois, mais sans doute le plus éprouvé en production à ce stade : il exécute des charges de travail réelles dans les régions Azure aujourd'hui, avec des clients comme Databricks qui font tourner leurs plateformes de données en production dessus, et non de simples déploiements pilotes. Contrairement à Graviton et Axion, qui s'inscrivent dans un cadre narratif adjacent à l'IA, Microsoft a commercialisé Cobalt plus simplement comme un levier de réduction des coûts et d'efficacité pour le calcul Azure ordinaire.

Pourquoi les hyperscalers contrôlent désormais leur propre silicon

Concevoir un CPU serveur de toutes pièces n'est pas une décision que les fournisseurs cloud ont prise à la légère — cela exige des années d'investissement en ingénierie de puces que la plupart des entreprises logicielles n'abordent jamais. La contrepartie, c'est la maîtrise d'une variable qui reposait autrefois entièrement sur les feuilles de route produits d'Intel et d'AMD : la performance par watt à l'échelle du datacenter. La puissance électrique est désormais la contrainte absolue sur la quantité de calcul qu'un hyperscaler peut physiquement déployer, compte tenu des limites de raccordement au réseau électrique et de la consommation colossale des clusters d'entraînement et d'inférence IA. Un CPU conçu en interne peut être réglé précisément pour le mix de charges de travail qu'exécute réellement ce fournisseur, plutôt que pour le profil généraliste qu'un fabricant de puces marchandes doit cibler pour servir tout le monde.

C'est aussi pourquoi le Grace CPU de Nvidia — une puce basée sur Arm conçue pour être placée directement à côté des GPU Nvidia sur la même carte — est pertinent ici, même si Nvidia n'est pas un fournisseur cloud. C'est la preuve la plus manifeste que l'avantage de Arm dans ce cycle ne tient pas vraiment aux coûts de licence du jeu d'instructions ; il tient à l'architecture qui permet à un concepteur de puces de construire exactement la combinaison CPU-mémoire-interconnexion dont son accélérateur ou sa charge de travail spécifique a besoin, au lieu d'acheter ce qu'Intel ou AMD a livré cette année-là.

Ce que cela signifie pour AMD, Intel et les fournisseurs Arm indépendants

L'accélération de la croissance serveur d'AMD suggère qu'il a capté des parts de marché à Intel plutôt que de perdre du terrain face à Arm — EPYC reste le choix x86 marchand par défaut pour les charges de travail qui ne sont pas gérées par un hyperscaler disposant de son propre programme silicon. Le retour à une croissance positive d'Intel est une victoire plus modeste, mais réelle après des années d'érosion de ses parts serveur. L'entreprise exclue de la tendance du silicon captif hyperscaler est Ampere Computing, le concepteur indépendant de puces serveur Arm dont les processeurs AmpereOne concurrencent directement Graviton et Axion auprès des clients qui ne souhaitent pas construire leur propre puce — les fournisseurs cloud en dessous du trio de tête, et les entreprises qui exécutent des charges de travail Arm en colocation plutôt que dans les clouds hyperscalers.

Ce que cela signifie si vous choisissez où exécuter vos charges de travail

Pour les équipes d'ingénierie qui évaluent les types d'instances cloud, la question pratique est passée de « Arm est-il suffisamment mature » à « quelles charges de travail devraient migrer en premier ». Les services sans état et à mise à l'échelle horizontale — couches web, API gateways, service d'inférence — tendent à enregistrer les gains prix-performances les plus nets sur les instances Graviton ou Axion, souvent 20 à 40 % de coût inférieur pour un débit équivalent, à condition que votre pipeline de build produise déjà des binaires Arm64 ou que votre runtime de langage abstraie la différence (Go, Java et la plupart des langages interprétés migrent avec des modifications minimales ; les bases de code C/C++ intégrant des intrinsèques spécifiques à une architecture nécessitent un vrai travail de portage). Les puces qui n'étaient autrefois qu'une optimisation de coûts de niche pour un sous-ensemble de charges de travail sont désormais le choix par défaut sur lequel AWS, Google et Microsoft souhaitent que les nouvelles capacités tournent — ce qui signifie que benchmarker sa propre charge de travail sur des instances Arm n'est plus une due diligence optionnelle, mais un rattrapage par rapport à là où l'infrastructure se trouve déjà.