Alternative à AWS sans KYC : quitter les hyperscalers

Pourquoi les équipes quittent AWS, DigitalOcean, Hetzner et Vultr

Le trafic de recherche pour une alternative à AWS sans KYC est dominé par des personnes qui ont déjà quelque chose en production. Cela compte, car cela change la question de quel cloud est le moins cher à qu'est-ce qui casse si je déménage. Trois déclencheurs expliquent l'essentiel des cas. Le premier est une exigence d'identité qui arrive après coup — un compte qui facturait tranquillement depuis un an se retrouve soudain limité tant qu'un document n'a pas été téléversé. Le deuxième est la facture : le compute était prévu, l'egress ne l'était pas. Le troisième est plus discret et arrive généralement en dernier — la prise de conscience qu'un compte cloud d'entreprise est un registre durable, taillé pour une citation à comparaître, de qui fait tourner quoi.

Les quatre noms du titre ne sont pas équivalents. AWS, DigitalOcean et Vultr sont des entreprises américaines aux structures juridiques américaines ; Hetzner est allemand et tarifé assez agressivement pour qu'on en tolère la paperasse. Ce qu'ils ont en commun n'est pas une politique précise mais une capacité : chacun détient un moyen de paiement vérifié et se réserve le droit d'en demander davantage, à sa discrétion, sur un compte que vous avez déjà bâti. L'alternative n'est pas une politique plus amicale — c'est un fournisseur qui ne collecte jamais ce matériau au départ, ce qui résume entièrement notre position no-KYC.

Ce que chaque hyperscaler vérifie avant de pouvoir démarrer une instance

Il est utile de découper la surface de vérification en couches, car aucun ID requis est généralement vrai et généralement hors sujet. La couche un est l'adresse e-mail et, de plus en plus, un numéro de téléphone qui doit accepter un SMS — déjà deux identifiants que la plupart des gens réutilisent partout. La couche deux est la carte de paiement, et c'est la couche qui fait le vrai travail : la carte a été émise par une banque qui a effectué une vérification d'identité complète, si bien que le fournisseur hérite d'une identité légale vérifiée sans jamais vous demander de document. La couche trois, invoquée sélectivement, est la demande de document — pièce d'identité, selfie, relevé bancaire — généralement déclenchée par un score de risque que vous ne voyez jamais.

C'est pourquoi payer un cloud américain avec une crypto de confidentialité achetée sur un exchange lié à une carte ne change presque rien : l'identité a été établie à la couche deux avant même qu'une crypto n'entre en jeu. Retirer le KYC de l'hébergement signifie retirer la relation de crédit qui l'exige, pas remplacer le rail de paiement greffé par-dessus. Le guide sur un VPS sans vérification d'identité couvre le volet compte en détail, et payer son hébergement anonymement couvre le volet financement, y compris les maillons de la chaîne qui trahissent les gens. Le glossaire définit les termes utilisés sur l'ensemble de ce site.

Facturation postpayée par carte face à un solde crypto prépayé

La différence structurelle entre les deux modèles, c'est le crédit. Un hyperscaler vous laisse consommer d'abord et facture ensuite, ce qui fait de vous un débiteur pour tout un mois à la fois — et personne n'accorde de crédit à une contrepartie anonyme. La vérification d'identité n'est pas un module ajouté à la facturation postpayée ; c'est ce qui rend la facturation postpayée possible. Inversez le sens et l'exigence s'évapore. Un solde prépayé ne porte aucun risque de crédit, donc il n'y a rien à garantir et aucune raison de savoir qui vous êtes. C'est le véritable mécanisme derrière un serveur cloud sans vérification d'identité, et il vaut la peine d'être compris avant qu'il ne se mette à ressembler à un argument marketing.

En pratique : un compte, c'est un pseudonyme et un mot de passe, avec huit codes de récupération délivrés à l'inscription et aucun e-mail nulle part dans la boucle. Vous rechargez entre $30.00 et $5,000.00 à la fois, dans l'une des 8 cryptos et variantes réseau proposées, sur 7 devises, Monero et Bitcoin figurant en tête de liste. Les déploiements et renouvellements débitent ensuite ce solde en interne — pas de facture, pas d'attente de confirmation, un VPS en ligne en environ 15 min. Le solde inutilisé est remboursable en crypto dans les 30 jours suivant la recharge qui l'a alimenté, moins les frais de réseau. Le mécanisme complet, y compris le barème de bonus sur les recharges plus importantes, se trouve dans la facturation par solde prépayé expliquée ; le tutoriel Monero montre une recharge de bout en bout.

Egress, bande passante et la facture que personne ne prévoit

L'egress facturé au compteur est le poste qui déclenche le plus souvent la recherche qui vous a mené ici. Le compute est facile à modéliser — des heures d'instance multipliées par un tarif — tandis que l'egress est fonction du succès que rencontre votre projet, soit précisément le chiffre que vous ne pouvez pas prévoir. Autour gravitent les compteurs accessoires : transfert inter-zones, unités de capacité du load balancer, heures de passerelle, et facturation au gigaoctet pour ressortir vos propres sauvegardes. Un mois de succès inattendu se traduit par une facture plutôt que par un goulot d'étranglement, et l'architecture finit par être façonnée par la grille tarifaire.

Notre réponse est forfaitaire. Chaque plan VPS embarque un port non compté — 1 Gbps sur toute la gamme, 2 Gbps sur le plus gros — et le prix mensuel est le prix total. Il n'y a aucun quota de transfert à dépasser ni de facturation au gigaoctet en sortie, ce qui explique pourquoi les médias, les cibles de sauvegarde, les miroirs et les sorties VPN ont tendance à migrer en premier. La mitigation L3/4 1.5 Tbps est incluse en standard, pas vendue en option facturée au compteur. Non compté ne veut pas dire non surveillé, et prétendre le contraire serait malhonnête : la politique d'usage acceptable continue de s'appliquer, et le spam, le command-and-control de malwares et le CSAM sont retirés dès détection.

Juridiction : qui peut atteindre vos données une fois sorti des clouds américains

Quitter un cloud américain change le système juridique auquel répond votre infrastructure, et c'est en général un effet plus important que le prix. Un fournisseur constitué aux États-Unis reste atteignable par une procédure américaine quel que soit le drapeau qui flotte sur le datacentre, parce que le levier se trouve dans la maison mère, pas dans la baie. Choisir un hébergeur en dehors de cette structure déplace la question vers un autre ensemble de tribunaux, avec des standards différents sur ce qu'une ordonnance doit contenir avant que quiconque n'agisse. C'est un vrai changement, pas une échappatoire : quelqu'un a toujours juridiction, et c'est vous qui choisissez qui.

Il y a 6 régions parmi lesquelles choisir. Bucarest et Amsterdam facturent au tarif de base et offrent la connectivité européenne la plus solide ; Zurich, Reykjavik, Kuala Lumpur et Panama City appliquent chacune un modificateur régional affiché en direct dans le configurateur, chacune achetant quelque chose de différent — une protection des données garantie par la loi, un cadre de liberté de la presse, une latence Asie-Pacifique en dehors des Five Eyes, ou l'absence de loi sur la conservation des données. Les arbitrages sont détaillés région par région dans quelle localisation offshore choisir ? et sur le plan légal dans comparatif des juridictions d'hébergement offshore. Notre position ne bouge pas : les notifications DMCA ne sont ni traitées ni suivies d'effet — le DMCA est une loi américaine sans force dans nos juridictions, et nous n'agissons que sur ordonnance contraignante d'un tribunal ayant compétence sur le serveur concerné. Ce que cette formule couvre et ne couvre pas est détaillé dans ce que signifie vraiment un hébergement « DMCA-ignored ».

Faire correspondre une instance AWS ou DigitalOcean à un plan no-KYC

La plupart des migrations sont plus modestes qu'elles n'en donnent l'impression. Une instance polyvalente, c'est un nombre de vCPU, un chiffre de mémoire et un disque, et le barème no-KYC VPS propose Drift, Shelf, Slope, Abyss et Hadal à partir de $8.00/mois — les caractéristiques exactes vivent sur la page des plans plutôt qu'ici, où elles finiraient par se périmer. Deux habitudes méritent d'être abandonnées pendant le déménagement. La première est de dimensionner à partir du type d'instance plutôt qu'à partir de la mesure réelle : un vCPU dédié sur EPYC avec du NVMe se comporte différemment d'une instance burstable qui throttle discrètement depuis des mois, et le remplacement honnête se situe souvent un cran en dessous de ce que suggérait l'ancienne étiquette.

La seconde est de traiter le stockage comme infini. Le stockage bloc que vous attachez au téraoctet à la demande devient un chiffre NVMe fixe par plan, si bien qu'une charge de travail qu'on a laissée s'étaler a besoin d'un vrai chiffre avant de bouger. Au-dessus du barème VPS, le matériel dédié démarre à $66.00/mois et c'est là que doit aller tout ce qui tourne sur une instance de classe metal-class ; il est disponible à Bucarest, Amsterdam et Zurich, et la mise à disposition prend 2–12 h plutôt que quelques minutes.

Ce que vous perdez vraiment en quittant un hyperscaler

C'est la section que la plupart des guides de migration omettent. Vous échangez une plateforme managée contre du root sur un serveur, et la différence représente du vrai travail. Il n'y a pas de service de stockage objet, pas de base de données relationnelle managée, pas de runtime serverless, pas de control plane Kubernetes managé, pas de système d'identité et d'accès avec politiques par rôle, et pas de groupe d'autoscaling qui ajoute discrètement des instances à trois heures du matin parce qu'une file d'attente s'est creusée. Tout ce que vous louiez comme un service devient quelque chose que vous installez, surveillez, patchez et sauvegardez vous-même. Il y a 6 régions plutôt que des dizaines, donc une empreinte edge véritablement mondiale n'est pas au menu. La facturation est mensuelle et prépayée plutôt qu'à la seconde, ce qui convient aux charges de travail stables et pénalise les charges en pics.

Il existe aussi un plafond de conformité, et il mérite d'être posé sans détour : si l'auditeur d'un client exige un fournisseur nommé, un accord de traitement des données signé et un rapport d'attestation, un hébergeur qui ne conserve délibérément aucun document d'identité ne pourra pas satisfaire ce questionnaire — celui-ci compris. Ce n'est pas une lacune que nous comptons combler : c'est une conséquence directe du modèle, pas un oubli. Jugez ce compromis à l'aune de votre propre modèle de menace plutôt que du nôtre. Le tableau comparatif nous place aux côtés de dix autres hébergeurs orientés confidentialité sur les mêmes critères, et la FAQ répond aux questions opérationnelles que ce guide garde délibérément courtes.

Quelles charges de travail migrent proprement, et lesquelles doivent rester

Les candidats à une migration propre sont ceux qui n'ont jamais utilisé un hyperscaler que comme une machine Linux avec un bon réseau. Sorties VPN et tunnels personnels — voir monter son propre WireGuard — ainsi que les relais Tor, le mail auto-hébergé, les sites statiques et installations CMS, les backends d'application et de jeu, les runners CI, les scrapers, les miroirs et tout ce qui est gourmand en egress. Aucun de ces cas ne porte de dépendance à un service managé, et le port forfaitaire non compté les rend généralement à la fois moins chers et plus simples.

Ceux qui doivent rester en place sont tout aussi identifiables. Tout ce qui est soudé à un service managé propriétaire relève de la réécriture plutôt que de la migration, et une réécriture déguisée en déménagement est exactement ce qui fait échouer les migrations. Tout ce qui est réellement élastique — un trafic qui varie d'un ordre de grandeur selon un calendrier — est précisément ce pour quoi la facturation à la seconde et les groupes d'autoscaling excellent. Tout ce qui relève d'un régime de conformité nommant ses fournisseurs reste là où la paperasse existe déjà. Un parc scindé est un résultat légitime, pas un aveu d'échec : migrez les charges de travail VPS offshore qui en profitent, et laissez le reste exactement où il est.

Étape par étape

1. 01

   Inventoriez ce que l'hyperscaler fait réellement pour vous

   Avant de chiffrer quoi que ce soit, dressez la liste de tous les services du compte, pas seulement des instances. Bases de données managées, buckets de stockage objet, files d'attente, certificats, zones DNS, tâches planifiées et rôles IAM constituent la vraie migration ; le compute est la partie facile. Tout élément de cette liste sans remplaçant auto-hébergé est une décision à prendre, pas une tâche à planifier.

2. 02

   Ouvrez un compte et alimentez un solde prépayé

   L'inscription se résume à un pseudonyme et un mot de passe — pas d'e-mail, pas de téléphone, pas de carte. Conservez les huit codes de récupération hors ligne avant d'aller plus loin : perdez le mot de passe et les huit codes, et le compte devient irrécupérable, car il n'existe aucune réinitialisation par e-mail en secours. Puis rechargez à partir de $30.00 dans la crypto de votre choix.

3. 03

   Dimensionnez le remplaçant et choisissez la région

   Reprenez les chiffres de CPU et de mémoire réellement mesurés, pas ceux provisionnés, et choisissez un échelon dans le barème. Choisissez la région d'abord pour son profil juridique, sa latence en second, puis lisez le modificateur régional dans le configurateur avant de valider. Un VPS est en ligne en environ 15 min ; le matériel dédié prend 2–12 h.

4. 04

   Reconstruisez les briques managées avant de déplacer la moindre donnée

   Montez les remplaçants et prouvez qu'ils fonctionnent pendant que l'ancienne stack sert encore le trafic : PostgreSQL ou MariaDB à la place de la base de données managée, un serveur de stockage objet ou un disque brut à la place du bucket, un reverse proxy à la place du load balancer managé, et votre propre automatisation de certificats. Durcissez la machine au fur et à mesure — SSH par clé uniquement, un pare-feu en default-deny, des mises à jour de sécurité automatiques.

   apt update && apt full-upgrade -y
   apt install -y ufw fail2ban unattended-upgrades
   ufw allow OpenSSH
   ufw enable

5. 05

   Synchronisez les données, puis synchronisez-les à nouveau

   Faites une première copie en masse pendant que l'ancien service tourne encore, puis un second passage court au moment de la bascule pour rattraper le delta. Les bases de données migrent via un dump et une restauration, ou via réplication si le budget de coupure est serré. Répétez la restauration sur la nouvelle machine avant de lui faire confiance — une sauvegarde jamais testée n'est pas une sauvegarde.

   rsync -aHAX --numeric-ids --info=progress2 /srv/ root@newhost:/srv/
   pg_dump -Fc appdb | ssh root@newhost 'pg_restore -d appdb'

6. 06

   Abaissez le TTL DNS, puis basculez

   Abaissez à 300 secondes le TTL de chaque enregistrement que vous prévoyez de déplacer, au moins un jour à l'avance, afin que l'ancienne valeur ait expiré de tous les caches avant la bascule. Modifiez les enregistrements, surveillez les journaux des deux serveurs jusqu'à ce que l'ancien se taise, puis remontez le TTL.

   dig +noall +answer example.com A
   dig +noall +answer +trace example.com A

7. 07

   Démantelez de façon réfléchie, pas immédiate

   Laissez à la migration un cycle de facturation complet avant de supprimer quoi que ce soit — l'ancienne instance est votre filet de secours, et elle ne coûte qu'un mois de plus au maximum. Une fois confiant, exportez tout ce que vous êtes tenu de conserver, supprimez les données, retirez le moyen de paiement, puis fermez le compte, dans cet ordre. Fermer un compte n'efface pas la trace qu'il a existé, ce qui est un argument pour ne pas en ouvrir un autre.