La meilleure pile de confidentialité auto-hébergée à cinq couches

En mars 2025, Krebs on Security a rapporté que des enquêteurs fédéraux américains avaient relié un vol de cryptomonnaie de 150 millions de dollars directement à la fuite de données LastPass de 2022. Le mécanisme était simple : certains clients stockaient des phrases de récupération dans les Notes sécurisées de LastPass, des attaquants ont obtenu des sauvegardes de coffres chiffrés, et des protections de coffre faibles ou anciennes ont permis de craquer certains contenus de coffres hors ligne.

La leçon n'est pas que LastPass était particulièrement négligent. La leçon, c'est que chaque fuite dont vous entendez parler, ce sont les données de quelqu'un d'autre monétisées pendant que l'e-mail d'excuses attend dans votre boîte de réception. L'auto-hébergement change qui peut faire cela à vos données. Il ne change pas le fait que quelqu'un le peut toujours.

Cet article s'adresse aux lecteurs dont le modèle de menace est l'exposition commerciale des données, c'est-à-dire la monétisation par les géants de la tech et les fuites de fournisseurs, et non la surveillance étatique, le journalisme à haut risque, l'activisme ou la divulgation judiciaire. L'architecture ci-dessous est une pile à cinq couches pour ce modèle de menace précis.

La version courte

Cette pile a cinq couches. Chaque couche retire une dépendance courante aux géants de la tech, mais aucune ne vous rend invisible.

• Réseau : WireGuard remplace un VPN commercial et limite la visibilité de votre FAI ou de votre réseau local.
• Identité : Vaultwarden remplace les gestionnaires de mots de passe hébergés et réduit l'exposition aux fuites côté fournisseur.
• Recherche : SearXNG réduit le profilage de recherche en relayant les recherches via votre VPS et en les gardant hors de votre compte de recherche connecté.
• Fichiers et photos : Nextcloud AIO et Immich remplacent Google Drive et Google Photos, coupant le scan de contenu cloud et la fusion de données entre produits.
• Communications d'équipe : Mattermost ou Rocket.Chat déplacent l'historique du chat d'équipe hors de Slack, Discord ou Teams.
• Limites principales : votre fournisseur de VPS peut toujours voir les métadonnées d'infrastructure, votre FAI peut toujours voir que vous vous connectez à votre serveur, et cette pile n'est pas conçue pour des adversaires étatiques.
• Note de juridiction : un hébergement dans l'UE renforce l'argument de la souveraineté des données, mais ce n'est pas un bouclier magique.

L'auto-hébergement déplace la confiance, il ne la supprime pas

Il existe un argument de longue date sur Hacker News, et il est correct sur le principe : « l'auto-hébergement sur un VPS ne résout pas la confidentialité, vous faites juste confiance à un autre fournisseur. » Quiconque conçoit une architecture de confidentialité devrait aborder cela directement plutôt que de le contourner. La réponse honnête, c'est que le déplacement de confiance est asymétrique. Il n'est pas équivalent.

Commencez par ce que l'auto-hébergement réduit. Le modèle économique de votre fournisseur SaaS n'est plus d'exploiter vos données, parce que le fournisseur a disparu. L'exposition aux fuites côté fournisseur change de forme : le coffre de Vaultwarden est chiffré côté client, mais des services lisibles par le serveur comme Nextcloud, Mattermost et Rocket.Chat ont toujours besoin d'un durcissement, de sauvegardes et d'un contrôle d'accès appropriés.

La leçon de LastPass n'était pas que le chiffrement des coffres n'a jamais existé. C'était que des sauvegardes de coffres chiffrés volées, des métadonnées non chiffrées, des réglages KDF anciens et des mots de passe maîtres faibles ont créé une voie de craquage hors ligne. Le profilage comportemental entre services se réduit aussi, parce qu'il y a moins de données inter-services qu'une seule entreprise puisse assembler. Le verrouillage par abonnement disparaît.

Maintenant, ce que l'auto-hébergement n'élimine pas. L'hyperviseur de votre fournisseur de VPS peut, en principe, lire la mémoire de votre VM. Votre fournisseur de VPS voit vos métadonnées au niveau de l'infrastructure : vers quelles IP vous vous connectez, quand, et combien de données circulent.

Votre FAI voit toujours que vous vous connectez à votre serveur. Les demandes légales juridictionnelles s'appliquent toujours au niveau du fournisseur de VPS, et une décision de justice reste une décision de justice. Un VPS, une application, une base de données ou un compte administrateur compromis peut toujours exposer des données.

C'est le calcul de la confiance qui compte. Un fournisseur de VPS a moins d'intérêt commercial à exploiter vos données que Google ou Meta, parce que le frais mensuel est le modèle économique, et vos données ne le sont pas. Un fournisseur de VPS a moins de données agrégées sur vous, à savoir votre seul serveur, et non votre historique de recherche, votre historique de localisation et votre boîte de réception réunis.

Dans l'UE, le fournisseur opère sous le RGPD et des conditions contractuelles spécifiques. Rien de tout cela ne rend un VPS plus sûr que Google dans toutes les dimensions. C'est un modèle de menace différent avec un profil d'exposition différent, et pour le modèle de menace que cet article traite, c'est une amélioration significative.

Il y a une distinction de plus qu'il vaut la peine de préciser. La confidentialité, c'est « ils ne savent pas ce que je fais ». L'anonymat, c'est « ils ne savent pas que c'est moi qui le fais ». L'auto-hébergement sur un VPS commercial améliore la confidentialité face aux fournisseurs SaaS et aux plateformes tierces.

Il ne vous donne pas l'anonymat face à votre fournisseur de VPS. Si vous avez besoin d'anonymat, vous utilisez Tor, pas un VPS, et le reste de cet article est le mauvais outil.

À retenir de cette section : un VPS déplace votre confiance d'un fournisseur SaaS dont le modèle économique est de monétiser vos données vers un fournisseur d'infrastructure dont le modèle économique est de vous vendre un serveur. Pour le modèle de menace de la plupart des lecteurs, c'est une amélioration significative, mais ce n'est pas l'invisibilité.

La pile à cinq couches en un coup d'œil

Cinq couches, déployées dans cet ordre : réseau, identité, recherche, fichiers, communications. Chacune répond à une menace distincte. Vous pouvez les déployer par étapes, et vous pouvez sauter les couches qui ne vous concernent pas. Le modèle est plus utile qu'une liste d'applications parce qu'il évolue avec vos préoccupations plutôt qu'avec le nombre de services tournant sur votre serveur.

À retenir de cette section : Commencez par WireGuard, Vaultwarden et SearXNG si vous voulez la pile de confidentialité la plus légère. N'ajoutez Nextcloud, Immich et le chat d'équipe qu'une fois prêt à une utilisation de RAM plus élevée, à la planification du stockage, aux sauvegardes et à plus de travail d'administration.

Couche 1 : la couche réseau (WireGuard)

Le fichier de configuration de WireGuard pour une installation mono-utilisateur typique fait douze lignes. Sa poignée de main se complète en un seul aller-retour et utilise le cadre du protocole Noise. Le module noyau est dans Linux mainline depuis la 5.6, ce qui signifie que le protocole que vous déployez en 2026 est le même qui est audité et stable depuis des années. C'est le bon choix par défaut.

Ce que cette couche traite : les observateurs du FAI et du réseau local qui verraient sinon chaque domaine auquel vous vous connectez, les attaquants en Wi-Fi public, et votre IP domestique exposée à chaque service que vous visitez. Votre trafic sort de votre VPS au lieu de sortir de votre appartement.

Ce qu'elle ne traite pas : la vue de votre fournisseur de VPS sur votre trafic sortant. Il voit à quoi votre point de sortie VPN se connecte, quand, et combien. WireGuard cache le trafic à votre FAI. Il ne cache pas le trafic au serveur qui opère la sortie.

Les fuites DNS sont aussi un problème distinct et ne sont pas gérées automatiquement ; vous devez pointer vos clients VPN vers un résolveur en qui vous avez confiance. Faites tourner Unbound sur le même VPS, ou utilisez un amont de confiance via DoT ou DoH. Le blocage publicitaire complet au niveau DNS avec Pi-hole est un sujet à part et n'est pas la bonne chose à combiner avec une sortie VPN pour la plupart des utilisateurs (plus de détails ci-dessous).

WireGuard face aux alternatives, brièvement. OpenVPN fonctionne toujours. La poignée de main est plus grande, l'empreinte de métadonnées est plus large, et le débit est plus faible. Il n'y a aucune raison de le choisir pour un nouveau déploiement à moins d'avoir spécifiquement besoin d'une fonctionnalité que WireGuard n'offre pas.

Tailscale est un outil différent : c'est un maillage zéro-config bâti sur WireGuard et excellent pour assembler vos propres services auto-hébergés entre machines. Ce n'est pas ce que vous voulez comme sortie de confidentialité vers internet, parce que le plan de coordination est hébergé par Tailscale.

Note : changer le port par défaut 51820/UDP peut réduire les scans à faible effort, mais cela ne fait pas ressembler WireGuard à du trafic HTTPS ordinaire ni ne contourne un filtrage sérieux. Considérez-le comme une réduction des scans, pas comme de la furtivité.

Pour le déploiement, nous avons un guide de configuration de WireGuard pour Ubuntu pas à pas qui s'accorde avec cette architecture.

À retenir de cette section : WireGuard sur votre VPS vous donne une sortie de réseau privé que votre FAI ne peut pas inspecter, mais il ne cache pas votre trafic au fournisseur de VPS qui opère la sortie.

Couche 2 : la couche identité (Vaultwarden)

Vaultwarden tourne avec moins de 200 Mo de RAM. C'est une réimplémentation en Rust de l'API Bitwarden, compatible avec tous les clients Bitwarden officiels (extensions de navigateur, applications de bureau, applications mobiles), et il ne nécessite pas l'image de référence lourde du serveur Bitwarden. Pour un seul utilisateur ou un foyer, c'est la bonne taille.

Ce que cette couche traite : les fuites de mots de passe côté fournisseur, comme l'échec de style LastPass, où des contenus de coffres ont fuité et ont fini par être déchiffrés hors ligne. La réutilisation d'identifiants entre services devient mécaniquement plus difficile une fois que vous avez un gestionnaire de mots de passe que vous utilisez vraiment. L'agrégation du profil d'identité entre services diminue, parce qu'aucun tiers ne voit la liste.

Ce qu'elle ne traite pas : votre propre OpSec. Un mot de passe maître faible, l'absence de 2FA sur le coffre, ou une attaque d'hameçonnage réussie sur vous met cette couche entièrement en échec. Un appareil compromis avec une extension de navigateur connectée la met en échec plus entièrement encore. Vaultwarden est un coffre, pas un substitut aux bases.

Il y a un avertissement opérationnel qui compte plus que tout autre dans cette pile. Auto-héberger votre gestionnaire de mots de passe signifie que vous êtes responsable des sauvegardes. Un VPS qui défaille au mauvais moment, ou un serveur que vous effacez par accident, vous verrouille hors de chaque compte que cette couche protège.

XDA Developers a aussi couvert ce risque directement, avertissant qu'un gestionnaire de mots de passe auto-hébergé peut vous verrouiller hors de comptes importants si l'accès, les sauvegardes ou la planification de la récupération échouent.

Avertissement : faites tourner des sauvegardes chiffrées automatisées du répertoire de données de Vaultwarden. Conservez un export chiffré hors ligne, stockez les codes de récupération séparément, et testez la restauration sur un appareil de rechange ou un conteneur temporaire. Ne comptez pas sur une seule sauvegarde de VPS. Ce n'est pas optionnel. C'est le prix de sortir le coffre de l'infrastructure du fournisseur.

Si vous centralisez l'authentification unique sur plusieurs services auto-hébergés plus tard, Authentik est le fournisseur d'identité open source vers lequel la plupart des gens finissent par se tourner. C'est une couche avancée et hors du périmètre de la pile principale.

Pour le déploiement, notre guide d'auto-hébergement de Vaultwarden est le compagnon de déploiement. Pour un regard plus approfondi sur le paysage des gestionnaires de mots de passe, voyez notre guide des meilleurs gestionnaires de mots de passe auto-hébergés.

À retenir de cette section : Vaultwarden sort votre coffre de mots de passe de l'infrastructure de fournisseurs sujette aux fuites, mais il vous met sur le dos la charge de la sauvegarde et de la récupération, et cette charge est réelle.

Couche 3 : la couche recherche et navigation (SearXNG)

Une instance SearXNG reçoit votre requête, la diffuse vers les moteurs amont (Google, Bing, DuckDuckGo, d'autres que vous activez), retire certains paramètres identifiants, et renvoie une page de résultats unifiée.

Vos requêtes atteignent Google, mais elles l'atteignent en tant que requêtes depuis votre VPS, et non depuis votre compte de recherche connecté. Une instance mono-utilisateur ne crée pas un grand pool d'anonymat, donc les moteurs amont peuvent toujours associer des schémas de requêtes à cette IP de VPS.

Ce que cette couche traite : le profilage des requêtes de recherche, le ciblage publicitaire comportemental indexé sur votre historique de recherche connecté, et la longue mémoire d'un compte de recherche. Le problème du « pourquoi est-ce que je vois des pubs pour la chose que j'ai cherchée hier » est réduit au niveau du compte de recherche.

Ce qu'elle ne traite pas : le pistage par les sites sur lesquels vous cliquez réellement. Les cookies, l'empreinte numérique et les traceurs sur les pages tierces sont un problème côté navigateur, pas côté recherche. Utilisez une configuration de navigateur durcie pour traiter cela.

SearXNG ne vous anonymise pas non plus face au moteur de recherche amont si votre VPS ne lui envoie que vos requêtes ; le trafic agrégé d'une instance fréquentée cache les utilisateurs individuels dans le bruit, mais une instance mono-utilisateur peut toujours ressembler au schéma de recherche d'un seul utilisateur.

Whoogle Search est l'alternative plus légère. C'est une façade pour Google, plus simple, et qui fait une seule chose. SearXNG agrège plusieurs moteurs, ce qui est plus utile si votre raison de quitter Google n'était pas spécifiquement Google. Choisissez en fonction du nombre de sources que vous voulez réellement.

Une note opérationnelle pour les instances mono-utilisateur. SearXNG transfère les requêtes aux moteurs amont, et Google peut limiter le débit des schémas de trafic suspects. Un seul utilisateur atteint rarement cette limite. Une petite instance publique le pourrait. Si les requêtes commencent à échouer, réduisez le nombre de moteurs amont, ajustez les réglages du limiteur de SearXNG, ou appuyez-vous davantage sur des moteurs amont moins hostiles.

À retenir de cette section : SearXNG relaie vos recherches via votre VPS et les garde hors de votre compte de recherche connecté. Il réduit le profilage de recherche direct, mais une instance mono-utilisateur privée ne crée pas un grand pool d'anonymat.

Couche 4 : la couche fichiers et photos (Nextcloud AIO + Immich)

Nextcloud AIO est le déploiement Docker tout-en-un de Nextcloud et la voie de moindre résistance vers un serveur fonctionnel de synchronisation de fichiers, de calendrier, de contacts et de collaboration documentaire.

Immich est son pendant pour les photos : vue chronologique, envoi automatique mobile depuis iOS et Android, reconnaissance faciale façon Google Photos traitée sur votre propre serveur ou l'hôte ML choisi, et un consensus communautaire honnête selon lequel c'est le remplaçant de Google Photos le plus utilisable actuellement disponible.

Ce ne sont pas des applications légères. Nextcloud AIO devrait être traité comme une base de 4 Go / 2 vCPU ; le machine learning d'Immich, la génération de vignettes et le premier scan de bibliothèque utiliseront ce que vous leur donnez.

Ce que cette couche traite : le scan par le fournisseur de stockage cloud, la reconnaissance de contenu photo, et le traitement côté cloud qui gardent une bibliothèque personnelle sensible à l'intérieur d'un compte de fournisseur, ainsi que la centralisation des données au niveau du compte qui garde fichiers, photos, recherche, historique de localisation et signaux d'identité sous un même compte d'entreprise.

Remplacer cela par un serveur que vous contrôlez casse cette centralisation.

Ce qu'elle ne traite pas : les octets vivent toujours sur un volume de stockage que votre fournisseur de VPS opère. Le chiffrement au repos est votre responsabilité, pas la sienne par défaut. La compromission côté appareil est un problème distinct ; si votre téléphone est rooté, le client Nextcloud dessus est exposé peu importe où vit le serveur.

Si votre seul besoin est de « garder ces dossiers synchronisés entre mes appareils », Syncthing est l'outil plus simple. Il est pair-à-pair, n'a pas de serveur au milieu, et fait bien cette seule tâche. Ce n'est pas un remplaçant des fonctionnalités de calendrier, de contacts et de collaboration que Nextcloud fournit ; c'est un remplaçant du sous-ensemble de synchronisation de fichiers.

Pour Immich spécifiquement, une règle de dimensionnement pratique compte. Nextcloud AIO devrait être traité comme une base de 4 Go / 2 vCPU. Immich n'est pas un léger module photo annexe une fois que le machine learning, les vignettes et un premier scan de bibliothèque entrent en jeu. Prévoyez environ 6 à 8 Go de RAM pour les configurations à forte composante Immich, surtout pendant la migration.

Pour le déploiement, nous avons un comparatif Nextcloud vs ownCloud pour les utilisateurs qui hésitent encore entre les deux, et un aperçu plus large des plateformes cloud auto-hébergées avec interface web si vous explorez le domaine.

À retenir de cette section : Nextcloud et Immich peuvent sortir fichiers et photos des comptes cloud façon Google, mais ils sont la première couche de cette pile à nécessiter sérieusement de la RAM, du stockage, une planification des sauvegardes et de la patience pour la migration.

Couche 5 : la couche communications (Mattermost ou Rocket.Chat)

Les espaces de travail Slack sont cherchables par Slack. Discord scanne le contenu pour des violations des conditions d'utilisation. Microsoft Teams conserve les enregistrements de chat selon les politiques de votre tenant, qui sont des politiques que votre service informatique peut voir.

Pour un chat d'équipe ou de famille qui ne devrait vivre dans aucun de ces endroits, un Mattermost ou Rocket.Chat auto-hébergé est la réponse standard. Cette couche consiste à garder les archives d'équipe hors du SaaS, pas à avoir un chat privé de bout en bout.

Ce que cette couche traite : l'archivage de messages côté fournisseur, le scan de contenu côté fournisseur, et la perte d'accès qui survient quand le fournisseur décide que votre compte est un problème. L'historique de messages de votre équipe réside sur votre serveur.

Ce qu'elle ne traite pas, et cela compte : le chiffrement de bout en bout. Mattermost et Rocket.Chat ne sont pas E2EE par défaut. L'administrateur du serveur peut lire les messages. L'administrateur du serveur, c'est désormais vous, ce qui est mieux que ce soit les employés d'un fournisseur SaaS, mais le principe compte toujours pour le modèle de menace de votre équipe.

Pour la messagerie sécurisée en tête-à-tête, Signal est la bonne réponse, pas un serveur auto-hébergé. Si la couche de communication doit être E2EE par défaut, regardez Matrix/Element ou utilisez Signal pour les chats personnels. L'auto-hébergement résout la messagerie d'équipe sans fournisseur ; il ne remplace pas Signal pour les modèles de menace personnels.

Mattermost face à Rocket.Chat. Les deux sont valables. Mattermost est plus resserré, plus profilé entreprise, et a moins de fonctionnalités optionnelles activées par défaut. Rocket.Chat est plus large, intègre plus de types de canaux, et a un écosystème de plugins plus grand. L'un ou l'autre convient pour le cas d'usage typique d'une pile de confidentialité : le chat d'une petite équipe ou d'une famille.

Réserve 2026 : vérifiez l'édition gratuite exacte avant de déployer Mattermost. Mattermost Entry a un plafond d'historique de 10 000 messages, tandis que Team Edition évite ce plafond mais a ses propres limites. Pour Rocket.Chat, prévoyez plus qu'un minuscule VPS de 1 Go parce que MongoDB, les envois et les intégrations ajoutent de la surcharge.

À retenir de cette section : Un Mattermost ou Rocket.Chat auto-hébergé sort l'archive de chat de votre équipe d'un fournisseur SaaS, mais si vous avez besoin d'un vrai chiffrement de bout en bout entre deux personnes, Signal reste le bon outil.

Ce qu'il NE faut PAS auto-héberger (et pourquoi)

Certaines choses qui semblent avoir leur place dans une pile de confidentialité n'en ont pas. Les lister fait partie de la construction d'une pile digne de confiance.

L'e-mail. N'auto-hébergez pas l'e-mail si vous n'êtes pas déjà un opérateur Linux expérimenté qui le veut spécifiquement. PrivacyGuides a une position claire et bien connue là-dessus, et c'est la bonne : seuls les utilisateurs avancés devraient faire tourner leur propre serveur de messagerie. Les raisons ne sont pas de la curiosité technique. SPF, DKIM et DMARC doivent être configurés et maintenus corrects.

La réputation d'IP doit être gagnée et entretenue. Le filtrage du spam est un état de fait permanent. Le combat de la délivrabilité avec Gmail n'est pas une étape de configuration ; c'est une condition continue. Pour tous les autres, un fournisseur géré respectueux de la confidentialité est vraiment la bonne réponse pour cette couche.

Proton Mail, Tuta (anciennement Tutanota) et Mailbox.org sont tous de bons choix. C'est une règle stricte de cet article : n'auto-hébergez pas l'e-mail pour une confidentialité grand public.

Pi-hole comme résolveur DNS principal de votre réseau domestique, sur un VPS. Pi-hole est formidable. Le mettre sur un VPS comme résolveur récursif pour tout l'internet de votre foyer est un point de défaillance unique qui casse l'internet pour tout le monde dans la maison quand le VPS a un hoquet. Pi-hole a sa place sur un Raspberry Pi à la maison. Il ne fait pas partie de cette pile.

Les réseaux sociaux fédérés. Mastodon, Pleroma et les autres sont intéressants et connexes. L'adoption est la principale contrainte, pas la confidentialité. Ils sont la bonne réponse pour certaines personnes, mais ne sont pas au cœur d'une pile de confidentialité axée sur sortir vos propres données des serveurs des géants de la tech.

Les outils d'anonymat. Tor, I2P, mixnets. Modèle de menace différent, article différent. Si vous en avez besoin, vous le savez déjà.

En résumé : Proton Mail ou un équivalent est une alternative gérée pour une couche spécifique, et le reconnaître fait partie d'une pile digne d'usage. L'auto-hébergement aide là où ces fournisseurs ne couvrent pas l'ensemble du flux de travail : photos, recherche, analytique personnalisée et chat d'équipe. Pour une confidentialité grand public, l'e-mail est la seule couche que cette pile devrait externaliser.

À retenir de cette section : La plupart des utilisateurs ne devraient pas auto-héberger l'e-mail. Un fournisseur géré respectueux de la confidentialité comme Proton Mail est vraiment la meilleure réponse pour cette seule couche, et le reconnaître fait partie de la construction d'une pile digne de confiance.

Où le faire tourner : dimensionnement du VPS et juridiction

La question du dimensionnement n'est pas abstraite. Cette pile a trois formes pratiques : le cœur léger de confidentialité, la couche fichiers, et la version riche en photos qui amène le machine learning d'Immich dans le mélange. Le saut de l'une à la suivante n'est pas cosmétique. Les fichiers, les vignettes, la reconnaissance faciale et la migration de la première bibliothèque sont ce qui transforme un petit VPS en un vrai budget de serveur.

Lisez le tableau ainsi :

• La pile minimale couvre les trois couches au plus fort rendement : réseau, identité et recherche.
• Base Nextcloud a besoin de plus de marge parce que PHP, le travail de base de données, l'indexation des fichiers, les tâches de synchronisation et l'interface web tournent tous ensemble.
• Pile fichiers et photos a besoin d'un budget plus grand parce que le machine learning d'Immich, les vignettes, la reconnaissance faciale et le premier scan de la photothèque peuvent solliciter le serveur durement pendant la migration.
• Le stockage compte parce que le calcul n'est que la moitié du plan. Les fichiers et les photos ont besoin de place pour grandir, de sauvegardes éloignées du VPS, et d'une voie de récupération qui fonctionne encore si le serveur a disparu.

Puis il y a la juridiction. En juin 2025, Microsoft a témoigné devant le Parlement français qu'elle ne pouvait pas garantir que les données hébergées dans l'UE seraient protégées de l'accès légal américain. Ce témoignage a sorti l'argument de la souveraineté des données de la théorie pour l'amener dans la conversation politique grand public.

Pour les utilisateurs qui priorisent la souveraineté des données, la juridiction de l'entreprise, l'emplacement du datacenter, les contrats, le modèle de chiffrement et l'emplacement des sauvegardes comptent tous.

If Le CLOUD Act fait partie de la préoccupation, ne traitez pas un datacenter dans l'UE seul comme toute la réponse. Un fournisseur dont le siège n'est pas aux États-Unis avec une région européenne est un choix plus propre qu'une région UE d'un hyperscaler dont le siège est aux États-Unis, mais cela ne rend toujours pas les données légalement intouchables.

La réserve : la juridiction est de la friction, pas de l'invulnérabilité. Une décision d'un tribunal allemand reste une décision de justice. Une décision néerlandaise aussi. Une demande légale suisse également. L'hébergement européen peut réduire une partie de l'exposition directe aux fournisseurs cloud dont le siège est aux États-Unis et ajouter un processus légal local, mais il ne rend pas les données légalement intouchables.

Pour le modèle de menace de la plupart des lecteurs, la friction ajoutée est utile. Ce n'est pas un bouclier magique.

À retenir de cette section : La pile légère peut tourner sur un petit VPS, mais les fichiers et les photos changent le budget. Utilisez 4 Go / 2 vCPU comme base Nextcloud seul, et prévoyez plutôt 8 Go / 4 vCPU pour une configuration Immich riche en photos. Cloudzy Marketplace réduit l'effort de configuration pour les applications principales, tandis que la juridiction ajoute de la friction légale, pas de l'invisibilité.

Comment déployer la pile sans transformer la configuration en projet

Vous pouvez construire chaque couche manuellement. C'est bien si le travail de configuration fait partie de l'attrait. Pour la plupart des lecteurs, ce n'est pas le cas. Le but de cette pile est de s'éloigner de la gravité des données des géants de la tech, pas de passer une semaine à déboguer Docker, des ports, le DNS et des fichiers de service avant même que la première application tourne.

La voie à moindre friction est de partir d'une image de VPS fonctionnelle et de durcir à partir de là. Cloudzy Marketplace inclut des images de VPS en un clic pour WireGuard, Vaultwarden, SearXNG, Nextcloud AIO et d'autres outils auto-hébergés, donc le déploiement de base n'est pas la partie qui mange le week-end.

Le travail qui compte encore est celui qu'aucun marketplace ne peut faire à votre place : DNS, règles de pare-feu, sauvegardes, contrôles d'accès, mises à jour et tests de récupération.

Le serveur en dessous compte toujours aussi. Cette pile, c'est du stockage, du réseau, du choix de région et de la marge, pas seulement des noms d'applications dans un tableau. Cloudzy vous donne une infrastructure de VPS adossée à du NVMe, un accès root complet, 13 régions, un réseau à 40 Gbps, une disponibilité de 99,95 % et une garantie satisfait ou remboursé de 14 jours.

Commencez petit pour WireGuard, Vaultwarden et SearXNG. Montez en gamme pour Nextcloud. Planifiez plus sérieusement pour Immich une fois que le machine learning, les vignettes et la migration de photos entrent en jeu.

Comment commencer

Cinq couches, chacune répondant à une menace spécifique. Aucune ne prétend vous rendre invisible. Toutes réduisent une exposition commerciale des données précise que vous acceptez actuellement par défaut.

Choisissez la seule couche qui répond à votre douleur actuelle la plus concrète. Si vous avez déjà ouvert un e-mail de notification de fuite, c'est la couche identité. Si vous avez remarqué des pubs vous suivant sur des sites que vous n'avez jamais visités, c'est la couche recherche. Déployez celle-là. L'architecture évolue. La décision de commencer, elle, n'a pas à le faire.

La configuration d'une seule couche prend un week-end au maximum. Les fichiers de configuration sont courts. Il n'y a aucune raison que ce soit plus compliqué que cela.

Foire aux questions

L'auto-hébergement sur un VPS protège-t-il vraiment ma confidentialité, ou est-ce que je fais juste confiance à un autre fournisseur ?

Oui, pour ce modèle de menace. Il déplace la confiance de fournisseurs SaaS qui monétisent les données des utilisateurs vers un fournisseur de VPS qui vend de l'infrastructure. Cela réduit l'exposition commerciale et le profilage inter-services, mais cela ne cache pas les métadonnées du VPS, les enregistrements de connexion du FAI, les appareils compromis, ni la surveillance étatique.

Quelle est la pile de confidentialité auto-hébergée minimale par laquelle je devrais commencer ?

Commencez par WireGuard, Vaultwarden et SearXNG. Ceux-ci couvrent la visibilité réseau, le risque de fuite côté fournisseur de mots de passe, et le profilage de recherche connecté sur un VPS de 2 Go de RAM. Ajoutez Nextcloud plus tard ; n'ajoutez Immich qu'après avoir plus de RAM, de stockage et de discipline de sauvegarde.

Héberger à Francfort ou Amsterdam est-il vraiment meilleur pour la confidentialité que les États-Unis ?

Les régions européennes peuvent réduire une partie de l'exposition directe aux fournisseurs dont le siège est aux États-Unis, mais elles ne rendent pas les données légalement intouchables. La juridiction de l'entreprise, l'emplacement du datacenter, les contrats, le chiffrement et l'emplacement des sauvegardes comptent tous. Des demandes légales allemandes, néerlandaises ou suisses peuvent toujours s'appliquer.

Devrais-je auto-héberger mon e-mail pour la confidentialité ?

Pour presque tout le monde, non. L'auto-hébergement de l'e-mail exige SPF, DKIM, DMARC, la réputation d'IP, le filtrage du spam et un travail de délivrabilité constant. Utilisez un fournisseur géré respectueux de la confidentialité comme Proton Mail, Tuta ou Mailbox.org. PrivacyGuides ne recommande l'e-mail auto-hébergé que pour les utilisateurs avancés.

De quoi WireGuard me protège-t-il réellement ?

WireGuard achemine le trafic via votre VPS, limitant ce que votre FAI et votre réseau local peuvent voir. Il ne cache pas le trafic sortant au fournisseur de VPS. Il peut toujours voir les métadonnées de connexion, les IP de destination, le timing et le volume. C'est de la confidentialité face à votre FAI, pas de l'invisibilité.