Le transfert de fichiers WebRTC permet à deux navigateurs de s'envoyer un fichier sans le téléverser dans un stockage cloud. Cela paraît simple, mais internet n'a pas été conçu pour que deux ordinateurs domestiques s'appellent directement. Ce guide détaille ce qui se passe réellement — signalisation, NAT, STUN, ICE, TURN, DTLS et canaux de données — avec des mots simples, en prenant StrongFolder comme exemple.
Qu'est-ce que WebRTC ?
WebRTC (Web Real-Time Communication) est un ensemble d'API de navigateur et de protocoles réseau, standardisés par le W3C et l'IETF, pour des connexions en temps réel entre navigateurs. Chrome, Edge, Firefox, Safari et Opera le prennent tous en charge. Il a été conçu pour les appels vidéo et vocaux, mais il possède aussi des canaux de données qui transportent n'importe quelles données binaires — ce qu'est précisément un fichier.
La propriété essentielle : une fois une connexion WebRTC établie, les données circulent entre les deux extrémités, et non vers le stockage d'un serveur. C'est ce qui rend possible le transfert de fichiers P2P dans le navigateur.
Pourquoi deux navigateurs ne peuvent-ils pas simplement se connecter ?
Parce que presque aucun appareil n'a sa propre adresse publique. Votre portable se trouve derrière une box, un pare-feu de bureau ou le réseau d'un opérateur mobile. Le routeur effectue du NAT (traduction d'adresses réseau) : de nombreux appareils privés partagent une seule adresse IP publique, et le routeur ne laisse entrer que le trafic qui répond à quelque chose envoyé depuis l'intérieur.
Deux navigateurs font donc face à trois problèmes avant que la moindre donnée de fichier puisse circuler :
- Ils ne savent pas comment se joindre — aucun ne sait que l'autre existe.
- Ils ne connaissent pas leur propre adresse publique — seulement l'adresse privée, comme 192.168.1.20.
- Leurs routeurs peuvent bloquer le trafic entrant non sollicité.
WebRTC résout chaque problème avec un mécanisme distinct.
Comment se déroule un transfert de fichiers WebRTC, étape par étape ?
Voici le déroulement complet, du clic sur « partager » au dernier octet :
Sender browser Servers Recipient browser
────────────── ─────── ─────────────────
1. Choose files ──── metadata ──▶ Signaling server
◀──────── 2. Open link ────────
3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP)
4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?"
5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates
6. ICE checks: try LAN → direct internet → TURN relay
7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake
8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk
Étapes 1–2 — Signalisation. L'expéditeur choisit des fichiers ; le service enregistre les métadonnées nécessaires au lien. Quand le destinataire ouvre le lien, les deux navigateurs sont connectés à un serveur de signalisation. WebRTC ne définit pas le fonctionnement de la signalisation ; StrongFolder utilise PeerJS avec son propre serveur de signalisation.
Étape 3 — Offre et réponse. Un navigateur crée une offre en SDP (Session Description Protocol) : « Je veux un canal de données, voici mon empreinte de chiffrement et mes capacités. » L'autre répond par une réponse. Les deux passent par le serveur de signalisation.
Étape 4 — STUN. Chaque navigateur demande à un serveur STUN : « De quelle adresse et de quel port me vois-tu arriver ? » La réponse est son adresse publique telle que le routeur l'a traduite. Les serveurs STUN traitent une toute petite requête et aucune donnée de fichier ; StrongFolder utilise des serveurs STUN publics, dont ceux de Google, ainsi que les siens.
Étape 5 — Candidats ICE. Chaque navigateur rassemble des candidats — des façons possibles de le joindre : son adresse sur le réseau local (host), son adresse publique obtenue via STUN (server-reflexive) et une adresse sur un relais TURN (relayed). Ils échangent leurs candidats via la signalisation.
Étape 6 — Tests de connectivité. ICE (Interactive Connectivity Establishment) teste les paires de candidats et choisit la meilleure qui fonctionne. Si les deux appareils sont sur le même Wi-Fi, un chemin local l'emporte. Si les routeurs le permettent, un chemin direct par internet (« hole punching ») l'emporte. Si rien de direct ne fonctionne, le chemin relayé est utilisé.
Étape 7 — DTLS. Avant que la moindre donnée circule, les navigateurs effectuent une poignée de main DTLS (TLS adapté à UDP) et vérifient que les empreintes des certificats correspondent à celles de l'offre et de la réponse. À partir de là, tout est chiffré.
Étape 8 — Canal de données. Au-dessus de DTLS fonctionne SCTP, qui assure au canal de données une livraison fiable et ordonnée. Dans StrongFolder, le navigateur du destinataire demande un fichier, le navigateur de l'expéditeur le lit sur le disque par morceaux et les envoie, et le destinataire écrit chaque morceau sur le disque dès son arrivée — ainsi, même les très gros fichiers n'ont jamais besoin de tenir en mémoire.
Que signifient STUN, TURN, ICE et les autres termes ?
| Terme | Rôle | Voit les données du fichier ? | Standard |
|---|---|---|---|
| Signalisation | Fait passer offres, réponses et candidats entre navigateurs | Non | Non standardisée (propre à chaque application) |
| NAT | Fonction du routeur qui partage une IP publique entre de nombreux appareils | — | — |
| STUN | Indique à un navigateur son adresse et son port publics | Non | IETF RFC 8489 |
| ICE | Rassemble les candidats et choisit un chemin qui fonctionne | Non | IETF RFC 8445 |
| TURN | Relaie le trafic quand aucun chemin direct ne fonctionne | Uniquement des paquets chiffrés | IETF RFC 8656 |
| DTLS | Chiffre la connexion (TLS pour UDP) | Il les chiffre | IETF RFC 9147 (1.3), RFC 6347 (1.2) |
| Canal de données SCTP | Livraison fiable et ordonnée des morceaux | Il les transporte (chiffrées) | IETF RFC 8831 |
Tous ces termes sont expliqués brièvement dans le glossaire.
Quand un relais TURN est-il utilisé, et que voit-il ?
Le relais est la solution de secours, pas la règle. ICE ne l'utilise que lorsqu'aucune paire de candidats directe ne se connecte — typiquement sur les réseaux à NAT symétrique (certains opérateurs mobiles), derrière des pare-feu d'entreprise qui bloquent l'UDP sortant, ou avec certains VPN.
Si une connexion directe est impossible (pare-feu d'entreprise strict, certains réseaux mobiles), le flux chiffré passe par un serveur relais (TURN) de StrongFolder. Le relais transmet les données et ne les stocke pas.
Le relais reçoit des paquets chiffrés en DTLS et les transmet. Il peut voir qu'un trafic circule, en quelle quantité et à quel moment — pas ce qu'il contient. Un transfert relayé peut être plus lent qu'un transfert direct, car chaque octet fait un détour par le relais. Si un transfert est anormalement lent, essayez un autre réseau : un partage de connexion depuis un téléphone ou le Wi-Fi de la maison se connectent souvent en direct là où un réseau de bureau n'y parvient pas.
Gratuit · dans votre navigateur · sans inscription
Le chiffrement WebRTC est-il sûr ?
WebRTC rend le chiffrement obligatoire : il est impossible d'ouvrir un canal de données non chiffré. DTLS utilise des algorithmes de chiffrement modernes négociés par les deux navigateurs, et de nouvelles clés sont créées pour chaque connexion.
Une réserve honnête s'applique à tous les services WebRTC. Les deux navigateurs se vérifient mutuellement grâce à des empreintes de certificat échangées via le serveur de signalisation. Vous faites donc confiance à la signalisation du service pour ne pas les altérer. C'est pourquoi StrongFolder décrit sa protection comme un chiffrement en transit — et non comme un chiffrement de bout en bout avec des clés que vous détenez, ni comme du « zero-knowledge ». Pour une vue plus large de ce que « sécurisé » veut dire, lisez Partage de fichiers sécurisé et Sécurité et confidentialité.
Pourquoi le navigateur de l'expéditeur doit-il rester ouvert ?
Parce que le navigateur de l'expéditeur est la source. Il n'y a pas de copie sur un serveur sur laquelle se rabattre : le canal de données ne lit les morceaux sur le disque de l'expéditeur que tant que l'onglet est ouvert et que l'appareil est actif. L'onglet du navigateur de l'expéditeur doit rester ouvert et en ligne jusqu'à ce que le destinataire ait fini de télécharger — les fichiers viennent de l'appareil de l'expéditeur, pas d'un serveur. La façon de s'organiser en conséquence est expliquée dans Pourquoi l'expéditeur reste en ligne.
Quelle est la vitesse du transfert de fichiers WebRTC ?
Il n'y a pas de vitesse fixe. Le plafond est le maillon le plus lent du chemin : généralement le débit montant de l'expéditeur. En ordre de grandeur, 1 Go prend environ 2,7 minutes à 50 Mbit/s, environ 80 secondes à 100 Mbit/s, et bien moins d'une minute sur un réseau local rapide. Les transferts réels sont un peu en dessous de ces chiffres à cause du surcoût des protocoles, de la vitesse des disques et, avec un relais, du détour supplémentaire. Un même lien peut être ouvert par plusieurs destinataires ; chacun télécharge directement depuis l'expéditeur. Plusieurs téléchargements simultanés se partagent le débit montant de l'expéditeur.
En résumé
Un transfert de fichiers WebRTC, c'est une courte négociation suivie d'un long flux chiffré : la signalisation présente les navigateurs, STUN et ICE trouvent un chemin à travers le NAT, TURN relaie en dernier recours, et des canaux de données chiffrés en DTLS transportent le fichier de disque à disque. Pour le côté pratique — ce que cela implique pour vous en tant qu'expéditeur —, commencez par le transfert de fichiers P2P dans le navigateur et Comment fonctionne StrongFolder.