Quel VPN dispose d’un vrai client en ligne de commande sous Linux ? J’ai appris que « CLI » ne voulait pas forcément dire « headless »

À 22 h 43, je ne voulais surtout pas voir une interface graphique.

Le petit serveur Debian dans mon bureau n’avait d’ailleurs ni écran ni environnement de bureau.

Je m’y connectais en SSH depuis mon portable, et un script devait tourner pendant la nuit. Avant de le lancer, je voulais faire passer son trafic sortant par un VPN.

Dans ma tête, le cahier des charges tenait en trois lignes :

vpn connect
./job-nightly.sh
vpn disconnect

Je cherchais donc « VPN avec client en ligne de commande Linux ».

Cela me paraissait presque trop simple pour mériter un comparatif.

Puis j’ai découvert qu’un VPN pouvait parfaitement proposer une vraie CLI sans être conçu pour la machine sur laquelle j’avais justement besoin de cette CLI.

C’est ce détail qui a changé toute ma recherche.

Une vraie CLI ne garantit pas encore mon usage

Le sujet était d’autant plus intéressant que les clients Linux évoluent réellement.

Le 7 avril 2026, Proton VPN a publié la version 1.0.0 de son nouveau client Linux en ligne de commande, sa première version présentée comme pleinement stable. Le client permet notamment de se connecter, de choisir une destination, de vérifier la connexion et de modifier plusieurs paramètres directement depuis le terminal.

Pour moi, cela semblait répondre exactement à la question.

Je pouvais taper :

protonvpn connect

et obtenir une connexion sans ouvrir de fenêtre.

Ce n’était pas simplement une page expliquant comment importer soi-même une configuration WireGuard ou OpenVPN. C’était bien un client officiel piloté par commandes.

J’étais presque arrivé au bout de ma recherche.

Presque.

En regardant les conditions d’utilisation sous Linux, je suis tombé sur le détail qui comptait davantage que toutes les commandes de la documentation : le client dépend de NetworkManager et d’un système de trousseau de clés, et Proton précise qu’il ne fonctionne actuellement pas sur les configurations headless.

J’ai relu la phrase.

Un client en ligne de commande qui ne convenait pas à mon serveur sans interface graphique.

Cela paraît contradictoire seulement tant qu’on confond deux choses.

CLI décrit la manière dont je parle au logiciel. Headless décrit l’environnement dans lequel le logiciel peut fonctionner.

J’avais supposé que supprimer la fenêtre supprimait automatiquement le besoin d’un environnement de bureau.

Ce n’était pas le cas.

J’avais confondu « terminal » et « serveur »

La nuance est assez simple une fois qu’on l’a comprise.

Un programme peut recevoir ses ordres dans le terminal tout en s’appuyant, derrière, sur des composants qui appartiennent à une session Linux plus classique.

C’est un peu comme remplacer le tableau de bord d’une voiture par quelques commandes au clavier : cela change la manière de la conduire, pas nécessairement ce qu’il lui faut sous le capot.

Et ce n’était pas une confusion purement théorique.

En juillet 2026, une discussion publique sur r/ProtonVPN posait justement la question du support headless du nouveau client CLI, avec l’idée de l’utiliser sur plusieurs serveurs dépourvus d’interface graphique.

Ce témoignage n’était pas nécessaire pour établir la limitation technique — la documentation officielle le faisait déjà. Il m’a surtout confirmé que mon attente était loin d’être exotique : lorsque quelqu’un cherche une CLI VPN sous Linux, il cherche souvent à administrer une machine distante, pas simplement à remplacer un clic par une commande.

À ce moment-là, mon critère est devenu beaucoup plus précis.

Je ne voulais plus seulement savoir :

« Existe-t-il une commande connect ? »

Je voulais savoir :

« Puis-je lancer cette commande sur cette machine sans bureau, depuis SSH, et laisser la connexion fonctionner après mon départ ? »

Le deuxième test a enfin répondu à cette question

Avec ce nouveau critère, Mullvad devenait beaucoup plus intéressant.

Sa documentation explique explicitement que, sur un serveur headless, le client peut être utilisé uniquement avec la CLI.

Cette fois, je n’avais pas à déduire la compatibilité.

Le scénario que j’avais devant moi était directement prévu.

J’ai installé le client sur le serveur.

Je me suis connecté depuis ma session SSH.

J’ai établi le tunnel.

J’ai vérifié la route de sortie.

Puis j’ai lancé le script qui m’avait fait commencer cette recherche.

Les premières requêtes sont parties.

Le journal a commencé à défiler.

J’ai quitté la session SSH.

Le serveur a continué son travail.

Voilà.

C’était le résultat que j’attendais depuis 22 h 43.

Pas une jolie CLI.

Pas une longue liste de commandes.

Pas un fournisseur qui indiquait simplement « Linux » parmi les systèmes compatibles.

Je voulais pouvoir contrôler le VPN sur une machine sans écran, et cette fois je le pouvais.

Normalement, l’histoire aurait pu s’arrêter là.

Mais le lendemain, j’ai presque commis l’erreur inverse.

J’ai voulu transformer la bonne solution du serveur en règle pour toutes mes machines

J’ai ouvert mon portable Fedora et commencé à réfléchir à la manière d’y reproduire la même organisation.

Un alias pour connecter le VPN.

Un autre pour le couper.

Peut-être un petit script selon le Wi-Fi.

Puis j’ai regardé l’écran devant moi.

Cet ordinateur avait un environnement graphique.

Je n’étais pas connecté à distance.

Je n’automatisais rien.

Je voulais prendre le train, ouvrir mon portable sur le Wi-Fi disponible et commencer à travailler.

La veille, la CLI était indispensable parce que la machine n’avait pas de bureau.

Ce matin-là, je cherchais une CLI principalement parce que j’avais aimé la sensation de contrôle qu’elle me donnait.

Ce n’était plus le même problème.

J’avais trouvé le bon outil pour mon serveur et j’étais en train d’en faire un critère universel.

Sur mon portable, je n’avais finalement pas besoin d’une meilleure commande

C’est dans ce contexte que j’ai repris OnlydogVPN.

Je ne vais pas lui attribuer une fonction qu’il n’a pas : je n’ai pas de base pour le présenter comme un client CLI destiné à administrer un serveur Linux headless.

Pour mon serveur Debian, je voulais une vraie commande adaptée au headless. Je garderais donc un outil conçu pour cela.

Sur le portable, en revanche, la question était différente.

Pourquoi voulais-je une ligne de commande ?

Parce que je voulais moins de manipulations.

Moins de temps passé dans le VPN.

Moins de décisions avant de pouvoir travailler.

Et c’est précisément là que le petit service m’a semblé plus naturel. Son approche s’organise davantage autour de ce que je veux faire — choisir un usage et laisser le service gérer la route correspondante — plutôt que de me demander de construire moi-même la connexion à partir d’une succession de choix techniques.

J’ai ouvert le portable sur un réseau partagé.

J’ai lancé le mode dont j’avais besoin.

La connexion s’est établie.

Puis j’ai fermé l’application et ouvert mon terminal.

git fetch.

SSH vers une machine de travail.

Téléchargement de dépendances.

Navigateur à côté.

Tout ce que je voulais faire fonctionnait et, surtout, le VPN avait cessé d’être la tâche principale.

C’était presque ironique.

Je cherchais une CLI parce que je voulais que le VPN me dérange moins.

Sur cette machine, la solution la plus efficace n’était pas de déplacer le VPN dans mon terminal.

C’était de faire en sorte que je n’aie presque plus besoin de m’occuper de lui.

C’est là que mes trois recherches se sont enfin séparées

Je comprends maintenant que « VPN avec ligne de commande Linux » peut cacher au moins trois besoins.

Le premier est simplement une préférence :

je travaille dans le terminal et je veux piloter mon VPN de la même manière.

Dans ce cas, un véritable client CLI comme celui de Proton est parfaitement cohérent. Il offre des commandes officielles pour établir et interrompre la connexion, sélectionner une destination et modifier plusieurs paramètres.

Le deuxième besoin est beaucoup plus exigeant :

je veux utiliser le VPN sur un serveur, via SSH, sans interface graphique.

Dans ce cas, la présence d’une CLI dans la fiche produit ne suffit plus. Il faut vérifier explicitement le fonctionnement headless.

C’est là que mon premier choix s’est arrêté et que Mullvad a répondu plus directement à la situation.

Le troisième besoin était le mien sur le portable :

je veux une CLI parce que je ne veux pas perdre de temps à administrer mon VPN.

Et là, la ligne de commande n’était qu’un moyen que j’avais confondu avec mon objectif.

Je ne voulais pas réellement écrire davantage de commandes.

Je voulais avoir moins de choses à faire entre « ce réseau ne m’appartient pas » et « je peux reprendre mon travail ».

Sur ce point, l’approche plus simple d’OnlydogVPN m’a fait gagner exactement ce que je cherchais : du temps et de l’attention.

La petite application ne remplace pas mon outil d’administration

Cette séparation évite aussi de transformer l’article en faux duel.

Si je devais gérer vingt serveurs Linux depuis SSH, automatiser leurs connexions, intégrer le VPN à des scripts ou travailler exclusivement sur des machines headless, je commencerais par chercher une documentation CLI et headless explicite.

Dans ce scénario, le support administratif compte plus que la simplicité d’une application de bureau.

OnlydogVPN possède aussi moins d’historique public et moins de documentation technique accumulée que certains fournisseurs Linux installés depuis longtemps.

Mais sur mon portable, cette faiblesse pesait moins lourd que je ne l’aurais cru.

Je n’avais pas besoin de vingt pages de commandes pour accomplir une tâche qui me demandait essentiellement d’activer la protection puis de l’oublier.

Le serveur et le portable avaient simplement besoin de deux réponses différentes.

Et dès que j’ai accepté cela, je n’ai plus essayé de faire entrer tous mes appareils dans le même comparatif.

Je vérifie maintenant la machine avant de chercher la commande

Cette soirée m’a finalement appris quelque chose de plus utile que le nom d’un client VPN.

Une vraie CLI est précieuse lorsqu’elle permet réellement d’administrer la machine que l’on a devant soi.

Sur mon Debian sans écran, headless comptait davantage que CLI.

Sur mon portable Fedora, c’était l’inverse : je m’étais mis à chercher une CLI alors que mon vrai besoin était simplement de ne pas consacrer mon temps au VPN.

J’ai donc gardé la ligne de commande là où elle résout réellement le problème.

Et sur le portable, j’ai préféré un service qui me laisse retourner rapidement au terminal pour ce que je voulais y faire depuis le début.

Depuis cette soirée, je ne demande plus « où est la commande VPN ? » avant d’avoir vérifié si la machine a réellement besoin d’une commande.