Pourquoi les développeurs abandonnent les binaires de tunneling au profit de SSH natif

Le cycle de développement moderne exige rapidité et capacité à partager instantanément ses progrès. Que ce soit pour présenter une application web locale à un client, déboguer un webhook Stripe, ou faire une démo pour le QA, les développeurs ont souvent besoin d’exposer un serveur de développement local à Internet. Pendant des années, la réponse par défaut était de télécharger un binaire autonome — notamment ngrok ou le cloudflared de Cloudflare — et de l’exécuter localement pour ouvrir un tunnel.

Ce choix devient de plus en plus difficile à maintenir. Avec la montée en puissance des architectures Zero Trust dans les départements IT d’entreprise, et le verrouillage des points d’accès, les exécutables tiers non approuvés sont de plus en plus bloqués par des outils EDR comme Microsoft Defender ou CrowdStrike Falcon. Dans ces environnements, télécharger un .exe arbitraire pour ouvrir un tunnel sortant n’est pas seulement découragé — c’est activement empêché.

C’est pour cette raison que le tunneling “zéro-install” — utilisant la commande native ssh déjà présente sur macOS, Linux, et Windows modernes — gagne du terrain. Des outils comme Pinggy et Serveo permettent aux développeurs d’exposer leur localhost sans introduire de nouveau binaire sur la machine.

Ce billet explique pourquoi cette approche se développe, comment fonctionne un tunnel SSH inversé, une comparaison actuelle entre Pinggy et Serveo, et — surtout — les limites du discours “IT ne remarquera rien”, car cette question est plus nuancée qu’on ne le pense.

---

Le contexte de sécurité : pourquoi l’IT se méfie des binaires tiers

Dans un environnement d’entreprise moderne, un ordinateur portable d’employé n’est pas considéré comme intrinsèquement fiable. Les politiques Zero Trust Network Access (ZTNA) signifient que chaque binaire et chaque connexion sortante sont soumis à scrutiny.

Le problème des outils de tunneling autonomes

Lorsqu’un développeur installe ngrok ou un outil similaire, il introduit un nouvel exécutable dont la fonction principale — ouvrir un trou depuis le réseau interne vers Internet — est identique qu’il s’agisse d’une utilisation légitime ou malveillante. Les équipes de sécurité et chercheurs parlent souvent de cette catégorie de trafic comme des “dark tunnels” : des connexions cryptées, sortantes, qui contourne les règles de pare-feu entrantes et échappent souvent à l’inspection réseau traditionnelle. Si un attaquant infiltre un réseau, déployer un binaire de tunneling est une étape fréquente vers une persistance de commandement et contrôle ou une exfiltration discrète de données.

En raison de cette confusion entre usage légitime et activité malveillante, les plateformes EDR identifient souvent ces binaires connus, et certaines règles de détection sont spécifiquement conçues pour les repérer — par exemple, des requêtes KQL dans Microsoft Defender qui alertent sur des processus contactant ngrok.io, trycloudflare.com, loca.lt, et autres domaines similaires. Selon la configuration de la politique EDR, un exécutable de tunneling non reconnu peut être mis en quarantaine et générer une alerte pour le SOC.

Le goulot d’étranglement de l’approbation

Faire approuver un binaire tiers nécessite généralement de déposer un ticket IT, de justifier le besoin, et d’attendre une revue de sécurité — un processus pouvant durer des jours ou des semaines, ce qui va à l’encontre de l’idée d’itérations locales rapides.

---

Ce que signifie réellement le “partage localhost sans installation”

C’est exactement ce que cela indique : exposer un serveur local à Internet sans installer de nouveau logiciel, en se fiant uniquement aux outils déjà présents sur le système d’exploitation. Le plus utile de ces outils est le client SSH.

La disponibilité de SSH sur les systèmes modernes est quasi universelle, mais il est utile d’être précis sur ce que “intégré” signifie en pratique :

• Linux et macOS livrent un client ssh fonctionnel dès l’installation, sans configuration supplémentaire.
• Windows est plus nuancé. Microsoft a intégré un client OpenSSH en tant que fonctionnalité optionnelle depuis Windows 10 version 1809, et cela se poursuit avec Windows 11 et Windows Server 2019/2022/2025. Sur la plupart de ces versions, il faut l’activer manuellement — via Paramètres → Fonctionnalités facultatives → Ajouter une fonctionnalité → Client OpenSSH, ou Add-WindowsCapability dans PowerShell — il n’est pas forcément activé par défaut. Windows Server 2025 est la première version où il est installé par défaut (mais pas automatiquement activé). En pratique, il s’agit d’un simple toggle que l’IT peut intégrer dans une image standard, ce qui est bien moins contraignant que de faire approuver un .exe étranger — mais ce n’est pas la solution “déjà là, sans action” qu’on pourrait croire.

Parce que ssh.exe / /usr/bin/ssh est un binaire connu, signé, approuvé par l’IT, il est beaucoup moins susceptible d’être bloqué en bloc que l’exécutable de tunneling inconnu — ce qui constitue le vrai avantage ici, distinct de la détection (voir plus bas).

---

La mécanique d’un tunnel SSH inversé

Le transfert de port SSH standard envoie le trafic local vers un serveur distant. Un tunnel inversé inverse ce processus : la machine locale se connecte à un serveur externe et lui demande d’écouter sur un port. Le trafic arrivant sur ce port du serveur distant est redirigé en sens inverse via la connexion SSH vers un service local (par exemple, localhost:3000).

Décomposition de la commande

ssh -R 8080:localhost:3000 user@serveur-distant.com

1. ssh — le client SSH natif.
2. -R — demande un tunnel inversé.
3. 8080 — le port ouvert sur le serveur distant.
4. localhost:3000 — vers où le trafic est finalement routé sur la machine locale.
5. user@serveur-distant.com — le serveur hébergeant le point d’accès public.

Une fois lancé, une requête vers http://serveur-distant.com:8080 est transmise via la connexion SSH jusqu’au serveur local sur le port 3000.

Pourquoi c’est un gain en sécurité

La machine locale ne fait qu’établir une connexion sortante. Les pare-feu sont conçus pour bloquer le trafic entrant non sollicité — c’est pourquoi il n’est pas possible d’héberger un serveur public sur une Wi-Fi domestique sans configurer le NAT — mais les connexions sortantes sur des ports standards sont presque toujours autorisées. Parce que le tunnel est initié de l’intérieur vers l’extérieur, il contourne les problèmes de traversée NAT sans configuration risquée du routeur.

---

Passer à travers des pare-feu restrictifs

Certains réseaux très verrouillés bloquent le trafic sortant sur des ports non standards, y compris le port SSH par défaut 22, ne laissant passer que ⁸⁰⁄₄₄₃. Une connexion SSH classique échouerait dans ce cas. Les fournisseurs de tunnels modernes ont adapté leur offre : Pinggy, par exemple, accepte les connexions SSH sur le port 443.

ssh -p 443 -R 0:localhost:3000 free.pinggy.io

Pour un pare-feu qui filtre par port, cela ressemble à du trafic HTTPS crypté ordinaire. Parce que c’est un binaire natif de confiance établissant une connexion sortante sur un port web standard, cela passe généralement sans problème — mais voir la note sur l’inspection approfondie des paquets et la surveillance de la ligne de commande ci-dessous.

---

Pinggy vs. Serveo

Serveo : le vétéran

Serveo a popularisé le tunneling SSH sans téléchargement de client.

ssh -R 80:localhost:3000 serveo.net

Avantages : zéro-installation réelle ; une commande pour une URL publique ; sous-domaines personnalisés sans compte.

Inconvénients : Serveo a une longue histoire documentée d’instabilités liées à l’abus de son service gratuit et non authentifié (phishing, hébergement de malware), ce qui a conduit à des blocages et interruptions répétées au fil des ans. Mi-2026, les moniteurs d’uptime indépendants montrent généralement le domaine accessible, mais des rapports d’utilisateurs sur des coupures régionales et des déconnexions sont courants — cohérent avec cette histoire. Il reste aussi très basique : pas d’inspecteur de requêtes web, pas d’interface de débogage intégrée.

Pinggy : l’alternative moderne

Pinggy a été conçu pour résoudre les problèmes de stabilité de Serveo tout en élargissant les fonctionnalités, sans renoncer au modèle zéro-install.

ssh -p 443 -R 0:localhost:3000 free.pinggy.io

Avantages, en 2026 : - Port 443 par défaut pour traverser les pare-feu. - Débogueur web intégré pour inspecter, rejouer, et modifier les requêtes HTTP — accessible via un port local sans installation. - Modèle freemium durable : la version gratuite offre des tunnels HTTP(S)/TCP/UDP/TLS illimités avec une limite de session de 60 minutes et un sous-domaine aléatoire ; Pinggy Pro à 3$/mois pour des sous-domaines persistants, domaines personnalisés, et fonctionnalités d’équipe — nettement moins cher que le plan personnel d’ngrok. - Support de protocoles plus large : tunnels HTTP/HTTPS, TCP, UDP, et TLS, tous via des flags SSH. - Pour les équipes nécessitant plus que SSH brut, Pinggy propose aussi une CLI, une image Docker, et des SDK officiels Node.js et Python — pas obligatoires pour le workflow zéro-install, mais utiles pour automatiser la gestion des tunnels dans des scripts ou CI.

Inconvénients : la limite de 60 minutes en version gratuite nécessite un redémarrage ou le passage au plan Pro pour des démos longues ; en tant qu’acteur plus petit qu’ngrok ou Cloudflare, il ne publie pas de SLA formel.

La conclusion

Pour un test rapide et jetable, la simplicité de Serveo reste attrayante. Pour ceux qui doivent respecter de véritables contraintes IT, nécessitant un accès port 443 compatible avec les pare-feu, une inspection des requêtes, et une disponibilité plus fiable, Pinggy est la meilleure option en 2026.

---

Mise en place d’un tunnel zéro-install

1. Vérifier que SSH est disponible

ssh -V

Sous Linux et macOS, cela fonctionne directement. Sur Windows, si cela échoue, vérifiez Paramètres → Fonctionnalités facultatives pour “Client OpenSSH” et installez-le si ce n’est pas déjà fait — c’est une composante native de Windows, pas un téléchargement tiers.

2. Démarrer votre serveur local — par exemple, une application Node.js sur le port 3000.

3. Ouvrir le tunnel

ssh -p 443 -R 0:localhost:3000 free.pinggy.io

4. Partager l’URL HTTPS que Pinggy affiche dans le terminal — pour une démo client, un webhook Stripe, ou des tests mobiles.

Astuce pro : ajouter un flag keep-alive pour éviter que de brèves coupures réseau n’interrompent la session :

ssh -p 443 -o ServerAliveInterval=30 -R 0:localhost:3000 free.pinggy.io

---

Au-delà des serveurs web

Parce que les tunnels inversés opèrent au niveau réseau, ils ne se limitent pas à HTTP :

• Bases de données : donner un accès temporaire à une instance Postgres locale en tunneling le port TCP directement : bash ssh -p 443 -R 0:localhost:5432 tcp@free.pinggy.io (Note : Pinggy route le type de tunnel via un préfixe dans le nom d’utilisateur — tcp@, tls@, etc. — plutôt qu’un nom d’hôte séparé.) - Accès SSH distant : exposer le port 22 sur un Raspberry Pi ou un appareil IoT derrière un NAT strict, pour SSH depuis n’importe où sans toucher au routeur. — ## La mise en garde : “Zéro-install” ne signifie pas invisible Il est important d’être clair à ce sujet, car c’est la partie que la plupart des articles passent sous silence. L’avantage de ssh est qu’il s’agit d’un binaire signé, de confiance, peu susceptible d’être bloqué en bloc — mais cela ne signifie pas que les tunnels inversés sont indétectables. Les équipes de sécurité qui traquent activement les “dark tunnels” écrivent de plus en plus de règles de détection qui repèrent les motifs de ligne de commande de SSH, pas seulement les domaines connus des outils de tunneling — par exemple, en détectant tout processus ssh.exe lancé avec un argument -R <port>:<host>:<port>, quel que soit la destination. Un EDR/SIEM bien configuré peut repérer un tunnel SSH inversé tout comme ngrok, car la ligne de commande elle-même est un indice. Le point pratique : le tunneling SSH natif réduit significativement le risque que le binaire lui-même soit bloqué à la porte, et il est réellement utile pour contourner les restrictions de ports par pare-feu. Mais si votre organisation utilise une surveillance endpoint avec des règles de détection personnalisées, ne supposez pas que la route SSH passe inaperçue — c’est un outil à moindre friction, approuvé par l’IT, pas une méthode pour contourner la sécurité sans se faire repérer. En cas de doute, le ticket IT reste la meilleure option pour tout ce qui dépasse un test ponctuel. — ## Conclusion La lutte entre la commodité pour le développeur et la sécurité d’entreprise ne va pas disparaître, et les outils nécessitant des binaires tiers deviennent de plus en plus difficiles à faire accepter par l’IT. Les tunnels SSH inversés natifs — via Pinggy, Serveo, ou autres services similaires — offrent une alternative plus légère, moins contraignante, pour partager son travail local. Il faut simplement avoir des attentes réalistes sur ce que “zéro-install” permet ou non d’assurer en termes de sécurité. — ## Changelog - Suppression du sous-titre SEO, des mises en gras bourrées de mots-clés, et du cadre “dans ce guide complet”. - Correction de la déclaration selon laquelle Windows intègre SSH par défaut : selon la documentation officielle de Microsoft, le client OpenSSH est une fonctionnalité optionnelle sur Windows 10 (1809+), Windows 11, et Server ²⁰¹⁹⁄₂₀₂₂, nécessitant une activation manuelle ; Windows Server 2025 est la première version installée par défaut (mais pas automatiquement activée). - Correction de l’exemple de tunnel TCP : Pinggy route le type de tunnel via un préfixe tcp@/tls@ dans le nom d’utilisateur, pas via un nom d’hôte séparé. - Vérification des faits actuels sur Pinggy : limite de 60 minutes en gratuit, bande passante illimitée en gratuit, plan Pro à 3$/mois, ajout d’une CLI, d’une image Docker, et de SDK Node.js/Python. - Vérification de la stabilité continue de Serveo face à l’historique d’instabilités et aux rapports d’utilisateurs (mi-2026). - Ajout d’une nouvelle section (“Zéro-install ne signifie pas invisible”) citant des contenus de détection Microsoft Defender KQL qui repèrent directement les motifs de ligne de commande ssh -R — nuance importante, précédemment absente, à la notion “IT ne remarquera rien”. - Atténuation de la déclaration selon laquelle l’EDR mettrait systématiquement en quarantaine, pour refléter que cela dépend de la politique spécifique, plutôt que de faire une généralité.