🚀The world's best VBA AI has evolved. ExcelMaster is now an autonomous Agent.Read more →
Back to Blog

VBA Wait dans Excel — Application.Wait, pourquoi il fige Excel, et quand utiliser Sleep à la place

|

VBA Wait dans Excel — Application.Wait, pourquoi il fige Excel, et quand utiliser Sleep à la place

TL;DR — Application.Wait met votre macro en pause jusqu'à un moment de l'horloge, pas pendant un certain nombre de secondes. C'est pourquoi Application.Wait 5 ne fait presque rien — 5 est un numéro de série d'heure du jour déjà situé dans le passé. Ce que vous voulez, c'est « maintenant plus cinq secondes », et sa résolution ne descend pas sous la seconde entière :

Sub PauseFiveSeconds()
    ' se reveiller a l'heure actuelle PLUS cinq secondes
    Application.Wait Now + TimeValue("0:00:05")
    MsgBox "Five seconds later."
End Sub

Application.Wait est l'outil vers lequel on se tourne en premier quand on veut qu'une macro « fasse une pause », et c'est aussi celui qu'on utilise mal en premier, parce que son nom masque son fonctionnement. Ce n'est pas un minuteur de cuisine réglé sur une durée — c'est un réveil réglé sur un moment. Ce guide repose sur cette seule idée, car le modèle du réveil explique chaque bizarrerie : l'argument, le plancher de la seconde entière, et le fait que, tant que le réveil est armé, Excel est complètement figé et ne peut rien faire d'autre.

Ce que vous allez apprendre

  • Le modèle mental — Application.Wait est un réveil (un moment), pas un chronomètre (une durée)
  • La règle qui piège tout le monde — l'argument est un temps absolu, pas une durée
  • Pourquoi il ne descend qu'à la seconde entière, et quoi utiliser pour les pauses inférieures à la seconde
  • Pourquoi il fige Excel — aucun redessin, aucun clic, aucune mise à jour de la barre d'état — pendant l'attente
  • L'avis honnête sur les cas où Application.Wait convient, et ceux où Sleep ou une boucle DoEvents est l'outil que vous vouliez vraiment

Le modèle mental : un réveil, pas un chronomètre

On ne dit pas à un réveil « sonne dans huit heures ». On lui dit « sonne à 7 h 00 ». Application.Wait fonctionne exactement pareil : vous lui donnez un point dans le temps où se réveiller, et il bloque jusqu'à ce que l'horloge système atteigne ce point. Il ne décompte pas une durée.

Ce seul fait est à l'origine du bug numéro un. Parce que l'argument est un moment, vous ne pouvez pas écrire le nombre de secondes voulu — vous devez écrire maintenant, plus les secondes voulues, et vous construisez « les secondes voulues » avec TimeValue :

Application.Wait Now + TimeValue("0:00:05")   ' se reveiller a maintenant + 5 secondes  -> attend ~5 s
Application.Wait Now + TimeValue("0:01:30")   ' se reveiller a maintenant + 1 min 30 s
Application.Wait "14:30:00"                    ' se reveiller a 14 h 30 aujourd'hui (un moment litteral)

Now est la date et l'heure courantes ; TimeValue("0:00:05") est la durée de cinq secondes exprimée comme valeur d'heure ; leur addition donne le moment situé cinq secondes plus tard. C'est ce dont Application.Wait a besoin.

La règle qui piège tout le monde : l'argument est un temps absolu

Voici la défaillance qui envoie les gens vers les moteurs de recherche. Ils lisent « Wait met la macro en pause » et écrivent :

Application.Wait 5      ' FAUX - n'attend PAS 5 secondes

Pour VBA, 5 ne signifie pas « cinq secondes ». C'est le numéro de série 5, c'est-à-dire une date/heure : cinq jours après l'époque 1900, à minuit — un moment vieux de plusieurs décennies. Application.Wait regarde l'horloge, constate que ce moment est passé depuis longtemps, et rend la main quasi instantanément. La macro ne lève pas d'erreur ; elle n'attend tout simplement pas. Ce silence — « ça n'a pas fait de pause et ça ne s'est pas plaint » — est précisément ce qui déroute autant.

Le même piège sous une forme plus subtile : Application.Wait Now + 5 attend cinq jours, car 5 ajouté à une date signifie cinq jours, pas cinq secondes. Enveloppez toujours la durée dans TimeValue (ou TimeSerial) :

Application.Wait Now + 5                      ' attend 5 JOURS - presque jamais ce que vous vouliez
Application.Wait Now + TimeValue("0:00:05")   ' attend 5 secondes - correct
Application.Wait Now + TimeSerial(0, 0, 5)    ' pareil, construit a partir de nombres

Si vous ne retenez qu'une ligne de cette page, que ce soit Now + TimeValue(...).

Seulement des secondes entières — pour plus fin, utilisez Sleep

TimeValue ne sait pas exprimer de fractions de seconde. La pause la plus fine que Application.Wait puisse prendre est une seconde ; il n'existe pas de TimeValue("0:00:00.25"). Si vous demandez une pause d'un quart de seconde — pour brider une boucle d'interrogation, espacer des requêtes, cadencer une animation — Application.Wait en est incapable.

C'est la ligne de partage nette entre les deux outils d'attente. Secondes entières, sans Declare : Application.Wait. Sous la seconde, précision à la milliseconde : l'API Windows Sleep. Si vous vous surprenez à souhaiter que Application.Wait accepte des millisecondes, c'est que vous l'avez déjà dépassé — passez à Sleep.

Ce que tout le monde oublie : il fige complètement Excel

Pendant que Application.Wait bloque, Excel ne fait rien d'autre. Il s'exécute sur l'unique thread d'Excel et ne libère pas ce thread pour traiter les messages. Donc, pendant l'attente :

  • l'écran ne se repeint pas,
  • un message de barre d'état que vous venez de définir n'apparaît pas,
  • les clics et les frappes s'accumulent sans être traités,
  • et si l'attente dure assez, Windows estampille « Ne répond pas » sur la fenêtre.

C'est le piège qui fait de Application.Wait le mauvais outil pour la raison la plus courante qui pousse à l'employer. Si votre objectif est « afficher un compte à rebours », « laisser l'utilisateur suivre la progression » ou « lui permettre d'appuyer sur Annuler », Application.Wait vous met des bâtons dans les roues — il fige justement l'interface que vous vouliez garder vivante.

Une pause réactive relève d'une tout autre construction : une courte boucle qui cède la main avec DoEvents pour qu'Excel continue de respirer pendant que le temps passe.

' Une pause qui garde Excel vivant et annulable - PAS Application.Wait
Dim finishAt As Double
finishAt = Timer + 5                 ' Timer = secondes depuis minuit
Do While Timer < finishAt
    DoEvents                          ' laisser Excel repeindre et gerer les clics
    If gCancel Then Exit Do
Loop

Notez ce qu'elle emploie : Timer pour mesurer les secondes écoulées et DoEvents pour garder la fenêtre vivante. Application.Wait ne vous offre ni l'un ni l'autre.

L'avis honnête : quand Application.Wait est vraiment le bon choix

Application.Wait mérite sa place dans exactement une situation : vous avez besoin d'une pause d'un nombre entier de secondes, et cela vous est réellement égal qu'Excel soit figé pendant ce temps. Le cas d'école est de laisser à un flux externe un instant pour se mettre à jour — vous venez de lancer une requête DDE/RTD, une requête web ou un rafraîchissement de QueryTable, et vous voulez patienter deux ou trois secondes que les données arrivent avant d'en lire le résultat. C'est simple, cela ne demande aucune déclaration d'API, et cela rend le CPU (il ne tourne pas à vide), si bien qu'une pause courte, non interactive et en secondes entières est un usage tout à fait valable.

Pour tout le reste, nommez ce que vous voulez vraiment :

  • Pause inférieure à la seconde (brider une boucle, espacer des appels) — Sleep, car Application.Wait ne peut pas descendre sous la seconde.
  • Une pause où Excel doit rester réactif (progression, annulation, compte à rebours visible) — une boucle DoEvents, car Application.Wait fige la fenêtre.
  • Exécuter quelque chose plus tard, selon un planning (toutes les 5 minutes, à 9 h) — Application.OnTime, et pas une attente du tout.

Un Excel figé est le comportement correct de Application.Wait, pas un bug. Le bug, c'est de l'employer quand un Excel figé n'est pas ce que vous vouliez.

Comment ExcelMaster aide

Choisir entre Application.Wait, Sleep, une boucle DoEvents et OnTime est une affaire de jugement : cela dépend de la nécessité d'un minutage inférieur à la seconde, du fait qu'Excel doive rester réactif, et du caractère ponctuel ou planifié du délai. Trompez-vous et, soit vous figez Excel alors que vous vouliez le garder vivant, soit vous écrivez Application.Wait 5 en vous demandant pourquoi rien ne se met en pause.

ExcelMaster fait ce choix à votre place. Décrivez ce que vous voulez — « faire une pause de deux ou trois secondes le temps que la requête se rafraîchisse » ou « attendre, mais en me laissant annuler » — et il retient la bonne construction : Application.Wait Now + TimeValue(...) pour une simple pause en secondes entières, une déclaration Sleep pour un bridage sous la seconde, ou une boucle DoEvents protégée quand la fenêtre doit rester réactive. Pas d'erreur d'un numéro de série, pas de macro figée là où vous en vouliez une vivante.

Questions fréquentes

Comment faire attendre 5 secondes à une macro en VBA ?

Utilisez Application.Wait Now + TimeValue("0:00:05"). L'argument de Application.Wait est un moment où se réveiller, pas une durée ; vous ajoutez donc le TimeValue de cinq secondes à Now (l'heure courante). Écrire Application.Wait 5 ne fonctionne pas — VBA lit 5 comme un numéro de série de date/heure situé dans le passé, si bien que la macro ne fait aucune pause.

Pourquoi Application.Wait 5 ne met-il pas ma macro en pause ?

Parce que 5 est interprété comme un numéro de série d'heure du jour (à peu près minuit le cinquième jour de 1900), déjà situé dans le passé. Application.Wait bloque jusqu'à ce que l'horloge atteigne le moment que vous lui avez donné, et ce moment est passé depuis longtemps, donc il rend la main immédiatement. Vous devez passer un moment futur, comme Now + TimeValue("0:00:05").

Application.Wait peut-il faire une pause de moins d'une seconde ?

Non. Application.Wait ne descend qu'à la seconde entière, car TimeValue ne sait pas exprimer de fractions de seconde. Pour une pause inférieure à la seconde — 250 millisecondes, par exemple — utilisez plutôt l'API Windows Sleep (Sleep 250), qui prend des millisecondes.

Pourquoi Excel se fige-t-il ou affiche-t-il « Ne répond pas » pendant Application.Wait ?

Parce que Application.Wait bloque l'unique thread d'Excel et ne le laisse pas traiter les messages pendant l'attente, si bien que l'écran ne peut pas se repeindre et que les clics ne sont pas gérés. Pour une pause où Excel doit rester vivant — afficher la progression ou permettre l'annulation — utilisez une courte boucle qui appelle DoEvents au lieu de Application.Wait.

Quelle est la différence entre Application.Wait et Sleep ?

Application.Wait est intégré à Excel, ne demande aucune déclaration, attend jusqu'à un moment de l'horloge et se résout à la seconde entière. Sleep est un appel d'API Windows que vous devez déclarer, attend un nombre de millisecondes (précision inférieure à la seconde) et exige l'attribut PtrSafe sur Excel 64 bits. Utilisez Application.Wait pour de simples pauses en secondes entières et Sleep quand il vous faut un minutage plus fin. Les deux figent Excel pendant l'attente.

Testé dans

Testé dans : Excel 365 (Windows 11), VBA 7.1 — dernière vérification le 19/08/2026.

Guides associés : VBA Sleep · VBA Timer · VBA DoEvents · VBA StatusBar · VBA ScreenUpdating