L'alternative au serveur de fichiers instantané : comment transformer localhost en lecteur public

Le dilemme du développeur : Vous venez de terminer une sprint critique du vendredi et devez transmettre une image Docker de 50 Go, un dump SQL volumineux ou un dossier d’actifs 4K non compressés à un client ou une équipe QA. Vous faites glisser le dossier dans Google Drive, S3 ou Dropbox, et regardez la barre de progression de l’upload avancer. Votre débit de téléchargement est rapide, mais la vitesse d’upload résidentielle est généralement une fraction de cela — donc avant que votre client puisse télécharger quoi que ce soit, vous devez attendre que l’intégralité de la charge utile ait fini de s’uploader.

Et si vous sautiez complètement l’intermédiaire du cloud et laissiez le client tirer les fichiers directement de votre machine ?

Des outils de tunneling comme LocalXpose et Localtonet proposent des modes de serveur de fichiers intégrés qui font exactement cela : pointez-les vers un dossier, et ils le publient instantanément à une URL publique, sans serveur web séparé ni attente d’upload. Cet article explique comment transformer localhost en serveur de fichiers, la mécanique derrière, et la syntaxe de commande vérifiée ainsi que les fonctionnalités pour ces deux outils — y compris le mode WebDAV de Localtonet et ses fonctionnalités de sauvegarde cryptée plus récentes.

---

Pourquoi le stockage cloud n’est pas l’outil adapté pour un transfert rapide

1. Le goulot d’étranglement du double transfert. Le stockage cloud est asynchrone : l’appareil A doit finir d’uploader 100% du fichier avant que l’appareil B puisse commencer à le télécharger. Sur une connexion domestique asymétrique, un fichier de 20 Go à 20 Mbps d’upload signifie plus de deux heures juste pour stager le transfert — avant que votre client ne touche un seul octet.
2. Limites de stockage et de bande passante. Un bundle de logs de plusieurs gigaoctets ou un snapshot d’environnement de staging peut rapidement dépasser le quota de stockage gratuit, obligeant à nettoyer ou à faire une mise à niveau pour ce qui est censé être un transfert unique.
3. Souveraineté des données. Uploader des sources propriétaires, des médias non publiés ou des données clients (même nettoyées) vers un cloud tiers signifie qu’elles reposent maintenant sur une infrastructure que vous ne contrôlez pas.
4. Fragilité de la synchronisation. Compresser de grands répertoires de petits fichiers (arbre node_modules, build de site statique) et les pousser via un client de synchronisation de bureau est une source courante de verrouillage de fichiers et de transferts corrompus.

L’alternative est le partage peer-to-peer, sans upload : le client tire le fichier directement de votre disque, en utilisant uniquement votre bande passante montante disponible.

---

Comment fonctionne réellement le partage de répertoire en reverse-proxy

Héberger soi-même un serveur de fichiers signifiait autrefois lutter contre votre réseau : IP statiques, redirection de ports du routeur, règles de pare-feu, et espérer que votre FAI ne vous place pas derrière un Carrier-Grade NAT (CGNAT), qui bloque complètement les connexions entrantes.

Les clients de tunneling modernes inversent cela. Au lieu d’ouvrir un port et d’attendre du trafic entrant, un agent léger sur votre machine établit une sortie vers le serveur edge d’un fournisseur de tunneling. Les connexions sortantes traversent NAT, CGNAT, et la plupart des pare-feux sans configuration. Le serveur edge vous fournit une URL HTTPS publique ; lorsqu’une requête est faite, il proxy cette requête via le tunnel déjà ouvert vers votre machine.

En pointant cette architecture vers un dossier plutôt qu’une application sur un port, vous obtenez le partage de répertoire en reverse-proxy : un chemin spécifique sur votre disque, exposé de manière sécurisée et temporaire, sans déployer de serveur web ni toucher à votre routeur.

---

Le serveur de fichiers intégré de LocalXpose

LocalXpose est un client de tunneling polyvalent (HTTP, TLS, TCP, UDP) qui inclut aussi un mode serveur de fichiers intégré directement dans son type de tunnel http — pas besoin de serveur web séparé.

La commande exacte

Les docs officiels de LocalXpose donnent cette syntaxe précise pour un partage de fichiers protégé :

loclx tunnel http --subdomain mypics --basic-auth user:pass --file-server /home/pics

--file-server prend directement le chemin du dossier ; --basic-auth user:pass protège tout le répertoire par authentification HTTP Basic avant même que la liste ne s’affiche, ce qui bloque les requêtes non authentifiées à la périphérie plutôt que sur votre machine. --subdomain est optionnel — omettez-le et LocalXpose en attribue un aléatoire.

Sur Windows, l’équivalent ressemble à :

loclx tunnel http --basic-auth client:supersecretpassword --file-server C:\Users\Dev\Deliverables

(Les pages marketing de LocalXpose montrent aussi une autre forme, --to /path --file-server avec --file-server comme un drapeau booléen — les deux apparaissent dans la documentation officielle, mais la syntaxe ci-dessus est celle documentée dans le tutoriel dédié au partage de fichiers et la plus sûre à copier.)

Installer le client

LocalXpose fournit des packages pour toutes les plateformes majeures :

# macOS (Homebrew)
brew install --cask localxpose

# Linux (Snap)
sudo snap install localxpose

# Toute plateforme avec Node
npm install -g loclx

# Windows (Chocolatey)
choco install localxpose

Connectez-vous une fois avec loclx account login, ou exportez ACCESS_TOKEN pour une utilisation non interactive/CI.

Sécuriser davantage

L’authentification de base est le minimum. LocalXpose supporte aussi un plugin ip_whitelist et un reserved_domain pour une URL de serveur de fichiers stable et mémorable, configurable via config.yaml :

file-server:
  type: http
  region: us
  reserved_domain: mydomain.com
  plugins:
    ip_whitelist:
      - 203.0.113.0/24
  apps:
    file_server:
      path: ./deliverables

Pour un partage qui doit rester actif sans surveillance, loclx service install enregistre LocalXpose comme un service OS en arrière-plan, permettant au tunnel de survivre à la fermeture du terminal ou au redémarrage.

---

Localtonet : trois modes de serveur de fichiers, pas un seul

Localtonet adopte une approche plus large : son type de tunnel File Server dispose d’un sélecteur “Type de Process” dédié dans le tableau de bord proposant trois modes distincts — Default (gestionnaire de fichiers dans le navigateur), SFTP, et WebDAV — tous pointés vers le même chemin de dossier local, sans daemon SFTP ou serveur web séparé.

1. Default — gestionnaire de fichiers basé sur le navigateur

Selon la documentation de Localtonet, le mode Default offre : upload, download, renommage, déplacement, copie, suppression, création de dossiers, recherche, aperçu, tagging, archivage, et partage. Les permissions sont gérées par tunnel avec des flags globaux Upload / Download / Delete / Create Folder / Move / Share, et des overrides par chemin où le plus spécifique prévaut — un schéma plus granulaire qu’un simple toggle “lecture/écriture/suppression”.

Depuis mi-2026, Localtonet a aussi ajouté une sécurité et une sauvegarde avancée à ce mode, intéressant si vous l’utilisez pour autre chose qu’un transfert ponctuel :

• Chiffrement AES-256-CBC du dossier, avec des clés qui ne quittent jamais votre machine.
• Sauvegarde mobile compatible Immich avec déduplication, pour l’utiliser comme cible de sauvegarde photo auto-hébergée.
• Sauvegarde cloud programmée vers Amazon S3 (et autres stockages compatibles comme Backblaze B2, Wasabi, MinIO), FTP ou SFTP — configurable avec plusieurs fournisseurs en parallèle (par ex., une cible S3 principale et une cible SFTP secondaire sur un NAS domestique).

La documentation de Localtonet ne confirme pas si toutes ces fonctionnalités du mode Default (chiffrement, sauvegarde Immich, sauvegarde cloud programmée) s’appliquent aussi en mode SFTP ou WebDAV — considérez-les comme spécifiques au mode Default jusqu’à ce que la documentation le précise.

2. SFTP — pour outils et automatisation existants

Choisir SFTP comme type de processus vous donne un point de terminaison SFTP standard, supporté par le même dossier local, permettant à FileZilla, WinSCP, rsync, ou scripts CI de se connecter sans modification de leur configuration. Parce que l’agent de Localtonet sert le point de terminaison SFTP, vous n’avez pas besoin d’installer ou d’exposer un daemon SSH/SFTP séparé.

3. WebDAV — monter le dossier comme lecteur réseau

WebDAV permet à un client de monter votre dossier partagé comme un lecteur natif plutôt que de le parcourir via une interface web ou un client de transfert de fichiers :

• Windows : Explorateur de fichiers → “Map network drive,” collez l’URL WebDAV de Localtonet, entrez les identifiants.
• macOS : Finder → Cmd+K (“Se connecter au serveur”), entrez l’URL.

Une fois monté, le client peut ouvrir, éditer et sauvegarder des fichiers avec leurs applications de bureau natives (Word, VS Code, Photoshop) sans cycle manuel de téléchargement/rechargement, et faire glisser-déposer de gros fichiers directement dans le montage.

Configurer un tunnel de serveur de fichiers Localtonet

1. Installez l’application Localtonet pour votre OS et connectez-vous.
2. Copiez votre AuthToken depuis le tableau de bord et collez-le dans l’application.
3. Allez à la page File Server, choisissez un type de processus (Sous-domaine aléatoire / Sous-domaine personnalisé / Domaine personnalisé), sélectionnez Default, SFTP ou WebDAV, et choisissez votre AuthToken et région du serveur.
4. Entrez le chemin du dossier local (ex. C:\Users\Work sous Windows, /root ou /usr/share sous Linux).
5. Cliquez sur Start. Par défaut, toutes les fonctionnalités sont activées publiquement dès que le tunnel démarre — cliquez sur Manage sous Permissions si vous souhaitez restreindre Upload, Delete ou Move avant de partager le lien.

---

Cadre général pour ces deux outils

1. Installer le client — LocalXpose (snap, brew, npm, choco) ou Localtonet (installateur plateforme depuis son tableau de bord).
2. Authentifier — loclx account login pour LocalXpose ; coller votre AuthToken dans l’application Localtonet.
3. Choisir un dossier sandboxé. Partagez un répertoire Transfer dédié, jamais votre racine de projet ou votre répertoire personnel — cela évite d’exposer accidentellement des fichiers .env, .git/ ou des artefacts de build.
4. Démarrer le tunnel avec authentification activée. Pour LocalXpose, toujours ajouter --basic-auth. Pour Localtonet, définir le mode Default avec le minimum de permissions nécessaires, ou utiliser les identifiants SFTP/WebDAV.
5. Partager l’URL, puis arrêter. Une fois le transfert confirmé, faites un Ctrl+C sur le tunnel LocalXpose ou cliquez sur Stop dans le tableau de bord de Localtonet — l’URL publique disparaît immédiatement.

---

Bonnes pratiques de sécurité

• Moindre privilège. Si quelqu’un a seulement besoin de télécharger, ne pas accorder Upload/Supprimer/Déplacer sur Localtonet, et ne pas sauter --basic-auth sur LocalXpose.
• Éphémère par défaut. Considérez un tunnel de serveur de fichiers comme un mot de passe temporaire — activez-le pour le transfert et fermez-le juste après, plutôt que de le laisser tourner en permanence.
• Isoler le dossier partagé. Copiez les fichiers dans un répertoire dédié plutôt que de pointer le tunnel vers un répertoire de travail ou de projet actif.
• Surveiller les logs. Les deux outils montrent l’activité de connexion en temps réel dans le CLI ou le tableau de bord — des IP inconnues ou une rafale de requêtes rapides et répétées (scan par bot) sont un signal pour arrêter immédiatement le tunnel.

---

Autres méthodes pour y parvenir

• Python + ngrok / Pinggy. Pas de client dédié ? python3 -m http.server 8080 dans le dossier cible, puis tunnelisez le port 8080 avec ngrok http 8080 ou Pinggy. Il manque la gestion des permissions d’un serveur de fichiers dédié, mais ça fonctionne partout où Python est disponible.
• Raccourci --serve de Pinggy. Le CLI récent de Pinggy (cli-js) a ajouté une commande en une ligne : pinggy --serve /chemin/vers/fichiers démarre un tunnel et sert ce répertoire directement, combinable avec ses autres flags d’authentification/IP-whitelist — réduisant l’écart avec LocalXpose et Localtonet.
• Tailscale / ZeroTier. Si les deux parties sont à l’aise avec l’installation d’un client VPN maillé, mettre les deux machines sur le même réseau privé et utiliser le partage de fichiers natif OS (SMB/CIFS) est une option — au prix d’obliger le destinataire à installer et s’authentifier dans le VPN en premier, ce qu’une URL simple ne nécessite pas.

---

Tarification actuelle (2026)

	LocalXpose	Localtonet
Niveau gratuit	2 tunnels HTTP actifs	1 tunnel, 1 Go de bande passante/mois, timeout de 30 min
Niveau payant	Pro : 8$/mois (96$/an) — 10 tunnels actifs, bande passante illimitée	Paiement à l’usage : ~2$ par tunnel actif/mois (au prorata ; un tunnel arrêté ne coûte rien)
Serveur de fichiers inclus ?	Oui, dans la limite des tunnels HTTP gratuits	Oui, facturé au même tarif par tunnel actif que les autres types

LocalXpose ne publie pas actuellement de limite de bande passante spécifique pour son niveau gratuit dans sa documentation — si cela compte pour un transfert unique volumineux, vérifiez la page de tarification avant de vous y fier.

---

FAQ

Que signifie transformer localhost en serveur de fichiers ? Cela consiste à exposer un dossier local spécifique via une URL publique pour que quelqu’un d’autre puisse télécharger (ou, selon le mode, uploader) des fichiers directement depuis votre machine — sans passer par un stockage cloud intermédiaire.

Est-ce sécurisé ? Cela peut l’être, si vous suivez les bonnes pratiques : utilisez HTTPS (les deux outils le provisionnent automatiquement), protégez le partage par authentification (--basic-auth sur LocalXpose, flags de permission ou identifiants SFTP/WebDAV sur Localtonet), ne partagez qu’un dossier sandboxé, et fermez le tunnel une fois terminé.

Ai-je besoin d’une IP publique ou de redirection de port ? Non. Les deux outils fonctionnent en établissant une connexion sortante de votre machine vers les serveurs edge du fournisseur, évitant complètement NAT, CGNAT, et la configuration du routeur.

Quelle est la différence pratique entre les modes SFTP et WebDAV de Localtonet ? SFTP est destiné aux outils et automatisation existants — FileZilla, WinSCP, rsync, scripts CI — qui parlent déjà le protocole SFTP. WebDAV permet de monter le dossier comme un lecteur natif pour que quelqu’un puisse ouvrir et sauvegarder des fichiers avec des applications de bureau classiques, sans client séparé.

---

Historique des modifications

Vérifié selon la documentation et les blogs officiels de LocalXpose et Localtonet, en date du 7 septembre 2026.

• Correction de la syntaxe CLI du serveur de fichiers de LocalXpose. La version initiale utilisait loclx tunnel http --file-server /path --basic-auth user:pass ; la page tutorielle officielle indique l’ordre des flags comme loclx tunnel http --subdomain X --basic-auth user:pass --file-server /path. La version initiale a été ajustée pour correspondre à cette documentation, en notant que les pages marketing montrent aussi une autre forme, --to /path --file-server en booléen.
• Remplacement des fonctionnalités non confirmées du mode Default de Localtonet. La version initiale mentionnait une édition en ligne des fichiers .json/.js/.css et une “corbeille intégrée” — aucune de ces fonctionnalités n’est confirmée dans la documentation ou les blogs actuels de Localtonet. La liste réelle inclut : upload, download, renommage, déplacement, copie, suppression, création de dossiers, recherche, aperçu, tagging, archivage, partage.
• Correction du modèle de permissions de Localtonet. La version initiale décrivait des “permissions utilisateur granulaires (Lecture, Écriture, Suppression)” ; la documentation précise que les flags globaux Upload/Download/Delete/Create Folder/Move/Share sont utilisés, avec des overrides par chemin, pas un simple toggle lecture/écriture/suppression.
• Ajout des capacités plus récentes du serveur de fichiers de Localtonet, absentes de la version initiale : chiffrement AES-256-CBC du dossier, sauvegarde mobile compatible Immich, sauvegarde cloud programmée vers S3, FTP ou SFTP — documenté à partir de mi-2026. Noté que ces fonctionnalités ne sont pas confirmées pour les modes SFTP/WebDAV.
• Clarification du modèle de configuration SFTP/WebDAV de Localtonet. La version initiale laissait entendre un processus générique “exposer un serveur SFTP local” ; en réalité, c’est un sélecteur “Type de Process” dans la page du tunnel File Server, avec un agent de Localtonet qui sert directement le protocole — pas besoin d’un daemon SFTP séparé.
• Ajout de l’option --serve de Pinggy comme alternative, car elle réduit l’écart avec les modes dédiés de LocalXpose et Localtonet, en démarrant un tunnel et en servant directement un répertoire.
• Tarification à jour pour les deux outils — absente du draft : LocalXpose (gratuit : 2 tunnels HTTP ; Pro : 8$/mois, 96$/an, 10 tunnels, bande passante illimitée) et Localtonet (gratuit : 1 tunnel/1Go/30 min ; paiement à l’usage : ~2$/tunnel actif/mois).
• Commandes d’installation concrètes pour LocalXpose (Homebrew, Snap, npm, Chocolatey) et options config.yaml, reserved_domain, ip_whitelist, loclx service install pour un tunnel de serveur de fichiers IP-restreint et persistant — absentes du draft.
• Suppression des éléments non standard comme une transcription de génération de code Python, des traceback, et du code d’écriture de fichiers qui avaient fuit dans le corps du draft, ainsi que la normalisation de la structure des titres en Markdown standard.