Encoders & Utilities

Temps de téléchargement

Estime la durée de téléchargement à toute vitesse de connexion.

Download time estimator Pick file size and connection speed — we will compute the transfer time. SI units (1 KB = 1000 B).
13m 20s
1 GB @ 10 Mbps
Raw time
800 s
Adjusted time
800 s
Total bytes
1 000 000 000
Bits per second
10 000 000

À propos de cet outil

Download Time estime combien de temps un fichier d'une taille donnée prendra à télécharger à une vitesse de connexion donnée. Entrez la taille du fichier dans n'importe quelle unité (KB, MB, GB, TB — binaire ou décimal), choisissez une vitesse en Mbps/MBps/Gbps (avec des présélections pour les paliers courants : 56k dial-up, 4G LTE, fibre 100 / 1000 Mbps), et l'outil retourne la durée sous forme conviviale (1 heure 23 minutes 12 secondes) plus quelques lignes de comparaison à d'autres vitesses courantes.

Les mathématiques sont simples — durée = taille / vitesse — mais les conversions d'unités piègent tout le monde. Les FAI vendent la vitesse en bits par seconde (Mbps) ; les tailles de fichiers sont en octets (MB) ; et « MB » lui-même est ambigu entre 1 000 000 octets (décimal, utilisé par les FAI et les disques) et 1 048 576 octets (binaire, utilisé par Windows et la RAM). L'outil étiquette chaque unité précisément afin que vous puissiez vérifier dans quel monde vous calculez.

Quand utiliser cet outil

  • Estimer les fenêtres de sauvegarde ou de migration. Un transfert cloud-vers-cloud de 500 GB à 1 Gbps représente ~70 minutes de transfert réel ; planifier cela vous donne la fenêtre de maintenance.
  • Comparer les forfaits internet. « 100 Mbps » vs « Gigabit » semble spectaculaire ; sur un téléchargement de jeu de 10 GB c'est 14 minutes vs 1,5 minute. Des chiffres concrets aident à décider si la mise à niveau en vaut la peine.
  • Dimensionner la bande passante CI/CD. Tirer une image Docker de 2 GB à chaque build sur un bureau partagé à 50 Mbps s'accumule vite.
  • Fixer des attentes utilisateur réalistes. « Cet export prendra ~5 minutes » bat un spinner sans barre de progression.

Pourquoi les téléchargements réels sont plus lents que le calcul

Le nombre que vous calculez est le minimum absolu. Les téléchargements réels rencontrent le slow-start TCP (la première seconde est à vitesse partielle), des plafonds de bande passante par connexion (un seul téléchargement HTTPS vers un serveur sature rarement une ligne fibre), la surcharge de négociation TLS, les goulots d'étranglement E/S disque et la contention de tuyau partagé. En règle générale, prévoyez 70–85 % du théorique pour un seul gros fichier, moins si vous téléchargez de nombreux petits fichiers.

Questions fréquentes

Pourquoi Mbps n'est pas la même chose que MB/s ?

Mbps est mégabits par seconde ; MB/s est mégaoctets par seconde. 1 octet = 8 bits, donc 100 Mbps ≈ 12,5 MB/s. Les FAI annoncent en bits car le nombre paraît 8× plus grand ; les systèmes d'exploitation affichent en octets car c'est ainsi que les fichiers sont mesurés. Le facteur de 8 est la plus grande source unique de confusion « pourquoi mon téléchargement est plus lent que mon test de vitesse ? ».

Quelle est la différence entre MB et MiB ?

MB = mégaoctet = 1 000 000 octets (décimal, SI). MiB = mébioctet = 1 048 576 octets (binaire, IEC). Le marketing des disques et FAI utilise MB ; les dialogues de taille de fichier Windows et les spécifications RAM utilisent MiB (souvent étiquetés « MB » de toute façon, ajoutant à la confusion). Pour un disque dur de 1 To vendu par un fabricant, vous obtenez ~931 Gio utilisables — même nombre d'octets, nom conventionnel différent.

Pourquoi mon téléchargement réel est-il plus lent que ce que dit le calculateur ?

Plusieurs raisons s'accumulent : slow-start TCP (le protocole monte progressivement, donc les premières secondes sont à vitesse partielle) ; surcharge de négociation TLS et DNS (les fichiers plus petits bénéficient à peine des hautes vitesses) ; plafonds de connexion unique (un flux HTTPS vers un serveur sature rarement la fibre) ; contention Wi-Fi local ; et la propre bande passante sortante du serveur. Prévoyez 70–85 % du théorique et vous serez rarement surpris.

Cet outil prend-il en compte la surcharge ?

Il calcule le minimum théorique sans protocole. Les transferts réels ajoutent ~3–5 % pour les en-têtes TCP/IP (40 octets par paquet de 1500 octets), plus quelques pour cent pour le framing TLS. Nous n'intégrons délibérément pas cela dans le chiffre principal car la surcharge varie selon le protocole — HTTP/3 est plus léger que HTTP/2 sur TLS sur TCP. Pour une planification pessimiste, ajoutez 5 % à la durée que l'outil rapporte.