VBA On Error dans Excel — Resume Next vs GoTo & pourquoi les macros cachent les bugs

Testé sur : Excel 365 v2509 · Excel 2021 · Excel 2019 · dernière vérification le 08/06/2026

En bref — On Error décide ce que fait votre macro après une erreur d'exécution : par défaut, elle s'arrête net et jette une boîte de dialogue au visage de l'utilisateur. On Error change cela. Il existe exactement trois formes, et choisir la mauvaise est précisément la façon dont une macro finit par corrompre des données en silence :

Sub TraiterDonnees()
    On Error GoTo Gestionnaire      ' toute erreur ci-dessous saute au gestionnaire
    Dim ws As Worksheet
    Set ws = Sheets("Rapport")      ' si "Rapport" n'existe pas → on saute plus bas
    ws.Range("A1").Value = 100

    Exit Sub                        ' ON S'ARRÊTE ici, sinon on tombe dans le gestionnaire
Gestionnaire:
    MsgBox "Échec de l'étape : " & Err.Description
End Sub

Les trois formes, en un seul bloc :

On Error GoTo Gestionnaire   ' route les erreurs vers un gestionnaire étiqueté — le choix fiable
On Error Resume Next         ' ignore l'erreur, exécute la ligne suivante — dangereux si on oublie
On Error GoTo 0              ' DÉSACTIVE le piégeage — retour à « s'arrêter et afficher la boîte »

Le modèle mental : On Error est un aiguillage pour « où aller quand je plante ? »

Imaginez chaque ligne de votre macro roulant sur une route. Le comportement par défaut quand une ligne heurte une erreur d'exécution — une feuille manquante, un /0, une incompatibilité de type — est de freiner brutalement : l'exécution s'arrête, et Excel affiche la boîte jaune Erreur d'exécution '…' avec Débogage / Fin. Pour vous, à la conception, c'est très bien. Pour un utilisateur qui lance votre outil, c'est un cul-de-sac qu'il ne sait pas lire.

On Error est l'aiguillage qui détourne ce plantage. Il n'empêche pas l'erreur — l'erreur se produit quand même — il décide seulement où va le contrôle ensuite. Ce simple recadrage dissipe l'essentiel de la confusion : vous n'« attrapez » rien au sens de Java ou Python, vous fixez une destination pour le prochain plantage.

L'aiguillage reste positionné pour le reste de la procédure courante (ou jusqu'à ce que vous le repositionniez). Il est propre à chaque procédure — un gestionnaire posé dans TraiterDonnees ne fait rien pour un Sub qu'elle appelle, sauf si ce Sub pose le sien.

La seule règle : `On Error Resume Next` cache les erreurs, il ne les gère pas

Voici la règle qui sépare une macro robuste d'une bombe à retardement :

On Error Resume Next dit à VBA « quoi qu'il vienne de casser, fais comme si de rien n'était et continue. » Il fait taire le symptôme. Il ne corrige pas le problème, et ne l'enregistre même pas.

Employé délibérément, sur une seule ligne dont vous attendez l'échec, c'est parfait. Employé à la légère — un On Error Resume Next en haut d'un Sub, puis oublié — il fait taire chaque bug de la procédure. La macro « marche », écrit des résultats à moitié vides, et personne ne s'en aperçoit pendant un mois.

Le motif honnête, c'est : portée étroite + vérification immédiate + on rééteint :

' On VEUT supprimer une forme qui peut exister ou non.
On Error Resume Next                 ' on l'arme pour exactement une ligne risquée
ActiveSheet.Shapes("AncienLogo").Delete
If Err.Number <> 0 Then Err.Clear    ' on prend acte & on réinitialise — la forme n'était pas là
On Error GoTo 0                      ' ON DÉSARME aussitôt — on cesse d'ignorer les erreurs

Trois choses rendent cela sûr : ça couvre une seule ligne, ça vérifie Err.Number juste après (voir l'objet Err), et ça appelle On Error GoTo 0 pour désarmer. Retirez l'une des trois et vous revenez à cacher des bugs.

Le second piège : oublier `Exit Sub` avant le gestionnaire

Un gestionnaire étiqueté n'est que du code au bas de la procédure. Rien n'empêche le chemin normal d'y entrer tout droit une fois le vrai travail terminé :

Sub EnregistrerRapport()
    On Error GoTo Gestionnaire
    ' ... vrai travail qui réussit ...
    MsgBox "Enregistré !"           ' message de succès
                                    ' ⚠ pas de Exit Sub — l'exécution continue...
Gestionnaire:
    MsgBox "Échec de l'enregistrement."   ' ...et l'utilisateur voit LES DEUX messages
End Sub

Lors d'une exécution réussie, l'utilisateur reçoit « Enregistré ! » et « Échec de l'enregistrement. » La correction tient en une ligne : Exit Sub (ou Exit Function) juste avant l'étiquette du gestionnaire, pour que le chemin normal quitte la procédure avant de pouvoir tomber dedans. C'est l'ossature structurelle décrite dans Gestion des erreurs VBA.

`On Error GoTo 0` — la forme que tout le monde oublie

On Error GoTo 0 rétablit le piégeage d'erreurs au comportement par défaut « s'arrêter et afficher la boîte ». Deux raisons de s'en soucier :

Après un Resume Next délibéré, c'est ainsi que vous cessez d'ignorer les erreurs, pour que le prochain vrai bug ne soit pas avalé.
En développement, c'est ainsi que vous laissez VBA s'interrompre sur la ligne fautive pour cliquer Débogage — au lieu d'un gestionnaire actif qui vous éloigne de la scène du crime.

On Error Resume Next
Set wb = Workbooks("Budget.xlsx")   ' peut-être ouvert, peut-être pas
On Error GoTo 0                     ' à partir d'ici, les erreurs arrêtent de nouveau la macro
If wb Is Nothing Then Set wb = Workbooks.Open("C:\Donnees\Budget.xlsx")

L'avis tranché : un `On Error Resume Next` nu, sans vérification de `Err`, est un bug, pas de la robustesse

On dégaine On Error Resume Next parce que ça fait disparaître la boîte rouge, et « aucun message d'erreur » donne l'impression d'« aucune erreur ». C'est faux. Une macro incapable d'échouer bruyamment est une macro à laquelle on ne peut pas se fier — elle échoue silencieusement dans vos données, c'est tout.

Ma règle de pouce : chaque On Error Resume Next doit avoir une vérification Err.Number correspondante et un On Error GoTo 0 à quelques lignes de là. Si vous ne pouvez pas montrer ces deux compagnons, vous n'avez pas géré l'erreur — vous l'avez enterrée. Pour tout ce qui dépasse l'esquive d'un seul échec attendu, utilisez On Error GoTo Etiquette et un vrai gestionnaire.

Laquelle utiliser, et quand

Vous voulez…	Utilisez	Attention à
Router toutes les erreurs en un point et réagir	`On Error GoTo Gestionnaire`	Mettez `Exit Sub` avant l'étiquette
Sauter une ligne dont vous attendez l'échec	`On Error Resume Next` (étroit)	Vérifiez `Err.Number`, puis `On Error GoTo 0`
Cesser d'ignorer / déboguer sur la vraie ligne	`On Error GoTo 0`	Sans lui, `Resume Next` reste armé
Réessayer la ligne fautive après correction	`Resume` (dans un gestionnaire)	Boucle infinie si la cause n'est pas réglée

Erreurs fréquentes avec On Error (et la correction)

Symptôme	Cause	Correction
La macro tourne mais les résultats sont à moitié vides	`On Error Resume Next` resté actif, avalant de vraies erreurs	Le retirer, ou le cantonner à une ligne + `On Error GoTo 0`
L'utilisateur voit le message de succès et celui d'échec	Pas de `Exit Sub` avant l'étiquette du gestionnaire	Ajouter `Exit Sub` juste avant `Gestionnaire:`
« Étiquette non définie »	`On Error GoTo X` mais aucune étiquette `X:` dans la procédure	Ajouter l'étiquette, ou utiliser `Resume Next` / `GoTo 0`
Le gestionnaire se déclenche mais on ne sait pas ce qui a cassé	On ne lit jamais `Err.Description` / `Err.Number`	Lire l'objet Err dans le gestionnaire
L'erreur arrête encore la macro après l'exécution du gestionnaire	Le gestionnaire a tourné mais n'a fait ni `Resume` ni `Exit`	Décider la sortie : `Resume Next`, `Resume` ou `Exit Sub`

Quand la gestion des erreurs est l'essentiel de votre macro — décrivez plutôt le travail

Remarquez la part d'une macro « simple » qui se transforme en plomberie : armer le gestionnaire, vérifier Err, désarmer, nettoyer, décider si l'on reprend. Sur un vrai pipeline — importer trois fichiers, rapprocher sur l'ID de commande, signaler les écarts — l'échafaudage d'erreurs peut peser plus lourd que la logique qui vous importe vraiment. ExcelMaster Agent vous laisse énoncer ce travail en français courant et génère du Python qui gère déjà les échecs et sauvegarde d'abord votre fichier — sans On Error, sans Resume, sans corruption silencieuse de vos données. Essayer gratuitement →

Guides liés

FAQ

Que fait On Error en VBA ? On Error fixe ce qui se passe lorsqu'une erreur d'exécution survient dans la procédure courante. Au lieu du comportement par défaut (s'arrêter et afficher la boîte Erreur d'exécution), vous pouvez router l'erreur vers un gestionnaire (On Error GoTo Etiquette), sauter la ligne fautive (On Error Resume Next), ou rétablir le comportement par défaut (On Error GoTo 0).

On Error Resume Next est-il une mauvaise pratique ? Pas en soi — mais seulement cantonné à une seule ligne dont vous attendez l'échec, suivi d'une vérification de Err.Number et d'un On Error GoTo 0. Laissé actif sur toute une procédure, il fait taire chaque erreur, ce qui cache les bugs et corrompt les résultats en silence. Pour la gestion générale, préférez On Error GoTo Etiquette.

Quelle différence entre On Error GoTo 0 et On Error Resume Next ? On Error Resume Next ignore les erreurs et continue à la ligne suivante. On Error GoTo 0 fait l'inverse — il désactive le piégeage d'erreurs, de sorte que la prochaine erreur arrête la macro et réaffiche la boîte. On emploie typiquement GoTo 0 pour désarmer un bloc Resume Next.

Comment désactiver la gestion des erreurs en VBA ? Utilisez On Error GoTo 0. Il efface tout réglage On Error Resume Next ou On Error GoTo Etiquette actif dans la procédure courante et rétablit le comportement par défaut de VBA : s'arrêter sur erreur.

On Error fonctionne-t-il à travers les procédures appelées ? Non. On Error est propre à chaque procédure. Si A pose un gestionnaire et appelle B, une erreur dans B n'est pas attrapée par le gestionnaire de A, sauf si B n'a pas le sien — auquel cas l'erreur remonte jusqu'à A. Chaque procédure qui doit gérer ses erreurs doit poser le sien.