Reprendre les transferts interrompus : ne jamais recommencer

Les transferts réutilisables découpent un fichier en blocs et suivent lesquels ont été reçus avec succès ; lorsque la connexion chute, le client reprend depuis le prochain bloc non envoyé plutôt que de redémarrer à l'octet zéro. Le standard web pour cela est tus.io (un protocole d'envoi réutilisable ouvert), implémenté par SwissTransfer, HexaTransfer, Vimeo, Cloudinary et de nombreux services de transfert modernes. Pour les téléchargements, les requêtes HTTP Range (RFC 7233) permettent aux navigateurs et aux outils comme curl ou aria2 de reprendre les téléchargements interrompus. Sans reprise sur interruption, un envoi de 9,8 Go qui échoue à 9,5 Go vous fait tout perdre — avec reprise, vous ne perdez que 50 Mo au maximum.

Le problème des envois non réutilisables

Un envoi de fichier naïf envoie l'intégralité du fichier en une seule requête HTTP POST. Si quoi que ce soit interrompt la connexion — coupure Wi-Fi, expiration du VPN, veille de l'ordinateur, coupure passagère de l'accès internet — la connexion TCP se ferme et le serveur écarte les données partielles reçues. Le client recommence depuis l'octet zéro.

Pour un envoi de 5 Go sur une connexion à 50 Mbit/s, c'est 13 minutes de travail perdues. Pour un envoi de 50 Go, c'est plus de deux heures. Le taux d'échec des envois non réutilisables sur les connexions mobiles est brutal — un envoi de 30 minutes sur une connexion 4G réussit rarement du premier coup.

Comment fonctionnent les protocoles réutilisables

Les envois réutilisables modernes fonctionnent en gros ainsi :

Création : le client envoie un POST au serveur avec la taille totale et les métadonnées du fichier. Le serveur retourne une URL unique pour cet envoi spécifique et réserve le stockage.
Découpage : le client découpe le fichier en blocs (généralement 5 à 64 Mo chacun).
Envoi : le client envoie chaque bloc via une requête PATCH avec un en-tête Content-Range ou Upload-Offset indiquant la position du bloc.
Acquittement : le serveur écrit le bloc dans le stockage et confirme le nouvel offset.
Reprise : si la connexion chute, le client envoie une requête HEAD vers l'URL d'envoi. Le serveur répond avec l'offset actuel (combien d'octets il a reçus). Le client reprend depuis cet offset.
Finalisation : quand le dernier bloc est acquitté, l'envoi est terminé.

Ce modèle est défini par la spécification tus.io (version 1.0.0 largement déployée). D'autres variantes incluent S3 Multipart Upload (pour les envois directs vers S3) et Google Cloud Storage Resumable Uploads.

Tus.io : le standard ouvert

Tus (« transloadit upload server ») est un protocole libre et ouvert maintenu par Transloadit. La spécification est disponible sur tus.io et implémentée par :

Bibliothèques client : tus-js-client (navigateur + Node.js), TUSKit (iOS), tus-android-client, tus-java-client
Implémentations serveur : tusd (serveur de référence Go), tus-node-server et de nombreuses intégrations de frameworks
Services commerciaux : SwissTransfer, HexaTransfer, Vimeo, Cloudinary, Transloadit, les serveurs compagnons d'Uppy

Le protocole est délibérément minimal : quatre verbes HTTP (POST, HEAD, PATCH, OPTIONS), une poignée d'en-têtes (Upload-Offset, Upload-Length, Tus-Resumable). Cela rend les implémentations simples et interopérables.

Choix de la taille des blocs

La taille des blocs arbitre entre granularité de reprise et surcharge HTTP.

| Taille de bloc | Coût de récupération en cas d'échec | Surcharge | |---|---|---| | 1 Mo | Perd ≤ 1 Mo | Élevée (nombreuses requêtes) | | 5 Mo | Perd ≤ 5 Mo | Modérée | | 16 Mo | Perd ≤ 16 Mo | Faible | | 64 Mo | Perd ≤ 64 Mo | Minimale | | 256 Mo | Perd ≤ 256 Mo | Surcharge négligeable, pénible en cas d'échec |

Pour les connexions stables, des blocs de 32 à 64 Mo maximisent le débit. Pour le mobile ou le Wi-Fi instable, des blocs de 2 à 5 Mo récupèrent plus vite de chaque défaillance. Les services choisissent généralement une valeur par défaut entre 5 et 10 Mo comme compromis.

Ce qui interrompt vraiment les transferts

Comprendre les modes d'échec aide à évaluer si l'implémentation de reprise d'un service est robuste :

Coupures Wi-Fi : changement de réseau, perte du signal, redémarrage du routeur. Très courant.
Veille de l'ordinateur : fermeture du couvercle sur macOS/Windows. Le système d'exploitation suspend le réseau ; au réveil, les connexions doivent souvent être rétablies.
Suspension d'onglet : les navigateurs modernes suspendent les onglets en arrière-plan pour économiser la mémoire. Les envois dans un onglet suspendu peuvent se bloquer.
Problèmes opérateur/réseau de collecte : changements de routage momentanés, réinitialisation de la poignée de main TLS requise.
Reconnexion VPN : les clients VPN renégocient périodiquement ; la connexion TCP meurt.
Redémarrages côté serveur : le service de transfert déploie une nouvelle version ; les requêtes en cours échouent.
Modifications de politique inter-origines : les pare-feu d'entreprise inspectant le trafic interrompent parfois les connexions de longue durée.

Une implémentation réutilisable robuste gère tout cela avec le même mécanisme : reconnexion, HEAD pour vérifier l'offset, reprise depuis là.

Reprise pour les téléchargements

Les requêtes HTTP Range (RFC 7233) alimentent les téléchargements réutilisables. Un serveur qui annonce Accept-Ranges: bytes dans ses en-têtes de réponse supporte les requêtes de plage. Les clients peuvent ensuite émettre Range: bytes=1000000- pour ne récupérer que les octets à partir de l'offset 1 000 000.

Les navigateurs utilisent cela automatiquement quand vous appuyez sur « Reprendre » dans le gestionnaire de téléchargements. Chrome, Firefox et Safari supportent tous la reprise pour les téléchargements depuis des serveurs conformes. La plupart des CDN (Cloudflare, Fastly, CloudFront) supportent les plages.

Les outils en ligne de commande offrent plus de contrôle :

curl -C - -O url reprend un téléchargement là où il s'est arrêté.
wget -c url fait de même.
aria2c -c -s 16 url télécharge avec 16 flux parallèles de requêtes de plage pour la vitesse.

Services qui supportent la reprise

Les services de transfert modernes gèrent majoritairement la reprise d'envoi :

| Service | Reprise d'envoi | Reprise de téléchargement | |---|---|---| | SwissTransfer | Oui (basé sur tus) | Oui (plages HTTP) | | HexaTransfer | Oui (découpé + compatible tus) | Oui | | WeTransfer | Oui (envois découpés) | Oui | | Dropbox Transfer | Oui | Oui | | Google Drive | Oui (API d'envoi réutilisable) | Oui | | OneDrive | Oui | Oui | | Box | Oui | Oui |

Les niveaux gratuits désactivent parfois la reprise pour encourager les mises à niveau payantes, mais c'est rare en 2026. Les anciens services sans reprise disparaissent des listes de recommandations car les utilisateurs se lassent des échecs.

Ce qui ne reprend pas automatiquement

Les envois HTTP POST simples dans les applications naïves ne reprennent pas. Les transferts FTP varient historiquement — certains clients et serveurs supportent les commandes REST (redémarrage), d'autres non. Les pièces jointes e-mail ne peuvent pas être reprises — si un envoi Gmail échoue à 90 %, vous recommencez.

Les transferts BitTorrent reprennent intrinsèquement parce que le protocole torrent suit les parties qui ont été vérifiées. C'est en partie pourquoi BitTorrent est resté utile pour les très grandes distributions même quand le web rattrapait les autres métriques.

Reprise avec chiffrement de bout en bout

Les envois réutilisables combinés au chiffrement côté client nécessitent un découpage soigneux. Le fichier est découpé en blocs, chaque bloc est chiffré avec AES-256-GCM en utilisant un IV unique (vecteur d'initialisation), puis envoyé. En cas de reprise, le client doit savoir quels blocs ont été complétés et continuer depuis le suivant.

Comme chaque bloc est chiffré et authentifié de façon indépendante (le mode AEAD de GCM), les envois partiels ne peuvent pas être altérés. Un serveur malveillant qui insérerait des données corrompues à l'offset 5 Go échouerait à l'authentification au déchiffrement par le destinataire — la non-correspondance du tag GCM serait détectée.

Les implémentations comme HexaTransfer utilisent des IV par bloc dérivés de façon déterministe d'une clé maître et d'un index de bloc, de sorte que la reprise ne nécessite pas de stocker les IV séparément. Le côté déchiffrement les reconstruit à partir de la même dérivation.

Bonnes pratiques côté client

Pour maximiser le succès de la reprise :

Gardez l'onglet actif pendant l'envoi. La suspension d'onglet par le navigateur tue les envois en cours. Un avertissement « ne fermez pas cet onglet » est standard dans les interfaces des services de transfert.
Branchez un câble quand c'est possible. Les coupures Wi-Fi causent la plupart des échecs.
Désactivez la mise en veille économique pendant les longs envois. macOS : caffeinate -i. Windows : l'utilitaire Awake de PowerToys ou les modifications du plan d'alimentation.
Ne changez pas de réseau Wi-Fi en cours d'envoi. La connexion TCP change d'IP et meurt.
Laissez l'envoi se terminer avant de fermer le couvercle. macOS moderne préserve parfois les envois lors d'une brève veille, mais ce n'est pas fiable.

Vérifier côté serveur

Certains services affichent des barres de progression incomplètes qui ne reflètent pas l'état réel du serveur. Après un envoi qui a survécu à une ou deux interruptions, actualisez la page et vérifiez que le lien fonctionne — ouvrez-le en navigation privée et téléchargez une petite partie. Si la reprise a fonctionné, le fichier complet se téléchargera correctement.

Pour les scénarios critiques, calculez un hash SHA-256 côté client, envoyez, et vérifiez en hachant le fichier téléchargé pour qu'il corresponde. Une vérification cryptographique de l'intégrité du fichier prend 10 secondes de CPU par gigaoctet et donne une certitude absolue.

Conclusion

La reprise sur transfert interrompu est une fonctionnalité de base en 2026 — tout service qui en est dépourvu est immédiatement rédhibitoire pour les fichiers de plus de quelques centaines de mégaoctets. Recherchez la conformité tus.io ou un comportement équivalent d'envoi découpé. Assurez-vous que le service que vous choisissez gère les interruptions avec grâce ; testez avec une coupure réseau délibérée sur un petit fichier avant de vous engager sur un gros transfert.

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