Les serveurs Arm pèsent désormais plus de 45% des revenus du marché des data centers, un seuil qui rebat les cartes face au x86.
Le basculement s’accélère dans le cloud et les infrastructures IA, où le coût total et les contraintes énergétiques dictent les choix plus que l’habitude. Derrière ce chiffre, on trouve des décisions très concrètes, contrats hyperscale, designs sur mesure, arbitrages sur la performance par watt et la capacité à livrer vite.
Le cap des 45%: Arm s’invite à la table des hyperscalers
Le passage au-delà de 45% des revenus reflète moins un effet de mode qu’un changement d’achats chez les grands comptes. Les budgets capex des opérateurs de cloud se déplacent vers des plateformes où la facture électrique et la densité en baie comptent autant que les benchmarks.
Dans les appels d’offres, l’argument revient en boucle, même quand il n’est pas affiché: performance utile par watt, et capacité à tenir des objectifs de refroidissement sans réaménager tout un site. Les architectures Arm s’insèrent bien dans cette logique, surtout quand le fournisseur contrôle la pile matérielle et logicielle.
La dynamique est portée par les acteurs capables de standardiser à grande échelle. Les hyperscalers privilégient des gammes qu’ils peuvent déployer par milliers, avec des profils de consommation prévisibles et une chaîne d’approvisionnement sécurisée.
Pour le x86, l’enjeu devient moins la présence que la part de portefeuille. Les mêmes clients continuent d’acheter, mais arbitrent davantage, une partie des charges partant vers Arm quand le ratio coût, énergie, disponibilité penche de ce côté.
Facture électrique et densité: le duel se joue au watt près
Dans un data center moderne, la ligne la plus sensible n’est pas le prix du serveur, mais son coût sur plusieurs années, énergie, refroidissement, espace, maintenance. Les directions infra parlent de TCO avant de parler de CPU, surtout quand la croissance des besoins IA met les sites sous tension.
Les plateformes Arm gagnent des points quand elles permettent de faire plus avec un budget énergétique fixe. À l’échelle d’un campus, quelques pourcents de rendement se traduisent par des mégawattheures, donc par de l’argent, et parfois par la possibilité, ou non, d’ajouter des racks.
Le x86 garde des atouts, compatibilité historique, large choix de fournisseurs, maturité des outils d’exploitation. Mais la comparaison se durcit sur les charges web, microservices, frontaux d’API, où la performance brute n’est pas toujours le facteur limitant.
Le débat se résume souvent à une question simple: combien de requêtes, de conteneurs, de jobs batch par kilowatt. Et sur ce terrain, Arm a pris une longueur d’avance dans plusieurs déploiements à grande échelle.
| Critère | Serveurs Arm | Serveurs x86 |
|---|---|---|
| Priorité d’achat actuelle | Optimisation énergie et densité | Polyvalence et compatibilité |
| Charges typiques | Cloud natif, microservices, frontaux | Legacy, bases critiques, environnements mixtes |
| Approche produit | Designs sur mesure fréquents | Catalogue large, cycles plateforme établis |
| Risque principal | Dépendance à un écosystème ciblé | Pression sur coûts et consommation |
IA, cloud natif, microservices: les charges qui font basculer les achats
Le basculement se voit d’abord sur les workloads où l’on scale horizontalement, frontaux web, services internes, pipelines de données, plateformes de conteneurs. Dans ces environnements, on raisonne en flottes de machines, donc en standardisation, en automatisation et en coût par instance.
Les puces Arm trouvent leur place quand les équipes peuvent compiler, tester et déployer sur des images homogènes, et quand l’orchestration masque le matériel. Les distributions Linux et les runtimes modernes ont réduit les frictions, ce qui rend la migration moins risquée pour beaucoup d’applications.
L’IA joue un rôle indirect mais massif. Les clusters GPU ou accélérateurs consomment énormément, ce qui pousse à optimiser le reste, nuds CPU, serveurs de stockage, ingestion, prétraitement. Si l’on peut économiser des watts sur l’infra de support, on libère du budget énergétique pour l’entraînement ou l’inférence.
À l’inverse, les charges très spécifiques, certains environnements Windows, des appliances anciennes, ou des bases critiques verrouillées par des certifications restent plus souvent côté x86. La bascule n’est pas totale, elle est sélective, mais elle pèse lourd en revenus.
Le x86 riposte: accélérateurs, plateformes denses et guerre des prix
Face à la progression d’Arm, les acteurs du x86 ne restent pas immobiles. La riposte passe par des plateformes mieux intégrées, des offres orientées densité, et une mise en avant des fonctionnalités de sécurité et de virtualisation déjà ancrées dans les parcs.
La compétition se déplace aussi vers les accélérateurs et la cohabitation CPU, GPU, DPU. Beaucoup de clients achètent des systèmes complets plutôt qu’un CPU isolé. Dans ce contexte, l’argument devient, qui propose le meilleur ensemble, disponibilité, support, outils, et une feuille de route crédible sur deux ou trois ans.
La variable la plus visible reste le prix. Quand une architecture menace de prendre une part significative d’un budget, les négociations se durcissent. Les remises, les bundles, et les contrats pluriannuels deviennent des leviers pour retenir des volumes côté x86.
Mais la pression est structurelle. Si les décideurs estiment que la courbe énergie, densité, coût d’exploitation penche durablement, le x86 doit prouver sa valeur sur des cas concrets, pas seulement sur des scores de performance maximale.
Migration Arm: gains rapides, mais pièges réels côté logiciel et supply chain
Adopter Arm dans un data center n’est pas un simple échange de serveurs. Les équipes doivent valider la chaîne CI/CD, les images de conteneurs, les dépendances natives, et parfois des bibliothèques propriétaires. Les gains de consommation peuvent être réels, mais ils se méritent, surtout dans les stacks hétérogènes.
Le premier piège est la compatibilité silencieuse. Une application peut démarrer, mais perdre en performance sur un module mal optimisé, ou échouer sur un composant rarement testé. Les organisations qui réussissent le mieux sont celles qui instrumentent, testent, et segmentent, service par service, avec des critères de SLA clairs.
Le second enjeu est la dépendance fournisseur. Certains déploiements Arm s’appuient sur des designs très spécifiques, parfois étroitement liés à un cloud ou à une gamme de serveurs. C’est efficace pour déployer vite, mais cela peut compliquer une stratégie multi-fournisseurs.
Enfin, la supply chain compte. Les achats data center se jouent sur la capacité à livrer, à maintenir, à remplacer. Les directions infra veulent des garanties de disponibilité et de pièces, car un gain énergétique perd son intérêt si les délais de remplacement allongent les incidents.
Source : Futurum Group
