Pourquoi « il reste 1 seconde » dure-t-il si longtemps ? — Comment fonctionnent les barres de progression et les estimations de temps

Vous regardez « il reste 1 seconde » depuis 30 secondes. Juste au moment où vous attendez la fin, l’affichage passe à « il reste 2 minutes ».

Copies de fichiers, installations d’applications, exports vidéo : les barres de progression sont utiles, mais elles semblent parfois évoluer dans un autre monde que l’horloge.

En réalité, une barre de progression n’est pas une horloge. Le pourcentage décrit la quantité de travail accomplie ; l’estimation de temps prédit la durée que pourrait prendre le travail restant ; l’achèvement signifie que les opérations requises ont réussi. Séparer ces trois idées change la façon de lire une tâche qui n’en finit pas à 99 %.

Cet article explique les mécanismes généraux à partir de la documentation d’API et d’interface de Windows. Il ne rétro-analyse pas l’algorithme interne d’une version particulière de l’Explorateur de fichiers. Les exemples chiffrés et la démo comparative utilisent des charges de travail fictives, et non des mesures sur un PC ou une connexion réseau.

1. Demandez d’abord : 100 % de quoi ?

Imaginez que vous relisiez 100 documents. Si 99 sont de courtes notes et le dernier un long contrat, « 99 documents terminés » peut être exact sans signifier « 99 % du temps est écoulé ».

Un indicateur de progression change lui aussi de sens selon son dénominateur.

Par exemple, le rappel de progression utilisé par l’API Windows CopyFileEx reçoit la taille totale du fichier et les octets transférés. Ces valeurs décrivent du travail, pas des secondes futures. ¹

flowchart TB
    accTitle: Pourcentage de progression, temps restant et achèvement
    accDescr: Le schéma sépare un rapport calculé à partir du travail accompli, une estimation de temps fondée sur une vitesse supposée et un achèvement établi par des résultats réussis.
    A["Travail accompli et travail total"] --> B["Pourcentage de progression"]
    C["Travail restant et vitesse prédite"] --> D["Temps restant estimé"]
    E["Les opérations requises réussissent"] --> F["Tâche globale terminée"]

Figure 1 : Un rapport, une prédiction et un résultat ne sont pas trois noms pour la même information.

Dans tout cet article, pourcentage de progression désigne la fraction de travail mesurable accomplie, barre de progression son indicateur visuel, et temps restant estimé la durée prédite. Ne pas pouvoir faire une prédiction fiable n’efface pas la progression déjà mesurée.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (9 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Comment 10 secondes restantes deviennent 79

L’estimation la plus simple utilise cette équation :

Temps restant ≈ travail restant ÷ vitesse de traitement future estimée

La difficulté n’est pas la division. C’est que la vitesse future n’a pas encore été observée. Nous utilisons donc la vitesse passée pour la prédire. Dans une explication de 2004 sur les estimations de temps de copie, Raymond Chen, de Microsoft, décrivait cette difficulté à prédire l’avenir. Cet article n’est pas une spécification du calcul utilisé dans les Windows d’aujourd’hui. ²

Prenons une copie fictive de 1 000 MiB. Un MiB vaut 1 048 576 octets. Supposons qu’elle se déroule d’abord à 80 MiB/s constants pendant 2,5 secondes, puis ralentisse à 10 MiB/s la seconde suivante.

La tâche a avancé durant cette seconde. Pourtant, la vitesse estimée pour le travail restant est tombée au huitième de sa valeur précédente, si bien que la durée prédite augmente. Cet exemple utilise directement la vitesse du dernier intervalle d’observation.

flowchart TB
    accTitle: Pourquoi le temps restant peut augmenter alors que le travail avance
    accDescr: Si la vitesse prédite baisse suffisamment, son effet l'emporte sur la réduction du travail restant et le temps restant calculé augmente.
    A["10 MiB accomplis en une seconde"] --> B["Il reste moins de travail"]
    C["La vitesse prédite chute fortement"] --> D["Le temps restant peut augmenter"]
    B --> D

Figure 2 : Une hausse de l’estimation de temps ne signifie pas que l’opération a reculé.

Il en va de même pour « il reste 1 seconde ». Une quantité qui prendrait une seconde à la vitesse précédente prendra plus longtemps si l’opération suivante est plus lente. Les intervalles d’observation et les arrondis influent aussi sur l’affichage. Mais un nombre qui ne change jamais ne doit pas être tenu pour normal sans examen : distinguez, comme ci-dessous, étapes de traitement, mises à jour d’interface et véritables blocages.

3. Une moyenne rendrait-elle l’estimation exacte ?

Répercutez chaque brève variation de vitesse et l’estimation sautille. N’utilisez que la moyenne depuis le départ et une phase initialement rapide peut maintenir l’estimation optimiste longtemps après un ralentissement durable.

Cela découle de la manière de combiner les observations. Supposons que nous accordions le même poids à une vitesse antérieure de 80 et à une nouvelle de 10. La vitesse prédite devient 45. Elle varie moins brutalement qu’une estimation fondée sur la seule dernière valeur de 10, mais si la vitesse reste réellement à 10, elle demeure un temps optimiste. La stabilité et la réactivité au changement sont deux objectifs distincts.

flowchart TB
    accTitle: Le compromis du lissage des estimations de vitesse
    accDescr: Donner plus de poids aux observations récentes rend l'estimation réactive mais variable, tandis que donner plus de poids à l'historique la rend plus lisse mais plus lente à s'adapter.
    A["Observations de vitesse"] --> B["Plus de poids aux données récentes"]
    A --> C["Plus de poids à l'historique"]
    B --> D["Réactive mais variable"]
    C --> E["Lisse mais plus lente à s'adapter"]

Figure 3 : Un nombre qui paraît stable n’est pas nécessairement une prédiction exacte.

C’est un exemple pour raisonner sur l’estimation, non la description d’un produit particulier. Ma recommandation de conception est d’éviter d’imposer un compte à rebours juste après le démarrage ou un changement d’étape. Attendez des observations exploitables, puis présentez une estimation du type « environ une minute ». Dire que l’estimation est en cours de recalcul peut être moins trompeur que de maintenir un « il reste 1 seconde » sans fondement.

4. 99 fichiers terminés, mais seulement 9,9 % des données

Considérons maintenant l’unité comptée plutôt que la vitesse. Il y a 100 fichiers : les 99 premiers font 1 MiB chacun et le dernier 901 MiB. Le total est de 1 000 MiB.

Après les 99 premiers fichiers, le nombre de fichiers donne 99 ÷ 100 = 99 %. Le volume de données donne 99 ÷ 1 000 = 9,9 %. Il ne reste qu’un fichier, mais il contient 90,1 % des données. Les deux calculs sont exacts : ils mesurent des choses différentes.

flowchart TB
    accTitle: Quand le dernier fichier est volumineux
    accDescr: Un gros fichier final après 99 petits fichiers fait diverger nettement la progression par nombre et la progression par octets.
    A["99 petits fichiers"] --> B["Presque terminé en nombre de fichiers"]
    C["Un gros fichier reste"] --> D["Une grande partie des données reste"]
    B --> E["Deux vues d'une même tâche"]
    D --> E

Figure 4 : 99 % en nombre de fichiers ne promet pas qu’il ne reste que 1 % du temps.

Les octets suffisent-ils pour autant ? Non. Transférer de nombreux petits fichiers par SMB entraîne à répétition des coûts de création de fichiers et d’allers-retours de requêtes. Le même nombre total d’octets n’a pas à prendre le même temps qu’un unique gros fichier. ³

En conséquence, « il reste 500 MiB » peut être une mesure exacte alors même que le temps nécessaire varie selon le contenu de ces 500 MiB. Afficher à la fois les fichiers et les octets est utile non parce qu’un chiffre serait faux, mais parce que chacun révèle ce que l’autre laisse de côté.

5. « Préparation » peut vouloir dire : recherche du dénominateur

Un pourcentage a besoin d’un total comme dénominateur. Or demander à une application de traiter un dossier entier ne signifie pas nécessairement qu’elle a déjà énuméré tous les fichiers qu’il contient.

Supposons que l’application estime qu’il y a 100 éléments, en traite 80, puis en découvre 100 autres. Ces mêmes 80 éléments terminés représentent désormais 80/200 au lieu de 80/100. L’affichage passe de 80 % à 40 %, mais le travail accompli n’a pas disparu. Présenter un total provisoire comme définitif a créé ce décalage avec l’attente du lecteur.

flowchart TB
    accTitle: Afficher la progression avant de connaître le total
    accDescr: Tant que les cibles sont en cours de découverte, évitez un pourcentage définitif ; une fois le total connu, combinez-le au travail accompli pour afficher un rapport.
    A["Découvrir les cibles"] --> B{"Le total est-il connu ?"}
    B -->|"Pas encore"| C["Afficher l'étape et le nombre découvert"]
    B -->|"Oui"| D["Afficher un pourcentage"]

Figure 5 : Un dénominateur inconnu n’est pas la même chose qu’une progression de 0 %.

Windows fournit des contrôles de progression pour des valeurs déterminées comme pour une activité indéterminée. ⁴ Dans cette situation, je recommande d’afficher quelque chose comme « Recherche d’éléments : 1 200 découverts », puis un pourcentage une fois le total connu. L’absence de compte à rebours n’est pas la preuve que rien ne se passe.

6. « Transfert 100 % » et « tout est terminé » marquent des frontières différentes

6.1 Une autre opération peut rester à la fin

À titre d’illustration, divisons le travail d’une application en trois étapes : transfert, vérification et finalisation du résultat. Si la conception impose une vérification après le transfert, la tâche globale n’est pas terminée à la fin du transfert. C’est un exemple de conception applicative, non une affirmation que toute copie ou installation suit ces étapes.

flowchart TB
    accTitle: Fin du transfert contre achèvement global
    accDescr: Cette application fictive vérifie et finalise le résultat après le transfert, si bien que les octets transférés seuls ne peuvent pas établir la réussite globale.
    A["Transfert"] --> B["Vérification"] --> C["Finaliser le résultat"] --> D["Réussite globale"]
    A -.-> E["Le transfert à 100 % s'arrête ici"]

Figure 6 : Une portée explicite permet d’expliquer pourquoi une autre étape suit les 100 %.

Plutôt que de maintenir une barre globale à 99 % avec « il reste 1 seconde », il est plus cohérent de changer l’état en « Transfert terminé ; vérification en cours ». Les recommandations d’interface de Microsoft pour les applications de bureau déconseillent également d’afficher un achèvement global avant que l’opération soit réellement terminée. ⁵

6.2 Les écritures ont elles aussi plus d’une frontière

Windows utilise normalement une mise en cache pour les écritures de fichiers. Selon les paramètres et les contrats d’API, l’écriture depuis l’application et la validation des données sur le stockage relèvent de frontières différentes. ⁶ FlushFileBuffers est une API destinée à envoyer au périphérique les informations mises en tampon pour un fichier donné. ⁷

flowchart TB
    accTitle: Vue conceptuelle des écritures mises en tampon
    accDescr: Avec la mise en tampon, l'écriture acceptée par l'application et l'écriture ultérieure côté stockage ne doivent pas être traitées comme le même événement.
    A["L'application écrit"] --> B["Conservé dans un tampon"] --> C["Écrit sur le stockage"]

Figure 7 : Il s’agit d’un schéma conceptuel des écritures mises en tampon, pas du contrat d’achèvement d’un produit donné.

Toutefois, une pause à 99 % n’est pas toujours causée par le vidage d’un cache. Savoir si la tâche vérifie, vide un cache ou attend autre chose doit être établi à partir de sa conception ou de ses enregistrements. Ne déduisez pas d’un simple chiffre de progression qu’il est sans risque de débrancher un périphérique USB ou de couper l’alimentation.

7. La tâche s’est-elle arrêtée, ou seulement l’affichage ?

Dans une application WPF sous Windows, le Dispatcher du thread d’interface traite le travail d’interface. Occuper ce thread longtemps retarde les mises à jour et les réponses aux saisies. Distinguez l’opération sous-jacente du travail qui en affiche les résultats à l’écran. ⁸

flowchart TB
    accTitle: Le chemin du traitement jusqu'à l'affichage de la progression
    accDescr: Même si l'opération signale sa progression, l'affichage ne peut la refléter tant que l'interface n'a pas traité la mise à jour.
    A["Traitement réel"] --> B["Signaler la progression"] --> C["Traiter la mise à jour d'interface"] --> D["Mettre à jour l'écran"]
    E["Thread d'interface bloqué"] -.-> C

Figure 8 : Un affichage figé ne signifie pas nécessairement que l’opération elle-même est figée.

À l’inverse, une animation conçue pour tourner indépendamment du travail réel peut continuer pendant que ce travail attend. « Ça bouge donc tout va bien ; c’est immobile donc c’est cassé » n’est pas une distinction suffisante.

Je recommande de consigner d’abord l’affichage et l’heure de départ, de vérifier les invites en attente de saisie, puis de comparer compteurs ou journaux dans le temps. Traitez les relevés du Gestionnaire des tâches comme des éléments de corroboration. Avant d’envisager l’arrêt, vérifiez la procédure d’annulation de l’application et le sort des sorties partielles.

L’annulation en .NET est elle aussi coopérative : demander l’annulation n’arrête pas l’opération immédiatement de soi-même ; l’opération doit y répondre. ⁹ C’est pourquoi « annulation en cours » et « annulé » devraient être des états distincts. Un affichage de progression seul ne peut pas fournir un nombre de minutes universel après lequel forcer la fermeture de l’application deviendrait sans risque.

8. Comparer trois affichages d’une même opération

Ouvrir la démo comparative des barres de progression

La démo avance à travers les observations d’une charge de travail fictive lorsque vous appuyez sur un bouton. Il n’y a pas à attendre, et elle ne lit, n’écrit ni ne téléverse aucun fichier. Le premier cas contient 99 petits fichiers et un gros. Pour chaque observation, elle affiche côte à côte une barre par nombre de fichiers, une barre par données transférées et l’état global de la tâche.

Pendant le transfert du dernier gros fichier, la barre par nombre reste à 99 % alors même que la barre de volume de données progresse. Quand les données transférées atteignent 100 %, l’état global est encore « vérification en cours ». Seule l’observation suivante marque la réussite. Vous pouvez voir comment un même travail peut sembler bloqué ou actif selon le seul mode d’affichage.

flowchart TB
    accTitle: Comment lire la démo comparative
    accDescr: Une seule observation d'une opération fictive alimente trois affichages : nombre de fichiers, données transférées et état global.
    A["Une opération fictive"] --> B["La même observation"]
    B --> C["Pourcentage par nombre de fichiers"]
    B --> D["Pourcentage par données transférées"]
    B --> E["État global de la tâche"]

Figure 9 : La démo compare trois vues d’une opération, pas trois opérations différentes.

Le second cas reproduit le ralentissement de la section 2 et montre le calcul qui transforme 10 secondes en 79. Il utilise le calcul suivant. C’est une estimation pédagogique volontairement simple, non une implémentation de production gérant les reprises, le parallélisme ou une prédiction propre à chaque étape.

function estimateSeconds(remaining, rate) {
  if (!Number.isFinite(remaining) || remaining < 0) return null;
  if (remaining === 0) return 0;
  if (!Number.isFinite(rate) || rate <= 0) return null;
  const seconds = remaining / rate;
  return Number.isFinite(seconds) ? seconds : null;
}

Utilisez des unités concordantes pour remaining et rate, par exemple des MiB et des MiB/s. Une valeur de retour de zéro signifie qu’il ne reste rien de la charge de travail mesurée, non que la tâche applicative entière a réussi. Pour un travail restant positif, une vitesse nulle ou inconnue produit null, afin qu’une estimation inconnue ne soit pas prise pour « il reste 0 seconde ».

9. Visez à ne pas induire en erreur, pas seulement à paraître précis

Pour la conception discutée ici, je garderais séparés l’étape en cours, le travail mesuré, une estimation de temps seulement lorsqu’elle est justifiée, et le résultat de réussite, d’échec ou d’annulation. Même en combinant des pourcentages d’étapes en une seule barre, une répartition telle que « transfert 80 %, vérification 20 % » représente des poids de conception, pas une garantie sur la répartition du temps de cette exécution.

flowchart TB
    accTitle: Construire un affichage de progression à partir d'observations
    accDescr: Affichez l'étape en cours, les quantités mesurées, une estimation de temps lorsqu'elle est justifiée et le résultat final comme des informations distinctes.
    A["Informations issues de l'opération"] --> B["Étape en cours"]
    A --> C["Travail mesuré et travail total"]
    A --> D["Estimation lorsqu'elle est justifiée"]
    A --> E["Réussite, échec ou annulation"]

Figure 10 : Gardez observations et prédictions distinctes, y compris à l’écran.

« Vérification : 400 / 1 000 éléments ; calcul du temps restant » peut être utile sans compte à rebours. Si vous affichez un horodatage, distinguez « dernière augmentation de la progression » de « dernière communication réussie avec l’interface ». Ne mettez pas à jour uniquement la seconde d’une façon qui ferait paraître normale une tâche bloquée.

Le même principe vaut pour l’accessibilité. L’élément HTML progress peut représenter une progression indéterminée en omettant sa valeur. ¹⁰ Pour un indicateur de progression ARIA personnalisé, omettez aria-valuenow lorsque la valeur est inconnue et fournissez un nom accessible identifiant ce qui progresse. ¹¹ L’affichage visuel comme l’information lue à voix haute doivent refléter honnêtement ce que l’on sait.

10. Questions fréquentes

« Il reste une seconde » sans achèvement signifie-t-il qu’une erreur s’est produite ?

L’affichage seul ne peut pas en décider. Distinguez une estimation inexacte, une autre étape, des mises à jour d’interface retardées et un véritable blocage. « C’est courant, donc tout va bien » et « une seconde est passée, donc c’est cassé » concluent tous deux trop vite.

99 % signifie-t-il qu’il reste 1 % du temps total ?

Non. Que le pourcentage compte des fichiers ou des octets, le temps par unité n’a pas à être constant. Multiplier le temps écoulé par 1 % ne donne pas la durée restante.

Une animation qui tourne signifie-t-elle que la tâche se porte bien ?

Un indicateur d’activité et une preuve d’avancement du travail sont deux choses différentes. Examinez ensemble le travail accompli, les étapes et les journaux. L’animation seule ne garantit pas que la tâche pourra aboutir.

Puis-je afficher une progression sans connaître le temps restant ?

Si le total et la quantité accomplie sont connus, vous pouvez afficher leur rapport. N’omettez que le compte à rebours lorsque la prédiction n’est pas fiable. Lorsque le total lui-même est inconnu, utilisez un indicateur indéterminé avec l’étape et le nombre d’éléments terminés.

11. Résumé : le temps restant est une prévision, l’achèvement un résultat

« Il reste une seconde » ne dure pas longtemps parce que l’ordinateur ne saurait pas compter jusqu’à un. Cela dure parce qu’un travail observé sert à estimer un temps de traitement qui n’a pas encore eu lieu. Unités de comptage, découverte des cibles, étapes finales et mises à jour d’interface retardées ajoutent d’autres complications.

flowchart TB
    accTitle: Questions à se poser devant un affichage de progression qui n'aboutit pas
    accDescr: Vérifiez ce que mesure le pourcentage, si la vitesse prédite a changé, s'il reste une autre étape et si c'est l'interface ou l'opération réelle qui est bloquée.
    A["Pourcentage de quoi ?"] --> B["La vitesse prédite a-t-elle changé ?"] --> C["Reste-t-il une autre étape ?"] --> D["Blocage de l'interface ou du traitement ?"]

Figure 11 : Transformez l’agacement devant un chiffre en questions que vous pouvez examiner.

En tant qu’utilisateur, regardez les étapes et les changements plutôt que les seuls chiffres. En tant que développeur, ne mélangez pas travail mesuré, prédiction et résultats. Plus important que de tomber juste à répétition sur « une seconde » : expliquer ce qui se passe maintenant et ce qui reste inconnu. Voilà le rôle d’un bon affichage de progression.

Liens de référence

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Une tâche bloquée à une seconde restante signifie-t-elle qu'une erreur s'est produite ?

L'affichage seul ne peut pas vous le dire. Distinguez une estimation de vitesse inexacte, une étape de traitement finale, une interface figée et un véritable blocage. Vérifiez l'évolution des compteurs et des journaux et cherchez des invites en attente de saisie. Ne forcez pas la fermeture de l'application au seul motif qu'elle affiche une seconde restante.

99 % signifie-t-il qu'il ne reste que 1 % du temps total ?

Non. Le sens dépend de ce que mesure le pourcentage — éléments, octets ou étapes pondérées — et ces unités n'ont pas à demander le même temps. Un pourcentage de progression mesure une fraction du travail, pas le temps restant lui-même.

Une animation qui tourne prouve-t-elle que la tâche se porte bien ?

Non. Quand l'animation et le traitement sont indépendants, l'animation peut continuer pendant que la tâche attend. Distinguez l'animation des preuves de travail accompli, comme les compteurs, les changements d'étape et les journaux.

Puis-je afficher une barre de progression sans estimation de temps fiable ?

Oui. Lorsque le total et la quantité accomplie sont connus, vous pouvez afficher leur rapport et omettre l'estimation de temps si la vitesse est instable. Lorsque le total lui-même est inconnu, affichez l'étape ou le nombre d'éléments terminés plutôt que d'inventer un pourcentage.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.