Comment fonctionne un transfert pair à pair, de navigateur à navigateur

2026-10-30·L’équipe Transferify

Dans un transfert instantané, le fichier va de votre navigateur au navigateur de votre destinataire. Il n’est pas envoyé d’abord quelque part, et il n’est jamais stocké sur nos serveurs. Notre service se contente de présenter les deux navigateurs l’un à l’autre. Le fichier est chiffré deux fois en route, circule sur plusieurs connexions à la fois pour aller plus vite, et c’est le navigateur du destinataire qui règle le rythme, pour qu’aucun des deux côtés ne manque de mémoire.

Cet article explique chacune de ces étapes. Pour la comparaison avec les transferts hébergés, voyez le pair à pair et les transferts hébergés.

Étape 1 : le lien est prêt avant tout envoi

Quand vous choisissez un transfert instantané, votre navigateur enregistre le transfert auprès de notre service : les détails des fichiers et les options que vous avez choisies. Aucun octet de fichier n’est envoyé. Une fois que le service a répondu, votre navigateur crée une nouvelle clé AES-256 pour ce transfert et l’ajoute au lien de partage après le « # ». Les navigateurs n’envoient cette partie d’un lien à aucun serveur : la clé n’atteint donc jamais notre service.

Le lien fonctionne tout de suite. Votre onglet détient désormais les fichiers et attend les destinataires.

Étape 2 : les deux navigateurs se mettent en relation

Quand votre destinataire ouvre le lien, son navigateur interroge d’abord notre service au sujet du transfert. Le service vérifie le lien : qu’il n’a pas expiré, que le mot de passe est correct si vous en avez défini un, et que sa limite de téléchargements n’est pas atteinte. Ce n’est qu’après ces vérifications qu’il indique au navigateur du destinataire quel navigateur contacter.

Deux navigateurs sur des réseaux différents ne peuvent pas simplement s’appeler. Ils échangent leurs informations de connexion par notre service de signalisation, qui relaie de courts messages entre eux par WebSocket. Ces messages décrivent comment se connecter. Ils ne contiennent ni données de fichier ni clé. Chaque navigateur détermine ensuite comment on peut le joindre :

• STUN. Des serveurs STUN publics indiquent à chaque navigateur son adresse telle que l’internet la voit, ce qui suffit pour la plupart des réseaux domestiques et de bureau.
• TURN, si nécessaire. Certains réseaux bloquent les connexions directes. Pour ceux-là, notre service crée à la demande des identifiants de relais, valables 24 heures et non en permanence, et la connexion passe par un relais TURN.

La récupération des identifiants de relais ne retient jamais longtemps un transfert : si elle prend plus de deux secondes, les navigateurs démarrent avec STUN seul, et les identifiants servent à la tentative de connexion suivante.

Un relais transmet le flux chiffré. Il ne peut pas le lire.

Étape 3 : chiffré deux fois

Chaque canal de données WebRTC est chiffré avec DTLS entre les deux navigateurs. Cela suffit déjà à protéger le fichier de quiconque observe le réseau, relais compris.

DTLS a pourtant une dépendance. Chaque navigateur prouve son identité par l’empreinte d’un certificat, et ces empreintes transitent par le service de signalisation. Un serveur de signalisation compromis pourrait les échanger et s’interposer, sans que DTLS le remarque.

Transferify ajoute donc sa propre couche. Votre navigateur scelle chaque bloc du fichier avec AES-256-GCM, avec la clé du lien, avant que le bloc entre dans la connexion. Le service de signalisation ne voit jamais cette clé. Un serveur placé au milieu ne verrait que des blocs chiffrés, et toute modification de sa part ferait échouer la vérification du destinataire. Chaque bloc est en outre lié à ce transfert, à ce fichier et à sa position : les blocs ne peuvent donc être ni réordonnés, ni supprimés, ni échangés avec ceux d’un autre fichier. Les détails sont dans comment Transferify chiffre vos fichiers dans votre navigateur.

Cette couche ne peut pas être désactivée. Si votre navigateur ne parvient pas à la mettre en place, le transfert ne démarre pas, et le navigateur d’un destinataire n’accepte que des blocs chiffrés.

Étape 4 : plusieurs connexions à la fois

Une seule connexion WebRTC utilise rarement une ligne rapide à fond, car chaque connexion augmente son débit d’envoi avec prudence, de son côté. Le navigateur du destinataire demande donc au vôtre de mener le transfert sur quatre connexions en parallèle, chacune avec sa propre route et son propre débit. Les deux navigateurs retiennent le plus petit des nombres que chaque côté autorise, sans jamais dépasser huit.

Votre navigateur répartit les blocs à tour de rôle sur les connexions, et celui du destinataire les remet dans l’ordre. Les connexions réussissent ou échouent ensemble : si l’une tombe, le transfert vers ce destinataire s’arrête dans son ensemble.

Étape 5 : le destinataire règle le rythme

Un réseau peut livrer des blocs plus vite qu’un disque lent ne peut les enregistrer. Sans limite, les blocs en attente s’accumuleraient dans la mémoire du destinataire jusqu’à ce que le navigateur abandonne.

À la place, le navigateur du destinataire accorde au vôtre un budget de 32 Mio de données chiffrées à la fois, et le renouvelle à mesure que les blocs sont déchiffrés et écrits. Votre navigateur n’envoie que tant qu’il lui reste du budget. Si le destinataire met le téléchargement en pause, votre navigateur attend simplement, et reprend à l’instant où le téléchargement avance de nouveau.

Du côté du destinataire, chaque bloc est déchiffré et vérifié à son arrivée, puis diffusé dans un téléchargement normal du navigateur par le gestionnaire de téléchargement propre au site, qui s’exécute dans le navigateur du destinataire : même un fichier très volumineux n’a donc jamais à tenir en mémoire. Si une vérification échoue, ce téléchargement est annulé plutôt qu’enregistré. Sur un navigateur où le gestionnaire de téléchargement n’est pas disponible, les fichiers jusqu’à 1 Gio sont assemblés en mémoire, et les plus volumineux ne peuvent pas y être reçus.

Étape 6 : vous voyez qui a le fichier

Quand le navigateur du destinataire a reçu un fichier en entier, il envoie à votre navigateur un accusé de réception. Votre page liste chaque destinataire qui a ouvert le lien et sa progression, et compte un fichier comme livré quand l’accusé du destinataire indique qu’il est arrivé en entier.

Plusieurs destinataires peuvent télécharger en même temps, chacun par ses propres connexions vers votre navigateur.

Ce qui met fin à un transfert

• Vous fermez l’onglet. Votre navigateur est l’endroit d’où le fichier est servi : le transfert s’arrête.
• Vous supprimez le transfert. Notre service le signale à votre onglet, qui ferme d’un coup les connexions de tous les destinataires. Le fichier circule depuis votre navigateur, pas depuis notre service : l’instruction doit donc parvenir à votre navigateur, et elle y parvient. La même chose se produit si nous suspendons un transfert à la suite de signalements d’abus.
• Le lien atteint sa date d’expiration. Les nouveaux destinataires ne peuvent plus l’ouvrir.

Quand l’utiliser

Les transferts instantanés conviennent aux gros fichiers quand vous pouvez garder l’onglet ouvert jusqu’à ce que votre destinataire les ait reçus. Si ce n’est pas possible, un transfert hébergé garde une copie chiffrée en ligne.

Essayez

Choisissez un fichier, optez pour un transfert instantané et envoyez le lien à un second appareil à vous : vous le verrez apparaître sur votre page et circuler. Lancez un transfert instantané.