VBA End dans Excel — End, End Sub, Exit Sub et Stop, à ne pas confondre

TL;DR — L'instruction End nue arrête toute la macro immédiatement : elle efface chaque variable (y compris de niveau module et Static), ferme les UserForms et saute tout nettoyage que vous aviez prévu. C'est autre chose que End Sub (qui marque seulement où finit un Sub), que Exit Sub (qui revient d'une seule procédure et laisse le programme continuer), et que Stop (qui met en pause dans le débogueur). Vous ne voulez presque jamais du End nu. Pour quitter une procédure, utilisez Exit Sub.

Sub WhyEndIsDangerous()
    Application.ScreenUpdating = False
    ' ... du travail ...
    If somethingWrong Then End       ' arret IMMEDIAT - ScreenUpdating reste a False !
    ' ... plus de travail ...
    Application.ScreenUpdating = True ' cette ligne de nettoyage ne s'execute jamais apres End
End Sub

Quatre constructions en VBA contiennent le mot end, et les confondre provoque de vrais bugs. Une seule d'entre elles — le End nu — arrête réellement votre programme, et de la façon la plus brutale qui soit. Les autres se contentent de fermer un bloc ou de revenir d'une procédure. Savoir laquelle est laquelle fait la différence entre une macro qui nettoie derrière elle et une macro qui laisse Excel dans un état à moitié configuré.

Ce que vous allez apprendre

Ce que fait vraiment l'instruction End nue — et l'ampleur de l'état qu'elle détruit
Pourquoi End, End Sub, End If, Exit Sub et Stop sont cinq choses différentes
Le vrai bug : comment End saute votre nettoyage et laisse ScreenUpdating ou les événements coupés
Pourquoi End efface les variables de niveau module et Static qu'un retour normal conserverait
Quand (si jamais) End est le bon choix, et quoi utiliser à la place
En quoi Stop diffère de End — mettre en pause pour déboguer plutôt que terminer

Le modèle mental : End est la prise, pas la porte

Alignez les quatre sosies selon l'ampleur de ce qu'ils arrêtent :

End If      ' ferme un bloc If            - n'arrete rien ; marqueur structurel
End Sub     ' marque la fin d'un Sub      - la procedure finit ici de toute facon
Exit Sub    ' revient de CETTE procedure  - le programme continue
End         ' termine TOUTE la macro      - tout s'arrete, aucun nettoyage

End Sub et End If sont de la ponctuation : ils disent à VBA où un bloc se termine. Ils ne « s'exécutent » pas. Exit Sub est une porte hors d'une procédure — vous partez, l'appelant continue, votre nettoyage s'exécute. Le End nu est la prise : il stoppe toute la pile d'appels d'un coup, comme si vous aviez appuyé sur le bouton Reset dans l'éditeur. Tout ce qui est en aval — l'appelant, l'appelant de l'appelant, la ligne de nettoyage que vous avez écrite deux lignes plus bas — est simplement abandonné. Cette seule distinction, porte contre prise, résume toute la page.

Ce que l'instruction End nue détruit vraiment

End fait bien plus qu'« arrêter le code ». Quand il se déclenche, VBA démolit tout l'état d'exécution de votre projet :

Toutes les variables sont réinitialisées — les variables locales, de niveau module et Static perdent leurs valeurs.
Tous les UserForms ouverts sont déchargés, sans que leurs événements QueryClose ou de nettoyage s'exécutent normalement.
La pile d'appels est jetée — aucune procédure qui s'y trouve n'a l'occasion de finir ni d'exécuter ses lignes restantes.
Les gestionnaires On Error sont effacés, et l'état d'exécution du projet VBA se réinitialise comme au premier démarrage.

Ce qu'il ne fait pas, c'est annuler quoi que ce soit de déjà appliqué au classeur ou à Application. C'est là le cœur du danger. Si vous avez mis Application.ScreenUpdating = False en tête et déclenché End au milieu, le rafraîchissement de l'écran reste coupé — parce que la ligne qui l'aurait rétabli est l'une des nombreuses lignes que End vient d'abandonner.

Le vrai bug : End saute votre nettoyage

La plupart des macros non triviales fixent un certain état d'Excel au départ et le rétablissent à la fin :

Sub Report()
    Application.ScreenUpdating = False
    Application.EnableEvents = False

    If Not FileExists() Then End    ' <-- le piege

    ' ... construire le rapport ...

    Application.EnableEvents = True     ' jamais atteint si End s'est declenche
    Application.ScreenUpdating = True   ' jamais atteint si End s'est declenche
End Sub

Si FileExists renvoie False, ce End arrête tout sur-le-champ. EnableEvents et ScreenUpdating restent à False, si bien que l'Excel de l'utilisateur ignore désormais silencieusement les événements de feuille et ne se redessine plus — un ticket de support « Excel figé » qui ressemble à un plantage mais n'est en réalité qu'un nettoyage sauté. Le correctif est de revenir, non de terminer : remplacez End par Exit Sub, et placez les lignes de restauration là où elles s'exécutent toujours (un chemin de sortie unique, ou un gestionnaire d'erreurs). Exit Sub quitte la procédure mais laisse s'exécuter votre nettoyage — et le reste du programme.

End efface les variables Static et de niveau module

Il y a une conséquence plus subtile qui mérite sa propre note. Un retour normal (Exit Sub, ou le simple fait d'atteindre End Sub) laisse intactes les variables de niveau module et Static — c'est tout leur intérêt, persister d'un appel à l'autre. Le End nu les jette avec tout le reste :

' Niveau module
Dim gRunCount As Long

Sub Tick()
    gRunCount = gRunCount + 1     ' cense s'accumuler d'un run a l'autre
    If gRunCount > 100 Then End   ' End remet gRunCount a 0 !
End Sub

Si une partie de votre conception repose sur un état qui survit entre les exécutions de la macro — un compteur, un objet en cache, une configuration chargée — un End égaré le réinitialise en silence, et le bug ne se révèle que bien plus tard sous la forme « le compte repart sans cesse de zéro ». Une raison de plus pour que le End nu soit rare et délibéré.

Stop n'est pas End : mettre en pause pour déboguer, pas terminer

Stop a l'air apparenté mais fait l'inverse de terminer. Il suspend l'exécution et vous dépose dans l'éditeur VBA à cette ligne, en mode arrêt, avec chaque variable encore vivante pour que vous puissiez les inspecter — exactement comme un point d'arrêt écrit dans le code :

Sub Investigate()
    Dim total As Double
    total = ComputeTotal()
    Stop                     ' pause ici dans l'editeur ; total est encore lisible
    Range("A1").Value = total
End Sub

Utilisez Stop pendant le débogage et retirez-le avant de livrer (contrairement à un point d'arrêt F9, Stop vit dans le source, si bien qu'un oubli arrêtera la macro d'un utilisateur dans l'éditeur). End termine ; Stop met en pause. Ni l'un ni l'autre ne doit se déclencher dans le code que vos utilisateurs exécutent — pour observer une macro en cours sans l'arrêter, voyez VBA Debug.Print.

Quand End est-il un jour le bon choix ?

Rarement, et toujours de façon délibérée. Les cas d'usage honnêtes sont étroits : une condition catastrophique et irrécupérable dans un outil autonome où vous préférez tout arrêter plutôt que risquer de continuer avec un état corrompu, ou le démantèlement d'une application pilotée par un UserForm non modal où vous voulez vraiment réinitialiser tout le projet. Même là, préférez atteindre une sortie propre unique — rétablir les réglages d'Application, fermer ce que vous avez ouvert — puis vous arrêter. Dans les macros de tous les jours, la réponse à « comment m'arrêter ici ? » est Exit Sub (quitter cette procédure) ou une restructuration pour que le code atteigne End Sub de lui-même. Si vous tapez le End nu, arrêtez-vous et assurez-vous que vous voulez vraiment dire tout terminer, sauter tout le nettoyage.

Comment ExcelMaster vous aide

Le End nu est un petit mot au rayon de destruction démesuré, et son dégât reste invisible jusqu'à ce qu'un utilisateur signale un Excel « figé » qui n'est en réalité que ScreenUpdating resté coupé. Les erreurs sont d'utiliser End quand vous vouliez Exit Sub, et de laisser un Stop dans du code livré.

ExcelMaster écrit des procédures qui sortent par une unique sortie propre : Exit Sub pour revenir, des lignes de restauration qui s'exécutent toujours, et aucun End ni Stop égaré dans le code que vos utilisateurs touchent. Quand une macro doit se retirer tôt, elle le fait sans laisser Excel à moitié configuré. Vous gardez le classeur et le code.

Questions fréquentes

Que fait l'instruction End en VBA ?

L'instruction End nue termine immédiatement toute la macro. Elle réinitialise toutes les variables (y compris de niveau module et Static), décharge les UserForms ouverts, jette la pile d'appels et efface les gestionnaires On Error — mais elle n'annule pas les changements déjà appliqués au classeur ou à Application, si bien que tout nettoyage que vous aviez prévu est sauté. Pour quitter une procédure sans cela, utilisez Exit Sub.

Quelle est la différence entre End et End Sub ?

End Sub marque simplement où une procédure Sub se termine — c'est un marqueur structurel, et la procédure finirait là de toute façon. Le End nu, écrit seul, termine tout le programme sur-le-champ, où qu'il apparaisse. End Sub ferme un bloc ; End arrête tout.

Devrais-je utiliser End pour arrêter une macro ?

En général non. Pour quitter la procédure courante, utilisez Exit Sub, qui revient à l'appelant et laisse s'exécuter votre nettoyage. Le End nu saute tout nettoyage et peut laisser ScreenUpdating désactivé ou les événements coupés, produisant un Excel qui semble figé. Réservez End aux situations rares, délibérées et irrécupérables.

Quelle est la différence entre End et Stop ?

End termine la macro et efface son état. Stop met l'exécution en pause et vous dépose dans l'éditeur VBA en mode arrêt, toutes les variables encore vivantes, pour que vous puissiez déboguer — comme un point d'arrêt écrit dans le code. Retirez Stop avant de livrer, car contrairement à un point d'arrêt F9 il vit dans le source et arrêtera la macro d'un utilisateur.

Pourquoi ScreenUpdating est-il encore désactivé après l'exécution de ma macro ?

Le plus probable : un End nu (ou une erreur non gérée) a arrêté la macro avant la ligne qui remet Application.ScreenUpdating = True. Comme End saute le code restant, la restauration ne s'est jamais exécutée. Remplacez End par Exit Sub et placez vos lignes de restauration sur un chemin de sortie unique ou dans un gestionnaire d'erreurs pour qu'elles s'exécutent toujours.

Testé dans

Testé dans : Excel 365 (Windows 11), VBA 7.1 — vérifié le 24/09/2026.

Guides associés : VBA Exit For · VBA GoTo · VBA On Error · VBA Debug.Print · VBA Sub