Correction de vitesse lente : diagnostiquer les problèmes
Diagnostiquez et corrigez les vitesses de transfert lentes. Dépannage étape par étape des problèmes réseau, navigateur et goulots côté service.
Pour corriger un upload lent, diagnostiquez dans l'ordre : mesurez la connexion brute avec speedtest-cli, comparez-la au débit réel de l'outil de transfert dans les DevTools, vérifiez les synchros en arrière-plan qui consomment de la bande passante, vérifiez que le service ne bride pas par transfert, et confirmez que vous êtes sur l'endpoint régional le plus proche. Une ligne à 500 Mbps qui délivre 40 Mbps à un service de transfert, c'est soit de la contention de bande passante, soit un mismatch de région CDN, soit du bridage serveur, soit un goulot mono-flux. Chacun a une correction différente, et tous se montrent dans l'onglet Network des DevTools avant que vous fassiez quoi que ce soit d'autre.
Mesurez le tuyau en premier
Avant de blâmer le service de transfert, confirmez que votre connexion délivre vraiment ce que vous croyez. Lancez speedtest-cli --json depuis un terminal, ou speedtest.net dans le navigateur. Notez les Mbps en upload, la latence et la gigue. C'est votre plafond. Si votre connexion « 500 Mbps » ne délivre que 80 Mbps en upload sur speedtest, aucun service de transfert ne fera mieux.
Lancez le test deux fois, une fois en Wi-Fi et une fois en Ethernet si possible. L'écart vous indique ce que votre Wi-Fi vous coûte. En Wi-Fi 5 dans un foyer moyen, comptez perdre 30 à 50 % du plafond filaire.
Comparez speedtest au débit réel du transfert
Ouvrez le service de transfert, démarrez l'upload, et ouvrez DevTools > onglet Network. Regardez le débit individuel des requêtes. Si speedtest indique 500 Mbps et que le transfert délivre 150 Mbps, l'écart a quatre causes probables : le service utilise un seul flux (ne peut pas saturer un tuyau à forte latence), l'endpoint CDN du service est loin de vous, des consommateurs de bande passante en arrière-plan volent du débit, ou le service rate-limite par transfert.
Les uploaders chunked parallèles (services basés sur tus.io, multipart S3, HexaTransfer) devraient lancer 4 à 8 requêtes concurrentes. Comptez-les dans le waterfall. Moins que ça sur une ligne rapide signifie que le service laisse de la bande passante inutilisée.
Éliminez les synchros en arrière-plan
Le Moniteur d'activité de macOS (onglet Réseau, tri par « Octets envoyés par sec ») et le Moniteur de ressources Windows (onglet Réseau) montrent la bande passante par processus. Coupables probables : Dropbox, Google Drive, OneDrive, iCloud Photos, Backblaze, Time Machine via réseau, synchro Adobe Creative Cloud. Quittez-les — ne mettez pas juste en pause, car la pause garde parfois les connexions TCP ouvertes.
Un appel Zoom HD utilise 2,5 Mbps en montant. Un upload YouTube en 4K depuis un autre onglet peut consommer 20 Mbps. Même les aperçus de fichiers Slack poussent quelques centaines de Ko/s. Sur des connexions asymétriques (100 Mbps en descendant, 10 Mbps en montant est un forfait câble courant), ça s'additionne vite.
Vérifiez l'endpoint régional
Beaucoup de services de transfert routent via des edges CDN. Si votre DNS ou GeoIP est périmé, vous pourriez uploader vers un edge à Francfort depuis Sydney, ce qui ajoute 300 ms d'aller-retour et écrase le débit mono-flux. Vérifiez l'IP de l'endpoint avec le panneau Network des DevTools (clic droit sur la requête > Copier > Copier l'URL, puis nslookup), puis faites un ping pour voir la latence.
Latence idéale vers l'ingestion d'un service de transfert : sous 20 ms pour la même ville, sous 50 ms pour le même continent, sous 100 ms pour intercontinental. Si vous êtes à 250 ms et que vous êtes sur le même continent que le service, quelque chose route via un edge distant.
Changez de DNS pour exclure un GeoIP périmé
Si vous êtes encore sur le DNS par défaut de votre FAI, essayez Cloudflare (1.1.1.1), Google (8.8.8.8) ou Quad9 (9.9.9.9) temporairement. Différents résolveurs renvoient différents edges CDN parce qu'ils répondent aux requêtes ECS (EDNS Client Subnet) différemment. Un changement peut faire baisser la latence d'upload de 50 ms et augmenter le débit de 20 % sans rien toucher d'autre.
Bufferbloat du routeur
Le bufferbloat est invisible aux speedtests normaux mais écrase les connexions à usage mixte. Lancez le test bufferbloat de Waveform sur waveform.com/tools/bufferbloat. Une note A+ signifie que votre routeur gère les files proprement. Une note F signifie que votre routeur introduit 200 à 2 000 ms de latence sous charge, ce qui non seulement nuit au trafic interactif mais force le contrôle de congestion TCP à reculer en boucle, taillant le débit d'upload.
Correction : activez SQM (Smart Queue Management) sur OpenWrt ou pfSense, activez QoS sur Asus/Netgear/Ubiquiti, ou achetez un routeur qui le fait par défaut (eero récent, Google Nest Wifi Pro).
Désactivez le VPN sauf si nécessaire
Un VPN ajoute 20 à 80 ms de latence et plafonne typiquement le débit à la bande passante montante du serveur VPN. Une ligne à 1 Gbps via un endpoint PIA ou NordVPN congestionné peut tomber à 50 Mbps. Les bons fournisseurs (Mullvad, ProtonVPN Plus) tiennent mieux ; les VPN gratuits étranglent presque toujours les uploads.
Si le service de transfert utilise déjà TLS 1.3 et le chiffrement de bout en bout, le VPN est redondant pour la confidentialité en transit. Coupez-le pendant les uploads, rallumez-le après.
Choix de navigateur et protocole
Chrome, Edge, Brave et Firefox supportent tous HTTP/3 (QUIC) nativement. Safari aussi, mais il bascule sur HTTP/2 par défaut pour certains hôtes. HTTP/3 sur UDP tolère bien mieux la perte de paquets que HTTP/2 sur TCP sur le cellulaire, le Wi-Fi d'hôtel ou les liens du dernier kilomètre perdants.
Vérifiez la colonne Protocole dans Network des DevTools. Si ça indique h2, vous êtes en HTTP/2. Si ça indique h3, vous êtes en HTTP/3. Les services qui servent les uploads en HTTP/3 voient des gains de 15 à 30 % sur les liens perdants.
Essayez un autre réseau pour isoler le problème
Le diagnostic le plus rapide : partagez la connexion de votre téléphone une minute et uploadez un morceau de test. Si le partage téléphone est plus rapide que votre Wi-Fi maison, le problème se situe dans votre réseau local (routeur, FAI ou appareil). Si le partage téléphone est à la même vitesse, le goulot est plus en amont (congestion de transit, limite côté service).
Ce seul test élimine la moitié des causes possibles en moins de deux minutes.
Quand le service est le goulot
Certains services de transfert plafonnent simplement le débit par transfert. Les offres gratuites de certains outils brident au-delà de 10 Mo/s quelle que soit votre connexion. Les paliers payants enlèvent souvent le bridage.
Si vous avez tout éliminé et que votre ligne à 500 Mbps délivre encore seulement 30 Mbps à un service spécifique, le service est la limite. Changez. HexaTransfer ne bride pas par transfert et fait tourner des uploads chunked parallèles qui saturent ce que votre tuyau peut réellement pousser jusqu'au plafond de 10 Go par transfert.
Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
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