Aller au contenu
HexaTransfer
Retour au blog
Transfert de fichiers

Navigateur plante pendant l'upload ? Solutions pour la stabilité

Navigateur plante pendant l'upload ? Corrigez les problèmes de mémoire et d'instabilité avec ces étapes de dépannage éprouvées pour gros transferts.

Si votre navigateur plante en plein upload, la cause est presque toujours la pression mémoire sur l'onglet. Chrome tue les onglets qui dépassent environ 2 à 4 Go de mémoire privée, et un service de transfert qui charge un fichier de 10 Go dans un seul objet Blob fera exploser ce plafond. Correction : utilisez un service qui streame le fichier en morceaux via la méthode slice() du File API (la plupart des services modernes le font), fermez tous les autres onglets avant d'uploader, désactivez les extensions qui s'accrochent aux requêtes fetch/XHR, et uploadez sur un ordinateur de bureau plutôt qu'un portable sur batterie. Firefox gère typiquement les gros flux File API avec moins d'overhead mémoire que Chromium.

Pourquoi les navigateurs plantent sur les uploads

Deux réalités architecturales entrent en collision. Premièrement, chaque onglet de navigateur est un processus séparé avec son propre plafond mémoire. Chrome limite chaque processus renderer à environ 4 Go sur les systèmes 64 bits avant que le OOM killer intervienne. Deuxièmement, la façon naïve d'uploader un fichier en JavaScript est de passer l'objet File entier dans un corps de fetch, que les navigateurs essaient souvent de mettre en buffer mémoire avant d'envoyer.

Un service de transfert bien conçu ne fait jamais ça. Il lit le fichier avec File.slice(start, end) pour produire un Blob pour chaque fragment de 5 à 20 Mo, uploade ce fragment, puis le libère. La mémoire reste bornée à environ tailleFragment * concurrence octets quelle que soit la taille du fichier.

Si votre upload démarre bien à 500 Mo de progression et que l'onglet devient gris à 2 Go, le service charge tout avant d'envoyer. Choisissez un autre service ou une autre approche.

Fermez les autres onglets de façon agressive

Chrome partage un seul processus renderer pour certains onglets groupés (Site Isolation change cela, mais la pression mémoire reste partagée au niveau système). Un second onglet jouant YouTube en 4K, un troisième avec Figma chargé, un quatrième avec Notion consommant 800 Mo chacun — tout s'additionne. Un upload de 10 Go sur un portable à 8 Go de RAM et 12 onglets ouverts joue avec le feu.

Avant de démarrer un gros upload, quittez Chrome entièrement et rouvrez-le avec seulement l'onglet du service de transfert. Le Moniteur d'activité (macOS) ou le Gestionnaire des tâches (Windows) doit montrer le navigateur utilisant bien moins de 2 Go dans cet onglet unique.

Désactivez les extensions

Les bloqueurs de publicités, les extensions de confidentialité, les gestionnaires de mots de passe et les analyseurs réseau (uBlock Origin, Privacy Badger, LastPass, HTTP Toolkit) s'injectent tous dans les requêtes réseau. La plupart ne posent pas de problème. Certains, surtout ceux avec du code obsolète, mettent en buffer les corps de requêtes pour les inspecter, ce qui contrecarre les uploads en streaming et fait exploser la mémoire.

Testez dans une fenêtre de navigation privée (les extensions sont désactivées par défaut). Si l'upload se termine proprement en navigation privée, les extensions sont en cause. Activez-les une par une pour trouver le coupable.

Désactivez l'accélération matérielle sur les GPU faibles

Les portables plus anciens avec des GPU Intel UHD 620 intégrés ou similaires plantent parfois lors de la mise à jour d'une barre de progression simultanément avec la lecture du buffer de fichier. L'option Paramètres > Système > « Utiliser l'accélération matérielle si disponible » de Chrome peut être désactivée. Cela sacrifie un peu de fluidité pour tout le reste mais stabilise les gros uploads sur les systèmes à mémoire contrainte.

De même, désactivez le mode « Économie de mémoire » de Chrome pour l'onglet d'upload, qui a été connu pour évincer des onglets sous pression en plein upload. Épinglez l'onglet ou excluez-le explicitement.

Passez à Firefox pour les très gros fichiers

Firefox gère historiquement le File API avec des budgets mémoire plus serrés que Chromium. Sur un upload de 10 Go qui plante Chrome en boucle, Firefox termine souvent le même travail sans drame. La différence n'est pas énorme sur les services bien conçus (les deux gèrent le streaming chunked correctement), mais sur les services avec des implémentations moins soignées, le modèle mémoire conservateur de Firefox est plus tolérant.

Safari sur macOS est aussi fiable pour les gros uploads, avec la réserve que iOS Safari ferme agressivement les onglets en arrière-plan.

Épinglez l'onglet et gardez-le au premier plan

Les onglets en arrière-plan sont les premiers à être évincés sous pression mémoire. Gardez l'onglet d'upload au premier plan. Ne passez pas à une autre fenêtre pendant 30 minutes pour revenir et trouver l'onglet rechargé. Les onglets « discarded » de Chrome affichent un placeholder gris au retour, et tout upload en cours est mort.

caffeinate sur macOS (caffeinate -s) ou la désactivation du mode veille de Windows pendant l'upload. Un portable qui se met en veille ferme les connexions WebSocket et XHR, et tous les services ne peuvent pas reprendre proprement ensuite.

Uploadez depuis un bureau, pas un portable sur batterie

Les portables sur batterie bridgent agressivement le CPU et la RAM. Le « Mode faible consommation » de macOS et « Économiseur de batterie » de Windows réduisent tous deux la priorité des tâches en arrière-plan, ce qui pour un onglet de navigateur faisant du chiffrement AES et des écritures réseau signifie des blocages.

Branchez-vous. Désactivez les modes d'économie de batterie. Si le portable propose des profils de performance CPU (Dell Power Manager, Lenovo Vantage), passez en mode « Performance » pendant la durée.

Redémarrez le navigateur avant de commencer

Chrome, Firefox et Edge ont tous des fuites mémoire lentes sur les longues sessions. Un navigateur ouvert depuis deux jours avec 40 onglets ouverts et fermés peut porter 2 Go de mémoire zombie avant même que vous ouvriez la page d'upload. Quittez complètement (Cmd+Q, pas juste fermer la fenêtre, sur macOS ; clic droit sur la barre des tâches > Quitter sur Windows) et rouvrez.

Vérifiez la RAM avec le Moniteur d'activité pendant l'upload

Pendant l'upload, surveillez la mémoire du processus navigateur. Moniteur d'activité macOS : onglet Mémoire, filtrez par nom du navigateur. Gestionnaire des tâches Windows : onglet Détails, triez par « Mémoire (jeu de travail privé) ».

Un upload chunked sain se stabilise à quelques centaines de Mo de mémoire navigateur quelle que soit la progression. Si la mémoire monte linéairement avec la progression d'upload (atteignant 5 Go à 50 % d'un fichier de 10 Go), le service met tout en buffer. C'est le bug. Trouvez un autre service.

Utilisez des services conçus pour les gros uploads navigateur

Un service de transfert bien conçu utilise des uploads chunked avec un pool de Web Workers pour le chiffrement, une mémoire bornée et un retry explicite sur les fragments échoués. HexaTransfer lit les fichiers via File.slice() dans des Web Workers, chiffre avec AES-256-GCM par fragment, et ne dépasse jamais quelques centaines de Mo de mémoire navigateur que vous envoyiez 50 Mo ou les 10 Go complets du plafond par transfert — ce qui compte quand votre navigateur gère déjà tout ce que votre journée lui lance.

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