Dernière mise à jour: 2026-07-09
« Relayium est-il sécurisé ? » est une question légitime — tout outil de transfert de fichiers prétend protéger la vie privée. Cette page explique exactement, en langage simple, comment Relayium garde vos fichiers privés, pour que vous puissiez juger l'affirmation plutôt que la croire sur parole.
Deux mécanismes de chiffrement différents entrent en jeu, parce qu'il y a deux situations différentes : envoyer un fichier en direct à quelqu'un qui est en ligne à l'instant, et laisser un lien de téléchargement pour que quelqu'un le récupère plus tard. Les deux empêchent le serveur d'accéder à votre fichier, mais y parviennent par des chemins différents — et il vaut la peine de savoir lequel s'applique quand.
Quand vous envoyez un fichier en temps réel — les deux personnes en ligne, navigateur à navigateur —, Relayium commence par faire générer à chaque appareil une nouvelle paire de clés avec X25519, le même échange de clés à courbe elliptique utilisé dans la messagerie sécurisée moderne (techniquement, crypto_kx de libsodium). Chaque appareil garde sa clé privée pour lui et n'envoie que sa clé publique à l'autre partie.
À partir de ces deux clés publiques, chaque appareil calcule indépendamment le même secret partagé — un processus qui fonctionne précisément grâce à la construction mathématique de l'échange de clés à courbe elliptique, et non parce que le secret aurait été envoyé quelque part. Ce secret partagé devient une clé AES-256-GCM qui n'existe qu'à l'intérieur des deux navigateurs. Chaque bloc du fichier est scellé avec cette clé et un nonce unique avant même de quitter l'appareil de l'expéditeur, si bien que tout ce qui traverse le réseau — y compris le serveur de signalisation qui a aidé les deux navigateurs à se trouver — ne voit jamais que du chiffré.
Il y a une subtilité qu'il vaut la peine d'exposer honnêtement. Le chiffrement intégré de WebRTC (DTLS) échange les empreintes de clés via le serveur de signalisation qui présente les deux appareils l'un à l'autre. Si ce serveur était malhonnête, il pourrait en théorie s'interposer et substituer ses propres clés — une attaque classique de l'homme du milieu — sans qu'aucun des deux navigateurs ne le remarque immédiatement.
Relayium comble cette faille avec un court code de vérification. Les deux appareils dérivent le même Short Authentication String (SAS) à 6 chiffres à partir de leurs deux clés publiques et l'affichent à l'écran. Si les codes correspondent, les clés n'ont pas été substituées, et personne ne s'est interposé. Mais un simple code à 6 chiffres ne représente qu'environ 20 bits, ce qu'un attaquant bien placé pourrait en principe tenter de forcer par force brute pour obtenir une correspondance après avoir vu les deux vraies clés. Pour l'empêcher, Relayium utilise une poignée de main « engagement puis révélation » : chaque partie envoie d'abord un hachage qui l'engage sur sa clé, et ne révèle la vraie clé qu'après avoir reçu l'engagement de l'autre. Cet ordre oblige un serveur malveillant à s'engager sur une fausse clé à l'aveugle, avant d'avoir vu la vraie — il ne peut donc pas choisir après coup une clé provoquant une collision, et le code court reste digne de confiance.
Le chiffrement protège la confidentialité, mais ne prouve pas automatiquement que rien n'a été corrompu ou altéré en chemin. Relayium le vérifie séparément : chaque bloc porte sa propre étiquette d'authentification AES-GCM, si bien qu'un bloc modifié échoue purement et simplement à se déchiffrer. En plus de cela, pendant l'envoi de chaque fichier, les deux parties calculent en continu un hachage SHA-256 sur son contenu en clair ; une fois le fichier terminé, le hachage de l'expéditeur est comparé à celui du destinataire. S'ils correspondent, ce qui atterrit sur le disque est identique octet par octet à ce qui a été envoyé — sinon, le fichier est signalé plutôt qu'accepté silencieusement.
Le transfert en temps réel exige que les deux personnes soient en ligne en même temps. Quand ce n'est pas possible, Relayium propose à la place un lien de téléchargement stocké — qui utilise un mécanisme réellement différent, à ne pas confondre avec celui du temps réel décrit ci-dessus.
Il n'y a pas d'échange de clés ici, car il n'existe pas encore de second appareil avec qui échanger. À la place, votre navigateur génère une unique clé AES-256-GCM aléatoire et l'utilise pour chiffrer les fichiers avant tout envoi. Cette clé n'est jamais envoyée au serveur — elle est ajoutée au lien de téléchargement après un caractère #, dans ce qu'on appelle le fragment d'URL, une partie de l'adresse que les navigateurs ne transmettent délibérément jamais à un serveur. Le serveur finit par ne stocker que du chiffré qu'il n'a aucun moyen de déchiffrer, plus des informations de gestion comme la taille du chiffré et un horodatage d'expiration. Quiconque ouvre le lien complet — fragment compris — peut déchiffrer le fichier localement dans son navigateur ; quiconque ne l'a pas ne voit qu'un bloc opaque sur le serveur. C'est la partie « connaissance nulle » : le serveur détient le fichier chiffré sans jamais détenir les moyens de le lire.
Il vaut la peine de préciser exactement où se situe le serveur dans tout cela, car « chiffré de bout en bout » est une affirmation facile à faire et plus difficile à faire avec précision. En mode temps réel, le fichier lui-même ne touche jamais les serveurs de Relayium — il circule directement entre les deux navigateurs. Le rôle du serveur de signalisation se limite à relayer les messages d'établissement de connexion (les informations techniques SDP/ICE dont WebRTC a besoin pour établir un lien direct) afin que les deux appareils puissent se trouver ; il ne voit jamais le contenu des fichiers, leurs noms, ni les clés.
Quand une connexion directe n'est pas possible — les deux parties étant derrière des NAT ou des pare-feu restrictifs —, le flux chiffré bascule vers un serveur relais TURN plutôt que d'échouer purement et simplement. Le relais ne transmet que du chiffré ; il n'a pas de clé et ne peut pas déchiffrer ce qui le traverse. Ce qu'il fait, c'est compter les octets qu'il relaie au titre du quota mensuel de relais du compte expéditeur, uniquement à des fins de mesure et de prévention des abus — sans jamais inspecter ce qu'il contient.
Non. En mode temps réel, la clé de chiffrement est dérivée indépendamment sur les deux appareils et ne les quitte jamais — les serveurs de Relayium ne la voient jamais, pas plus que le contenu des fichiers. Pour les liens stockés, la clé ne vit que dans le fragment d'URL, que les navigateurs n'envoient jamais à un serveur, si bien que le serveur ne détient jamais que du chiffré qu'il ne peut pas déchiffrer.
En mode temps réel, uniquement les informations d'établissement de connexion nécessaires pour présenter deux appareils l'un à l'autre — jamais les octets du fichier. Pour les liens stockés, il voit du chiffré ainsi que des informations de gestion comme la taille et la date d'expiration — jamais le contenu en clair, les noms de fichiers, ni la clé de déchiffrement.
C'est un repli utilisé uniquement lorsqu'une connexion directe est impossible, et il ne traite toujours que du chiffré — il n'a pas de clé, donc il ne peut pas lire ce qu'il relaie. Relayium compte les octets relayés au titre du quota mensuel de votre compte, mais n'inspecte jamais leur contenu.
Oui. La conception du protocole et tout le code client et serveur sont publics sur GitHub sous licence MIT, si bien que la cryptographie décrite ici peut être auditée de façon indépendante plutôt que crue sur parole.
Arrêtez le transfert. Une différence signifie que la vérification « engagement puis révélation » a échoué, ce qui indique un homme du milieu potentiel plutôt qu'un simple incident bénin — ne poursuivez pas avant d'avoir compris pourquoi.
Curieux de voir à quoi cela ressemble en pratique ? Lancez un transfert et observez le code de vérification apparaître sous vos yeux.
Essayer Relayium maintenant