Comment choisir la région offshore de son serveur

Tout écran de déploiement vous pose la même question vers la fin, et presque personne n'y réfléchit : où cette machine doit-elle physiquement se trouver ? La plupart des gens choisissent l'option la plus proche, ou la première de la liste, et passent à la suite. C'est pourtant le seul choix de la page qu'on ne peut plus défaire ensuite sans copier un service en production vers une nouvelle machine — et c'est aussi le choix qui détermine qui peut contraindre votre hébergeur, quelles informations existent sur vous, et jusqu'où une plainte doit remonter avant que quelqu'un soit tenu d'y répondre. Cela mérite mieux que deux secondes. Voici comment y réfléchir honnêtement, y compris les aspects que l'industrie de l'hébergement offshore a tendance à passer sous silence.

La juridiction est un réglage de friction, pas un bouclier

La correction la plus utile à apporter avant de comparer des pays est celle-ci : choisir un emplacement ne place pas votre serveur hors la loi. Cela change quelle loi s'applique, qui doit être convaincu, et combien de temps cela prend. Ce sont des différences pratiques considérables, et ce n'est pas la même chose que l'immunité. Un hébergeur situé dans une juridiction respectueuse de la vie privée n'est pas obligé de donner suite à un email type de plainte envoyé par un ayant droit étranger — c'est réel, et cela compte. Ce même hébergeur répondra tout de même à une injonction valide émanant d'un tribunal qui a réellement autorité sur lui.

Lisez les argumentaires marketing avec ce filtre en tête et presque tout se résout proprement. « DMCA-ignored » signifie que le processus américain de notification et de retrait ne lie pas un hébergeur situé hors de la juridiction des États-Unis, ce qui n'est jamais qu'une description de la façon dont fonctionne le droit territorial — nous en détaillons les mécanismes dans l'hébergement offshore et DMCA-relaxed expliqué. « Bulletproof » signifie tout autre chose, et généralement des ennuis, ce qui fait l'objet de l'hébergement offshore face à l'hébergement bulletproof. Ce que vous achetez réellement, dans presque tous les cas légitimes, c'est de la friction : assez de distance légale pour que les plaintes automatisées et la pêche spéculative ne se traduisent pas par un retrait immédiat, sans pour autant prétendre que quoi que ce soit sur l'internet public serait hors d'atteinte.

Les cinq questions auxquelles une région répond réellement

Retirez les drapeaux et les argumentaires marketing, et une région répond en réalité à cinq questions distinctes. C'est en les confondant que commencent la plupart des mauvaises décisions, car un pays peut exceller sur l'une et être médiocre sur une autre.

• Qui peut contraindre l'opérateur. Une société d'hébergement répond devant les tribunaux du pays où elle opère. Toute autre autorité dans le monde doit passer par une procédure d'entraide judiciaire internationale, un tribunal local, ou une demande que l'opérateur est libre de refuser. C'est la question dont « offshore » traite vraiment.
• Quelles informations existent au départ. Une contrainte légale ne peut jamais produire que ce qui a déjà été stocké. Une juridiction sans obligation générale de conservation des données permet à un opérateur de ne garder que des journaux minimaux en toute légalité, et aucune injonction ne peut extraire une information qui n'a jamais été écrite.
• Qui d'autre se trouve en amont de vous. Votre hébergeur se situe derrière des opérateurs de transit, une allocation d'adresses IP, et — si vous en utilisez un — un registrar de nom de domaine, chacun dans sa propre juridiction. Un plaignant bloqué au niveau de l'hébergeur remonte fréquemment tout simplement d'un maillon dans la chaîne.
• Jusqu'où voyagent les paquets. La physique se moque de votre modèle de menace. Chaque kilomètre entre votre serveur et les personnes qui l'utilisent est de la latence que vous payez à chaque requête, pour toujours.
• Ce que la loi locale elle-même interdit. Un pays hors de portée de votre adversaire peut avoir ses propres règles de contenu et de surveillance, plus strictes que celles que vous avez quittées. S'éloigner d'un système juridique signifie se rapprocher d'un autre.

Un bon choix est celui qui obtient un bon score sur les questions qui comptent pour votre charge de travail spécifique, et qui accepte consciemment un mauvais score sur les autres. Aucune région ne gagne sur les cinq à la fois, et tout hébergeur prétendant le contraire est en train de vous vendre quelque chose.

La conservation des données : la loi qui décide ce qui existe à remettre

C'est le facteur le plus lourd de conséquences, et le moins discuté. Les débats sur la surveillance se concentrent sur l'accès, mais l'accès vient après le stockage — une injonction contraint à divulguer des informations qui existent, elle n'en crée aucune. La question à se poser sur une juridiction n'est donc pas « peuvent-ils exiger des données » mais « mon hébergeur est-il légalement tenu de générer des données sur moi dès le départ ».

• Les obligations générales de conservation des données en Europe sont bien plus faibles que leur réputation ne le laisse penser. La directive européenne qui imposait une conservation de masse a été invalidée par la Cour de justice de l'Union européenne en 2014, et les lois nationales qui ont tenté de la reproduire ont depuis été jugées à plusieurs reprises incompatibles avec le droit de l'UE. Plusieurs États membres n'ont aujourd'hui aucune obligation générale de conservation qui soit réellement applicable.
• La Roumanie en est l'exemple le plus net, et une vraie raison pour laquelle Bucharest revient si souvent dans l'hébergement orienté confidentialité. Sa cour constitutionnelle a invalidé la loi nationale sur la conservation des données, puis invalidé son remplacement, au motif qu'une conservation indiscriminée est incompatible avec les droits constitutionnels à la vie privée.
• Les règles de conservation visent en général les opérateurs télécoms et les fournisseurs d'accès, pas les sociétés d'hébergement. Cette distinction compte souvent plus que le pays lui-même : une obligation rédigée pour l'opérateur qui connecte des abonnés à internet ne s'étend fréquemment pas à une société qui vous loue une machine virtuelle.
• Ce que l'opérateur choisit de conserver constitue l'autre moitié de l'équation, et cela relève entièrement de sa politique interne, pas de la loi. Deux hébergeurs dans le même pays peuvent avoir des réponses totalement différentes, et celui qui garde quatre-vingt-dix jours de tout est pire pour vous qu'une juridiction plus stricte dotée d'un opérateur à journalisation minimale.
• Les informations de paiement sont la question de conservation qui piège vraiment les gens. Un hébergeur d'une propreté irréprochable sur les journaux serveur, mais qui détient aussi votre numéro de carte et votre adresse de facturation, possède sur vous un dossier d'identité complet — et il survivra au serveur pendant des années.

Les alliances Eyes, sans le marketing

Chaque page d'hébergement offshore cite les alliances Five Eyes, Nine Eyes et Fourteen Eyes, en général comme une simple liste noire. La réalité sous-jacente existe bel et bien : un dispositif de partage du renseignement, apparu entre les États-Unis, le Royaume-Uni, le Canada, l'Australie et la Nouvelle-Zélande, élargi ensuite au Danemark, à la France, aux Pays-Bas et à la Norvège, puis élargi de nouveau pour inclure l'Allemagne, la Belgique, l'Italie, l'Espagne et la Suède. Cela vaut la peine d'être connu. Cela s'applique aussi, la plupart du temps, au mauvais problème.

Ces dispositifs concernent le renseignement électronique échangé entre agences d'État. Ils sont à peu près hors sujet face aux menaces ordinaires qu'affronte un serveur normal — une plainte pour droit d'auteur, un signalement d'abus déposé par un concurrent, une citation à comparaître civile, un hébergeur qui plie sous la pression. Traiter l'appartenance à une alliance comme la seule variable qui compte produit des décisions franchement mauvaises, et les Pays-Bas en sont l'exemple permanent : membres du Nine Eyes, ils sont en même temps l'un des meilleurs endroits au monde pour héberger, avec un peering excellent, un régime juridique mature qui exige une véritable procédure légale plutôt qu'un email type, et une loi de protection des données solide. Écarter Amsterdam sur la foi d'une liste trouvée sur Wikipédia, tout en ignorant le droit de la conservation des données, la politique de l'opérateur et votre propre trace de paiement, revient à optimiser le terme le moins important de l'équation.

Les alliances comptent si votre adversaire est un service de renseignement étatique — auquel cas votre choix d'hébergement n'est qu'une petite partie d'un problème bien plus vaste, et ce n'est pas un guide qu'il vous faut. Pour tous les autres, le classement qui prédit les résultats réels est le suivant : ce que l'opérateur sait de vous, ce que la loi locale l'oblige à stocker, la difficulté pour une partie étrangère de contraindre quoi que ce soit, et seulement ensuite quels traités le gouvernement a signés.

Les huit régions privacy-tier, une par une

Notre réseau compte 14 régions, dont huit sont classées privacy-tier. Cette étiquette n'est pas une revendication d'immunité légale — elle signifie que la région combine un environnement juridique qui exige une procédure en bonne et due forme, un réseau qui ne plie pas à la réception d'une notification automatisée, et une infrastructure que nous exploitons nous-mêmes plutôt que revendue par un tiers. Voici le portrait honnête de chacune, inconvénients compris.

• Amsterdam, Pays-Bas. L'emplacement le mieux connecté de la liste, et la réponse par défaut correcte pour la majorité du trafic européen. Excellent peering, un système juridique qui exige une véritable procédure, une loi de protection des données solide — à mettre en balance avec l'appartenance au Nine Eyes et un écosystème d'ayants droit bien organisé qui sait déposer ses plaintes dans les règles.
• Bucharest, Roumanie. Une jurisprudence constitutionnelle sur la vie privée exceptionnellement solide, ses tribunaux ayant invalidé à deux reprises la législation sur la conservation des données, une infrastructure aux normes de l'UE à un coût nettement inférieur, et une bonne latence vers l'ensemble de l'Europe centrale et orientale. Le peering reste un cran en dessous d'Amsterdam et Frankfurt.
• Zurich, Suisse. Hors de l'UE, avec une culture juridique de la vie privée profondément enracinée et un seuil élevé pour les demandes étrangères, qui doivent transiter par des canaux formels plutôt qu'arriver par email. Ce n'est pas un vide juridique — les autorités suisses coopèrent avec les demandes internationales valides — et c'est l'endroit le plus cher de la liste.
• Reykjavík, Islande. Un environnement réellement singulier pour la liberté d'expression, aucun lien avec le noyau du Five Eyes, un climat frais et une énergie géothermique bon marché. Le compromis, c'est la géographie : chaque paquet traverse un câble sous-marin, donc attendez-vous à une pénalité de latence sensible depuis tout endroit qui n'est pas l'Atlantique Nord.
• Helsinki, Finlande. Politiquement stable, hors du Fourteen Eyes, une infrastructure excellente et le chemin le plus court vers l'internet balte et russophone. La Finlande a bien étendu ses pouvoirs de collecte du renseignement ces dernières années, donc c'est solide plutôt qu'absolu.
• Luxembourg. Une petite juridiction dotée d'une longue tradition institutionnelle de confidentialité et de l'un des régulateurs les plus attentifs à la vie privée dans l'UE, qui héberge une part disproportionnée de l'infrastructure financière européenne. La capacité est limitée par rapport aux grands hubs, et le prix le reflète.
• Kuala Lumpur, Malaisie. Réellement hors de l'orbite juridique euro-américaine, ce qui est tout l'intérêt, avec une bonne portée vers l'Asie du Sud-Est. Mettez cela en balance avec les propres lois malaisiennes sur le contenu et les communications, qui ne sont pas permissives, et une latence vers l'Europe ou les Amériques que vous sentirez passer.
• Moscow, Russie. Effectivement hors de portée des procédures civiles occidentales, ce qui pour certaines charges de travail est exactement ce qu'il faut. Le pays dispose aussi d'une des législations nationales les plus exigeantes au monde en matière de données et de surveillance, donc c'est clairement l'échange d'une exposition légale contre une autre, différente et plus lourde, plutôt qu'une amélioration générale de la confidentialité.

Si vous cherchez un choix par défaut sans raison particulière d'en dévier : Amsterdam pour les audiences européennes, Bucharest quand vous voulez de la distance avec la machinerie des ayants droit d'Europe de l'Ouest sans renoncer à l'infrastructure de l'UE, Zurich quand la priorité est un seuil procédural élevé, et Kuala Lumpur quand la priorité est d'être entièrement hors du système euro-américain. Reykjavík est un choix délibéré, que vous faites en ayant le budget de latence ouvert sous les yeux.

Les six régions standard, et quand elles sont la bonne réponse

Les six autres — Frankfurt, Paris, London, New York, Singapore et Tokyo — sont des emplacements ordinaires, bien connectés, dans des juridictions ordinaires. Elles existent parce qu'un très grand nombre de charges de travail n'ont strictement aucune dimension adverse, et sont tout simplement mieux servies en étant proches de leurs utilisateurs.

• La charge de travail est contrainte par la latence et le public est régional. Une application qui dessert le Japon depuis Tokyo est tout simplement meilleure que la même application servie depuis l'Islande, et aucune théorie juridictionnelle n'y change quoi que ce soit.
• Le contenu est parfaitement quelconque. Un site d'entreprise, un outil interne, un environnement de préproduction ou un projet personnel n'attire aucune plainte, donc acheter de la friction contre des plaintes n'achète rien du tout.
• Vous avez besoin du peering le plus profond possible. Frankfurt et New York se trouvent au sommet de deux des plus grands points d'échange internet au monde, et pour des charges de travail à fort trafic sortant, c'est une différence mesurable.
• La confidentialité dont vous avez besoin se situe au niveau du compte, pas sur la carte. Payer depuis un solde en crypto sans identité rattachée vous donne le même anonymat à Frankfurt qu'à Reykjavík — la juridiction concerne la résistance à la contrainte, pas le fait que votre nom figure ou non sur la machine.
• C'est un nœud parmi plusieurs autres. Les déploiements multi-régions mélangent couramment une base privacy-tier pour les données avec des périphéries standard-tier pour la portée, ce qui est une architecture sensée plutôt qu'un compromis.

Ce dernier point mérite qu'on s'y attarde, car c'est l'erreur la plus courante dans l'autre sens. Des gens choisissent une région privacy-tier lointaine pour une charge de travail qui n'a aucun modèle de menace, paient la latence tous les jours pendant des années, et n'obtiennent rien qu'ils n'auraient pu avoir en payant en Monero depuis un email jetable à Frankfurt. La confidentialité au niveau du compte et la friction au niveau de la juridiction sont deux achats indépendants, et la plupart des gens n'ont besoin que du premier.

La latence est un coût réel — ne la payez pas pour rien

La distance est le seul facteur, dans toute cette discussion, qui ne relève pas de l'interprétation. La lumière dans la fibre parcourt environ deux cents kilomètres par milliseconde, et les routes réelles ne sont jamais droites, donc une règle de travail approximative est d'environ une milliseconde d'aller-retour pour cent kilomètres de séparation, plus tout ce que le trajet ajoute en commutation et en détours.

• À l'intérieur d'une même région — d'Amsterdam à Frankfurt, de Zurich à Paris — vous restez à moins de dix millisecondes, et l'emplacement est en pratique gratuit du point de vue des performances.
• À l'échelle de l'Europe, environ dix à quarante millisecondes. Bucharest et Helsinki desservent parfaitement bien l'Europe de l'Ouest ; cette plage est invisible pour la plupart des applications.
• De l'Islande à l'Europe continentale s'ajoute un tronçon de câble sous-marin, qui atterrit généralement dans une fourchette de vingt à quarante millisecondes, et le tronçon transatlantique est nettement plus long.
• Europe vers Asie du Sud-Est, c'est le gros morceau : couramment cent cinquante millisecondes ou plus dans chaque sens. Sur un protocole bavard, cela se multiplie jusqu'à quelque chose que les utilisateurs décrivent comme cassé.
• Les charges de travail interactives souffrent le plus. Un bureau distant, une session SSH ou une base de données qui multiplie les petits allers-retours amplifie directement la latence, tandis que le transfert en masse et les traitements par lots la remarquent à peine.

Choisir une région : une courte procédure de décision

1. 01Écrivez noir sur blanc l'adversaire réelUn bot d'ayant droit, un concurrent qui dépose des signalements d'abus, un plaignant au civil, un employeur curieux, un service de renseignement national — chacun appelle une réponse complètement différente. Si la réponse honnête est « personne en particulier », vous voulez le tier standard, et vous venez de vous épargner beaucoup de latence.
2. 02Situez vos utilisateurs sur une cartePas l'endroit où vous êtes — celui d'où vient le trafic. Cela fixe le budget de latence, et pour la plupart des charges de travail, cela élimine plus d'options que toutes les considérations juridiques réunies.
3. 03Décidez si la charge de travail est interactiveLes bureaux distants, le travail intensif en SSH et les applications en direct sont pénalisés par la distance. Les nœuds, les relais, les sauvegardes, les traitements par lots et le stockage y sont presque indifférents, ce qui les rend libres d'être placés loin.
4. 04Vérifiez ce que la loi locale interdit, pas seulement ce qu'elle permetUne juridiction hors de portée de votre adversaire peut restreindre votre contenu d'une façon que votre pays d'origine ne fait pas. Lisez la destination comme un lieu avec ses propres règles, plutôt que comme une absence de règles.
5. 05Remontez la chaîne au-dessus de votre hébergeurLes opérateurs de transit et, surtout, votre registrar de domaine relèvent de juridictions distinctes avec des politiques distinctes. Un plaignant arrêté par un hébergeur résilient réussit très souvent un maillon plus haut, et un registrar qui plie fait tomber votre nom de domaine, peu importe où se trouve le disque.
6. 06Réglez la couche du compte avant la couche de la carteInscrivez-vous avec un email qui ne vous est pas rattaché, payez depuis un solde en crypto, et gardez la machine hors de votre nom légal. C'est moins cher, plus rapide et plus efficace que n'importe quel choix de région, et c'est l'étape que tout le monde saute.
7. 07Présélectionnez deux régions et mesurez les deuxUn candidat privacy-tier et un candidat de convenance. Déployez la plus petite instance dans chacune, faites tourner votre propre trafic contre elles pendant une heure, et laissez les chiffres décider plutôt que la carte.
8. 08Prévoyez de vous être trompéGardez une configuration reproductible et des sauvegardes portables, afin que changer d'avis sur une région soit une affaire d'après-midi plutôt qu'une crise. C'est une bonne pratique de toute façon, et cela retire l'essentiel de la pression pesant sur la décision.

Ce qu'un emplacement de serveur ne peut pas faire pour vous

Le magasinage de juridiction a un plafond bien défini, et c'est en le heurtant que des gens finissent mal exposés tout en se sentant bien protégés. Voici les choses qu'aucun pays, sur aucune liste, ne réglera.

• Elle ne peut pas effacer une trace de paiement. Si le serveur a été acheté avec une carte à votre nom légal, la machine est à votre nom légal dans absolument toutes les juridictions de la planète. Cela se règle à l'inscription, bien avant qu'on touche au menu déroulant des régions.
• Elle ne peut pas corriger vos logiciels. Une application vulnérable est compromise à Reykjavík exactement aussi vite qu'à New York, et un attaquant ne remplit aucun formulaire.
• Elle ne peut pas cacher le nom de domaine. Un registrar détient votre identité même derrière une confidentialité WHOIS, et chaque certificat que vous émettez publie le nom d'hôte exact dans des journaux de transparence publics que n'importe qui peut consulter.
• Elle ne peut pas protéger les données que vous envoyez ailleurs. Un outil d'analytics, le suivi d'erreurs, un CDN, un relais email, un prestataire de paiement — chacun expédie les données de vos utilisateurs dans sa propre juridiction, et l'emplacement de serveur le plus strict ne les y suit pas.
• Elle ne peut pas dissimuler vos propres connexions. Si vous administrez la machine depuis votre adresse personnelle en SSH non protégé, les métadonnées de connexion existent aux deux extrémités, quel que soit le drapeau planté sur le rack.
• Elle ne peut pas rendre légal un contenu illégal. Un contenu réellement illicite n'est le bienvenu sur aucun réseau sérieux, le nôtre compris, et aucune juridiction n'en constitue un permis.
• Elle ne peut pas compenser un opérateur qui garde tout. Un pays privacy-tier devant un hébergeur qui journalise chaque requête pendant un an vous donne une adresse au nom rassurant, et aucune confidentialité réelle.

Le motif de cette liste est que la juridiction n'est qu'une couche parmi plusieurs, et ni la première ni la plus efficace. Les couches qui font le plus gros du travail sont, dans l'ordre : ne pas rattacher d'identité à l'inscription, payer d'une façon qui ne peut pas remonter jusqu'à vous, garder la machine elle-même difficile à percer, et choisir son emplacement seulement ensuite. Si vous n'avez pas encore lu ce que signifie l'hébergement sans KYC et pourquoi Bitcoin est pseudonyme plutôt qu'anonyme, ces deux guides comptent plus que cette page — et recharger en Monero est ce qui referme la trace on-chain si cela compte pour vous.

Les erreurs qui rendent le choix pire qu'un tirage au sort

• Choisir uniquement à partir d'une liste d'alliances Eyes, ce qui optimise contre les services de renseignement tout en ignorant le droit de la conservation des données, la politique de l'opérateur et la trace de paiement, qui décident presque tous les résultats réels.
• Payer cent quatre-vingts millisecondes de latence pour toujours, pour une charge de travail dont personne n'allait jamais se plaindre.
• Supposer qu'offshore signifie irresponsable, puis découvrir que le régulateur local a des règles de contenu plus strictes que celles que vous cherchiez à éviter.
• Durcir magnifiquement l'hébergeur, puis enregistrer le domaine chez un registrar grand public à votre propre nom, ce qui rouvre toute la question en une seule étape.
• Confondre la réputation d'un pays avec sa loi actuelle — le paysage européen de la conservation des données en particulier a beaucoup changé, dans les deux sens, et la plupart des articles à ce sujet ont des années de retard.
• Placer une base de données loin de l'application qui l'interroge, si bien que chaque chargement de page paie l'aller-retour plusieurs fois de suite.
• Choisir une juridiction pour le serveur et laisser les sauvegardes chez un prestataire dans une juridiction complètement différente, ce qui fait discrètement du prestataire de sauvegarde le maillon le plus faible.
• Décider une fois pour toutes et ne jamais revenir sur ce choix, alors que les lois, les routes de câbles et vos propres schémas de trafic changent tous en quelques années.

Faites les parties ennuyeuses, et la carte devient une décision bien plus modeste qu'il n'y paraît. Inscrivez-vous sans identité, alimentez le solde en crypto, durcissez la machine dans les dix premières minutes, gardez votre accès administratif derrière un tunnel WireGuard, et gardez les sauvegardes quelque part que vous contrôlez. Choisissez ensuite la région pour la raison qui s'applique réellement à votre charge de travail — friction contre les plaintes, distance avec un système juridique précis, ou simple proximité avec vos utilisateurs — et acceptez en connaissance de cause l'échange que vous faites. Les 14 régions coûtent le même prix sur chaque offre de VPS, donc la seule monnaie que vous dépensez jamais ici, c'est la latence.