Transfert chiffré pair à pair : guide technique
Construisez des systèmes de transfert de fichiers chiffré pair à pair : traversée NAT, serveurs de signalisation et chiffrement de bout en bout.
Le transfert de fichiers pair à pair envoie les octets directement entre deux navigateurs ou appareils sans que le fichier ne transite jamais par un serveur. WebRTC, standardisé dans les RFC 8825 à 8837, fournit le transport : canaux de données chiffrés sur UDP avec DTLS 1.3, traversée NAT via ICE, STUN et TURN, et signalisation sur WebSocket ou HTTP. Des outils comme Snapdrop, Wormhole.app et Magic Wormhole prouvent que le modèle fonctionne. Pour les organisations soumises au RGPD et aux recommandations de l'ANSSI, l'attrait est réel : aucun fichier ne transite par un serveur tiers, aucune donnée ne réside dans un pays tiers. Voici comment construire ce type de système : la poignée de main de signalisation, les pièges de la traversée NAT, la couche de chiffrement et ce qu'on gagne ou perd par rapport aux services de relais cloud.
Pourquoi le P2P pour le transfert de fichiers
L'attrait est simple : aucun serveur ne stocke votre fichier, pas de facture de bande passante pour le service de transfert, et l'envoi de l'expéditeur est directement le téléchargement du destinataire sans copie intermédiaire. Pour un transfert de 10 Go entre deux utilisateurs sur le même réseau gigabit local, le P2P peut se terminer en 80 secondes, tandis qu'un relais cloud uploaderait vers un serveur distant puis retéléchargerait, doublant l'utilisation de la bande passante et la latence. La confidentialité est aussi un argument : les octets du fichier n'existent que sur les appareils de l'expéditeur et du destinataire. Les compromis : les deux parties doivent être en ligne simultanément, la traversée NAT échoue parfois, et la connexion est aussi rapide que le lien d'upload du participant le plus lent.
Les canaux de données WebRTC comme transport
WebRTC a démarré comme protocole vidéo/audio, mais RTCDataChannel offre un transport binaire arbitraire avec livraison soit fiable ordonnée (comme TCP) soit non fiable non ordonnée (comme UDP). Sous le capot, les canaux de données fonctionnent sur SCTP sur DTLS 1.3 sur UDP. La couche DTLS assure confidentialité et intégrité authentifiée via AES-128-GCM ou ChaCha20-Poly1305, négociés lors de la poignée de main. Pour le transfert de fichiers, créez un canal fiable ordonné, découpez le fichier en messages de 16 Ko à 64 Ko (Chrome a historiquement limité la taille des messages à 256 Ko) et envoyez-les séquentiellement avec contrôle de flux via le seuil bufferedAmount.
Le rôle du serveur de signalisation
WebRTC a besoin d'un serveur de signalisation pour échanger les informations de connexion (offres et réponses SDP, candidats ICE) entre les pairs. Le serveur de signalisation ne relaie pas les octets de fichier, seulement environ 5 Ko de métadonnées de connexion. Un service de signalisation basé sur WebSocket en Node.js, Python ou Go gère cela en quelques centaines de lignes de code. Firebase Realtime Database, Supabase Realtime et Pusher fonctionnent tous comme backends de signalisation. Le serveur de signalisation voit qui parle à qui et quand, mais jamais le contenu des fichiers. La plupart des services de transfert de fichiers P2P font tourner leur signalisation gratuitement car la bande passante est dérisoire.
Traversée NAT : STUN, TURN et ICE
La plupart des appareils se trouvent derrière du NAT, rendant les connexions IP directes impossibles. ICE (Interactive Connectivity Establishment, RFC 8445) essaie plusieurs chemins de connexion. STUN (RFC 8489) permet à un pair de découvrir son IP et port publics via un serveur STUN public ; Google gère stun.l.google.com gratuitement. Si les deux pairs ont des NAT raisonnables (full-cone ou restricted-cone), la connexion UDP directe fonctionne dans peut-être 70 % des tentatives. Pour les NAT symétriques, les pare-feux d'entreprise et le CGNAT, TURN (RFC 8656) relaie le trafic via un serveur. Les serveurs TURN sont coûteux car ils transportent les octets réels du fichier. Le coturn auto-hébergé, twilio.com/stun, ou Cloudflare Calls offrent des options. Attendez-vous à 10 à 30 % des transferts P2P tombant en repli vers TURN en conditions réelles.
Couche de chiffrement au-dessus de DTLS
DTLS chiffre déjà les données WebRTC, donc un chiffrement supplémentaire au niveau applicatif est une mesure de ceinture et bretelles. La poignée de main DTLS authentifie les certificats des pairs, mais WebRTC utilise typiquement des certificats auto-signés qui ne vérifient pas l'identité — ils vérifient que la connexion se fait avec le même pair qui a signé le SDP. Le chiffrement de bout en bout au niveau applicatif avec AES-256-GCM et un secret partagé dérivé du rendez-vous de signalisation ajoute une garantie d'identité. Le SPAKE2 PAKE (Password-Authenticated Key Exchange) de Magic Wormhole dérive une clé forte à partir d'une phrase courte lisible par un humain, de sorte que même un serveur de signalisation compromis ne peut pas déchiffrer.
Stratégie de découpage pour le transfert P2P
Les canaux de données WebRTC ont une limite de taille de message (256 Ko dans la plupart des navigateurs, avec une fragmentation des messages plus grands qui fonctionne mais est peu fiable). Découpez les fichiers en messages de 16 Ko à 64 Ko par message pour la compatibilité. Suivez la quantité mise en mémoire tampon via bufferedAmount et bufferedAmountLowThreshold pour implémenter le contrôle de flux : pausez l'envoi quand le tampon dépasse 1 Mo, reprenez quand il descend sous 256 Ko. Pour l'intégrité, hachez chaque chunk avec SHA-256 et incluez le hachage dans un manifeste envoyé en premier. Le récepteur réassemble, vérifie les hachages et écrit sur le disque via l'API File System Access ou un téléchargement Blob.
Considérations mobiles et multi-appareils
Le P2P bureau-à-bureau fonctionne bien. Mobile-à-bureau introduit des complications : les navigateurs mobiles appliquent une suspension agressive des onglets, donc l'expéditeur doit garder l'onglet du navigateur au premier plan. L'implémentation du canal de données dans iOS Safari a historiquement été moins fiable que Chromium. Les uploads en arrière-plan sur mobile nécessitent des implémentations basées sur des applications natives. L'impact sur la batterie compte aussi : les sessions WebRTC soutenues déchargent les batteries plus vite que les téléchargements HTTPS. Pour les transferts mobile-à-mobile sur le même Wi-Fi, AirDrop (iOS/macOS) et Nearby Share (Android) surpassent le P2P navigateur en utilisant des protocoles d'appareils directs.
Découverte de pairs sans comptes centraux
Comment deux inconnus se connectent-ils sans système basé sur les comptes ? Plusieurs schémas fonctionnent. Un court code comme le « 4-truck-roger » de Magic Wormhole sert à la fois d'adresse de rendez-vous et de mot de passe ; le serveur de signalisation mappe les codes aux sessions. Les QR codes encodant une URL de session fonctionnent pour les transferts en personne. Le tap NFC sur Android connecte par proximité. Pour les réseaux plus grands, une DHT comme la Mainline DHT de BitTorrent peut amorcer la découverte de pairs sans serveur central, mais les recherches DHT prennent des secondes et ne conviennent pas au partage occasionnel de fichiers.
Menaces de sécurité spécifiques au P2P
Le P2P introduit des menaces que les relais cloud n'ont pas. La divulgation d'adresse IP : les connexions directes révèlent l'IP publique de chaque pair à l'autre, pouvant potentiellement désanonymiser des utilisateurs dans des contextes sensibles à la vie privée (lanceurs d'alerte, activisme). Certains services P2P forcent le relais TURN pour cacher les IP au détriment des performances. La distribution de malwares est plus difficile à modérer car l'opérateur du service ne voit jamais le contenu des fichiers. Le déni de service par épuisement des connexions sur le serveur de signalisation nécessite une limitation de débit.
Quand le relais cloud l'emporte
Pour les transferts asynchrones où l'expéditeur et le destinataire ne sont pas en ligne simultanément, le P2P échoue complètement — il n'y a aucun pair pour recevoir. Pour les grands transferts qui dépassent la fenêtre de session (les onglets de navigateur mobile se ferment, les ordinateurs portables se mettent en veille), le modèle « upload et partage d'un lien » du relais cloud est simplement plus pratique. Pour la distribution un-vers-plusieurs, un seul upload avec distribution CDN bat N sessions P2P simultanées. HexaTransfer utilise le modèle de relais cloud avec chiffrement de bout en bout côté client AES-256-GCM, obtenant l'essentiel des avantages de confidentialité du P2P avec un bien meilleur support asynchrone et multi-destinataires.
Essayez-le sur https://hexatransfer.com — gratuit, sans compte, 10 Go maximum.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier