Qu'est-ce que le transfert de fichiers pair à pair ?

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

« 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, et non vers le serveur d'une entreprise avant d'en redescendre. Aucune étape intermédiaire où une copie pourrait rester.

Cela paraît simple, mais les chemins réels diffèrent. Cette page explique d'abord le WebRTC/ICE général, où TURN peut servir de secours, puis distingue l'implémentation de Relayium : WebRTC navigateur est direct sur le même LAN, TURN est utilisé par conception entre réseaux, et le CLI est direct-only.

P2P contre la méthode habituelle : supprimer l'étape intermédiaire

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.

Transfert par téléversement : votre appareil vers un serveur vers l'appareil de l'autre — deux sauts, une copie stockée entre les deux.
Transfert pair-à-pair : votre appareil directement vers l'appareil de l'autre — un seul saut, rien de stocké.
Le mode navigateur temps réel de Relayium a deux voies : WebRTC est direct sur le même LAN ; entre réseaux, TURN transporte par conception du texte chiffré de bout en bout, sans copie ni historique de contenu côté serveur.

Comment deux appareils se trouvent réellement : STUN

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 voyez-vous 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.

STUN n'apprend et ne partage jamais que des adresses réseau — jamais le contenu des fichiers, leurs noms, ni les clés de chiffrement.
Relayium utilise WebRTC directement pour les sessions navigateur sur le même LAN. La voie navigateur entre réseaux est délibérément relayée.
Les commandes send/receive et text du CLI Relayium sont P2P et direct-only : aucun octet de fichier ou de message ne transite par TURN ni par un autre serveur Relayium. Si les deux extrémités ne peuvent pas établir de connexion directe, la session échoue au lieu de se rabattre sur un relais.
Deux appareils sur le même réseau (aucun code requis) se connectent généralement le plus directement de tous, car il n'y a souvent aucun NAT en travers du chemin.

Quand aucun chemin direct ne peut être trouvé : le relais TURN

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.

Dans une conception WebRTC/ICE générale, TURN peut être le relais de secours lorsqu'un chemin direct échoue. L'application navigateur Relayium choisit explicitement WebRTC direct sur le même LAN et TURN dès le départ pour toutes les sessions entre réseaux. Le fichier est déjà chiffré de bout en bout : le relais ne transporte que du texte chiffré et ne peut ni lire ni déchiffrer le contenu.

Sur le même réseau, Relayium relie les appareils directement ; entre réseaux, il utilise le relais TURN par défaut, car un chemin direct y est si souvent introuvable.
Le relais ne transmet que du texte chiffré ; il ne possède jamais la clé de déchiffrement et ne peut lire ni le contenu des fichiers, ni leurs noms, ni rien d'autre à leur sujet.
Les commandes send/receive et text du CLI Relayium sont P2P et direct-only : aucun octet de fichier ou de message ne transite par TURN ni par un autre serveur Relayium. Si les deux extrémités ne peuvent pas établir de connexion directe, la session échoue au lieu de se rabattre sur un relais.

Pourquoi cela compte : vie privée et vitesse

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.

Comment Relayium assemble tout cela

Ce qu'il vous faut pour le vérifier vous-même

Deux appareils que vous pouvez regarder en même temps — un portable et un téléphone sont l'idéal.
Un petit fichier. Ce qui compte ici, c'est le chemin que prend la connexion, pas le débit.
Un moment avec les deux sur le même Wi-Fi, et un moment sur des réseaux différents — couper le Wi-Fi du téléphone pour passer en données mobiles suffit.

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 d'appairage : 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 transfert passe par un relais TURN chiffré — la voie fiable à travers des NAT imprévisibles, et il ne transporte que du texte chiffré ; le destinataire n'a toujours besoin d'aucun compte.

Une fois la voie temps réel ouverte, jusqu'à 1 000 fichiers circulent en continu sur la route choisie, chacun vérifié par SHA-256. Relayium ne conserve aucune copie de contenu ni aucun historique temps réel côté serveur. Si l'autre personne est hors ligne, le lien stocké à divulgation nulle est un mode distinct.

Les deux appareils sur le même Wi-Fi, ouvrez Relayium sur chacun et envoyez le fichier.
```
https://relayium.com/
```
Lisez l'étiquette que l'application donne à la connexion. Sur un même réseau, elle indique LAN direct.
Mettez maintenant les deux appareils sur des réseaux différents et renvoyez, cette fois avec un code d'appairage.
```
https://relayium.com/cross-network
```
Relisez l'étiquette. P2P direct signifie qu'un chemin direct a été trouvé à travers Internet. Relais signifie qu'il n'y en avait pas, et que le relais chiffré a transporté les octets.
Notez ce que vous avez obtenu, et sur quelle paire de réseaux. C'est votre propre réponse à la question posée en ouverture de cet article, plutôt que la nôtre.

Ce que les étiquettes vous apprennent

Sur un même réseau, vous obtenez LAN direct. D'un réseau à l'autre, vous obtenez soit P2P direct, soit Relais, et laquelle des deux dépend des deux réseaux et non de quelque chose que vous auriez configuré.

Relais n'est pas un échec. C'est le repli qui existe et qui fait son travail, et le relais ne transporte jamais que du chiffré — c'est exactement le cas décrit par la section TURN de cet article, vu de l'intérieur.

Quand l'étiquette n'est pas celle attendue

Trois choses surprennent la première fois. Aucune n'est un défaut à corriger, mais chacune mérite qu'on sache la nommer.

Ce que vous voyez, ce qu'il faut vérifier, ce que cela signifie

D'un réseau à l'autre, c'est toujours Relais, jamais P2P direct.

https://relayium.com/cross-network   # the path label reads the same on both ends

Vérifiez si les deux extrémités sont en données mobiles ou derrière un NAT d'opérateur, la raison habituelle pour laquelle aucun chemin direct n'existe. Il n'y a rien à corriger : c'est le repli prévu, le relais ne transporte que du chiffré, et ces mêmes deux appareils continuent de passer en direct, et gratuitement, sur un même réseau.

Sur un même Wi-Fi, LAN direct n'apparaît jamais.

https://relayium.com/   # both devices on one Wi-Fi, and the path label never says LAN direct

Vérifiez si le réseau isole ses clients : les Wi-Fi invités, ainsi que beaucoup de réseaux d'hôtel et de bureau, bloquent purement et simplement le trafic entre appareils. Là, les deux appareils ne se voient pas du tout ; utilisez donc l'appairage entre réseaux, qui ne dépend pas de leur capacité à se joindre localement.

Il n'y a aucune étiquette de chemin.

https://relayium.com/   # there is no path label until the two ends have connected

L'étiquette nomme une connexion : elle apparaît donc dès qu'il y en a une. Tant que les deux extrémités ne se sont pas trouvées, il n'y a rien à nommer — et un transfert qui ne démarre jamais est un problème différent d'un transfert qui a pris un chemin inattendu.

Questions fréquentes

Le pair-à-pair est-il la même chose que le chiffrement de bout en bout ?

Les deux sont liés mais pas identiques. Le P2P décrit la communication entre terminaux sans garantir que chaque saut réseau soit direct ; TURN peut transporter le trafic. Le chiffrement détermine si un intermédiaire peut le lire. Relayium utilise WebRTC direct sur le même LAN et TURN chiffré de bout en bout entre réseaux, que le relais ne peut ni lire ni déchiffrer.

Un transfert P2P touche-t-il quand même un serveur ?

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. Entre réseaux différents, dans le navigateur, un relais TURN transmet par conception les données de fichier chiffrées, mais même alors il ne traite que du texte chiffré qu'il ne peut pas déchiffrer.

Pourquoi une connexion directe échouerait-elle en premier lieu ?

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. Plutôt que de passer une vingtaine de secondes à le découvrir à chaque transfert, l'application web de Relayium fait passer d'emblée tous les transferts entre réseaux par le relais — c'est donc le relais, et non une tentative directe échouée, qui les achemine.

Un transfert P2P est-il plus lent quand il passe par un relais ?

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.

Les deux personnes ont-elles besoin d'un compte pour un transfert P2P ?

Deux appareils sur le même réseau n'ont besoin d'aucun compte. Envoyer entre réseaux différents via un code d'appairage 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 ? Ouvrez Relayium sur deux appareils et démarrez une session temps réel chiffrée.

Essayer Relayium maintenant