Quelles alternatives à DigitalOcean pour développeurs ?

Ce qui change réellement avec les alternatives à DigitalOcean

La plupart des alternatives à DigitalOcean modifient la facture, pas la machine. Dans tous les cas, vous obtenez une machine virtuelle Linux avec une adresse IP publique, un disque virtio et un accès root. Votre kernel ne tient pas compte du logo affiché dans le panneau de contrôle. Les différences qui déterminent le choix sont le prix par Go de RAM, le volume de transfert inclus et le coût de chaque octet supplémentaire, la nature réelle du disque et la part de la stack située au-dessus du système d’exploitation qu’un autre opérateur exécutera pour vous.

Ce guide compare ces critères, car un développeur peut tous les vérifier depuis un terminal ou à partir d’une grille tarifaire publiée. Il indique également dans quels cas DigitalOcean reste le bon choix. Une comparaison qui ne reconnaît aucun avantage ne serait qu’une publicité.

Tous les prix ci-dessous correspondent aux tarifs publics affichés, vérifiés le 5 août 2026. Les prix évoluent, et plusieurs fournisseurs présentés ici ont modifié les leurs pendant 2026. La structure tarifaire évolue beaucoup plus lentement. Commencez donc par examiner les ratios et le modèle de facturation, puis vérifiez le tarif du jour sur la page officielle du fournisseur avant de vous engager.

Le prix par Go de RAM est la valeur à comparer

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

Chez un même fournisseur, le prix par Go de RAM varie à peine. DigitalOcean facture $6.00 par Go avec l’offre de 1 Go, et le même montant de $6.00 par Go avec l’offre de 4 Go, facturée $24.00 par mois. Choisir une offre plus grande chez le même fournisseur ne donne droit à aucune remise. La taille de l’offre n’est donc pas le critère de décision. C’est le fournisseur qui compte.

Akamai, qui vend désormais ce qui était autrefois Linode, facture ses offres partagées de 2 Go et 4 Go respectivement $12 et $24, exactement comme DigitalOcean. Son offre d’entrée de gamme est moins chère, à $5.00. Lorsque deux entreprises affichent exactement les mêmes prix, c’est un signal important : ce niveau de gamme est fixé en fonction d’un concurrent, et non du matériel. Il continuera donc à suivre le prix de ce concurrent.

L’écart apparaît chez les fournisseurs qui construisent leurs propres datacentres et facturent en euros. Une offre Hetzner CX23 fournit 4 Go de RAM pour environ $6.49 par mois, soit $1.62 par Go. C’est proche du quart du tarif de DigitalOcean. Ce montant en dollars est converti à partir d’un prix affiché en euros. Il varie donc avec le taux de change. Hetzner a également augmenté ses prix cloud en 2026. Les anciens articles comparatifs citent donc des tarifs qui n’existent plus.

Le prix par Go de RAM ne dit rien du CPU fourni. Avec un vCPU partagé, l’hyperviseur planifie votre cœur en concurrence avec ceux des autres clients. Le contrôle fiable se fait sur une machine que vous avez réellement louée :

vmstat 1 10

Lisez la colonne st. Elle indique le pourcentage de temps pendant lequel votre vCPU était prêt à s’exécuter, mais où l’hyperviseur a attribué le cœur physique à un autre client. Quelques pourcents sous charge sont normaux. Une valeur durablement à deux chiffres indique que l’hôte est surabonné. Aucun prix par Go ne compense un cœur que vous ne pouvez pas utiliser. Exécutez ce test pendant votre heure de pointe. Le steal time dépend des voisins, et les voisins ont leurs propres horaires. Pour avoir une vue d’ensemble du coût réel d’un mois d’hébergement, une fois le stockage et le trafic ajoutés, consultez ce que coûte un VPS d’un mois à l’autre.

Le coût réel du transfert inclus

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean inclut 1 To de transfert sortant avec son offre d’entrée de gamme et facture le dépassement au GiB, soit environ 10.00 $ par To supplémentaire. Akamai inclut le même volume et facture environ moitié moins, soit environ 5.00 $ par To. Vultr inclut 2 To, avec un tarif de dépassement similaire. Hetzner inclut 20 To, puis facture environ 1.20 $ par To supplémentaire, soit un écart d’un ordre de grandeur par rapport aux autres.

Trois éléments structurels comptent davantage que les chiffres affichés. Le trafic entrant est gratuit chez les quatre fournisseurs : seul le trafic sortant est comptabilisé. DigitalOcean et Vultr mutualisent le volume inclus entre tous les serveurs du compte. Une machine très sollicitée consomme donc le quota d’une autre, tandis qu’une flotte de petits serveurs partage un même volume global. Le trafic entre serveurs via un réseau privé ou un réseau VPC n’est généralement pas comptabilisé. Placer la base de données sur l’interface privée est donc aussi une décision de facturation, pas seulement de sécurité.

Tout cela est sans importance si vous êtes loin de la limite. Un blog, une API qui renvoie du JSON ou un petit SaaS n’atteindront pas 1 To par mois. La vidéo, les galeries d’images, les serveurs de jeux, les miroirs de paquets et les cibles de sauvegarde hors site l’atteindront. Mesurez avant de partir du principe que ce ne sera pas le cas :

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

vnstat -m affiche le transfert par mois, en séparant les données reçues et transmises. Seule la colonne des données transmises est facturée. La base de données est vide au départ. La première mesure utile est donc disponible un jour après l’installation, et le premier mois complet un mois plus tard. D’ici là, le graphique de bande passante du fournisseur est le seul relevé disponible.

Posez une autre question à laquelle aucune grille tarifaire ne répond : lorsque vous dépassez le volume inclus, le fournisseur vous facture-t-il le dépassement ou limite-t-il le port ? La facturation coûte de l’argent. La limitation pénalise les utilisateurs, précisément au moment où ils sont les plus nombreux. Vous devez savoir ce qu’achète un pic de trafic.

NVMe ou SATA : vérifiez ce que vous avez réellement

Le panneau indique NVMe. Cela décrit les disques de l’hôte, mais votre machine virtuelle n’y est peut-être pas stockée. Le stockage local place votre disque virtuel sur des disques installés dans la même machine physique. Le stockage réseau le place sur un cluster de stockage distinct, accessible via le réseau du datacentre. C’est ce qui permet le redimensionnement instantané, la migration à chaud et les snapshots sur place.

Dans le guest, les deux types de stockage se présentent de la même manière :

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

ROTA et rotational renvoient 0 pour tout périphérique que l’hôte déclare comme non rotatif. Un volume réseau reposant sur du NVMe renvoie donc exactement la même valeur qu’un NVMe local. Cette valeur indique que le disque n’utilise pas de plateau rotatif. Elle ne permet pas de savoir où se trouve le disque. Confirmer la présence d’un disque NVMe sous Linux présente les noms des périphériques et ce que chacun implique.

La latence à une profondeur de file d’attente de 1 permet de les distinguer, car une seule petite lecture ne peut pas être masquée par d’autres opérations. Un NVMe local répond depuis le même châssis. Un volume réseau ajoute un aller-retour sur le réseau du datacentre à chaque lecture. Sa latence minimale est donc plus élevée, même si son débit semble similaire avec une file d’attente profonde.

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

La première exécution affiche un bloc clat, qui correspond à la latence d’achèvement. Consultez la ligne du 99e percentile plutôt que la moyenne, car la moyenne masque les blocages perceptibles par les utilisateurs. La deuxième exécution affiche IOPS= sur sa ligne de synthèse. Exécutez les deux tests chez le fournisseur que vous utilisez et sur une instance d’essai du fournisseur envisagé, le même jour, puis comparez vos deux propres valeurs. Une valeur publiée par l’un ou l’autre fournisseur a été mesurée sur une machine que vous ne pouvez pas observer. Exécutez également chaque test trois fois à des heures différentes, car un hôte peu sollicité et un hôte très sollicité donnent des résultats différents avec la même offre. Évaluer correctement un VPS présente la méthode, et ce que signifie réellement un VPS SSD explique les termes marketing sous-jacents.

Régions : mesurez la latence, ne consultez pas la carte

Une liste de régions reste un argument marketing tant que vous ne l’avez pas mesurée. Ce que ressent l’utilisateur correspond à l’aller-retour entre son réseau et votre serveur. Cela dépend du chemin emprunté par les paquets, pas de la distance sur une carte. Un serveur situé à 300 km, derrière une liaison de transit saturée, sera moins performant qu’un serveur situé à 1,500 km sur un chemin dégagé.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

mtr affiche chaque saut avec sa propre perte de paquets et sa latence. Ainsi, un écart de 60 ms entre deux sauts permet d’identifier la liaison qui vous pénalise, au lieu d’accuser la destination. Exécutez cette commande depuis une machine connectée au réseau utilisé par vos utilisateurs. Les routes entre datacenters sont les meilleures routes d’internet. Elles donnent une image favorable de tous les fournisseurs, de la même manière.

Un point structurel reste valable même si les prix changent. Si un fournisseur ne possède qu’une seule région sur votre continent, votre plan de reprise après sinistre consiste à changer de continent, avec la latence que cela implique. Comptez les régions vers lesquelles vous pourriez réellement basculer, pas celles qui figurent sur la page.

Les snapshots et les sauvegardes sont facturés séparément

Les options de stockage sont souvent ce qui rend un forfait bon marché coûteux. DigitalOcean facture les snapshots $0.06 par GiB et par mois. Les sauvegardes automatiques sont facturées selon le serveur : 20% du prix du forfait pour des sauvegardes hebdomadaires, 30% pour des sauvegardes quotidiennes, avec aussi une option facturée selon l’usage, par GiB. Les deux modèles se défendent, mais ils présentent des inconvénients opposés. Un prix calculé en pourcentage suit la taille du serveur. Un serveur volumineux qui contient peu de données est donc facturé trop cher. Un prix par GiB suit le volume de données. Un petit serveur associé à un volume important est donc facturé trop cher.

Demandez combien coûte une restauration et combien de temps elle prend. Le prix de conservation d’une sauvegarde ne représente qu’une partie du problème. Demandez aussi si la suppression du serveur supprime également ses snapshots.

Conservez ensuite une copie que le fournisseur ne contrôle pas. Les snapshots du fournisseur restent dans le compte de celui-ci. La perte des identifiants, un échec de paiement ou la suspension du compte peut donc rendre le serveur et ses sauvegardes indisponibles au même moment. Des sauvegardes restic vers un stockage qui vous appartient coûtent quelques dollars de stockage objet. Vous pouvez les restaurer chez n’importe quel fournisseur. C’est ce qui rend une migration réversible plutôt que définitive.

Quelle part de la stack voulez-vous gérer ?

Les fournisseurs se situent sur un continuum. À une extrémité, vous louez une machine et vous y gérez vous-même toute la stack. À l’autre, vous poussez une branche Git et vous ne voyez jamais de serveur. Le prix par Go de RAM est une comparaison pertinente uniquement à la première extrémité, car à la seconde vous achetez du travail plutôt que de la mémoire, et le travail n’a pas de prix par Go.

Déterminez honnêtement à quelle extrémité vous vous situez avant toute comparaison. Une base de données managée à 15.15 $ par mois semble chère face à un serveur à 6 $, jusqu’à ce que vous évaluiez les heures nécessaires : réplication, basculement, restauration à un instant donné, mises à niveau de version mineure et alerte qui réveille quelqu’un à 03:00. Si ce travail vous incombe, gérez-le vous-même et conservez la différence. Si votre travail consiste à développer l’application, racheter ce service coûte peu. Le partage entre services managés et non managés détermine la colonne de la grille tarifaire que vous devez consulter. Si la réponse honnête est que vous voulez la machine entière et ses disques pour vous seul, il s’agit d’une question VPS ou serveur dédié plutôt que d’une question de fournisseur. La même question se pose pour le reste de la facture mensuelle d’un développeur : comparer les offres Claude et ChatGPT dépend de la part du travail que vous souhaitez déléguer, et non du prix affiché.

Quand DigitalOcean est le bon choix

DigitalOcean est intéressant lorsque vous achetez une plateforme plutôt qu’une machine virtuelle.

• Bases de données managées. PostgreSQL et MySQL managés commencent à $15.15 par mois pour 1 GiB de RAM et 10 GiB de stockage. Le stockage supplémentaire est facturé par GiB. Les nœuds standby sont facturés par nœud. Reproduire cette fiabilité vous-même nécessite Patroni ou repmgr, un magasin de consensus, un proxy de connexion et un exercice de failover réellement répété. Une équipe de deux personnes ne peut pas maintenir tout cela et livrer des fonctionnalités.
• App Platform. Vous poussez une branche, obtenez un build, un certificat et un service en fonctionnement, sans système d’exploitation à patcher. La version VPS bon marché de ce produit, c’est vous, un samedi.
• Object storage et load balancers couverts par un provider Terraform mature. Une flotte que vous pouvez détruire et reconstruire à partir du code vaut plus qu’un prix unitaire inférieur.
• L’entreprise derrière le produit. Des niveaux de support publiés, une status page avec un historique et une organisation qui répondra au questionnaire de sécurité d’un client. Si vous revendez de l’hébergement, cela vaut plus que quelques dollars par GB.

DigitalOcean devient cher lorsqu’il s’agit de machines virtuelles ordinaires, en quantité, avec un véritable trafic sortant. C’est précisément le cas qu’une alternative permet de résoudre, et cela représente l’essentiel de ce qu’achète un développeur qui s’auto-héberge.

Migrer vers un nouveau fournisseur sans interruption

L’interruption pendant une migration a une seule cause : du trafic arrive encore à l’ancienne adresse IP après le déplacement des données vers la nouvelle. Chaque étape ci-dessous sert à réduire cette période et à la rendre prévisible.

Commencez par le DNS, au moins 48 heures avant la migration. Les resolvers mettent votre enregistrement A en cache pendant la durée de son TTL (time to live). Un enregistrement avec un TTL de 24 heures peut donc continuer à envoyer les utilisateurs vers l’ancien serveur jusqu’à un jour après sa modification. Réduire le TTL au moment du basculement ne sert à rien, car les resolvers ont déjà l’ancienne valeur avec son ancienne date d’expiration. Réduisez-le d’abord, attendez l’expiration de l’ancienne valeur, puis migrez.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

La première commande affiche le TTL actuel dans la deuxième colonne de la réponse. Définissez-le à 300 chez votre fournisseur DNS, puis attendez plus longtemps que la valeur que vous venez de remplacer.

Procédez ensuite dans cet ordre.

1. Provisionnez le nouveau serveur et sécurisez-le avant d’y déployer quoi que ce soit. Les dix premières minutes sur un nouveau VPS couvre l’étape que l’on néglige lorsqu’on est pressé.
2. Installez la stack applicative et effectuez une première copie des données avec rsync, pendant que l’ancien serveur continue de répondre normalement.
3. Émettez maintenant le certificat TLS sur le nouvel hôte, avec un challenge DNS-01. Un challenge HTTP-01 valide l’adresse IP vers laquelle le DNS pointe actuellement, qui est encore celle de l’ancien serveur. Un challenge DNS-01 élimine entièrement ce problème d’ordre des opérations.
4. Testez le nouvel hôte avant toute modification publique en surchargeant le DNS sur votre propre ordinateur portable. Ajoutez 203.0.113.20 example.com à /etc/hosts, consultez le site réel, puis supprimez la ligne. Aucun utilisateur n’est affecté par ce test.
5. Évaluez la taille de la base de données. En dessous de quelques Go, un dump et une restauration tiennent dans le gel des écritures. Au-delà, configurez plusieurs jours à l’avance une réplication de l’ancienne base de données vers la nouvelle et laissez-la rattraper son retard. Le gel ne couvrira ainsi que la promotion.
6. Gelez les écritures. Placez l’application en maintenance ou en lecture seule. C’est la seule étape visible par les utilisateurs et elle doit durer quelques minutes.
7. Effectuez la synchronisation finale : le même rsync, puis la synchronisation finale de la base de données.
8. Modifiez les enregistrements A et AAAA pour les faire pointer vers la nouvelle adresse IP. Avec un TTL de 300 secondes, la plupart des resolvers suivent le changement en environ cinq minutes.
9. Laissez l’ancien serveur en fonctionnement et accessible pendant au moins une journée, car certains resolvers ignorent les TTL courts. Si l’ancienne application accepte encore les écritures, les utilisateurs arrivant tardivement écriront dans la mauvaise base de données. Faites donc pointer l’ancien hôte vers la nouvelle base de données ou faites-lui renvoyer une page de maintenance.
10. Surveillez le taux d’erreur du nouveau serveur pendant une journée, rétablissez ensuite le TTL à sa valeur normale et détruisez l’ancien serveur après une semaine, pas le soir même.

La copie elle-même utilise deux commandes, exécutées chacune deux fois. Synchronisation des fichiers :

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a conserve le propriétaire, les permissions et les horodatages, -H conserve les hard links, -AX conserve les ACL et les extended attributes, et --numeric-ids empêche rsync de remapper les identifiants utilisateur via des noms différents entre les deux machines. Exécutez-la plusieurs jours à l’avance, puis de nouveau pendant le gel. Elle ne transférera alors que les éléments qui ont changé.

Pour PostgreSQL si la base est assez petite pour utiliser un dump :

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

Pour MySQL ou MariaDB :

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction crée le dump dans une seule transaction pour les tables InnoDB. Le résultat est donc cohérent et l’application peut continuer à écrire pendant l’opération. Sans ce flag, mysqldump verrouille les tables. Le gel des écritures commence alors plus tôt que prévu et vous ne choisissez plus son moment.

Deux éléments externes à vos serveurs peuvent également provoquer des problèmes. Une nouvelle adresse IP n’a aucune réputation pour l’envoi d’e-mails. Les messages envoyés directement depuis le nouveau serveur sont donc filtrés comme spam. Utilisez un relay qui dispose déjà d’une bonne réputation. De plus, tout partenaire qui autorise votre IP sortante, comme une payment gateway ou le firewall d’un client, doit être mis à jour avant le basculement. Sinon, ces appels commencent à échouer dès que le trafic est déplacé.

À vérifier avant de vous engager

• Vérifiez si le prix est promotionnel et à quel tarif il est renouvelé. Une remise appliquée à la première période, puis suivie d’un doublement au renouvellement, constitue un coût réel, simplement reporté.
• Vérifiez si la période est prépayée. Les offres prépayées sur plusieurs années, comme celles de SSD Nodes, permettent de réduire fortement le prix par Go de RAM grâce au paiement initial. En contrepartie, vous ne pouvez pas résilier le mois suivant. Choisissez donc une durée correspondant à votre niveau de certitude.
• Vérifiez le coût mensuel d’un snapshot, ainsi que le coût d’une restauration et sa durée en minutes.
• Vérifiez si le dépassement est facturé ou limité.
• Vérifiez si IPv6 est correctement routé ou s’il s’agit simplement d’une adresse ajoutée séparément.
• Vérifiez s’il existe une API avec un provider Terraform maintenu, si vous comptez reconstruire l’infrastructure à partir du code plutôt que manuellement.
• Vérifiez comment joindre le support et quel est le délai de réponse annoncé pour un serveur indisponible, plutôt que pour une question commerciale.

Choisissez le fournisseur selon le critère qui pèse le plus dans votre facture. Si ce critère est la mémoire, le prix par Go de RAM permet de trancher. S’il s’agit du trafic sortant, c’est le volume de transfert inclus qui compte. S’il s’agit de votre temps, choisissez la plateforme managée. Parmi les quatre plateformes comparées ici, DigitalOcean est la plus performante sur ce point.

FAQ

Hetzner est-il toujours moins cher que DigitalOcean ?

Pour une simple machine virtuelle, le coût par Go de RAM est nettement inférieur : environ $1.62 contre $6.00 pour les offres partagées d’entrée de gamme au 5 août 2026. La comparaison change dès que des services managés entrent en jeu. Hetzner vend des serveurs et du réseau. Vous devez donc fournir vous-même la base de données managée ou la plateforme push-to-deploy, ou faire appel à un tiers, ce qui représente du temps facturé. Hetzner a également augmenté ses tarifs cloud en 2026. Vérifiez donc le montant actuel en euros au lieu de vous fier à un article ancien.

Quelle alternative à DigitalOcean choisir si j’ai besoin d’une base de données managée ?

Vultr et Akamai vendent tous deux des bases de données managées. Ce sont donc les substituts les plus proches si c’est la base de données managée qui vous retient chez DigitalOcean. Les hébergeurs européens low-cost n’en proposent généralement pas. Vous devez alors administrer vous-même PostgreSQL ou MySQL, notamment la réplication et un failover testé. C’est un vrai travail. Comparez son coût aux $15.15 par mois d’une instance managée de 1 GiB avant de conclure que le serveur moins cher vous a réellement fait économiser.

Comment déplacer un site en production vers un nouveau fournisseur sans interruption ?

Réduisez le TTL DNS à 300 secondes au moins 48 heures avant la migration. Les resolvers continuent en effet de servir l’ancienne adresse IP pendant la durée indiquée par le TTL précédent. Préparez et testez le nouvel hôte pendant que l’ancien continue de servir le trafic. Utilisez pour cela un override /etc/hosts sur votre propre machine afin que personne d’autre ne le voie. Ensuite, bloquez les écritures pendant quelques minutes, exécutez le dernier delta rsync et la dernière synchronisation de la base de données, basculez les enregistrements A et AAAA, puis laissez l’ancien serveur fonctionner pendant une semaine au cas où un resolver ignorerait le TTL court.

Un VPS moins cher signifie-t-il que les disques sont plus lents ?

Pas nécessairement. Le point important est de savoir si votre disque virtuel est local à l’hôte ou situé sur un cluster de stockage réseau, ce que le panel indique rarement. lsblk -o NAME,ROTA signale 0 dans les deux cas, car les deux supports sont non rotatifs. Mesurez plutôt les performances : exécutez fio avec --iodepth=1 --bs=4k --direct=1, puis lisez la latence d’exécution au 99e percentile. Un volume réseau ajoute un aller-retour sur le réseau du datacentre à chaque lecture. Son niveau de latence minimal est donc supérieur à celui d’un NVMe local, même lorsque le débit avec une file de requêtes profonde semble similaire.

Mes e-mails seront-ils toujours distribués depuis le nouveau serveur ?

Souvent pas au début. Une nouvelle adresse IP n’a aucun historique d’envoi. Les serveurs destinataires considèrent donc les e-mails provenant de cette adresse comme suspects, et ceux-ci arrivent dans les spams ou sont rejetés. Les enregistrements SPF et DKIM pointent également vers l’ancien hôte tant que vous ne les avez pas mis à jour. Envoyez les e-mails applicatifs via un relay ou un service d’e-mail qui dispose déjà d’une bonne réputation. Mettez à jour les enregistrements DNS de la messagerie avant la bascule, et non après.