Transfert de fichiers en réseau local
Transférez fichiers et texte directement entre appareils sur le même réseau local via WebRTC — aucun serveur requis
Qu'est-ce que le transfert de fichiers en réseau local ?
Le transfert de fichiers LAN utilise WebRTC en pair à pair pour envoyer fichiers et texte entre deux appareils du même réseau local. Une fois la connexion établie, les données peuvent circuler directement entre les navigateurs sans être d’abord téléversées vers un service de stockage externe. C’est pratique pour des ordinateurs de bureau, appareils de test, réseaux domestiques, salles de classe, laboratoires et échanges rapides où une clé USB, un dossier cloud ou une pièce jointe de messagerie serait moins commode. La vitesse dépend du réseau, du navigateur et des appareils. Pour des fichiers sensibles, il faut vérifier le destinataire et fermer la session après transfert.
Comment utiliser
Comment utiliser
- Sur un appareil, cliquez sur « Créer une connexion » : le système génère un code QR contenant les informations de connexion
- Scannez le code QR avec un autre appareil : la page s'ouvre automatiquement et génère un code de réponse
- Scannez le code de réponse avec le premier appareil : la connexion WebRTC est établie
- Une fois connectés, les deux parties peuvent échanger des messages texte et tout type de fichiers
Conseils de transfert
- Gardez les deux appareils actifs et connectés à un réseau accessible pendant le transfert ; fermer l'onglet ou mettre l'appareil en veille interrompt la session WebRTC.
- Pour des fichiers très volumineux ou critiques, vérifiez le fichier téléchargé après le transfert, car la mémoire du navigateur, la qualité du réseau et les limites de l'appareil peuvent affecter la fiabilité.
Cas d’utilisation
Principe technique
Le transfert de fichiers en réseau local repose sur WebRTC (Web Real-Time Communication), la norme W3C/IETF définie dans les RFC 8825-8835, conçue à l'origine pour l'audio et la vidéo en temps réel dans le navigateur. Le même mécanisme pair à pair prend en charge l'API RTCDataChannel, qui transporte des charges utiles binaires arbitraires entre deux navigateurs sans aucun serveur relais dans le chemin de données. La signalisation qui ouvre le canal est ce que réalise la poignée de main par QR code : l'émetteur crée un bloc SDP (Session Description Protocol, RFC 8866) décrivant ses capacités multimédia et de données, l'encode dans une URL ou un QR code, et le destinataire renvoie un SDP en retour. Une fois que les deux parties ont appliqué la description distante, ICE (Interactive Connectivity Establishment, RFC 8445) collecte les adresses de transport candidates. Chaque candidat est un tuple (IP, port, protocole) associé à une priorité : les candidats host (l'IP locale de l'appareil sur le LAN) l'emportent généralement sur le même réseau, mais les candidats srflx (server-reflexive, appris via une requête STUN binding) et relay (relayés par TURN, RFC 8656) sont essayés par ordre de priorité. Les vérifications de connectivité envoient des requêtes STUN binding entre les candidats ; la première paire qui réussit devient la paire de candidats sélectionnée. Une fois qu'ICE atteint l'état connecté, DTLS (Datagram Transport Layer Security, RFC 6347, le cousin UDP-friendly de TLS 1.2/1.3 défini dans les RFC 5246/8446) authentifie les deux pairs via les empreintes de certificat présentes dans le SDP, en réalisant une poignée de main en un aller-retour. Les clés de session DTLS protègent ensuite chaque paquet SCTP (Stream Control Transmission Protocol, RFC 4960/RFC 9260) au-dessus, et chaque DataChannel est une paire de flux SCTP fonctionnant sur cette unique association DTLS. Les fichiers volumineux sont envoyés par morceaux via le DataChannel. La couche SCTP du navigateur fragmente chaque message en enregistrements d'environ 16 Ko (MTU SCTP par défaut moins la surcharge DTLS + SCTP + Chunk Header, et configurable selon l'implémentation, souvent 16 Ko ou 64 Ko selon le moteur), et le destinataire les réassemble dans l'ordre. Le contrôle de flux et de congestion (RFC 4960 §6) empêche l'expéditeur de submerger le destinataire : cwnd croît additivement sur les ACK et se réduit multiplicativement sur les pertes, la même forme que l'AIMD de TCP mais appliquée par association SCTP. Sur un LAN gigabit, le débit bout en bout est généralement limité à 200-400 Mo/s par le coût d'encodage du thread principal du navigateur (transformation de chaque morceau en vue ArrayBuffer et insertion dans la pile SCTP), et non par la vitesse du réseau. La page réassemble les morceaux entrants en un seul Blob et le propose au téléchargement, permettant à l'utilisateur de choisir où les octets seront enregistrés, ce qui évite au destinataire de conserver des gigaoctets en mémoire à pleine charge. Comme les données circulent en pair à pair avec un chiffrement de type DTLS-SRTP, les routeurs intermédiaires et tout serveur relais ne voient que du texte chiffré ; l'exploitant de la page ne voit jamais le texte en clair et il n'y a aucune étape de téléversement. Le compromis est la nécessité d'un serveur de signalisation pour échanger les SDP — cette page utilise les QR codes et les liens copier-coller comme canal de signalisation manuel et sans serveur, ce qui explique pourquoi deux scans sont nécessaires.
- WebRTC est une norme W3C/IETF (RFC 8825-8835) qui regroupe trois moteurs : SDP pour la négociation, ICE pour la collecte de candidats, et DTLS-SRTP / DTLS-SCTP pour la sécurité du transport.
- La poignée de main par QR code est une signalisation sans serveur : l'émetteur publie une offre SDP, le destinataire renvoie une réponse SDP, et aucun serveur central ne voit jamais le chemin de données.
- ICE (RFC 8445) collecte les candidats host, srflx (réflexif STUN), prflx (réflexif pair) et relay (TURN, RFC 8656) ; la paire de plus haute priorité qui réussit les vérifications de connectivité devient le transport sélectionné.
- DTLS (RFC 6347) effectue une poignée de main en un aller-retour vérifiée par empreinte utilisant les hachages de certificat ancrés dans le SDP, puis chiffre chaque octet sur le fil — aucun retour HTTP ou WebSocket en clair.
- DataChannel fonctionne sur SCTP-au-dessus-de-DTLS, pas en UDP brut : SCTP fournit des flux ordonnés, fiables et orientés message avec contrôle de congestion (RFC 4960 §6) au-dessus d'un socket UDP.
- La taille des morceaux est d'environ 16 Ko par défaut (selon le navigateur, parfois 64 Ko) : le destinataire réassemble les morceaux en un seul Blob et déclenche un téléchargement pour éviter de conserver l'intégralité du fichier en mémoire.
- La mémoire du navigateur est la vraie limite : un fichier de 1 Go représente environ 1 Go de consommation ArrayBuffer, donc sur mobile la limite pratique est généralement de 200-500 Mo par transfert, et non la vitesse du réseau.
- La traversée NAT de WebRTC nécessite un serveur STUN/TURN pour les pairs sur des réseaux différents ; cette page suppose une topologie sur le même LAN, donc les candidats host (IP locales) l'emportent généralement sans consulter de serveur STUN.
Exemples
Envoyer des photos du téléphone vers l'ordinateur
1. Sur l'ordinateur, cliquez sur « Créer une connexion » pour générer un QR code
2. Scannez-le avec le téléphone ; la page s'ouvre et produit un code de réponse
3. Scannez le code de réponse sur l'ordinateur pour finaliser la poignée de main
4. Sélectionnez les photos à envoyer et cliquez sur EnvoyerEnvoyer des fichiers de l'ordinateur vers le téléphone
Une fois la connexion établie, cliquez sur « Envoyer un fichier » sur l'ordinateur et choisissez un document, une archive ou une vidéo.
Le téléphone reçoit une invite et enregistre le fichier d'un simple appui.Échanger des messages texte
Une fois connectés, les deux côtés peuvent saisir du texte dans le champ et l'envoyer.
Aucune application supplémentaire requise — c'est une simple discussion bidirectionnelle dans le navigateur.FAQ
Comment le transfert de fichiers fonctionne-t-il ?
Deux appareils sur le même réseau local se connectent en pair-à-pair via WebRTC. Une fois la signalisation établie, les fichiers transitent directement entre les navigateurs — ils ne passent par aucun serveur intermédiaire. La vitesse dépend de votre réseau local (Wi-Fi ou Ethernet) ; un Wi-Fi typique délivre 30 à 150 Mbit/s.
Mes fichiers quittent-ils le réseau local ?
Une fois la connexion WebRTC établie, non — les octets des fichiers ne circulent qu'entre les deux appareils. Une petite étape de signalisation (échange des descriptions de session) passe par un serveur de coordination avant que la connexion ne soit en place ; cet échange contient des métadonnées, pas le contenu des fichiers.
Pourquoi les deux appareils ne se connectent-ils pas ?
Les deux appareils doivent être sur le même réseau Wi-Fi ou segment LAN. Les réseaux d'entreprise bloquent souvent les connexions pair-à-pair ; le Wi-Fi invité isole souvent les clients les uns des autres (« isolation client »). Essayez un Wi-Fi personnel ou un partage de connexion. Un VPN sur l'un des appareils peut aussi bloquer la connexion directe.
Y a-t-il une limite de taille de fichier ?
WebRTC n'a pas de limite protocolaire, mais les limites pratiques sont la mémoire du navigateur et la durée de vie de l'onglet. Les transferts de plusieurs Go fonctionnent en général sur les ordinateurs de bureau ; les navigateurs mobiles peuvent suspendre l'onglet et interrompre le transfert. Gardez les deux onglets au premier plan pendant les gros transferts.
Les fichiers transférés sont-ils chiffrés ?
Oui. Les canaux de données WebRTC utilisent un chiffrement DTLS-SRTP de bout en bout ; même un attaquant sur le même Wi-Fi ne peut lire le contenu du fichier. L'étape de signalisation utilise HTTPS vers le serveur de coordination. Considérez le transfert comme privé tant que les deux extrémités sont fiables.
Cela fonctionne-t-il pour des utilisateurs non techniques ?
Oui — partagez le code de salle ou l'URL avec l'autre personne ; elle l'ouvre dans son navigateur et la connexion s'établit automatiquement. Aucune installation d'application. L'interface ressemble à AirDrop sans la restriction de plateforme. Fonctionne entre iOS Safari, Android Chrome, Windows Edge, macOS Firefox, etc.
Puis-je envoyer à plusieurs appareils en même temps ?
La plupart des versions prennent en charge une salle un-à-un. Pour envoyer à plusieurs destinataires, répétez le transfert ou utilisez un outil de multidiffusion. Le transfert de groupe sur WebRTC est implémentable mais consomme N fois la bande passante d'envoi.