Upload en échec ? Corriger les erreurs de transfert courantes

Un upload qui échoue tombe presque toujours dans l'une de cinq catégories : instabilité réseau (coupures Wi-Fi, reroutage FAI), épuisement mémoire du navigateur (Chrome qui tue un onglet à 2 Go de RAM), rate limiting ou quota côté service, fichier source corrompu, ou antivirus/pare-feu qui bloque les requêtes sortantes. Commencez par vérifier l'onglet Network des DevTools pour le vrai code de statut HTTP de la requête échouée. Un 413, c'est « payload trop grand ». Un 502 ou 503, c'est le service. Un « ERR_CONNECTION_RESET », c'est votre réseau. Chacun a une correction différente.

Lisez l'erreur réelle, pas le message générique

La plupart des interfaces d'upload affichent « Upload échoué » et s'en tiennent là. C'est inutile. Ouvrez les DevTools du navigateur (F12 ou Cmd+Option+I), basculez sur l'onglet Network, et regardez la requête échouée. Le code de statut vous indique où est le problème : la série 400 signifie votre côté (413 trop gros, 401 auth, 403 interdit), la série 500 signifie leur côté (502 mauvaise passerelle, 503 ralentir, 504 timeout). Les erreurs de connexion comme ERR_CONNECTION_RESET ou net::ERR_NETWORK_CHANGED signifient que la connexion TCP est morte en plein transfert.

Faites une capture d'écran de la requête échouée et de ses en-têtes de réponse avant de fermer quoi que ce soit. Si vous escaladez au support, ces en-têtes pointent généralement le problème.

Coupures Wi-Fi : le tueur silencieux

Les puces Wi-Fi des portables basculent entre points d'accès et entre bandes (2,4 GHz et 5 GHz) parfois. Chaque bascule lâche la connexion TCP pendant une fraction de seconde, ce qui tue un upload mono-flux. Les services d'upload qui implémentent des uploads chunked résumables (basés sur tus.io, multipart S3) survivent à cela ; les uploads en POST unique non.

Si vous pouvez vous brancher en filaire, faites-le. L'Ethernet ne bascule pas. Sinon, restez au moins dans une seule pièce et désactivez « Auto-switch SSID » ou le band-steering mesh pendant l'upload. Lancez un ping continu vers 1.1.1.1 dans un autre terminal et repérez les trous — ce sont là où vos uploads meurent.

Plantages de navigateur et éviction d'onglet

Chrome tue les onglets quand ils dépassent un seuil mémoire, typiquement autour de 2 à 4 Go par onglet selon la RAM disponible. Uploader un fichier de 10 Go via un navigateur qui le met entièrement en mémoire (mauvaise implémentation) va planter. Uploader via un navigateur qui streame des morceaux (bonne implémentation, utilisant la méthode slice() du File API) n'utilise que quelques centaines de Mo de RAM quelle que soit la taille du fichier.

Si votre navigateur plante en boucle sur les gros uploads, essayez Firefox, qui gère historiquement les gros uploads File API avec moins de pression mémoire que Chromium. Assurez-vous que le service utilise des uploads chunked ; si un fichier de 5 Go est chargé dans un Blob unique avant POST, c'est le problème de conception.

Fermez tous les autres onglets. Redémarrez le navigateur avant de commencer. Désactivez les extensions (les bloqueurs de publicités, les extensions de confidentialité et les gestionnaires de mots de passe injectent parfois dans les flux d'upload et les cassent).

Pare-feu d'entreprise et proxies

Les réseaux d'entreprise font souvent tourner de l'inspection profonde de paquets, du shaping de trafic ou des serveurs proxy qui injectent des certificats. Symptômes : les uploads réussissent pour les petits fichiers mais échouent à une taille spécifique (souvent 100 Mo ou 1 Go), ou l'erreur indique « SSL handshake failed » ou « certificate verification failed ».

Vérifiez en uploadant depuis le hotspot d'un téléphone (hors du réseau d'entreprise). Si ça fonctionne là, le problème vient de votre côté. Options : demander à l'IT de mettre l'endpoint d'upload du service en liste blanche, utiliser un VPN (si autorisé) pour contourner le shaper, ou passer sur un réseau personnel.

Zscaler, Cisco Umbrella et les appliances Palo Alto sont des coupables fréquents. Ils inspectent souvent les fichiers au-delà d'un seuil de taille et timeout sur les gros flux.

Antivirus qui scanne le flux sortant

Windows Defender, Bitdefender, Norton et Kaspersky peuvent scanner le trafic HTTPS sortant en interceptant TLS. Sur les gros uploads, le scan lui-même peut ralentir le débit de 40 à 60 %, et sur certaines versions il introduit des timeouts qui tuent la connexion.

Désactivez temporairement la protection web en temps réel (pas l'antivirus complet, juste le composant d'inspection HTTPS) et réessayez. Si l'upload réussit, ajoutez le domaine du service de transfert à la liste d'exclusion de l'antivirus. Ne laissez pas la protection web désactivée de façon permanente.

Limites de débit côté service

Si vous récupérez des réponses 429 ou 503, le service vous bride. Raisons possibles : vous faites tourner trop de morceaux parallèles (revenez à 4 workers au lieu de 8), vous avez atteint un quota journalier de l'offre gratuite (l'offre gratuite de WeTransfer plafonne à 2 Go par transfert mais a des limites de volume journalier implicites), ou vous êtes sur une IP partagée qui a été signalée (courant sur le Wi-Fi d'hôtel et de café).

Attendez 15 minutes et réessayez. Ou changez de réseau. Ou changez de service.

Fichier source corrompu

Rarement, le fichier lui-même est le problème. Une corruption de système de fichiers (secteur défectueux sur un disque externe, copie interrompue) produit un fichier qui se lit bien sur les premiers Mo et renvoie des erreurs I/O au-delà. L'upload stagne à un pourcentage constant à chaque tentative.

Testez en copiant le fichier sur un autre disque local d'abord. Si la copie échoue au même pourcentage, c'est la source. Lancez chkdsk sur Windows ou diskutil verifyDisk sur macOS sur le disque source. Pour les fichiers critiques, restaurez depuis une copie saine avant de retenter l'upload.

Erreurs de date, heure et certificat TLS

Si votre horloge système est fausse de plus de quelques minutes, la validation du certificat TLS échoue et les uploads sortent en erreur avec « certificate not yet valid » ou similaire. Mac et Windows synchronisent généralement via NTP automatiquement, mais après une longue veille ou une carte mère à pile vide, les horloges dérivent.

Forcez une synchro NTP : sntp -sS time.apple.com sur macOS, ou Paramètres > Heure et langue > Date et heure > Synchroniser maintenant sur Windows.

VPN qui échouent silencieusement

Certains clients VPN (surtout les gratuits) lâchent les connexions TCP de longue durée après 5 à 10 minutes parce que leurs jetons de session se rafraîchissent. Un upload de 2 Go qui prend 20 minutes meurt au renouvellement du jeton, silencieusement. Soit basculez vers un VPN payant avec une meilleure gestion de session (Mullvad, ProtonVPN, IVPN), soit déconnectez le VPN pendant les uploads si le service est déjà chiffré TLS de bout en bout.

Les services chiffrés de bout en bout signifient que vous n'avez pas besoin du VPN pour la confidentialité pendant le transfert lui-même. HexaTransfer, par exemple, chiffre avec AES-256-GCM côté client avant que le fichier ne quitte votre navigateur, donc ajouter le chiffrement VPN par-dessus est une précaution supplémentaire, pas une nécessité.

Essayez un service qui retente les morceaux automatiquement

Si vous avez résolu les problèmes locaux évidents et que les uploads continuent d'échouer, le service lui-même gère peut-être mal les interruptions. Un service avec retry automatique par morceau et état de session résumable continue de fonctionner à travers les hoquets (une bascule Wi-Fi, un bref reroutage FAI) qui tuent les uploaders mono-flux. HexaTransfer fait tourner des uploads chunked parallèles avec retry par morceau et survit à la plupart des courts événements réseau sans intervention manuelle.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.