Quel VPN utilise des serveurs uniquement en RAM ? J’ai découvert que « RAM-only » protège surtout ce qui ne doit pas survivre au serveur

Je ne cherchais pas un nouveau VPN lorsque j’ai commencé cette comparaison.

Je lisais l’avis publié par la CNIL après le piratage du système d’information de la Direction générale des Finances publiques.

L’incident annoncé en août 2026 avait permis à un tiers de consulter et d’extraire certaines informations concernant des particuliers et des professionnels, notamment des données fiscales et cadastrales.

Un VPN n’aurait évidemment pas empêché cette intrusion.
Ce n’était ni le même système ni le même problème.

Mais l’événement m’a fait poser une question beaucoup plus personnelle à propos des services auxquels je confie des données :

si une machine est compromise, copiée ou saisie physiquement, qu’est-ce qu’il reste dessus ?

Quelques minutes plus tard, je recherchais deux mots :
RAM-only.

Je pensais avoir trouvé le critère de confidentialité le plus facile à comparer de tout le marché VPN.

Puis j’ai compris qu’il répondait très bien à une question précise — et beaucoup moins bien à toutes les autres.

La réponse littérale est assez claire

Si la question est simplement « quels VPN documentent une infrastructure fonctionnant uniquement en mémoire vive ? », plusieurs grands fournisseurs ont une réponse solide.

ExpressVPN utilise son architecture TrustedServer. Le fournisseur explique que ses serveurs VPN fonctionnent en mémoire volatile plutôt que de s’appuyer sur un disque persistant, de sorte que leur contenu disparaît au redémarrage.

Surfshark présente lui aussi son réseau comme composé à 100 % de serveurs RAM-only.

Mullvad a suivi la même direction et a annoncé avoir achevé la migration de son infrastructure VPN vers des serveurs sans disque fonctionnant en RAM.

Sur ma feuille de comparaison, ces trois noms ont donc obtenu une coche.
C’était exactement ce que je cherchais.
Ou plutôt, exactement ce que je croyais chercher.
J’ai commencé à traiter le reste comme secondaire.

Nombre de pays.
Interface.
Type de compte.
Tout cela pouvait attendre.

Le serveur fonctionnait uniquement en RAM : très bien, pensais-je, j’avais trouvé le critère décisif.

Le problème est apparu lorsque j’ai essayé d’expliquer précisément ce que cette coche garantissait.

Une machine RAM-only oublie ce qu’elle contenait lorsqu’on l’éteint

Le principe est assez simple.
Un disque ressemble à un carnet.
Vous pouvez éteindre l’ordinateur, le rallumer plus tard et retrouver ce qui a été écrit.
La RAM ressemble davantage à un tableau blanc qui dépend de l’électricité.

Coupez l’alimentation, et ce qui s’y trouvait disparaît.
Pour un serveur VPN, cette différence est importante.

Une architecture sans stockage persistant évite qu’un ensemble de fichiers, de journaux ou de résidus reste simplement sur le disque pendant des mois. Elle change aussi fortement ce qu’on peut espérer récupérer d’un serveur que l’on débranche puis que l’on examine après coup.

C’est une vraie amélioration d’architecture.
Mais j’avais mentalement ajouté une promesse que la RAM, elle, ne fait pas.
J’étais passé de :
« ce qui est uniquement en RAM disparaît à l’arrêt »

à :
« ce VPN ne peut pratiquement rien conserver sur moi ».
Ce n’est pas la même chose.

Le serveur n’a pas besoin d’être éteint pour que ses données intéressent quelqu’un

C’est la documentation de Mullvad qui m’a fourni la distinction la plus utile.

Le fournisseur explique qu’une infrastructure fonctionnant en RAM n’empêche pas, par elle-même, la journalisation de données. Elle réduit surtout le risque qu’une information reste accidentellement stockée sur la machine et puisse être récupérée plus tard.

Cette phrase a fait perdre beaucoup de valeur à ma simple colonne « RAM-only : oui/non ».
Un serveur en fonctionnement n’a évidemment pas une mémoire vide.

Il doit traiter les paquets, maintenir l’état nécessaire au tunnel et exécuter son logiciel.

La RAM protège surtout contre la persistance après coup.

Un utilisateur de r/DigitalPrivacy posait d’ailleurs presque exactement cette question en juillet 2026 : si un VPN fonctionne uniquement en RAM, qu’est-ce qui empêche des données présentes pendant l’exécution d’être consultées ou envoyées ailleurs ?

C’était le morceau qui manquait à mon raisonnement.
Je m’étais concentré sur ce qu’on pourrait trouver dans une machine morte.
J’avais oublié de me demander ce qu’un service possède pendant qu’elle est vivante.

J’ai donc arrêté de regarder seulement ce qui survit au redémarrage

Cette distinction m’a ramené à l’incident qui avait déclenché toute ma recherche.

Ce qui m’avait dérangé dans la violation de données de la DGFiP n’était pas seulement l’idée qu’un vieux disque puisse être récupéré.

C’était surtout qu’un ensemble d’informations utiles existait quelque part et avait pu être extrait.

Encore une fois, un serveur VPN et un système fiscal n’ont rien de comparable techniquement.

Mais le principe de réduction du risque est le même : ce qui n’a jamais été collecté ne peut pas être volé plus tard.

La CNIL formule d’ailleurs cette logique très simplement dans ses recommandations de sécurité : limiter les données à ce qui est réellement nécessaire réduit aussi les conséquences d’une intrusion.

À ce moment-là, mon critère a changé.
Je continuais à apprécier RAM-only.

Mais je ne voulais plus seulement savoir comment un VPN faisait disparaître une information.

Je voulais regarder une étape plus tôt :
pourquoi cette information avait-elle besoin d’exister ?

Mon premier candidat RAM-only restait excellent — mais il répondait à une autre partie du problème

ExpressVPN restait très convaincant sur le critère qui m’avait amené ici.
TrustedServer est documenté publiquement.
L’architecture RAM-only est au cœur de son infrastructure.

Le service possède aussi davantage d’ancienneté, de localisations et d’évaluations externes qu’une petite application récente.

Si mon exigence était uniquement :

« je veux un fournisseur dont l’infrastructure VPN est publiquement documentée comme RAM-only »,

la réponse serait parfaitement défendable.

Mais en regardant le parcours complet d’utilisation, j’ai remarqué une couche que ma feuille de comparaison ne prenait pas en compte.

Adresse e-mail.
Compte.
Informations nécessaires à la gestion de l’abonnement.
Rien d’anormal là-dedans pour un service commercial.

Mais ces données ne disparaissent pas simplement parce que le serveur VPN auquel je me connecte redémarre.

Je pouvais donc avoir un relais qui oublie son état au redémarrage tout en conservant ailleurs une identité de compte parfaitement durable.

Une fois formulé ainsi, RAM-only a cessé d’être une note globale de confidentialité.
C’est devenu ce que cette architecture est réellement :
une excellente protection pour une couche précise.

Avec le deuxième VPN, mon test a commencé avant même le serveur

J’ai alors ouvert OnlydogVPN.

Je ne le classerais pas parmi les fournisseurs dont toute l’infrastructure est publiquement documentée comme RAM-only : je n’ai pas trouvé de preuve équivalente permettant de l’affirmer.

Mais ce qui m’a intéressé s’est produit avant que cette question devienne centrale.

Pour l’usage de base testé, je pouvais commencer sans passer par le parcours conventionnel d’un nouveau compte avec adresse e-mail et mot de passe.

J’ai ouvert l’application.
Pas de nouvelle adresse à saisir.
Pas de mot de passe supplémentaire à créer.
J’ai lancé la connexion.

Puis j’ai vérifié mon adresse IP publique.
Elle avait changé.
J’ai ouvert les pages personnelles que je voulais consulter et repris ma navigation.
Le tunnel faisait son travail.

Mais cette fois, ce qui me plaisait n’était pas seulement ce que le serveur pourrait oublier plus tard.

C’était ce que je n’avais pas eu besoin de donner avant même de me connecter.
Je n’avais pas ajouté une nouvelle identité de compte à l’équation.

Après une heure passée à réfléchir à ce qu’une machine pourrait conserver, cette absence est devenue beaucoup plus concrète que je ne l’aurais imaginé au début.

Je cherchais une technologie d’effacement ; j’ai commencé à apprécier l’absence de donnée

RAM-only intervient après qu’une information a eu besoin d’exister dans la mémoire du serveur.

La minimisation intervient plus tôt.

C’est la différence entre écrire une information sur un tableau qu’on effacera proprement à la fin de la journée et décider qu’elle n’avait aucune raison d’être écrite au départ.

Les deux approches sont utiles.
Elles ne protègent simplement pas le même endroit.

Un fournisseur peut d’ailleurs combiner une infrastructure RAM-only, une politique no-log sérieuse, des audits et une collecte de compte limitée. Mullvad est intéressant précisément parce qu’il travaille sur plusieurs de ces dimensions au lieu de présenter la RAM comme une garantie magique.

Mais cette réalisation a changé la façon dont je regardais le petit service.
Je ne pouvais pas lui donner la coche « infrastructure entièrement RAM-only documentée ».

Je pouvais en revanche constater directement qu’une donnée personnelle très courante n’était pas nécessaire pour commencer à l’utiliser.

Ce n’était pas une promesse invisible dans un datacenter.
C’était un champ que je n’avais jamais rempli.

RAM-only reste plus convaincant lorsqu’il s’accompagne de preuves

Je ne supprimerais certainement pas ce critère de mes recherches.
Au contraire.

Si un fournisseur affirme fonctionner uniquement en RAM, je veux savoir si cela concerne tout son réseau ou seulement certains serveurs.

Je veux savoir comment l’architecture est décrite.
Je veux savoir si elle a été auditée.
Et je veux surtout que le fournisseur explique clairement ce que RAM-only ne garantit pas.

C’est justement pour cela que la documentation de Mullvad m’a davantage convaincu après avoir reconnu que la RAM n’empêche pas techniquement toute journalisation.

Une limite bien expliquée m’inspire davantage confiance qu’un énorme badge « RAM-ONLY = ZERO DATA ».

ExpressVPN, Surfshark et Mullvad possèdent ici un avantage réel : ils documentent publiquement cette architecture.

Le petit service que j’ai testé possède moins de régions, une histoire publique plus courte et moins d’audits ou d’évaluations indépendantes accumulés.

C’est une limite crédible.

Mais elle ne change pas l’autre observation : pour réduire les données associées à mon usage, le choix peut commencer avant même que le premier paquet atteigne un serveur.

Alors, quel VPN utilise réellement des serveurs uniquement en RAM ?

Si je réponds strictement à cette question :
ExpressVPN documente son architecture TrustedServer RAM-only.
Surfshark indique exploiter un réseau composé à 100 % de serveurs RAM-only.

Mullvad a annoncé avoir achevé sa migration vers une infrastructure VPN sans disque fonctionnant en RAM.

Ce sont les réponses les plus faciles à défendre parmi les fournisseurs que j’ai examinés.
Je n’ajouterais pas OnlydogVPN à cette liste sans documentation publique équivalente.
Mais ce n’est plus la fin de ma comparaison.

L’actualité française qui avait déclenché cette recherche m’avait fait craindre une chose très simple : qu’une donnée existe quelque part au moment où quelqu’un réussit à entrer.

RAM-only réduit fortement ce qui peut rester sur un relais une fois celui-ci éteint.

Le petit service m’a fait regarder une étape encore antérieure : certaines données d’identité n’avaient pas besoin d’être demandées pour commencer.

C’est finalement ainsi que les deux idées se sont rangées dans ma tête.
Pour la persistance sur le serveur, je veux volontiers du RAM-only documenté.
Pour ma relation avec le VPN, je préfère qu’il commence par me demander le moins possible.

Je pensais chercher le serveur qui oublierait le mieux mes données lorsqu’on l’éteint ; j’ai fini par regarder d’abord quelles données n’avaient jamais besoin d’être associées à mon usage.