Hébergement web offshore : héberger un site à l'étranger étape par étape

En bref : l'hébergement web offshore consiste à faire tourner votre site sur un serveur situé hors du pays où vous vivez, généralement chez un fournisseur qui demande peu de données personnelles. Pour le mettre en place, louez un VPS à l'étranger, enregistrez le domaine avec la confidentialité WHOIS et payez en crypto, pointez le DNS vers le serveur, servez le site avec Caddy pour un HTTPS automatique, puis durcissez le serveur, sauvegardez-le et gardez l'identité du site séparée de la vôtre.

L'hébergement offshore change qui détient votre serveur et les données de votre compte. Il ne rend pas légal un contenu illégal, ne vous cache pas de votre registraire ni de votre trace de paiement, et ne corrige pas les erreurs opérationnelles. La dernière section détaille ces limites. Pour une vue d'ensemble, voir hébergement offshore.

Étape 1 : choisir un VPS offshore

Un VPS vous donne l'accès root complet : vous contrôlez le serveur web, les journaux et les clés TLS au lieu de dépendre d'un panneau d'hébergement mutualisé. Pour un site statique ou un petit CMS, 1–2 vCPU et 1–2 Go de RAM suffisent ; les bases de données et les applications plus lourdes demandent davantage.

Chez NoctisNode, les nouveaux serveurs sont déployés en FI-1 (Finlande). L'inscription ne demande qu'un e-mail et un mot de passe, le paiement se fait uniquement en crypto avec le XMR par défaut, et un serveur se déploie environ 35 secondes après le crédit du paiement. L'offre Wisp (1 vCPU, 1 Go de RAM, 20 Go NVMe, $6 pour 28 jours) convient à un site statique ; Pulse (2 vCPU, 2 Go, 40 Go, $10) convient à WordPress ou équivalent. Notez qu'il n'y a pas de réinitialisation du mot de passe par e-mail : conservez vos identifiants en lieu sûr. Comparez les options dans meilleur VPS offshore.

Étape 2 : enregistrer le domaine discrètement et payer en crypto

• ▹Choisissez un registraire qui accepte les cryptomonnaies et propose gratuitement la confidentialité ou le masquage WHOIS, afin que vos coordonnées ne soient pas publiées.
• ▹N'oubliez pas que le registraire conserve tout ce que vous lui fournissez. Utilisez une adresse e-mail dédiée au domaine, pas votre adresse personnelle.
• ▹Les registraires exigent généralement des coordonnées exactes selon leurs conditions ; des données fausses peuvent justifier une suspension : lisez les conditions avant de décider quoi soumettre.
• ▹Certains TLD nationaux imposent des règles de résidence ou n'autorisent pas la confidentialité. Vérifiez la politique du TLD avant d'acheter, plutôt que de présumer.
• ▹Activez la 2FA du compte chez le registraire et un verrou de transfert. Perdre le domaine est un risque plus grand que perdre le serveur.
• ▹Payez le VPS en Monero pour un minimum de liens on-chain ; voir [payer un VPS avec Monero](/guides/pay-for-vps-with-monero).

Étape 3 : pointer le DNS vers le serveur

Utilisez le DNS du registraire ou un fournisseur DNS distinct. Dans les deux cas, l'hébergeur DNS peut voir quels enregistrements existent et souvent les volumes de requêtes. Fixez un TTL bas (300 secondes) pendant la configuration pour que les changements se propagent vite.

Étape 4 : servir le site avec Caddy et le HTTPS automatique

Caddy obtient et renouvelle automatiquement les certificats TLS dès que le DNS pointe vers le serveur et que les ports 80 et 443 sont ouverts. Debian 12/13 et Ubuntu 24.04 fournissent un paquet `caddy` ; le dépôt apt de Caddy propose des versions plus récentes si besoin. Placez vos fichiers dans `/var/www/example`, remplacez `example.com` par votre domaine et rechargez. Pour faire du proxy vers une application plutôt que servir des fichiers statiques, voir reverse proxy Caddy.

sudo apt update && sudo apt install -y caddy
sudo mkdir -p /var/www/example

# /etc/caddy/Caddyfile
example.com {
    root * /var/www/example
    file_server
    encode zstd gzip
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer"
        -Server
    }
    log {
        output discard
    }
}

www.example.com {
    redir https://example.com{uri} permanent
}

sudo systemctl reload caddy

Étape 5 : durcir le serveur et mettre en place les sauvegardes

1. 01.Créez un utilisateur sudo non root, passez aux clés SSH et désactivez la connexion par mot de passe ; suivez le [durcissement SSH](/guides/ssh-hardening).
2. 02.Activez un pare-feu : `sudo ufw allow OpenSSH && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw enable`.
3. 03.Activez les mises à jour de sécurité automatiques : `sudo apt install -y unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades`.
4. 04.Ne conservez que les journaux nécessaires. Le Caddyfile ci-dessus supprime les journaux d'accès ; décidez délibérément plutôt que par défaut.
5. 05.Sauvegardez les fichiers du site et les bases de données hors du serveur avec des sauvegardes chiffrées, par exemple restic vers un second emplacement ; voir [sauvegardes restic](/guides/restic-backups).
6. 06.Testez une restauration au moins une fois. Le solde prépayé chez votre hébergeur compte aussi : s'il est épuisé, le serveur est suspendu ; gardez-le approvisionné.

Séparer le site web de votre identité

• ▹Utilisez un e-mail dédié pour le compte d'hébergement, le registraire et tous les services du site ; ne réutilisez jamais votre adresse ou votre nom d'utilisateur personnels.
• ▹Évitez les identifiants d'analytics, de publicité ou de tags tiers que vous utilisez aussi sur des sites personnels ; des identifiants partagés relient les sites entre eux.
• ▹Les journaux Certificate Transparency publient chaque nom d'hôte pour lequel vous obtenez un certificat : ne créez pas de sous-domaines qui en révèlent plus que voulu.
• ▹Supprimez les métadonnées des images et documents (EXIF, champs auteur) et vérifiez l'historique git à la recherche de vrais noms et e-mails avant de publier.
• ▹Administrez le serveur via Tor ou un VPN plutôt que depuis votre IP personnelle, et n'hébergez pas vos projets personnels sur la même IP.
• ▹Séparez aussi le paiement : alimentez le compte depuis un portefeuille non lié à un compte de plateforme d'échange à votre nom.

Ce contre quoi l'hébergement web offshore ne protège pas

• ▹Votre droit local : héberger un site à l'étranger ne change pas les règles qui s'appliquent là où vous vivez.
• ▹Les suspensions de domaine : le registraire ou l'opérateur du TLD peut suspendre un domaine quel que soit l'emplacement du serveur.
• ▹Le traitement des abus : les hébergeurs agissent toujours sur les signalements d'abus vérifiés, offshore ou non.
• ▹Les traces de paiement et de compte : plateformes d'échange, processeurs de cartes et fournisseurs d'e-mail conservent leurs propres enregistrements.
• ▹Vos propres erreurs : noms d'utilisateur réutilisés, identifiants d'analytics partagés, métadonnées et connexions d'administration depuis votre IP personnelle réduisent le reste à néant.
• ▹Les attaques contre le site : la localisation offshore n'est pas une protection DDoS, et un CMS non mis à jour se fait compromettre partout.

FAQ