Relayium

Relayium vs magic-wormhole : transfert de fichiers CLI

Dernière mise à jour: 2026-07-12

magic-wormhole s'est bâti discrètement un public fidèle : on le lance, on obtient un code court et facile à lire comme 7-crossover-clockwork, on le dicte à l'autre personne, et le fichier arrive — chiffré de bout en bout, sans compte ni serveur dont il faut se soucier. La CLI Relayium repose sur une idée similaire : un code court appaire directement deux ordinateurs et chiffre tout ce qui passe entre eux.

Les deux se recoupent beaucoup, et là où ce n'est pas le cas, mieux vaut être précis — y compris sur le seul point où magic-wormhole est aujourd'hui réellement plus robuste que la CLI Relayium.

Ce que les deux ont en commun

Les deux outils résolvent le même problème central de la même manière honnête : aucun fichier qui reste sur un serveur que vous ne contrôlez pas, et un court code comme seule chose que les deux extrémités se transmettent par un autre canal. magic-wormhole ne demande aucun compte ; Relayium n'en demande un qu'à l'expéditeur, pour que son serveur puisse générer ce code, et le destinataire toujours pas.

Le seul point où magic-wormhole est plus robuste : il a un relais

C'est le compromis honnête, et il vaut la peine de le dire clairement plutôt que de l'édulcorer. magic-wormhole embarque un Transit Relay sur lequel il peut basculer quand les deux extrémités ne parviennent pas à ouvrir une connexion directe entre elles — par exemple si les deux côtés sont derrière un NAT strict ou symétrique sans moyen de percer. Le relais ne voit jamais que du chiffré, mais parce qu'il existe, le transfert aboutit quand même.

Le send/receive de Relayium est exclusivement direct : il tente une connexion directe pendant quelques secondes juste après la poignée de main, et s'il n'en trouve pas, le transfert échoue purement et simplement plutôt que de basculer vers un relais — par conception, les serveurs de Relayium ne touchent jamais aux octets d'un transfert CLI entre réseaux. En pratique, c'est rare (la plupart des réseaux domestiques et professionnels autorisent un chemin direct), mais si vous déplacez des fichiers entre deux machines toutes deux derrière un NAT inhabituellement strict, magic-wormhole a plus de chances de simplement fonctionner. Si aucun chemin direct ne se trouve et que la fiabilité compte plus que d'éviter un relais, c'est le cas où se tourner vers magic-wormhole — ou utiliser le push/pull ou le daemon-direct de Relayium vers un serveur réellement joignable, qui eux ne dépendent pas de ce saut P2P direct.

Avant de commencer

Tout ci-dessous passe par la CLI relayium, alors installez-la d'abord si ce n'est pas fait. Sous macOS ou Linux, une commande place un binaire précompilé dans votre PATH :

curl -fsSL https://relayium.com/install.sh | sh

SSH et daemon-direct : parler à un serveur que vous exploitez déjà

Là où la CLI Relayium ajoute une réelle surface, c'est en dehors du cas ponctuel du code d'appairage : deux autres façons de déplacer des fichiers qui s'appuient sur une infrastructure que vous possédez déjà, un terrain que magic-wormhole ne cherche pas à couvrir.

relayium push / pull réutilise votre accès SSH existant, donc aucune nouvelle brique à qui faire confiance et aucun code d'appairage à partager. push fonctionne même vers un serveur sans relayium installé, en basculant sur un simple flux tar via la connexion SSH — ce repli n'existe que pour push ; pull a toujours besoin de relayium sur la machine distante, puisqu'il y joue le rôle d'expéditeur.

relayium serve transforme n'importe quelle machine que vous possédez en cible daemon-direct, accessible via TLS 1.3 avec épinglage, sans SSH ni code d'appairage — la confiance s'établit à la première connexion (approuvée de façon interactive, ou pré-autorisée pour un usage sans surveillance) puis reste épinglée ensuite, la même idée qu'une clé d'hôte SSH.

relayium push ./photos user@your-server:backups/
relayium serve --dir ~/incoming
relayium push ./build relayium://your-server

Synchronisation de dossiers et un serveur auto-hébergeable

magic-wormhole envoie un lot de fichiers (ou un dossier compressé) puis se termine — pour mettre à jour l'autre côté, il faut renvoyer, sans aucune notion de ce qui devrait être supprimé. La CLI Relayium ajoute relayium sync, un miroir incrémental à sens unique sur l'un ou l'autre des transports ci-dessus : il ne déplace que ce qui a changé ; --delete supprime sur la destination les fichiers disparus de la source (un daemon ne le respecte que s'il a été lancé avec --allow-delete, le destinataire doit donc explicitement l'accepter) ; --watch continue de resynchroniser en temps réel à chaque changement, sans tâche cron nécessaire.

Si vous ne voulez pas dépendre de relayium.com et préférez tout exploiter vous-même, le serveur de Relayium peut aussi être auto-hébergé sous la forme d'un seul conteneur Docker ; pointez la CLI dessus avec --server.

relayium sync ./photos user@your-server:backups/photos --delete --watch

Comparatif des fonctions en un coup d'œil

Les différences qui comptent le plus, côte à côte :

Questions fréquentes

La CLI Relayium est-elle gratuite ?

Oui, entièrement. Il n'y a aucun palier payant et rien à mesurer — chaque mode connecte directement les deux extrémités, et la CLI est open source.

A-t-elle besoin d'un compte ?

send oui, et le up cloud aussi. push/pull utilise votre propre accès SSH et daemon-direct utilise une confiance par certificat TLS avec épinglage entre vos machines, donc ni l'un ni l'autre ne touche un compte Relayium. send/receive fait exception : seul le serveur peut générer un code d’appairage, et seulement pour un compte connecté, donc l'expéditeur lance une fois relayium login — un send auquel vous passez un code qu'on vous a donné n'en génère aucun et ne demande pas de connexion. Recevoir ne nécessite jamais de compte.

Que se passe-t-il si je suis derrière un NAT strict et qu'il n'y a aucun chemin direct ?

Dans ce cas, le send/receive de Relayium est exclusivement direct et échouera — il ne bascule pas vers un relais. Le Transit Relay de magic-wormhole peut néanmoins transporter le flux chiffré et mener le transfert à bien. Si vous avez besoin que ça fonctionne quel que soit l'état du réseau, magic-wormhole gère ce cas aujourd'hui ; le push/pull ou le daemon-direct de Relayium vers un serveur joignable fonctionnent aussi, car ils ne dépendent pas d'un saut P2P direct.

Puis-je utiliser le code d'appairage de la CLI avec l'application web de Relayium ?

Pas encore pour un transfert appairé en direct — le send/receive de la CLI utilise sa propre poignée de main directe, distincte du flux d'appairage du navigateur basé sur WebRTC, donc les deux n'interopèrent pas aujourd'hui. Pour remettre un fichier à quelqu'un via un simple navigateur, utilisez le lien de téléchargement stocké de Relayium ou le mode par code d'appairage propre à l'application web.

Puis-je l'auto-héberger ?

Oui. Le serveur de Relayium est distribué sous forme d'image Docker (docker compose up -d --build), et vous pouvez pointer le send/receive de la CLI vers votre propre instance avec --server https://your-domain.

Installez la CLI Relayium gratuite et essayez push, sync ou send — gratuit, avec un transfert à base de code tout aussi rapide à démarrer que magic-wormhole.

Obtenir la CLI

À lire ensuite