Dernière mise à jour: 2026-07-09
« Pair à pair » est une expression employée un peu librement, alors voici ce qu'elle signifie vraiment pour un transfert de fichiers : votre fichier va directement d'un appareil à l'autre, pas vers le serveur d'une entreprise puis à nouveau vers le bas. Aucune étape intermédiaire où une copie pourrait rester.
Cela paraît simple, mais Internet n'a pas été conçu pour que deux appareils quelconques se trouvent tout seuls et se parlent directement — la plupart des connexions se cachent derrière des routeurs et des pare-feu jamais prévus pour être atteints de l'extérieur. Cette page explique, en termes simples, comment une connexion directe s'établit réellement, quand elle ne le peut pas, et ce que cela signifie pour votre vie privée et la vitesse. Relayium sert d'exemple concret tout au long du texte, puisqu'il s'agit d'une implémentation fonctionnelle exactement de ce mécanisme.
La plupart des outils « envoyer un fichier » fonctionnent par téléversement : votre fichier part de votre appareil vers le serveur de l'entreprise, y est stocké, puis l'autre personne le télécharge à son tour. Cela fait deux sauts, et pendant un moment, une copie complète de votre fichier repose sur le stockage de quelqu'un d'autre — même si elle est supprimée par la suite.
Le transfert pair à pair supprime cette étape. Une fois qu'une connexion est ouverte entre votre appareil et celui de l'autre personne, les octets du fichier circulent directement sur ce seul saut, et nulle part ailleurs. Il n'y a pas de copie côté serveur à stocker, à sécuriser ou à finir par supprimer, puisqu'elle n'a jamais été téléversée en premier lieu.
Voici la partie qui n'est pas évidente : votre appareil ne connaît presque certainement pas sa propre adresse telle qu'elle est vue depuis l'Internet public — il se trouve derrière un routeur domestique ou la traduction d'adresse réseau (NAT) d'un opérateur mobile, qui le dissimule derrière une adresse IP publique partagée et réattribue les ports à la volée. L'autre appareil est dans la même situation. Aucun des deux ne peut simplement « composer » l'autre directement sans d'abord déterminer quelle adresse permettrait réellement de l'atteindre.
C'est à cela que sert STUN (Session Traversal Utilities for NAT). Chaque appareil pose brièvement une question à un serveur STUN léger : « depuis quelle adresse et quel port me vois-tu arriver ? » La réponse lui indique sa propre adresse visible de l'extérieur — ni fichier, ni contenu, juste assez d'information réseau pour décrire un chemin pour le rejoindre. Les deux appareils échangent cette information (via une étape de signalisation qui ne transporte que des détails d'établissement de connexion, jamais des octets de fichier), puis tentent d'ouvrir un chemin direct vers l'adresse de l'autre. Dans une large part des cas réels — en particulier deux appareils sur le même Wi-Fi, ou des NAT au comportement prévisible — cela fonctionne, et une connexion entièrement directe s'ouvre.
Parfois, STUN ne suffit pas. Certains NAT — en particulier sur des réseaux d'entreprise plus stricts ou chez certains opérateurs mobiles — sont suffisamment imprévisibles pour qu'aucun chemin direct ne puisse être découvert à partir des seules informations externes. Si les deux appareils se trouvent derrière ce genre de NAT, une connexion réellement directe est tout simplement impossible ; quelque chose doit relayer le trafic entre les deux.
C'est le rôle de TURN (Traversal Using Relays around NAT) : un serveur relais de secours auquel les deux appareils se connectent lorsqu'un chemin direct échoue. Ce n'est pas tant un contournement ou un compromis sur la vie privée qu'une nécessité liée à la façon dont certains réseaux sont construits — mais il vaut la peine d'être précis sur ce qu'il voit et ne voit pas. Chez Relayium, le fichier est déjà chiffré de bout en bout avant d'atteindre le relais, si bien que celui-ci ne transmet toujours que du chiffré — des données scellées dont il n'a pas la clé. Il déplace des octets ; il ne peut pas les lire.
L'argument de la vie privée est simple : quand les octets du fichier ne traversent qu'un seul saut, directement entre deux appareils, il n'existe aucune étape de stockage côté serveur où une copie pourrait rester, être journalisée ou être consultée par quelqu'un d'autre — parce qu'elle n'y a jamais été déposée. C'est une garantie structurellement différente d'un « nous promettons de la supprimer un jour ».
L'argument de la vitesse suit la même logique. Un transfert téléversement-puis-téléchargement doit traverser le réseau deux fois — une fois vers le haut, une fois vers le bas — et attend souvent que le côté émetteur ait entièrement terminé avant que le côté récepteur puisse commencer. Une connexion directe ne traverse le réseau qu'une seule fois, et les données peuvent circuler en continu entre les deux appareils, aussi vite que le permet la connexion la plus lente, sans serveur intermédiaire limitant le débit ou ajoutant sa propre latence.
Ouvrez relayium.com sur deux appareils du même réseau et ils se trouvent généralement automatiquement — pas de compte, pas de code, rien à installer ; c'est le cas du réseau local, où STUN n'est souvent même pas nécessaire. Pour envoyer sur Internet vers quelqu'un sur un autre réseau, on utilise un code de jumelage : l'expéditeur se connecte, génère un code (ou partage un lien, avec en option un QR code à scanner), et dès que l'autre personne rejoint, le même processus — STUN puis TURN si nécessaire — s'exécute pour ouvrir une connexion directe ou relayée ; le destinataire n'a besoin d'aucun compte, quel que soit le chemin emprunté.
Dans tous les cas, une fois la connexion ouverte, jusqu'à 1 000 fichiers d'un même lot circulent directement dessus, chacun vérifié indépendamment par un hachage SHA-256, afin que vous sachiez que ce qui est arrivé correspond exactement à ce qui a été envoyé. Si le temps réel n'est pas possible — par exemple si l'autre personne est hors ligne —, il s'agit d'un mode réellement différent (un lien stocké à connaissance nulle), pas de pair à pair, et cela vaut la peine d'être compris séparément.
Les deux sont liés mais pas identiques. Le P2P décrit le chemin réseau — des octets circulant directement entre deux appareils. Le chiffrement décrit si ces octets sont illisibles pour quiconque se trouverait entre les deux. Les transferts en temps réel de Relayium réunissent les deux : un chemin direct (ou relayé mais chiffré), avec un fichier scellé de bout en bout quel que soit le chemin emprunté.
Un petit serveur de signalisation aide les deux appareils à trouver l'adresse l'un de l'autre — mais il ne voit jamais que des informations d'établissement de connexion, jamais les octets du fichier. Si aucun chemin direct ne peut être trouvé, un relais TURN transmet les données de fichier chiffrées, mais même alors il ne traite que du chiffré qu'il ne peut pas déchiffrer.
Certains réseaux — souvent des pare-feu d'entreprise stricts ou certains NAT d'opérateurs mobiles — sont construits de façon à rendre impossible la découverte d'une adresse joignable à partir des seules informations externes. C'est plus rare que ça n'en a l'air, mais quand cela arrive, un relais permet au transfert de continuer à fonctionner plutôt que d'échouer purement et simplement.
Cela peut ajouter un peu de latence, puisque le relais est un saut supplémentaire que traversent les données, et qu'il s'agit d'un serveur partagé plutôt que dédié. Mais c'est généralement encore plus rapide qu'un flux téléversement-puis-téléchargement, car il n'y a pas d'attente que le fichier arrive entièrement sur un serveur avant que le côté téléchargement puisse démarrer.
Deux appareils sur le même réseau n'ont besoin d'aucun compte. Envoyer entre réseaux différents via un code de jumelage exige que l'expéditeur se connecte, mais la personne qui reçoit n'a jamais besoin de compte, quel que soit le chemin emprunté.
Curieux de voir l'effet que ça fait ? Ouvrez Relayium sur deux appareils et observez une connexion directe se former en temps réel.
Essayer Relayium maintenant