# Comment fonctionne le transfert de fichiers WebRTC Source: https://help.strongfolder.com/fr/guides/how-webrtc-file-transfer-works/ Updated: 2026-11-05 > Le transfert de fichiers WebRTC se déroule en trois phases. Un serveur de signalisation présente deux navigateurs l'un à l'autre ; STUN et ICE trouvent un chemin réseau à travers les box et routeurs (NAT), avec un relais TURN en secours si aucun chemin direct n'existe ; puis les navigateurs ouvrent un canal de données chiffré en DTLS et transmettent le fichier par morceaux, en direct ou via le relais, sans le stocker. 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. **Key facts** - **WebRTC** est un standard des navigateurs pour des connexions directes et chiffrées entre deux appareils ; les outils de fichiers utilisent ses **canaux de données**. - La **signalisation** présente les navigateurs ; **STUN** et **ICE** trouvent un chemin à travers les routeurs (**NAT**) ; un **relais TURN** transmet le trafic quand aucun chemin direct n'existe. - **Chiffrement :** chaque canal de données utilise **DTLS** — WebRTC n'a pas de mode non chiffré. - StrongFolder utilise PeerJS au-dessus de WebRTC, un serveur de signalisation StrongFolder, des serveurs STUN publics (dont ceux de Google) et ses propres relais TURN. Les fichiers ne sont jamais téléversés ni stockés sur un serveur StrongFolder. - Le fichier est transmis par morceaux du disque de l'expéditeur au disque du destinataire ; l'expéditeur reste en ligne. ## Qu'est-ce que WebRTC ? [WebRTC](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/guides/p2p-file-transfer/). ## 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](https://help.strongfolder.com/en/glossary/#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 : 1. Ils ne savent pas **comment se joindre** — aucun ne sait que l'autre existe. 2. Ils ne connaissent pas **leur propre adresse publique** — seulement l'adresse privée, comme 192.168.1.20. 3. 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](https://help.strongfolder.com/en/glossary/#signaling). 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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/#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](https://help.strongfolder.com/en/glossary/). ## 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. [Envoyer des fichiers](https://strongfolder.com) ## 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é](https://help.strongfolder.com/en/guides/secure-file-sharing/) et [Sécurité et confidentialité](https://help.strongfolder.com/en/security/). ## 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](https://help.strongfolder.com/en/guides/why-sender-stays-online/). ## 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](https://help.strongfolder.com/en/guides/p2p-file-transfer/) et [Comment fonctionne StrongFolder](https://help.strongfolder.com/en/how-it-works/). ## FAQ ### Qu'est-ce qu'un canal de données WebRTC ? Un canal de données est la partie de WebRTC qui transporte des octets quelconques entre deux navigateurs, au lieu de l'audio ou de la vidéo. Il repose sur SCTP au-dessus de DTLS au-dessus d'UDP : il est donc chiffré et peut être configuré pour une livraison fiable et ordonnée — ce dont le transfert de fichiers a besoin. ### Quelle est la différence entre STUN et TURN ? Un serveur STUN indique seulement à un navigateur à quoi ressemble son adresse publique, pour que les deux navigateurs puissent tenter de se connecter directement ; aucune donnée de fichier n'y transite. Un serveur TURN est un relais : quand aucun chemin direct ne fonctionne, le flux chiffré passe par lui. StrongFolder exploite ses propres relais TURN, qui transmettent les données sans les stocker. ### Le serveur de signalisation voit-il mes fichiers ? Non. Le serveur de signalisation ne fait passer entre les navigateurs que des messages de connexion — descriptions de session et candidats réseau. Les données des fichiers circulent sur le canal de données, en direct ou via un relais TURN. ### Le transfert de fichiers WebRTC est-il chiffré ? WebRTC chiffre chaque canal de données avec DTLS : le flux de fichiers est donc chiffré pendant le transfert, sur chaque connexion. WebRTC n'autorise pas de canaux de données non chiffrés. Les clés sont négociées par les deux navigateurs ; leurs empreintes passent par la signalisation, c'est pourquoi il s'agit d'un chiffrement en transit et non d'un chiffrement de bout en bout avec des clés que vous gérez. ### Pourquoi un transfert WebRTC échoue-t-il parfois ou reste-t-il lent ? Généralement à cause du chemin réseau : un pare-feu strict ou un VPN bloque l'UDP direct, la connexion se rabat alors sur un relais TURN en TCP, ou ne s'établit pas du tout. Essayez un autre réseau (par exemple un partage de connexion depuis un téléphone), désactivez le VPN, ou demandez au service informatique d'autoriser WebRTC. ### Un relais TURN peut-il lire mes fichiers ? Le relais transmet des paquets chiffrés en DTLS entre les deux navigateurs. Il voit du trafic chiffré, des tailles et des horaires, pas le contenu des fichiers, et le relais de StrongFolder ne stocke pas ce qu'il transmet.