Serveur cloud Ampere ARM64 : 2 ans d'utilisation chez Hetzner, mon analyse

"Pourquoi payer moins cher ?" Ce n'était pas ma seule question il y a 2 ans. Je me demandais aussi : "Pourquoi consommer autant d'énergie pour héberger un blog ?"

Les datacenters représentent environ 2% des émissions mondiales de CO2, et cette part ne cesse d'augmenter. En découvrant les serveurs ARM64 chez Hetzner, j'ai réalisé que je pouvais faire quelque chose.

Ces processeurs Ampere, avec leur efficacité énergétique, permettent de diviser par deux la consommation électrique par rapport à un serveur x86 classique. À 2.99€/mois (sans IPV4), c'était gagnant sur tous les plans : portefeuille et planète.

Mais était-ce trop beau pour être vrai ? Fallait-il accepter des compromis sur les performances ou la compatibilité ?

Après 24 mois d'utilisation en conditions réelles pour ce site et d'autres projets à usage professionnel, voici mon bilan.

Pourquoi j'ai choisi les processeurs Ampère ?

Comme je l'expliquais dans l'introduction, c'est d'abord l'efficacité énergétique de ces processeurs qui m'a convaincu d'opter pour cette solution. Le coût venait après dans mes critères de choix. Cette orientation n'est possible que parce que l'architecture technique du site s'y prête bien. Pour rappel, le site tourne sur le CMS Kirby, qui fonctionne sans base de données classique mais propose quand même une interface d'administration complète. On se retrouve avec un système hybride, dynamique côté backend et pour certaines fonctionnalités du frontend, mais qui se rapproche finalement d'un site statique pour l'utilisateur final. Le plugin Staticache s'occupe de cette partie statique et réduit considérablement le rendu PHP, ce qui allège la charge sur le processeur.

L'autre bonne surprise dans cette histoire, c'est que financièrement aussi les processeurs Ampère s'en sortent mieux. Ce qui est cohérent quand on y réfléchit : moins de consommation électrique, moins de chaleur dégagée, donc moins d'énergie nécessaire pour refroidir l'ensemble. Sauf que cette affirmation était valable avant que Hetzner ne bouleverse un peu la donne avec de nouvelles offres d'entrée de gamme sur leurs serveurs cloud x86. Ils bradent maintenant leurs anciennes générations de serveurs. Du coup, le serveur cloud CX23 avec processeur AMD/Intel propose 2 CPUs, 8 Go de RAM et 40 Go de NVMe pour 2,99 € hors IPv4. En comparaison, le serveur cloud CAX11 qui embarque un processeur Ampère offre exactement la même configuration (2 CPUs, 8 Go de RAM, 40 Go de NVMe) mais à 3,29 € sans IPv4.

Le concept de Hetzner qui consiste à recycler ses anciens serveurs pour leur offrir une seconde vie mérite d'être salué. C'est une démarche pertinente. Mais ils auraient quand même pu maintenir ce petit avantage tarifaire en faveur des Ampère, ça aurait été un peu plus cohérent.

Au-delà de cette question de processeur ARM64 versus x86 pour l'hébergement du site, il y a un autre aspect qui a pesé dans mon choix, même s'il n'est pas directement lié à cette problématique technique mais plus sur le choix de l'hébergeur. L'interface graphique que propose Hetzner pour gérer les serveurs cloud est vraiment excellente. C'est probablement l'une des meilleures que j'ai eu l'occasion de tester jusqu'à présent, et le taux de disponibilité qui va avec est très bon également.

La mise en place

J'ai donc opté pour le serveur cloud CAX11 pour héberger ce site. Il est largement dimensionné pour les besoins actuels. Et si jamais le trafic devait exploser un jour (un scénario que je juge peu probable), la charge devrait être absorbée sans problème grâce aux mécanismes de cache mis en place.

Le site tournait initialement sur Debian 12, puis je l'ai basculé sur Debian 13 il y a un peu plus d'un mois. Côté stack technique, Cloudflare fait office de proxy en amont du serveur, et sur la machine elle-même je suis parti sur une configuration classique avec Nginx, PHP et Redis.

Évidemment, quand on choisit une offre cloud chez Hetzner, il faut être capable d'installer et de maintenir un serveur Linux. On est vraiment à l'opposé de ce que proposent les hébergements mutualisés. Les deux approches ont leurs avantages et leurs limites, mais ce n'est pas vraiment le sujet ici.

Sur la question de la compatibilité avec les processeurs ARM64 sous Linux, je n'ai rencontré aucun problème. Tous les paquets que j'ai installés ont fonctionné du premier coup. L'écosystème gère maintenant très bien ce type de processeur.

Performances après 2 ans

Sur le plan de la stabilité et de la fiabilité, le bilan est sans appel. Je n'ai connu aucune coupure du site en dehors des redémarrages que j'avais moi-même planifiés pour effectuer des mises à jour techniques. Malgré un tarif vraiment modeste, la stabilité et la fiabilité sont bien présentes. Il faut toutefois relativiser, comme je l'indiquais plus haut le trafic du site reste faible.

Cela dit, j'ai aussi testé cette configuration dans un contexte professionnel avec des sites qui génèrent un trafic nettement plus conséquent, entre 1000 et 1500 visites par jour. L'environnement était similaire, le même CMS, le même système de cache. Et là encore, la stabilité et la fiabilité étaient au rendez-vous sans faillir.

Durant toute cette période je n'ai été confronté à aucun dysfonctionnement, aucune limite technique non plus. Bref, l'expérience s'est révélée vraiment convaincante.

La question de la latence géographique

Un point à aborder : Hetzner propose uniquement des datacenters en Europe, principalement en Allemagne (Falkenstein et Nuremberg) et en Finlande (Helsinki). Pour une audience française ou européenne, la latence reste très acceptable, généralement entre 10 et 30 ms.

En revanche, si vous visez un public en Amérique du Nord, en Asie ou en Afrique, la distance géographique va jouer sur les temps de réponse. Comptez 150 à 200 ms depuis la côte Est des États-Unis, davantage depuis l'Asie.

La solution : utiliser un CDN comme Cloudflare pour distribuer vos contenus statiques depuis des points de présence mondiaux. Dans mon cas, Cloudflare agit comme proxy et compense largement la localisation du serveur.

Pour un blog personnel ou un site européen, cette limitation est mineure. Le temps de chargement dépend surtout de l'optimisation du code, du poids des ressources et du système de cache. C'est différent pour une boutique e-commerce internationale ou une application où chaque milliseconde compte. Là, il faudra investir dans un CDN performant ou choisir un hébergeur avec des datacenters mieux répartis.

Pour qui c'est adapté ?

Cas d'usage idéaux

Les sites web classiques avec des CMS comme WordPress (sans 10 000 plugins !), Kirby ou Grav fonctionnent parfaitement sur ARM64. Même chose pour les sites statiques générés avec Hugo, Jekyll ou Eleventy. Si votre projet repose sur des bases solides comme Nginx, Apache ou Caddy associés à PHP, MySQL ou Redis, vous êtes en terrain favorable.

Les applications Node.js ou Python trouvent également leur place sur ces processeurs. Les sites e-commerce de petite ou moyenne envergure tournant sur PrestaShop ou WooCommerce s'en sortent bien aussi, à condition que le trafic reste raisonnable et que les mécanismes de cache soient correctement configurés.

Les environnements de développement et de test représentent un autre usage intéressant. Déployer plusieurs instances pour tester différentes configurations ou versions d'un projet devient abordable financièrement.

Et puis il y a tous les projets où la contrainte énergétique fait partie du cahier des charges, où l'écoconception n'est pas juste un mot à la mode mais un véritable objectif technique.

Quand éviter l'ARM64

Si votre projet dépend de logiciels propriétaires ou de bibliothèques spécifiques qui n'existent qu'en version x86, vous allez rencontrer des problèmes. Certains outils professionnels, notamment dans le domaine de l'analyse de données ou du traitement d'images complexes, ne proposent pas encore de version ARM64. Il faut vérifier la compatibilité avant de se lancer.

Les applications qui nécessitent une puissance de calcul importante sur une longue durée ne sont pas forcément à leur place sur ces processeurs. Si vous faites du rendu vidéo, de l'encodage massif ou du machine learning intensif, vous aurez probablement besoin de machines plus musclées avec des processeurs x86 haut de gamme, voire des GPU dédiés.

Les sites à très fort trafic, on parle de dizaines de milliers de visites simultanées, demanderont une infrastructure plus robuste et probablement une montée en gamme vers des serveurs dédiés. Et puis si vous n'êtes pas à l'aise avec Linux, si vous préférez une interface de gestion simplifiée type cPanel ou Plesk, mieux vaut vous orienter vers un hébergement mutualisé classique. L'ARM64 demande un minimum d'autonomie technique qu'il ne faut pas sous-estimer.

Le bilan

Comme il a été évoqué en introduction, si vous vous posez les questions de l'usage et de l'impact du numérique sur l'environnement avec la consommation énergétique, vous faites un premier pas vers un web moins énergivore.

Cette gamme de processeurs ARM64 peut effectivement être une partie de votre réponse, mais certainement pas la seule. Au-delà d'un processeur moins énergivore, il faut également réfléchir à l'optimisation de votre code, à la mise en cache efficace des contenus, au poids de vos images et ressources. La sobriété numérique passe aussi par des choix de conception plus minimalistes, en évitant les frameworks JavaScript trop lourds quand ce n'est pas nécessaire, en limitant le nombre de requêtes HTTP, ou encore en privilégiant des polices système plutôt que des webfonts volumineuses. Chaque élément compte dans cette démarche globale.

Mon expérience avec l'ARM64, que ce soit sur ce site personnel ou dans mes projets professionnels avec un trafic plus conséquent, a confirmé que cette solution offre un bon équilibre entre performance, coût et impact environnemental. La stabilité est au rendez-vous et les limitations techniques restent marginales pour la plupart des usages web courants.

Si vous hésitez encore, je vous encourage vivement à tester cette approche sur un projet personnel ou un environnement de développement avant de l'envisager pour un site en production. C'est le meilleur moyen de vous familiariser avec l'écosystème ARM64 et de vérifier que toutes vos dépendances sont compatibles. Le coût d'entrée est suffisamment bas pour permettre l'expérimentation sans risque.

Le choix de l'hébergeur compte aussi dans cette équation. Des acteurs comme Hetzner qui proposent non seulement des offres ARM64 mais qui adoptent également des démarches responsables comme le recyclage de leurs anciens serveurs participent à cette dynamique plus vertueuse. C'est un critère qui mérite d'être pris en compte au même titre que les performances ou le prix.

Et puis il faut regarder vers l'avenir. L'ARM64 gagne progressivement du terrain dans le monde de l'hébergement web. L'écosystème continue de mûrir, les outils s'améliorent, la compatibilité s'étend. Ce qui peut sembler encore un peu marginal aujourd'hui deviendra probablement une option de plus en plus standard demain. Autant prendre un peu d'avance sur cette transition.

Les plus et les moins

Foire aux questions

Recommandations

27/05/2024

Présentation de Kirby, le CMS low-tech sans base de données

En savoir plus

29/01/2024

La consommation d'eau des data centers va exploser avec l'utilisation de l'IA

En savoir plus

30/05/2025

L'impact écologique de l'IA quantifié par une étude du MIT

En savoir plus

Journal des modifications