Par l'équipe HushVPS · Mis à jour en 2026 · 7 min de lecture
Demandez à dix sociétés d'hébergement si elles conservent des logs et dix d'entre elles diront non. Cela ne vous dit presque rien. La question intéressante — celle qui détermine si « sans logs » vous protège ou décore simplement une page d'accueil — est ce que signifie sans logs pour un VPS en pratique : quelles données un serveur doit physiquement toucher pour fonctionner, lesquelles un fournisseur choisit d'écrire, et combien de temps tout cela survit sur le disque. Cet article démonte le slogan et le reconstruit comme une liste de contrôle que vous pouvez réellement vérifier.
« Sans logs » est une phrase marketing avant d'être technique. Elle semble absolue, et les absolus se vendent. Mais un serveur privé virtuel est un ordinateur dans un rack, et les ordinateurs ne fonctionnent pas à partir de rien. Chaque hébergeur, sans exception, traite certaines données au moment où il vous sert. Un fournisseur qui prétend conserver littéralement zéro tout en fournissant une machine fonctionnelle est soit imprécis dans son langage, soit espère que vous ne poserez pas la question de suivi. Le cadrage honnête n'est pas « nous ne touchons aucune donnée » — c'est impossible — mais « voici exactement ce que nous touchons, ce que nous éliminons, et ce que nous conservons. »
Avant d'aborder ce qu'un bon fournisseur évite, il est utile d'être lucide sur ce qu'aucun d'entre eux ne peut éviter. Ce sont les points de contact inévitables entre vous et la machine.
Pour qu'un paquet atteigne votre VPS, le réseau doit savoir où l'envoyer. Cela signifie que votre adresse IP et celle du serveur sont visibles par la couche de routage tant que la connexion est à jour. C'est ainsi que fonctionne IP ; ce n'est pas un choix politique. Le choix politique concerne ce qui se passe ensuite. Un hébergeur qui journalise écrit cette connexion dans un enregistrement durable et consultable — une ligne par session, conservée pendant des semaines. Un hébergeur sans logs laisse l'état de routage exister pendant les microsecondes nécessaires et ne le consigne jamais dans un fichier journal. Même physique, résultat opposé.
Pour vous remettre un serveur, l'hébergeur doit confirmer que vous avez payé, puis provisionner la machine en fonction d'un enregistrement de votre commande. Avec un processeur de carte, cet enregistrement est lourd : un nom, une adresse de facturation, un identifiant de transaction qui vous lie à l'achat pour toujours. Avec Monero, la confirmation est un paiement qui est effectué sans qu'un processeur écrive votre identité dans un registre — c'est pourquoi le modèle de paiement et le modèle de confidentialité sont liés, et non séparés. Dans les deux cas, un certain jeton de commande doit exister assez longtemps pour fournir et supporter le service. La question est de savoir s'il est lié à une identité réelle ou à rien de plus qu'une chaîne aléatoire.
Les hôtes gèrent également des signaux opérationnels transitoires : détection d'abus pour empêcher un seul locataire de faire tomber un nœud, diagnostics de crash lorsqu'un hyperviseur se comporte mal, métriques de capacité pour savoir quand ajouter du matériel. Ces données sont réelles et nécessaires. La distinction qui compte est de savoir si ces signaux sont limités à la santé de la plateforme et de courte durée, ou s'ils servent tranquillement de registre de surveillance de ce que fait chaque client.
Maintenant, l'autre côté de la médaille. Une grande partie de ce que les gens craignent dans les « logs » est entièrement évitable, et l'éviter est une décision de conception prise bien avant qu'une requête n'arrive :
Le modèle est la minimisation : collecter le moins à la porte, conserver le moins ensuite, et concevoir pour que les enregistrements sensibles ne voient simplement jamais le jour. Les données jamais collectées ne peuvent pas fuiter, ne peuvent pas être assignées et ne peuvent pas être vendues.
Voici le détail que la plupart des pages « sans logs » omettent. Pour chaque donnée qu'un hébergeur conserve, il y a une durée de vie — une fenêtre de conservation — après laquelle elle est supprimée. « Nous conservons votre jeton de commande » signifie quelque chose de complètement différent à 24 heures par rapport à 24 mois. Une politique sérieuse nomme la fenêtre pour chaque type de données. Un slogan vous donne un seul mot (« non ») et vous laisse deviner. Lorsque vous évaluez un fournisseur, regardez au-delà de l'affirmation principale et cherchez le calendrier de conservation. S'il n'existe pas, la promesse « sans logs » n'a pas de forme, et une promesse sans forme ne peut pas être vérifiée.
L'expression « zéro log » persiste parce qu'elle est facile à imprimer et difficile à réfuter d'un coup d'œil. Mais elle confond deux choses très différentes — les données traitées de manière transitoire et les données conservées durablement — en un seul absolu confiant. Les éducateurs en confidentialité le soulignent depuis des années : la valeur réside dans les détails, pas dans le superlatif. Des guides indépendants comme Privacy Guides orientent systématiquement les lecteurs vers des fournisseurs dont les affirmations sont documentées et vérifiables plutôt que vers ceux qui ont le slogan le plus audacieux, et la Electronic Frontier Foundation soutient depuis longtemps que la minimisation des données — et non des promesses maximales — est ce qui protège réellement les utilisateurs. Traitez toute bannière « nous ne journalisons rien, jamais » comme une invitation à lire les petites lignes, pas comme un substitut à celles-ci.
Une affirmation que vous ne pouvez pas vérifier n'est qu'une impression. Trois artefacts concrets transforment « faites-nous confiance » en « vérifiez-nous », et aucun d'eux ne nécessite de compte.
Une vraie politique indique, en langage clair, ce qui est collecté, ce qui est conservé et pendant combien de temps — et elle correspond à ce que dit la page marketing. Si le document de confidentialité est plus vague que la page d'accueil, croyez moins la page d'accueil. Notre propre politique de confidentialité est rédigée pour correspondre au tableau de conservation de la page produit, et non pour enterrer la réponse dans un jargon juridique.
Un canary signé qui se renouvelle selon un calendrier est un fil déclencheur passif : s'il cesse de se mettre à jour ou si sa formulation change discrètement, ce changement est en soi un signal. Il ne peut pas prouver une négative, mais un canary maintenu associé à une page de transparence montre que le fournisseur a pensé à la contrainte, pas seulement à la publicité.
Le test le plus convaincant est celui que vous effectuez. Commencez une commande, laissez le champ email vide, payez en Monero, et remarquez le moment où l'on ne vous a jamais demandé d'identité. Les données qui ne sont jamais demandées ne peuvent pas être journalisées — et vous pouvez le confirmer en observant ce que le paiement exige réellement, plutôt qu'en faisant confiance à un badge. C'est exactement la conception derrière notre VPS sans logs vérifiable : la liste de conservation est publiée, les champs sensibles sont absents par construction, et l'affirmation est destinée à être inspectée avant que vous dépensiez une cryptomonnaie.
Une dernière distinction à retenir. L'hébergement anonyme concerne la porte d'entrée — ne pas collecter d'identité lors de l'inscription. Sans logs concerne la chronologie — ne pas conserver d'enregistrement de votre activité pendant son déroulement. Ils se renforcent mutuellement mais ne sont pas synonymes. Un hébergeur peut être anonyme à l'inscription et journaliser votre trafic, ou collecter votre identité et ne conserver aucun journal d'activité. La posture de confidentialité la plus forte fait les deux à la fois : minimiser ce qui est demandé et minimiser ce qui est conservé. Lorsque vous lisez « sans logs », lisez-le comme une moitié de cette paire et vérifiez si l'autre moitié est également présente.
HushVPS publie un tableau de conservation en langage clair, ne conserve que ce qui est nécessaire au fonctionnement du service et vous offre trois moyens de vérifier. Sans KYC, facturation en Monero, accès root complet.