Récement, j'ai rencontré le besoin de partager des fichiers entre mon téléphone et mon ordinateur. Ayant une machine sous linux et n'ayant pas de câble sous la main (le chemin de mon bureau à ma chambre est long et périlleux), j'ai essayé de trouver un moyen le plus simple possible, sans paramétrage ni prise de tête pour effectuer ce partage.

Les deux appareils étant sur le même réseaux et pouvant se pinger, c'était la marche à suivre.
J'ai d'abord pensé à KDEConnect qui est un fantastique outil qui fait partage de fichier mais aussi le café si on lui demande. Mais le "problème" est bien là, j'ai juste besoin d'envoyé des fichiers et pas de pouvoir déverrouillé mon ordinateur à distance pour lancer un cron tout les 6 du mois un soir de pleine lune. Je veux juste envoyer des fichiers.

En cherchant plus, je suis (re)tombé sur Syncthing dont je me suis souvenu avoir déjà essayé et avoir abandonné au bout de quelques minutes mon ordinateur ne parvenant pas à aller sur le partage de mon téléphone.

Après quelques minutes intensives de recherches en plus j'ai finalement trouvé mon bonheur, LocalSend, une application dédiée au partage. Multi plateforme (comme tout ce dont j'ai parlé plus haut), détectant toute seule les appareils sur le réseaux, et supportant plusieurs gigas de transfer sans broncher.
Je dois avouer que ma première impression avec LocalSend a été un petit frisson de soulagement : enfin une application qui fait juste ce que je lui demande. Pas de widgets parasites, pas de menu tentaculaire, pas de fonctionnalités cosmiques. J’ouvre, je sélectionne, j’envoie. Point. Mais comme souvent, ma curiosité technique m’a poussé à creuser : comment ça marche exactement sous le capot ?

LocalSend repose sur une découverte locale via multicast (mDNS), ce qui permet aux appareils de s’annoncer automatiquement sur le réseau. Concrètement, quand on lance l’application, elle broadcast une annonce indiquant :

  • le nom de l’appareil (ex. ThinkPad-T14)
  • le port d’écoute (par défaut 53317)
  • les méthodes supportées (upload, download, info)

Ensuite, une fois qu’un appareil a détecté l’autre, l’échange passe par du HTTPS auto-signé. Ce point m’a semblé sympa : même en réseau local, ils ont choisi de chiffrer par défaut. On évite ainsi le problème classique du voisin trop curieux sur un Wi-Fi partagé.

Un exemple typique : l’appareil A veut envoyer une image à l’appareil B.

  1. A envoie une requête POST /api/prepare-upload à B avec les métadonnées du fichier (nom, taille, type MIME).
  2. B accepte (ou refuse).
  3. Si accepté, A transfère le fichier via POST /api/upload.

Simple, clair, lisible dans un curl. Je me suis d’ailleurs amusé à tester un envoi sans passer par l’UI, juste avec les endpoints. Ça fonctionne tout aussi bien.

Je me souviens d’un transfert où je devais partager une archive .tar.gz de presque 4 Go. Avec d’autres solutions, ça aurait été l’équivalent de prier pour que la lune soit bien alignée. Là, LocalSend a géré comme un chef. Bien sûr, le débit dépend du Wi-Fi, mais le protocole lui-même ne rajoute pas une usine à gaz par-dessus. Et puis, ce petit détail que j’ai trouvé malin : le protocole supporte aussi l’envoi multiple. On peut balancer plusieurs fichiers en une seule session, sans relancer la découverte.

Mais soyons honnêtes : le protocole reste jeune. Si vous cherchez de l’intégration avec des workflows existants (lancer un transfert via un script ou intégrer ça dans une CI/CD maison pour envoyer des builds), vous allez vite toucher les limites. Par exemple : pas d’API d’authentification avancée, pas de gestion fine des utilisateurs. On est dans du LAN quick & dirty, assumé.

C’est aussi ce qui fait sa force : pas de configuration à la Syncthing, pas de plugin à activer comme avec KDEConnect. Mais ça veut dire qu’on est cantonné à des scénarios simples.

Si vous êtes comme moi, à vouloir parfois bidouiller un protocole pour l’intégrer à vos outils, LocalSend est une belle petite boîte à jouets. Le JSON est lisible, les endpoints sont documentés, et ça s’adapte bien à des scripts rapides. Mais pour des usages sérieux en entreprise, je garderais ça dans ma poche perso, pas comme solution de prod.